Closed JavaTailor closed 2 years ago
Duplicated with a recent nightly xlinux build. @hzongaro can someone take a look pls. I've added it to the 0.33 milestone plan.
It looks like the failure isn't exposed with the Java 8 build because of differences in the amount of inlining that happens.
The crash happens in TR_LoopVersioner::detectCanonicalizedPredictableLoops
because _loopTestTree
is NULL. The call to TR_LoopCanonicalizer::checkLoopForPredictability
ends up not setting _loopTestTree
because the region that it's looking at is no longer a loop due to an earlier transformation.
86 [0x7fffd29afc90] Acyclic region
Subgraph: (* = exit edge)
(0x7fffd29afd60:0x7fffd29add70)86 --> 150(0x7fffd29b7b00)
(0x7fffd29afdf0:0x7fffd29af840)125 --> 84(0x7fffd29afed0)*
(0x7fffd29b7b00:0x7fffd29b7aa0)150 --> 125(0x7fffd29afdf0)
Exit edges:
(0x7fffd29afdf0)125 -->84
86 [0x7fffd29add70] Block
125 [0x7fffd29af840] Natural loop
Subgraph: (* = exit edge)
(0x7fffd29af910:0x7fffd29ad890)125 --> 83(0x7fffd29af9a0)
(0x7fffd29af9a0:0x7fffd29ade90)83 --> 84(0x7fffd29afbb0)* 125(0x7fffd29af910)
Exit edges:
(0x7fffd29af9a0)83 -->84
125 [0x7fffd29ad890] Block
83 [0x7fffd29ade90] Block
150 [0x7fffd29b7aa0] Block
84 [0x7fffd29ade30] Block
I'm not sure whether the right thing to do is add an additional test of whether _loopTestTree
is non-NULL, or avoid calling TR_LoopVersioner::detectCanonicalizedPredictableLoops
for something that is not a loop, or have TR_LoopCanonicalizer::checkLoopForPredictability
handle non-loops by not returning a positive result, or maybe something else.
In any event, Devin @jdmpapin, may I ask you to investigate this?
Opened eclipse/omr#6531 with a fix
Keep in mind it will need to be double delivered, if we think this is appropriate, to get into the 0.33 release.
Opened eclipse-openj9/openj9-omr#147 for 0.33
Closing as the fixes are merged.
Affected versions
We found a test case with crash problems. To facilitate analysis, we simplified the test case and the simplified class file can ben found at attachment.
Windows 10:
Java -version output under Windows 10
Problem summary
We found that in a normal test case, if we executed the test case using J9-JDK11 it would report crash, but if we executed it using J9-JDK8 it would report nothing. Below is the information we executed using J9-JDK11, and our test case can be found in the attachment. To further verify this problem, we compiled OpenJ9 ourselves with the #6423 modification
Attachment
TestCase4.zip