JDK-8249605 : C2: assert(no_dead_loop) failed: dead loop detected
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,11,12,13,14,15,16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-07-16
  • Updated: 2023-09-26
  • Resolved: 2020-08-03
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 11 JDK 16
11.0.10-oracleFixed 16 b09Fixed
Related Reports
Duplicate :  
JDK-8316939 - C2: assert(no_dead_loop) failed: dead loop detected
Description
The attached fuzzer test hits the following assertion failure.

To reproduce:
$ java -Xmx1G -Xcomp -Xbatch -XX:-TieredCompilation -XX:CompileOnly=Test Test.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/christian/jdk/open/src/hotspot/share/opto/phaseX.cpp:923), pid=23357, tid=23369
#  assert(no_dead_loop) failed: dead loop detected
#
# JRE version: Java(TM) SE Runtime Environment (16.0) (slowdebug build 16-internal+0-2020-07-13-1111353.christian...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 16-internal+0-2020-07-13-1111353.christian..., compiled mode, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xf02e58]  PhaseGVN::dead_loop_check(Node*)+0x18e
..........
Command Line: -Xmx1G -Xcomp -Xbatch -XX:-TieredCompilation -XX:CompileOnly=Test --add-modules=ALL-DEFAULT jdk.compiler/com.sun.tools.javac.launcher.Main Test.java
..........
Current thread (0x00007f4bfc343fc0):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=23369, stack(0x00007f4bf8005000,0x00007f4bf8106000)]


Current CompileTask:
C2:  12334   93    b        Test::lMeth (228 bytes)

Stack: [0x00007f4bf8005000,0x00007f4bf8106000],  sp=0x00007f4bf81013c0,  free space=1008k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xf02e58]  PhaseGVN::dead_loop_check(Node*)+0x18e
V  [libjvm.so+0xf040c2]  PhaseIterGVN::transform_old(Node*)+0x26c
V  [libjvm.so+0xf03ce4]  PhaseIterGVN::optimize()+0x148
V  [libjvm.so+0x6d5d82]  Compile::Optimize()+0x18a
V  [libjvm.so+0x6cfaca]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x1090
V  [libjvm.so+0x5ce7a7]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x15b
V  [libjvm.so+0x6ea926]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x88e
V  [libjvm.so+0x6e95b3]  CompileBroker::compiler_thread_loop()+0x3df
V  [libjvm.so+0x10a0bdf]  compiler_thread_entry(JavaThread*, Thread*)+0x69
V  [libjvm.so+0x109bd90]  JavaThread::thread_main_inner()+0x146
V  [libjvm.so+0x109bc41]  JavaThread::run()+0x11f
V  [libjvm.so+0x1097eca]  Thread::call_run()+0x180
V  [libjvm.so+0xea6716]  thread_native_entry(Thread*)+0x1e4
Comments
Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.10-oracle. Applies clean.
02-10-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/6565fb0907fa User: chagedorn Date: 2020-08-03 08:24:56 +0000
03-08-2020
http://cr.openjdk.java.net/~chagedorn/8249605/webrev.00/ There is a dead memory loop detected during IGVN. In the testcase, many nodes are dying during IGVN because they are not reachable anymore. In this process, a (not yet dead) memory phi node (150 Phi) with two inputs is processed (see [1]): (1) 289 MergeMem, whose base memory is 150 Phi and has one slice for 274 StoreD which is again an output of 150 Phi (2) 356 MergeMem, whose base memory is top (i.e. dead and would be removed when IGVN processes this node) In PhiNode::Ideal, we check if a phi node is part of a dead loop where all its inputs reference itself over a MergeMemNode input whose base memory is the phi node itself again [2]. However, in this check we do not account for dead MergeMemNodes (like the input 356 MergeMem of 150 Phi). Therefore, we do not return top and apply the optimization [3] to replace 150 Phi by a new MergeMemNode (380 MergeMem) whose base memory is top and now has again one slice which is input and output to 274 StoreD [4]. This cycle is later detected and the assertion fails. The fix accounts additionally for dead MergeMemNodes when trying to detect dead loops in PhiNode::Ideal to return top instead of a new dead MergeMemNode. [1] https://bugs.openjdk.java.net/secure/attachment/89582/before_PhiNode_Ideal.png [2] http://hg.openjdk.java.net/jdk/jdk/file/8f7ede592c28/src/hotspot/share/opto/cfgnode.cpp#l2234 [3] http://hg.openjdk.java.net/jdk/jdk/file/8f7ede592c28/src/hotspot/share/opto/cfgnode.cpp#l2246 [4] https://bugs.openjdk.java.net/secure/attachment/89583/after_PhiNode_Ideal.png
03-08-2020