JDK 25 |
---|
25 b21Fixed |
Blocks :
|
|
Causes :
|
|
Causes :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
I found this during work on JDK-8340093. I took the test added by JDK-8263971: TestLostDependencyOnZeroTripGuard.java And only changed the limit 3 -> 2. https://github.com/openjdk/jdk/pull/3190 It could be a JDK24 regression of JDK-8334724, was the initial guess by [~chagedorn]. https://github.com/openjdk/jdk/pull/19831 -------------------- How to Reproduce --------------------- On latest JDK24 or JDK25 (did not reproduce on JDK23). /oracle-work/jdk-25/fastdebug/bin/java -Xcomp -XX:-TieredCompilation -XX:CompileOnly=Test::* -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM -XX:UseAVX=2 -XX:StressSeed=139899009 -XX:CompileCommand=printassembly,*::mainTest Test.java # # A fatal error has been detected by the Java Runtime Environment: # # SIGFPE (0x8) at pc=0x00007ff0009728af, pid=273793, tid=273794 # # JRE version: Java(TM) SE Runtime Environment (25.0+8) (fastdebug build 25-ea+8-LTS-843) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-ea+8-LTS-843, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # J 88 c2 Test.mainTest([Ljava/lang/String;)V (115 bytes) @ 0x00007ff0009728af [0x00007ff000972760+0x000000000000014f] # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /oracle-work/jdk-fork5/core.273793) # # An error report file with more information is saved as: # /oracle-work/jdk-fork5/hs_err_pid273793.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # Aborted (core dumped) From my first assessment, it looks exactly like the bug from: https://github.com/openjdk/jdk/pull/3190 A DivI sits in the main-loop. But that main-loop eventually is fully unrolled, and loses its loop structure. Before this, the DivI had to be scheduled after the loop-phi of the main-loop. But after the loop structure removal, the DivI can float up, even inside the pre-loop with StressGCM. https://github.com/openjdk/jdk/pull/3190 Should have fixed this with the CastII. But then the CastII was removed again by: https://github.com/openjdk/jdk/pull/19831 (needs to be confirmed, this is only speculation at this point)
|