JDK-8341818 : C2 compilation fails with "dead loop detected"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 22,23,24,25,26
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-10-09
  • Updated: 2025-05-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26Unresolved
Related Reports
Relates :  
JDK-8268019 - C2: assert(no_dead_loop) failed: dead loop detected
Relates :  
JDK-8334060 - Implementation of Late Barrier Expansion for G1
Description
compiler/c2/TestDeadLoopSplitIfLoop.java failed twice with:

dist dump
---------------------------------------------
   4    0  Root  === 0 217 216 136 165 181  |193  [[ 0 1 3 21 22 23 26 27 196 31 33 45 49 73 218 109 120 131 152 160 176 192 241 ]] 
   3   45  ConI  === 0  [[ 48 232 ]]  #int:1
   3    1  Con  === 0  [[ ]]  #top
   2  232  If  === 1 45  [[ 235 234 ]] P=0.999999, C=-1.000000 !orig=[157] !jvms: TestDeadLoopSplitIfLoop::test @ bci:55 (line 58)
   1  234  IfTrue  === 232  [[ 166 ]] #1
   0  166  CastPP  === 234 166  [[ 166 193 177 177 ]]  #long[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact * !orig=240 !jvms: TestDeadLoopSplitIfLoop::test @ bci:55 (line 58)

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (c:\sb\prod\1728431921\workspace\open\src\hotspot\share\opto\phaseX.cpp:784), pid=10516, tid=16152
#  assert(no_dead_loop) failed: dead loop detected

Current CompileTask:
C2:391   16    b        compiler.c2.TestDeadLoopSplitIfLoop::test (88 bytes)

Stack: [0x0000007238600000,0x0000007238700000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xcf3c61]  os::win32::platform_print_native_stack+0x101  (os_windows_x86.cpp:235)
V  [jvm.dll+0xfbd00d]  VMError::report+0x148d  (vmError.cpp:1011)
V  [jvm.dll+0xfbf68d]  VMError::report_and_die+0x80d  (vmError.cpp:1846)
V  [jvm.dll+0xfbfd84]  VMError::report_and_die+0x64  (vmError.cpp:1611)
V  [jvm.dll+0x5887fb]  report_vm_error+0x5b  (debug.cpp:193)
V  [jvm.dll+0xd3900d]  PhaseGVN::dead_loop_check+0x18d  (phaseX.cpp:784)
V  [jvm.dll+0xd3eb89]  PhaseIterGVN::transform_old+0xa9  (phaseX.cpp:1197)
V  [jvm.dll+0xd3b0b1]  PhaseIterGVN::optimize+0x261  (phaseX.cpp:1047)
V  [jvm.dll+0x5126a4]  Compile::Optimize+0x1a4  (compile.cpp:2241)
V  [jvm.dll+0x51048f]  Compile::Compile+0x113f  (compile.cpp:853)
V  [jvm.dll+0x41a609]  C2Compiler::compile_method+0x179  (c2compiler.cpp:145)
V  [jvm.dll+0x52d527]  CompileBroker::invoke_compiler_on_method+0x747  (compileBroker.cpp:2306)
V  [jvm.dll+0x52ab9b]  CompileBroker::compiler_thread_loop+0x33b  (compileBroker.cpp:1962)
V  [jvm.dll+0x851e06]  JavaThread::thread_main_inner+0x266  (javaThread.cpp:760)
V  [jvm.dll+0xf1e474]  Thread::call_run+0x1b4  (thread.cpp:239)
V  [jvm.dll+0xcf22c7]  thread_native_entry+0xd7  (os_windows.cpp:554)
C  [ucrtbase.dll+0x2268a]  (no source info available)
C  [KERNEL32.DLL+0x17ac4]  (no source info available)
C  [ntdll.dll+0x5a4e1]  (no source info available)
Comments
Attached a reduced reproducer found by the Java Fuzzer recently which fails intermittently: $ java -XX:RepeatCompilation=500 -XX:CompileCommand=compileonly,Test::test -XX:-TieredCompilation -Xbatch -XX:+StressIGVN -XX:PerMethodTrapLimit=0 Test.java We should double-check when fixing this if it also fixes the originally reported issue.
12-05-2025
Intermittent and not a new regression. Deferring to JDK 26 for now.
05-05-2025
I had a quick look at this in the debugger and it looks like the exact same issue as JDK-8268019. As described in https://github.com/openjdk/jdk/pull/4860, we split an If through a loop header region. Unfortunately, the fix for JDK-8268019 is not correct because although the Region is not on the worklist, the backedge will still become top later: 137 IfTrue === 1 [[ 138 ]] #1 !jvms: TestDeadLoopSplitIfLoop::test @ bci:48 (line 58) 202 IfTrue === 201 [[ 138 ]] #1 !jvms: TestDeadLoopSplitIfLoop::test @ bci:84 (line 63) 138 Region === 138 202 137 [[ 138 157 146 ]] #reducible !jvms: TestDeadLoopSplitIfLoop::test @ bci:48 (line 58) We probably need to delay this optimization until we run loop opts and can reliably identify loop regions. For some reason, I can not reproduce the issue with JDK <= 21 but I'm pretty sure the issue affects older releases as well. UPDATE: This first reproduces with JDK 22 b14, might be due to JDK-8305637 or JDK-8314997 ([~chagedorn]).
14-10-2024
I'm deferring this to JDK 25 for now. [~chagedorn] might want to have a look at this.
14-10-2024
The IR output differs from run to run. I can reproduce this with JDK 24-ea+19-2198 and ReplayCompiles and -XX:+StressIGVN: java -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=replay_pid10516.log -XX:+StressIGVN -XX:StressSeed=4002101507 Other seed: 4280751696 Or run with java -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=replay_pid10516.log -XX:+StressIGVN -XX:RepeatCompilation=100000 The issue does not reproduce with jdk-24+18-2071 but first with jdk-24+18-2072 which is the build that JDK-8334060 went in. UPDATE: With ZGC, I can also reproduce this with earlier versions. I will update the affects versions accordingly.
09-10-2024
ILW = Same as JDK-8268019 = P3
09-10-2024