A DESCRIPTION OF THE PROBLEM :
During production up-time of ~10.5 h the HotSpot C2 CompilerThread0 crashed with SIGSEGV (si_addr=0x2c) inside libjvm.so while compiling the hot method io.netty.util.internal.ReferenceCountUpdater::retryRelease0 (70 bytes).
The crash is 100 % reproducible under load when the method reaches the C2 compilation threshold.
Core file and replay log show the SEGV occurs in Compile::final_graph_reshaping_walk(Node_Stack&, Node*, Final_Reshape_Counts&, Unique_Node_List&) at offset 0x33e while dereferencing a node that appears to have already been eliminated or corrupted.
Environment
Oracle JDK 25.0.1+8-LTS-27 (build 25.0.1+8-LTS-27)
Linux 5.15.0-315.196.5.2.el9uek.x86_64 (Oracle Linux Server 9.7, VMware VM)
8 vCPU, 16 GB RAM, G1GC, CompressedOops on, no JVM tuning flags
Steps to Reproduce
Start attached Spring-Boot 3.4 executable (uses Netty 4.1.115.Final) with default flags.
Drive >5 k rps through the reactive Netty-based gateway for ~3 min (method invocation count > 50 000).
Observe C2 CompilerThread0 crash with identical stack trace (see hs-err_pid179067.log attached).
Expected Behavior
C2 should complete compilation without native crash.
Actual Behavior
JVM terminates with SIGSEGV.
Work-around
Upgrade to Adoptium Temurin 25.0.2+9 (confirmed fixed).
Or disable C2: -XX:TieredStopAtLevel=1 (performance regression ~15 %).
Attachments
hs-err_pid179067.log (original crash log)
core.179067.gz (compressed core file)
replay_pid179067.log (generated by -XX:+CreateCoredumpOnCrash)




REGRESSION : Java version that customer using for null