Open fjeremic opened 4 years ago
Both issues can be reproduced with OpenJ9 latest nightly driver.
For x86: Test.java.zip
bin/java '-Xjit:limit={Test.test*}(count=1,traceFull,log=log.trace,lastOptIndex=44,lastOptSubIndex=2),disableasynccompilation' Test
For Power: Test.Utils.zip
bin/java -cp ./junit-4.11.jar:. -Xjit:count=0 Test
@aviansie-ben could you please help take a look at the Power issues noted above? It seems the refcounts are all messed up somehow.
Oops, it looks like the byteswapped store optimization on Power wasn't correctly checking that the *byteswap
node wasn't commoned. I'd actually encountered this issue and was sure I'd fixed it before submitting the PR, but it looks like the fix ended up on the wrong branch by mistake. :sweat_smile: That issue should be fixed by #5645.
There were issues spotted since #5623 on x86 and Power.
On 32-bit x86 we seem to have problems when we use register pairs in that the byte swap is not correctly performed. Here is what we generate:
This is incorrect as we are not byte swapping the full 8-byte value. In fact it seems to use a totally incorrect register
edi
where as the 64-bit value got loaded into a register pairedx:eax
.There also appears to be an issue with 64-bit x86 which I'm currently tracking down.
For Power there are compile time segfaults encountered. The jitdump shows the following:
There are two issues here. Node
n24908n
does not seem to get its reference count properly decremented following evaluation. We encounter a segfault when we try to do adecReferenceCount
on noden387n
because it's reference count when evaluatingglRegDeps
is 0 which should not be the case. It seems following evaluation ofn8183n
we somehow decrement the reference count ofn387n
. There is also a problem with the refcount ofn8165n
as its reference count does not seem to be decremented following evaluation ofn8183n
.The backtrace on Power is:
These issues come from the OpenJ9 project. I'll add notes now on how to reproduce.