mu-impl-fast issueshttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues2019-04-09T16:39:56+10:00https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/48Set user-defined thread local when launching boot image2019-04-09T16:39:56+10:00Yi LinSet user-defined thread local when launching boot imageCurrently Zebu assumes no user-defined thread local due to the fact that at the time the code was written, we cannot persist heap objects.
However, there is no reason preventing us implementing this now. Currently Zebu assumes no user-defined thread local due to the fact that at the time the code was written, we cannot persist heap objects.
However, there is no reason preventing us implementing this now. Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/49Stack guarded page may not be able to detect overflow/underflow if frame size...2018-09-10T06:31:06+10:00Yi LinStack guarded page may not be able to detect overflow/underflow if frame size is larger than page size.Currently we are guarding (write/read protect) the two pages above and below stack memory so if any write/read occurs for the pages we will know a overflow/underflow happens. However if a frame size is larger than the guarded page size (...Currently we are guarding (write/read protect) the two pages above and below stack memory so if any write/read occurs for the pages we will know a overflow/underflow happens. However if a frame size is larger than the guarded page size (e.g. `ALLOCA` a large piece of stack memory, but never access it), it is possible that we totally skip the guarded page, and cause the stack keeps growing beyond the guarded boundary.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/50Capture stack overflow/underflow signal2018-09-10T06:31:05+10:00Yi LinCapture stack overflow/underflow signalWe are guarding pages above and below the Mu stack, thus an overflow/underflow would trigger a write/read protection. We should register handling to catch the signal, and identify its cause (overflow/underflow or other segfaults).We are guarding pages above and below the Mu stack, thus an overflow/underflow would trigger a write/read protection. We should register handling to catch the signal, and identify its cause (overflow/underflow or other segfaults).https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/51Memory order in store/load API calls2018-09-10T06:31:05+10:00Yi LinMemory order in store/load API callsFor API calls `load()`/`store()`, they take memory order as an argument. However I am uncertain whether we need to do anything special for different memory orders. Current implementation just does a plain load/store in `vm.handle_load()`...For API calls `load()`/`store()`, they take memory order as an argument. However I am uncertain whether we need to do anything special for different memory orders. Current implementation just does a plain load/store in `vm.handle_load()` and `vm.handle_store()`.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/52Use make_boot_image() for all Zebu tests2018-09-10T06:31:05+10:00Yi LinUse make_boot_image() for all Zebu testsDue to the fact that we didn't have `make_boot_image()` in early development, currently the tests are written in different ways for code generation and linking:
1. use `compile_to_sharedlib()` (as exposed in API, but not in the Mu spec) ...Due to the fact that we didn't have `make_boot_image()` in early development, currently the tests are written in different ways for code generation and linking:
1. use `compile_to_sharedlib()` (as exposed in API, but not in the Mu spec) to link generated code to a dynamic library
1. use `make_boot_image()` (as exposed in API) to link generated code to an executable
1. use `compile_fnc()` to link generated code to a dynamic library for *cargo tests*
1. manually compile code, persist vm, and link for *cargo tests*
Currently 1 and 2 are internally using `make_boot_image()`. But others are not.
Since `make_boot_image()` in Zebu allows generating dynamic library or executable (depends on output file name), we can make all the test use `make_boot_image()`. This will make the linking for all tests unified, and make it easy to make changes.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/58[x86-64] Alias don't seam to override previous ones2018-09-10T06:31:05+10:00Isaac Garianoisaac@ecs.vuw.ac.nz[x86-64] Alias don't seam to override previous onesThe pytest `test_heap.py::test_preserve_ref_field` succeeds when run on it's own, but fails when run as a group (e.g. with `pytest test_heap.py`), I looked at the generated code and it's functionally identical in both cases.
All three te...The pytest `test_heap.py::test_preserve_ref_field` succeeds when run on it's own, but fails when run as a group (e.g. with `pytest test_heap.py`), I looked at the generated code and it's functionally identical in both cases.
All three tests in `test_heap.py` creat functions called `test_fnc` and global cells called `gcl`, it then loads the generated shared libraries. The first two tests are supposed to return the number 42, the last one is supposed to return 298, but actually returns 42, as such I think it's quite possible when loading a shared library with an alias defined, it doesn't properly override the previous alias.
I am defining aliases using `.equiv`, like so:
```
.globl __mu_gcl
__mu_gcl:
.globl gcl
.equiv gcl, __mu_gcl
```
And the same with `test_func`.
I could try and replace the aliases with labels, but then the function would have two names, and may cause problems if we try and resolve an address to a name (which we don't currently do, except for native functions in back trace printing).
Perhaps I could use another directive (like `.set`, or `.eqv`, but the docs say their the same).Isaac Garianoisaac@ecs.vuw.ac.nzIsaac Garianoisaac@ecs.vuw.ac.nzhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/60[aarch64] Unimplemented Backend Features2018-09-10T06:31:05+10:00Isaac Garianoisaac@ecs.vuw.ac.nz[aarch64] Unimplemented Backend FeaturesI noticed there are lots of things that zebu doesn't implement, so I decided to make a list, and will try and keep it up to do (I would like to implement stuff here specifically the mu specific things like traps, watch points, threads an...I noticed there are lots of things that zebu doesn't implement, so I decided to make a list, and will try and keep it up to do (I would like to implement stuff here specifically the mu specific things like traps, watch points, threads and stack related things, as I feel currently Zebu is mostly just LLVM with exceptions and a garbage collector that doesn't collect..)
I'm not entirely sure what the x86-64 backend implements, so i've only listed things for aarch64: (note features with a * next to them haven't been tested properly yet), I have also included things I believe are not implemented on x86-64 but are on aarch64:
Types:
* [ ] `int<n>`:
* [x] n = 1 (some arithmetic)
* [x] * n <= 64 and n != 8, 16, 32, or 64
* [x] * n = 128, floating point conversions
* [ ] n > 64 and n != 128
* [ ] `struct` SSA variables
* [ ] `hybrid` SSA variables
* [ ] `array` SSA variables
* [x] `tagref64`
* [x] `threadref`
* [x] `stackref``
* [ ] `framecursorref`
* [ ] `irbuilderref`
* [ ] `vector<t n>`
Instruction Clauses:
* [ ] keep Alive Clauses
* [ ] Exception clauses
* [x] CALL
* [ ] binop (divison by zero)
* [ ] NEW/NEYHYBRID (allocation failure)
* [ ] LOAD/STORE/CMPXCHG (null referenced)
* [ ] CCALL (implementation defined)
Instructions:
* [ ] `TAILCALL`:
* [x] When the callee's stack argument size is less than or equal to the caller's
* [ ] When the callee's stack argument size is greater than the caller's
* [ ] For unimplemented types:
* [ ] `EXTRACTVALUE`/`INSERTVALUE`
* [ ] `EXTRACTELEMENT`/`INSERTELEMENT`
* [ ] `SHUFFLEVECTOR`
* [ ] Memory
* [x] `ALLOCA`/`ALLOCAHYBRID`
* [x] * `CMPXCHG`
* [x] * `FENCE`
* [ ] `ATOMICRMW`
* [ ] Traps/watchpoints
* [ ] `TRAP`
* [ ] `WATCHPOINT`
* [ ] `WPBRANCH`
* [x] Thread/stack instructions
* [x] `NEWTHREAD`
* [x] `SWAPTSTACK`
Common Instructions
* [x] thread and stack things:
* [x] new_stack
* [x] kill_stack
* [x] thread_exit
* [x] current_stack
* [x] set_threadlocal
* [x] get_threadlocal
* [x] tr64.*
* [ ] futex.*
* [ ] kill_dependency
* [ ] native.* (except nativ.pin and nativ.unpnin)
* [ ] meta.*
* [ ] irbuilder.*https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/93Issues before enabling GC2017-11-21T14:37:55+11:00Yi LinIssues before enabling GCThe GC rewrite should have fixed most of the problems, however, there are a few known issues that need to be done before enabling GC.
* https://gitlab.anu.edu.au/mu/mu-impl-fast/issues/21 about some utility functions in C that help f...The GC rewrite should have fixed most of the problems, however, there are a few known issues that need to be done before enabling GC.
* https://gitlab.anu.edu.au/mu/mu-impl-fast/issues/21 about some utility functions in C that help find references in stack/heap. They need to be fixed for correctness. And also `set_low_water_mark()` should be called by the VM to set a limit for stack scanning. Alternatively we may also let GC know about stack bounds so it won't go beyond the stack memory.
* inserting yieldpoint.
* Allowing finding base reference for internal references. As we have 16 bytes min size and 16 bytes min alignment of objects, for any reference we mask it to 16 bytes, and see if it contains a valid object encoding (non-empty, or with certain bits set).https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/6IR rewrite pass before instruction selection2017-11-21T13:50:53+11:00Yi LinIR rewrite pass before instruction selectionSome instructions such as `NEW` will be expanded into a sequence of code (may involve new blocks), and some instructions such as `THREADEXIT` will be expanded into a CCall into runtime service functions. Currently this is done at instruc...Some instructions such as `NEW` will be expanded into a sequence of code (may involve new blocks), and some instructions such as `THREADEXIT` will be expanded into a CCall into runtime service functions. Currently this is done at instruction selection pass, by directly expanding such instructions into machine code. Alternatively, a better choice is to rewrite/expand such instructions into Mu IR before instruction selection. Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/21GC related C functions return inaccurate result2017-11-21T13:46:42+11:00Yi LinGC related C functions return inaccurate result`gc/src/heap/gc/clib_x64.c` contains C functions for GC, such as `get_registers()`, which contains inline assembly to save all values in general purpose registers into an array. However C compilers may generate code that changes the regi...`gc/src/heap/gc/clib_x64.c` contains C functions for GC, such as `get_registers()`, which contains inline assembly to save all values in general purpose registers into an array. However C compilers may generate code that changes the registers before saving.
We may want to rewrite the function in assembly instead of C. And I believe it is reasonable that we want to eliminate all C functions in the code base and replace them with assembly (all C functions are pretty simple). Ideally we want only Rust code and assembly in the code base.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/90Register allocation with special registers2017-10-19T15:11:10+11:00Yi LinRegister allocation with special registersMy register allocator currently deals with special registers in the following way:
1. special registers are not `usable`, thus it cannot be assigned to a temporary.
1. coalescing will not combine special registers with temporaries (even ...My register allocator currently deals with special registers in the following way:
1. special registers are not `usable`, thus it cannot be assigned to a temporary.
1. coalescing will not combine special registers with temporaries (even if it is safe and optimal to do so)
We can make this cleaner by manipulating interferences with special registers, and let register allocator make the decision:
* make special registers alive at function exit, so it conflicts with all other temporaries, and register allocator won't assign it to any of the temporaries. But coalescing may combine temporaries with special registers if possible.
* to prevent coalescing in some cases, such as
```
mov SP -> t
add t, 8 -> t
```
we cannot coalesce SP with t. Otherwise changing t will also change the stack pointer. For a general case,
```
OP t, v -> u
```
if t cannot be coalesced with special register S, the instruction selector can generate code
```
mov t -> t0 (with def S)
OP t0, v -> u
```
this will add an interference edge between t0 and S, and prevent the coalescing.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/67[x86_64] JIT backend2017-10-09T17:34:52+11:00Yi Lin[x86_64] JIT backendI will probably be working on a JIT backend for x86_64. Currently I am considering using Intel XED (https://intelxed.github.io/), which is a C library from Intel under Apache 2.0 license for encoding x86/x86_64 instructions. This tool (h...I will probably be working on a JIT backend for x86_64. Currently I am considering using Intel XED (https://intelxed.github.io/), which is a C library from Intel under Apache 2.0 license for encoding x86/x86_64 instructions. This tool (https://github.com/servo/rust-bindgen) can generate Rust bindings from C/C++ headers, with which I can easily use the library in our implementation.
As I implement the JIT backend, I expect a lot of changes to the existing code (as we switch from AOT focus to adapt both). So I suggest we postpone the JIT backend for aarch64 for a while until I have reached some milestones for x86_64, such as
* JIT compile an add function
* JIT compile a function that contains a loop
* JIT compile a function that contains a call
* JIT compile a function that uses VM runtime
Whether doing JIT or AOT is a build-time option for Zebu. Please let me know if you think this is problematic.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/89fannkuchredux slowdown after commit de9d31255831eb89299d93960a3c7a4de514f3a82017-10-09T16:28:58+11:00Yi Linfannkuchredux slowdown after commit de9d31255831eb89299d93960a3c7a4de514f3a8de9d31255831eb89299d93960a3c7a4de514f3a8 corrected the logic in x86 backend to decide whether an integer constant is a valid x86 immediate number (32 bits). It is intended to allow more constants as x86 immediate numbers. However, on mub...de9d31255831eb89299d93960a3c7a4de514f3a8 corrected the logic in x86 backend to decide whether an integer constant is a valid x86 immediate number (32 bits). It is intended to allow more constants as x86 immediate numbers. However, on mubench (http://squirrel.anu.edu.au/mubench/) it shows a slowdown for fannkuchredux after the commit. I need to investigate into this.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/88Known issues with PyPy-zebu2017-10-05T13:10:05+11:00Isaac Garianoisaac@ecs.vuw.ac.nzKnown issues with PyPy-zebuTheir are several bugs I have noticed when running pypy-zebu: (unless otherwise specified I have confirmed the errors for both architectures, I have also confirmed that these errors don't occur with the normal pypy):
1. Pypy in intera...Their are several bugs I have noticed when running pypy-zebu: (unless otherwise specified I have confirmed the errors for both architectures, I have also confirmed that these errors don't occur with the normal pypy):
1. Pypy in interactive mode (but not when reading from a file) segfaults when their is a syntax error:
```
$ echo '.' | pypy-zebu -i
Python 2.7.12 (e8da6780d84e, Oct 04 2017, 01:16:24)
[PyPy 5.6.0 with Mu] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> Segmentation fault (core dumped)
```
LLDB reports:
```
* thread #2, name = 'Mu Thread #7595', stop reason = signal SIGSEGV: invalid address (fault address: 0x20)
frame #0: 0x0000000000f1a2b2 pypy-zebu`__mu_W_SyntaxError_descr_repr_0Zdblk15ZdZa821942Zccallsite_26
pypy-zebu`__mu_W_SyntaxError_descr_repr_0Zdblk15ZdZa821942Zccallsite_26:
-> 0xf1a2b2 <+0>: movq 0x20(%rax), %rax
0xf1a2b6 <+4>: movq 0x28(%rax), %rdi
```
1. Pypy only reads the first commandline argument, e.g. pypy-zebu <(echo 'print "hello"')' prints 'hello', but 'pypy-zebu -v <(echo 'print "hello"')' dosn't (it can bee seen that the argument is not considered their at all:
```
pypy-zebu -c pass
Argument expected for the '-c' option
usage: /home/isaacg/mu-client-pypy/pypy/bin/pypy-zebu [options]
Try `/home/isaacg/mu-client-pypy/pypy/bin/pypy-zebu -h` for more information.
```
As well as
```
$ echo 'import sys; print sys.argv[1]' | pypy-zebu - 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IndexError: list index out of range
```
1. Pybench segfaults (when it dosn't run out of gc space) (e.g. `MU_IMMIX_SPACE=40000000000 pypy-zebu pybench.py`), lldb reports:
```
* thread #2, name = 'Mu Thread #7595', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
frame #0: 0x0000000001002cf1 pypy-zebu`__mu_descr_file_fdopen_0_v1Zcepilogue + 24
pypy-zebu`__mu_descr_file_fdopen_0_v1Zcepilogue:
-> 0x1002cf1 <+24>: retq
```
EDIT: On aarch64 GDB reports:
```
Thread 2 "Mu Thread #9020" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xfffb509db030 (LWP 31518)]
0x0000000000000000 in ?? ()
```
or
```
Thread 2 "Mu Thread #9020" received signal SIGBUS, Bus error.
[Switching to Thread 0xfffb509db030 (LWP 31535)]
0x005f5f7472617473 in ?? ()
```
2. `help()` throws a `ValueError`:
```
$ MU_IMMIX_SPACE=40000000000 pypy-zebu
Python 2.7.12 (e8da6780d84e, Oct 04 2017, 01:16:24)
[PyPy 5.6.0 with Mu] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> help()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/isaacg/mu-client-pypy/lib-python/2.7/site.py", line 472, in __call__
import pydoc
File "/home/isaacg/mu-client-pypy/lib-python/2.7/pydoc.py", line 56, in <module>
import sys, imp, os, re, types, inspect, __builtin__, pkgutil, warnings
File "/home/isaacg/mu-client-pypy/lib-python/2.7/inspect.py", line 39, in <module>
import tokenize
File "/home/isaacg/mu-client-pypy/lib-python/2.7/tokenize.py", line 103, in <module>
re.compile, (Token, PseudoToken, Single3, Double3))
File "/home/isaacg/mu-client-pypy/lib-python/2.7/re.py", line 194, in compile
return _compile(pattern, flags)
File "/home/isaacg/mu-client-pypy/lib-python/2.7/re.py", line 249, in _compile
p = sre_compile.compile(pattern, flags)
File "/home/isaacg/mu-client-pypy/lib-python/2.7/sre_compile.py", line 595, in compile
groupindex, indexgroup
ValueError: cannot convert negative integer to unsigned
>>>>
```
3. (aarch64 only) when it runs out of memory and panics, it segfaults:
```
$ MU_IMMIX_SPACE=1 pypy-zebu
thread 'Mu Thread #9020349' panicked at 'Triggering GC when GC is disabled', /home/isaacg/mu-impl-fast-git/src/gc/src/heap/gc/mod.rs:259:8
Segmentation fault (core dumped)
```
GDB reports:
```
Thread 2 "Mu Thread #9020" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xffffb1b31030 (LWP 2811)]
0x0000ffffb75909e0 in ?? () from /lib/aarch64-linux-gnu/libgcc_s.so.1
(gdb) bt
#0 0x0000ffffb75909e0 in ?? () from /lib/aarch64-linux-gnu/libgcc_s.so.1
#1 0x0000ffffb7591234 in _Unwind_Backtrace () from /lib/aarch64-linux-gnu/libgcc_s.so.1
#2 0x0000ffffb7c274d8 in std::sys::imp::backtrace::tracing::imp::unwind_backtrace () at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
#3 0x0000ffffb7c22678 in std::sys_common::backtrace::_print () at /checkout/src/libstd/sys_common/backtrace.rs:71
#4 0x0000ffffb7c32d58 in std::sys_common::backtrace::print () at /checkout/src/libstd/sys_common/backtrace.rs:60
#5 std::panicking::default_hook::{{closure}} () at /checkout/src/libstd/panicking.rs:380
#6 0x0000ffffb7c32968 in std::panicking::default_hook () at /checkout/src/libstd/panicking.rs:396
#7 0x0000ffffb7c33270 in std::panicking::rust_panic_with_hook () at /checkout/src/libstd/panicking.rs:611
#8 0x0000ffffb7a2994c in std::panicking::begin_panic_new::h91c15d79ddd4536b () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#9 0x0000ffffb7a3811c in mu_gc::heap::gc::sync_barrier::hebcd16541e55b150 () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#10 0x0000ffffb7a3466c in mu_gc::heap::immix::immix_mutator::ImmixMutatorLocal::yieldpoint_slow::h9cccb390ce79aedf () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#11 0x0000ffffb7a34888 in mu_gc::heap::immix::immix_mutator::ImmixMutatorLocal::alloc_from_global::h102601e3553ebff9 () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#12 0x0000ffffb7a407f4 in muentry_alloc_fast () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#13 0x0000000000cdc6e8 in pypy_mu_main_0 ()
#14 0x0000000000cdc69c in entry_point_0 ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
```
1. pypy is allocating zero sized object with Zebu. This does not seem correct. The only zero sized type in Mu is `void`. Either the client is allocating `void` object, or there is a bug somewhere. https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/86Issue with rodal on macOS when dynamically linking with boot image2017-09-22T11:10:22+10:00Yi LinIssue with rodal on macOS when dynamically linking with boot imageI am not sure if I fully understood the problem. Isaac @igariano01 may explain more on this.
Generally the issue is that rodal needs to redefine `malloc()` and `free()` that Rust uses to manage heap memory. Those are weak symbols, so r...I am not sure if I fully understood the problem. Isaac @igariano01 may explain more on this.
Generally the issue is that rodal needs to redefine `malloc()` and `free()` that Rust uses to manage heap memory. Those are weak symbols, so rodal redefines them. Thus if an object is dumped by rodal, it cannot be freed by the default `free()`, instead it is freed by rodal.
However on macOS, Rust uses a different allocator when generating dynamic libraries instead of using `malloc()`/`free()`, and those cannot be redefined. Thus when we link to mu as a dynamic library, rodal cannot redefine the `free()` function. However, there seems no issue when linking to mu a as static library.
One solution that seems very hacky is to disable dynamic link with mu in boot image generation. Branch https://gitlab.anu.edu.au/mu/mu-impl-fast/tree/static-link-for-macos has the fix.
The other solution is to use Rust's nightly feature to provide a custom allocator (rodal will implement a custom allocator along with deallocation). Branch https://gitlab.anu.edu.au/mu/mu-impl-fast/tree/global_allocator has a fix. This is a more elegant approach. But my only concern is that this requires us to use nightly Rust. I am concerned the language implementation itself is more buggy in a nightly version, and we will meet problems when debugging (e.g. whether it is our bug, or their bug). And if we switch to nightly Rust, it is very likely that we will start using more nightly features, and we will not be able to go back to stable Rust in the future.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/85DYLD_LIBRARY_PATH dependent tests fails on macOS with SIP enabled2017-09-19T15:39:44+10:00Zixian CaiDYLD_LIBRARY_PATH dependent tests fails on macOS with SIP enabledhttps://groups.google.com/forum/#!topic/caffe-users/waugt62RQMU
https://github.com/oracle/node-oracledb/issues/231
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathD...https://groups.google.com/forum/#!topic/caffe-users/waugt62RQMU
https://github.com/oracle/node-oracledb/issues/231
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html
We should encode these differentlyhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/42Exception handling for native frames2017-09-09T14:19:11+10:00Yi LinException handling for native framesCurrent implementation will fail for being unable to find information about native frames.Current implementation will fail for being unable to find information about native frames.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/61Inline functions with TAILLCALL's2017-09-09T02:33:04+10:00Isaac Garianoisaac@ecs.vuw.ac.nzInline functions with TAILLCALL'sInlining a function with a tailcall like any other function will break the tailcall (as it will cause the function calling the inlined function to return, and not the inlined function), we could however easily inline such a function acco...Inlining a function with a tailcall like any other function will break the tailcall (as it will cause the function calling the inlined function to return, and not the inlined function), we could however easily inline such a function according to the following rules:
* If the TAILCALL is recursive (i.e. calls the containing function itself) change it to a BRANCH to the Inlined entry block
* Otherwise expand out the tailcall into an equivalent pair of CALL and RET instructions, and inline as normal
In both these cases (assuming the function is otherwise suitable to inline), inlining should be more efficient than calling the function that tailcalls.
However inlining functions (with or without tailcalls) may break OSR which seems to expect every function call to have it's own frame (except tailcalls replace the CALLER's frame).https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/73Signal handler for Zebu2017-08-05T00:16:06+10:00Yi LinSignal handler for ZebuThis issue tracks what signal we need to be able to identify for Zebu:
* stack overflow/underflow (access to protected guard page)
* `INT3` code patching trap
There are a few rust crates that abstracts over signal handling on Unix, we m...This issue tracks what signal we need to be able to identify for Zebu:
* stack overflow/underflow (access to protected guard page)
* `INT3` code patching trap
There are a few rust crates that abstracts over signal handling on Unix, we may consider using them instead of doing it in a C/FFI approach:
* [chan-signal](https://github.com/BurntSushi/chan-signal)
* [signal](https://github.com/tailhook/signal)
* [rust simple signal](https://github.com/swizard0/rust-simple-signal)Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/72[x86_64] code patching atomicity2017-08-04T17:48:08+10:00Yi Lin[x86_64] code patching atomicityCommit a49d8ab64c2e4e30ddeaf036c74d45fa01fb701b added a naive code patching mechanism to the JIT compiler - it simply rewrites the code array. This is problematic as it leaves the instruction in an incoherent state before the instruction...Commit a49d8ab64c2e4e30ddeaf036c74d45fa01fb701b added a naive code patching mechanism to the JIT compiler - it simply rewrites the code array. This is problematic as it leaves the instruction in an incoherent state before the instruction is completely overwritten.
One solution to this is to patch the first byte as `INT3`. The compiler then patches the rest bytes before it patches the first byte into expected instruction. If the patching is happening, and the instruction gets executed, it triggers a `INT3` trap, and the execution will trap into signal handler with `SIGSEGV`. The signal handler will check if current instruction is `INT3`(`0xCD`); if so, it sets back the program counter, and re-execute the instruction. Thus the execution will not proceed unless the patching is finished.
Once I start implementing a signal handler for Zebu, I will implement this.Yi LinYi Lin