JDK 21 | JDK 23 | JDK 24 |
---|---|---|
21.0.6-oracleFixed | 23.0.2Fixed | 24 b19Fixed |
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
ADDITIONAL SYSTEM INFORMATION : OpenJDK 64-Bit Server VM (fastdebug 21.0.5+5-Nightly) for linux-amd64 Redhat 8.9 A DESCRIPTION OF THE PROBLEM : While we were upgrading from java 8 to java 21, we encountered an issue where some of the files that our code writes were corrupted. We traced that to a small method that transfers bytes from an Unsafe based Buffer to java.nioByteBuffer. This was happening right after the method got compiled by C2. We believe that after inlining and loop optimizations, the generated code is incorrect (the update positionAddress instruction was likely moved out of the loop). I think we've confirmed that when we got a crash report by using a fastdebug build of the Java21. REGRESSION : Last worked in version 8u421 ACTUAL - # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/jenkins/node/workspace/Corretto21/generic_linux/x64/build/Corretto21Src/installers/linux/universal/tar/corretto-build/buildRoot/src/hotspot/share/opto/loopopts.cpp:1643), pid=3104989, tid=3105002 # assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect # # JRE version: OpenJDK Runtime Environment Corretto-21.0.5.5.1 (21.0.5+5) (fastdebug build 21.0.5+5-Nightly) # Java VM: OpenJDK 64-Bit Server VM Corretto-21.0.5.5.1 (fastdebug 21.0.5+5-Nightly, mixed mode, compressed oops, compressed class ptrs, parallel gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x11fb779] PhaseIdealLoop::try_sink_out_of_loop(Node*)+0xc89 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to xxx/core.3104989) # # If you would like to submit a bug report, please visit: # https://github.com/corretto/corretto-21/issues/ # ---------- BEGIN SOURCE ---------- I haven't been able to create a small reproducer that doesn't use any of our internal code yet. The bug is pretty subtle. I am hoping that the hs_err report file could give us more insight into when it happens so that I can make a small executable test case. Is there any easy way to produce this, perhaps using the compiler replay functionality? ---------- END SOURCE ---------- CUSTOMER SUBMITTED WORKAROUND : Using either -XX:-SplitIfBlocks or -XX:CompileCommand=exclude,methodname We also rewrote the code in a slightly different way so it no longer happens. FREQUENCY : always
|