mu issueshttps://gitlab.anu.edu.au/groups/mu/-/issues2019-07-24T02:44:33+10:00https://gitlab.anu.edu.au/mu/mu-spec/-/issues/20Change common instructions to intrinsics2019-07-24T02:44:33+10:00Javad Ebrahimian Amirijavad.amiri@anu.edu.auChange common instructions to intrinsicsCommon instructions should be changed to intrinsics in the spec, because ”common” instructions are extremely rare.Common instructions should be changed to intrinsics in the spec, because ”common” instructions are extremely rare.https://gitlab.anu.edu.au/mu/rodal/-/issues/1HashMap2019-08-06T10:08:46+10:00Javad Ebrahimian Amirijavad.amiri@anu.edu.auHashMapThe implementation of `std::collections::HashMap` has completely changed since rust-1.36.
Currently, rodal only works with rust versions 1.28 to 1.35.
To make it work on 1.36+ needs changing how rodal handles std library's `HashMap`s.The implementation of `std::collections::HashMap` has completely changed since rust-1.36.
Currently, rodal only works with rust versions 1.28 to 1.35.
To make it work on 1.36+ needs changing how rodal handles std library's `HashMap`s.https://gitlab.anu.edu.au/mu/mu-spec/-/issues/22Redefine the API in XML (or another high-level language)2019-07-24T02:44:34+10:00Kunshan WangRedefine the API in XML (or another high-level language)As @U60333591 Javad suggested fixing the terminologies (https://gitlab.anu.edu.au/mu/mu-spec/issues/20, https://gitlab.anu.edu.au/mu/mu-spec/issues/21), I suggest fixing the scripts that manages the API headers and the intrinsics documen...As @U60333591 Javad suggested fixing the terminologies (https://gitlab.anu.edu.au/mu/mu-spec/issues/20, https://gitlab.anu.edu.au/mu/mu-spec/issues/21), I suggest fixing the scripts that manages the API headers and the intrinsics documentation, too.
There is a directory `https://gitlab.anu.edu.au/mu/mu-spec/tree/master/scripts` that contains some scripts. In the past, every time I modified intrinsics (still called CommInsts at that moment), I called the `synchronise_everything.sh` script to make things consistent.
- `synchronise_everything.sh`: This executes the following scripts.
- `muapi-irbuilder-to-comminsts.py`: This parses the `muapi.h` header file, finds the IR builder API part, and generates the corresponding intrinsics (CommInsts) in the `common-insts.rst` document. The purpose is that *all API functions should be available as intrinsics (CommInsts)*, with differences if appropriate.
- `comminsts-to-muapi.py`: It parses the `common-insts.rst` file, grep the comminst definitions, and generate the corresponding definitions in the `muapi.h` header.
You see, it is quite dirty. I have to parse the embedded code in the `.rst` documents as well as the `.h` header, and inject contents into each other. In fact, this is my least favourite part of the spec.
I have long been thinking that it should be done differently.
- **The API should be defined in a more machine-readable format**, such as XML, and
- **the API should be defined in a higher-level type system**, not C, but can be easily mapped to C, Java, or other high-level languages and generate bindings accordingly.
For example, here is an API function that creates a new thread on an unbound stack, and resumes the stack normally:
```c
MuThreadRefValue (*new_thread_nor)(MuCtx *ctx, MuStackRefValue stack,
MuRefValue threadlocal,
MuValue *vals, MuArraySize nvals); /// MUAPIPARSER threadlocal:optional;vals:array:nvals
```
The `MUAPIPARSER` magic is followed by several other magics that tells the parser that the `threadlocal` parameter is optional, and `vals` is an array, and its length is `nvals`. What it really means, in Java, is:
```java
MuThreadRefValue new_thread_nor(
MuStackRefValue stack,
Optional<MuRefValue> threadlocal,
List<MuValue> vals);
```
Yes. I have been careful to limit what type the API can use, hoping to make it less susceptible to the complexity of the API (such as struct layout). As a result,
- The possible types of parameters and the return value only includes scalar types (including pointers) and lists (as C arrrays), but not structs, and
- If a parameter has pointer type, it may or may not be optional, but it is always documented, and
- If a parameter has list type, it is always required to supply its length in another parameter.
But we cannot express the idea of "optional" and "array with length" in plain C, and those are what the `MUAPIPARSER` magic is for. Using Java is okay since its type system can express those ideas, but it is still difficult to parse. XML should be a better choice.
```xml
<class name="MuCtx">
<method name="new_thread_nor">
<param name="stack" type="MuStackRefValue" />
<param name="threadlocal" type="optional:MuRefValue" />
<param name="vals" type="list:vals" />
<return type="MuThreadRefValue" />
</method>
</class>
```
It should be easy to convert such XML snippet into a C function declaration (perhaps not the other way around).
I am not sure if the documentation should be included as part of the XML, because I still think reStructuredText is more appropriate for documentation.
I don't know how intrinsics should be described. Maybe inline code snippets are still appropriate, because they should be in Mu IR, and should be precisely specified.
I think most Mu-related projects are not as active as a few years ago, so it should be safe to fix the implementations, too, without worrying about getting in the way of other contributors.https://gitlab.anu.edu.au/mu/mu-spec/-/issues/21Change global memory to static memory2019-07-24T02:43:20+10:00Javad Ebrahimian Amirijavad.amiri@anu.edu.auChange global memory to static memoryThis should be done because the heap is also globalThis should be done because the heap is also globalhttps://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-perf-benchmarks/-/issues/22Size of quicksort micro benchmark2017-11-21T09:39:55+11:00Zixian CaiSize of quicksort micro benchmarkCurrently, we read the numbers off from the bundled file, and then put them in global cells/static/whatever. It would be ideal to change the size of quicksort test.Currently, we read the numbers off from the bundled file, and then put them in global cells/static/whatever. It would be ideal to change the size of quicksort test.https://gitlab.anu.edu.au/mu/mu-perf-benchmarks/-/issues/21Use temporary files instead of IPC2017-11-21T10:09:42+11:00Zixian CaiUse temporary files instead of IPCCurrently, we are piping stdin/stdout to read the output from callbacks, but we may run into scheduling issues, which will introduce the noise into the measurement.Currently, we are piping stdin/stdout to read the output from callbacks, but we may run into scheduling issues, which will introduce the noise into the measurement.https://gitlab.anu.edu.au/mu/mu-perf-benchmarks/-/issues/20Sanity check for mubench2017-11-21T09:37:37+11:00Zixian CaiSanity check for mubenchWe'd like to have a sanity check inside the script. For example, we want to check the option for CPU governor, i.e. whether CPU frequency scaling is turned off or not. We may also want to add check for hyper-threading for example.
The b...We'd like to have a sanity check inside the script. For example, we want to check the option for CPU governor, i.e. whether CPU frequency scaling is turned off or not. We may also want to add check for hyper-threading for example.
The bottom line is before running a script, we want to make sure whether our assumptions are violated or not.https://gitlab.anu.edu.au/mu/mu-client-pypy/-/issues/21RPython level optimizations meta issue2017-11-11T00:35:26+11:00Zixian CaiRPython level optimizations meta issuehttps://gitlab.anu.edu.au/mu/mu-client-pypy/issues/20https://gitlab.anu.edu.au/mu/mu-client-pypy/issues/20Zixian CaiZixian Caihttps://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/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-client-pypy/-/issues/20Pidigits benchmarks produces slightly inefficient IR2017-11-11T10:26:14+11:00Isaac Garianoisaac@ecs.vuw.ac.nzPidigits benchmarks produces slightly inefficient IRI have compared the Mu IR output from the pidigits benchmark with the clang llvm output, and have noted a few differences (beyond of course the way allocation and exception handling is done):
(I have converted the llvm output were relav...I have compared the Mu IR output from the pidigits benchmark with the clang llvm output, and have noted a few differences (beyond of course the way allocation and exception handling is done):
(I have converted the llvm output were relavent to Mu ir)
* clang seems to prefers shifts and or's to adds,
e.g:
```
v_0 = ADD<int<64>> n2_1 n2_1
```
=>
```
v_0 = SHL<int<64>> n2_1 <int<64>>1
```
and
```
SHL<int<64>> k_2 <int<64>>1
...
v199 = ADD<int<64>> k2_0 <int<64>>1
```
=>
```
SHL<int<64>> k_2 <int<64>>1
...
v199 = OR<int<64>> k2_0 <int<64>>1
```
* clang prefers selects over branches:
e.g:
```
blk3(...):
...
cmpres_50 = SLT<int<64>> d_4 <int<64>>0
BRANCH2 cmpres_50 blk5(...) blk8(...)
blk5(...):
u_6 = SUB<int<64>> n1_4 p_1
blk6(u_6 ...)
blk8(...):
u_10 = SUB<int<64>> p_1 n1_4
blk6(u_10 ...)
blk6(u_7 ...):
...
```
=>
```
blk3(...):
...
cmpres_50 = SLT<int<64>> d_4 <int<64>>0
u_6 = SUB<int<64>> n1_4 p_1
u_10 = SUB<int<64>> p_1 n1_4
u_7 = SELECT<int<64>> cmpres_50 u_6 u_10
...
```
Also
```
BRANCH2 v879 blk17(v218) blk17(ldgcl_29)
```
=>
```
x = SELECT v879 v218 ldgcl_29
BRANCH blk17(x)
```
* Clang dosn't indirect in order to get string constants:
```
ldgcl_33 = LOAD <ref<@hyb1>> @gcl16
...
STORE <ref<@hyb1>> irv242_itm_0 ldgcl_33
```
=>
```
...
STORE <ref<@hyb1>> irv242_itm_0 @pypy_g_rpy_string_19
```
(Note in the later case a cast may be neccesary (but Zebu will make that a NOP)
* clang doesnt compare against NULL pointers stupidly:
```
v875 = REFCAST <ref<void> ref<@stt10>> <ref<void>>NULL
cmpres_56 = EQ<ref<@stt10>> v215 v875
v216 = ZEXT <int<1> int<8>> cmpres_56
v876 = EQ<int<8>> v216 <int<8>>1
```
=>
```
v876 = EQ<int<8>> v216 <ref<@stt10>>NULL
```
(a similar thing is done for non-null comparisons (the first EQ is replaced be a NE))
* clang calls it's memset intrinsic (we can do the same thing with a memset CCALL)
```
...
BRANCH2 cmpres_59 blk22(<int<8>>32 length_12 r_15 <int<64>>0 N_17 f_17) blk23(...)
blk25(<int<64>> times_2 <int<8>> ch_3 <int<64>> j_1 <ref<@hyb1>> newstr_1 <int<64>> N_21 <ref<@stt12>> f_22):
irnewstr_1_0 = GETIREF<@hyb1> newstr_1
iranewstr_1_0 = GETVARPARTIREF<@hyb1> irnewstr_1_0
irnewstr_1_itm_0 = GETELEMIREF<int<8> int<64>>iranewstr_1_0 j_1
STORE <int<8>> irnewstr_1_itm_0 ch_3
j_2 = ADD<int<64>> j_1 <int<64>>1
BRANCH blk22(ch_3 times_2 newstr_1 j_2 N_21 f_22)
blk22(<int<8>> ch_2 <int<64>> times_1 <ref<@hyb1>> newstr_0 <int<64>> j_0 <int<64>> N_19 <ref<@stt12>> f_19):
cmpres_60 = SLT<int<64>> j_0 times_1
BRANCH2 cmpres_60 blk25(times_1 ch_2 j_0 newstr_0 N_19 f_19) blk23(newstr_0 N_19 f_19)
```
=>
```
BRANCH2 cmpres_59 blk25(length_12 r_15 N_17 f_17) blk23(...)
blk25(<int<64>> times_2 <ref<@hyb1>> newstr_1 <int<64>> N_21 <ref<@stt12>> f_22):
iranewstr_1_0 = GETVARPARTIREF <@hyb1> newstr_1
iranewstr_1_0_ptr = COMMINST @uvm.native.pin<ref<@hyb1>>(newstr_1)
CCALL<(uptr<int<8>> int<32> int<64>)->()> <ufuncptr<(uptr<void> int<32> int<64>)->()>>
EXTERN "memset" (iranewstr_1_0_ptr <int<32>>32 times_2)
COMMINST @uvm.native.unpin<ref<@hyb1>>(iranewstr_1_0)
BRANCH2 blk23(newstr_1 N_21 f_22)
```
* There are a couple of instructions whose values are preserved and passed across blocks (i.e. not recomputed), e.g.
```
blk11(...):
...
r_12 = SREM<int<64>> i_45 <int<64>>10
cmpres_53 = EQ<int<64>> r_12 <int<64>>0
...
blk14(...):
...
cmpres_55 = NE<int<64>> r_13 <int<64>>0
BRANCH2 cmpres_55 blk19(...) blk15(...)
blk19(...):
r_14 = SREM<int<64>> i_49 <int<64>>10
v223 = SUB<int<64>> <int<64>>10 r_14
...
```
=>
```
blk11(...):
...
r_12 = SREM<int<64>> i_45 <int<64>>10
cmpres_53 = EQ<int<64>> r_12 <int<64>>0
...
blk14(...):
...
BRANCH2 cmpres_53 blk15(f_14) blk19(N_15 i_48 f_14)
blk19(...):
v223 = SUB<int<64>> <int<64>>10 r_12
...
```
* Constant comparisons are elided:
```
blk20(...):
... //blk20 body
cmpres_59 = NE<int<64>> <int<64>>1 <int<64>>0
BRANCH2 cmpres_59 blk22(...) blk21(...)
blk22(...):
... //blk22 body
blk21(...):
...
```
=>
```
blk20(...):
... //blk20 body
... // blk22 body
```
And ofcourse blk21 (which is now unreachable) should be deleted.
* The Mu Ir haze a crazy null comparison and branch bassed on the result, but the argument to the null comparison is allways the result of a NEWHYBRID, so it can't ever be null:
```
v887 = REFCAST <ref<void> ref<@hyb1>> <ref<void>>NULL
cmpres_61 = NE<ref<@hyb1>> v228 v887
v230 = ZEXT <int<1> int<8>> cmpres_61
v888 = EQ<int<8>> v230 <int<8>>1
....
BRANCH2 v888 blk24(v228 v229 N_20 f_20) blk24(ldgcl_30 v229 N_20 f_20)
```
=>
```
BRANCH v888 blk24(v228 v229 N_20 f_20)
```
(and since `blk24`, is now only reached by one destination clause, it can be inlined... and deleted)
* When the LLVM version has a 'PHI' node where one of the variants is a string constant, the Mu version emits a LOAD to a global cell and then passes the result to a dest-clause, however this causes the load to be executed even if the branch is not taken, I suggest you put such 'phi' loads in their own blocks:
```
...
ldgcl_28 = LOAD <ref<@hyb1>> @gcl15
BRANCH2 v876 blk17(ldgcl_28) blk16(...)
```
=>
```
...
BRANCH2 v876 phi() blk16(...)
phi():
ldgcl_28 = LOAD <ref<@hyb1>> @gcl15
BRANCH blk17(ldgcl_28)
```
Oh and the layout of blocks is very different, but because Zebu will internally re order them, this is not a problem (I will compare the assembly blocks layout instead).John ZhangJohn Zhanghttps://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-client-pypy/-/issues/19PyPy-JIT meta issue2017-11-11T00:35:27+11:00Zixian CaiPyPy-JIT meta issue* [ ] AOT and JIT should map a lltype to same mutype.
* [ ] High level type information should be accessible during runtime.
* [ ] Efficient way to encode/decode type information in JitCode. #4
* [ ] CCALL a ufuncptr of an expos...* [ ] AOT and JIT should map a lltype to same mutype.
* [ ] High level type information should be accessible during runtime.
* [ ] Efficient way to encode/decode type information in JitCode. #4
* [ ] CCALL a ufuncptr of an exposed Mu function. #15
* [ ] How to model guards, loops and bridges in Mu.Zixian CaiZixian Caihttps://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-client-pypy/-/issues/16PyPy-Holstein: execute subprocess.Popen failure2017-08-31T11:00:50+10:00John ZhangPyPy-Holstein: execute subprocess.Popen failure## Problem Description
The compiled PyPy interpreter is having problem executing `subprocess.Popen()`. The function calls `os.fork()`, then `os.execvp()` in the child process. Though a second process is forked, the execution seems to ha...## Problem Description
The compiled PyPy interpreter is having problem executing `subprocess.Popen()`. The function calls `os.fork()`, then `os.execvp()` in the child process. Though a second process is forked, the execution seems to halt and not making any progress after that (CPU usage become 0).
Following test exposes the problem:
```python
def test_subproc():
import sys
import subprocess
target = sys.executable
proc = subprocess.Popen(['file', target],
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
output = proc.communicate()[0]
print output
rc = proc.wait()
assert rc == 0
```https://gitlab.anu.edu.au/mu/mu-spec/-/issues/17Swapstack exc_caluse2017-08-08T01:22:09+10:00Isaac Garianoisaac@ecs.vuw.ac.nzSwapstack exc_caluseCurrently the swap stack instruction requires an exception clause, this makes no sense if the current_stack_clause is 'KILL_OLD'.
I suggest making a minor change:
* If the current stack clause is 'KILL_OLD', require that the exception cl...Currently the swap stack instruction requires an exception clause, this makes no sense if the current_stack_clause is 'KILL_OLD'.
I suggest making a minor change:
* If the current stack clause is 'KILL_OLD', require that the exception clause is absent (and have control flow analysis treat this instruction in the same was a thread_exit, I.e. it has no successor)
* Otherwise, require an exception clause
Also am I correct in assuming it's undefined behaviour to do a swap_stack/new_thread where the new stack clause is THROW_EXC but the last thing executed on the swappee was not a swap stack instruction with an exception clause?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