mu-impl-fast issueshttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues2017-10-09T16:28:58+11:00https://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/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/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 Linhttps://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/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/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/33Rework on pin/unpin2017-07-19T15:02:01+10:00Yi LinRework on pin/unpinCurrent `PIN`/`UNPIN` directly get translated into a runtime call into GC to pin/unpin the object, which simply push/remove the object reference to/from a root set (synchronisation required). This is inefficient, and also the behaviour i...Current `PIN`/`UNPIN` directly get translated into a runtime call into GC to pin/unpin the object, which simply push/remove the object reference to/from a root set (synchronisation required). This is inefficient, and also the behaviour is different from the spec (in which you need unpin operations to match every pin operation).
This will need rework, probably along with #12 .
And it is also related with https://gitlab.anu.edu.au/mu/mu-spec/issues/7, which proposes to separate immovability and immortal semantics of `PIN` instruction.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/32Calling function defined in another bundle does not work2017-06-07T00:22:48+10:00Isaac Garianoisaac@ecs.vuw.ac.nzCalling function defined in another bundle does not workI am trying to define a function in one bundle, and call it another, and i'm getting an error:
Heres an example that will reproduce the problem:
file argc_exit.uir:
```
.funcsig @exit_sig = (int<32>) -> ()
.funcdef @argc.exit <@...I am trying to define a function in one bundle, and call it another, and i'm getting an error:
Heres an example that will reproduce the problem:
file argc_exit.uir:
```
.funcsig @exit_sig = (int<32>) -> ()
.funcdef @argc.exit <@exit_sig>
{
%entry(<int<32>>%arg):
CCALL #DEFAULT <ufuncptr<@exit_sig> @exit_sig> <ufuncptr<@exit_sig>>EXTERN "exit"(%arg)
RET
}
```
file argc_inline.uir:
```
.typedef %char = int<8>
.funcdef @my_main <(int<32> uptr<uptr<%char>>)->(int<32>)> VERSION @my_main_v1
{
%entry(<int<32>>%argc <uptr<uptr<%char>>>%argv):
CALL <(int<32>)->()> @argc.exit (%argc)
RET <int<32>>1
}
```
Then using my mu-tool-compiler:
`./muc -r -f my_main argc_exit.uir argc_inline.uir emit/argc`
(use -c if you wan't to see the API calls it uses).
`thread '<unnamed>' panicked at 'Operand 1013' is neither a local var or a global var', src/vm/api/api_impl/muirbuilder.rs:1290 stack backtrace:`
(the symbol with Id 1013 is @argc.exit).
I tracked the error down and it appears to be comming from the function `get_treenode` in (src\vm\api\api_impl\muirbuilder.rs).
My guess is the API implementation only looks for things defined in the current bundle and not other bundles.
However from my understanding of the Mu-spec you should be able to refer to entities declared in previously loaded bundles.
A workaround is to combine both files into the same bundle such as with `./muc -r -f my_main <(cat argc_exit.uir && cat argc_inline.uir) emit/argc`.Kunshan WangKunshan Wanghttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/22[x86_64] Status flags undefined for mul/div/idiv2017-06-29T12:53:30+10:00Yi Lin[x86_64] Status flags undefined for mul/div/idivThe following table summerizes how Mu integer binops are mapped to x86_64 insts, and how x86_64 insts affect status flags.
| Mu IR | X86_64 Inst | #N (signed) | #Z (zero) | #C (carry) | #V (overflow) |
|:-----: |:-----------: ...The following table summerizes how Mu integer binops are mapped to x86_64 insts, and how x86_64 insts affect status flags.
| Mu IR | X86_64 Inst | #N (signed) | #Z (zero) | #C (carry) | #V (overflow) |
|:-----: |:-----------: |:-----------: |:---------: |:----------: |:-------------: |
| ADD | add | ✓ | ✓ | ✓ | ✓ |
| SUB | sub | ✓ | ✓ | ✓ | ✓ |
| AND | and | ✓ | ✓ | - | - |
| OR | or | ✓ | ✓ | - | - |
| XOR | xor | ✓ | ✓ | - | - |
| MUL | mul | ✗ | ✗ | ✓ | ✓ |
| UDIV | div | ✗ | ✗ | - | - |
| SDIV | idiv | ✗ | ✗ | - | - |
| UREM | div | ✗ | ✗ | - | - |
| SREM | idiv | ✗ | ✗ | - | - |
| SHL | shl | ✓ | ✓ | - | - |
| LSHR | shr | ✓ | ✓ | - | - |
| ASHR | sar | ✓ | ✓ | - | - |
`mul`, `div` and `idiv` generate undefined signed flag (#N), and zero flag(#Z). We will need to generate extra code to check, and set those flags.https://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/20[x86_64] int<1> arithmetics return wrong result2017-05-01T15:36:35+10:00Yi Lin[x86_64] int<1> arithmetics return wrong resultCurrently Zebu treats int<1> the same as int<8>. This is fine if the client only uses int<1> as boolean. If the client uses int<1> arithmetic operations, Zebu returns wrong result.
We should either explicitly forbid int<1> arithmetic...Currently Zebu treats int<1> the same as int<8>. This is fine if the client only uses int<1> as boolean. If the client uses int<1> arithmetic operations, Zebu returns wrong result.
We should either explicitly forbid int<1> arithmetics or implement it.