Bug ID: JDK-8293941 C2: assert(false) failed: Bad graph detected in build_loop

Versions (Unresolved/Resolved/Fixed)

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 21
21Resolved

The attached Java Fuzzer test starts to fail after JDK-8252372 with the following assertion:

To reproduce:

$ java -Xcomp -XX:-TieredCompilation  -XX:CompileOnly=Test Test.java
$ java -Xcomp -XX:-TieredCompilation  -XX:CompileOnly=Reduced Reduced.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S34703/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/247a8232-5dbb-4725-b447-2bd89d2efd4c/runs/35076a8c-95e7-4b2e-a59b-644c9012a433/workspace/open/src/hotspot/share/opto/loopnode.cpp:5856), pid=25245, tid=25258
#  assert(false) failed: Bad graph detected in build_loop_late
#
# JRE version: Java(TM) SE Runtime Environment (20.0+15) (fastdebug build 20-ea+15-1019)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+15-1019, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x14b5f27]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x187
............
Command Line: -Xcomp -XX:-TieredCompilation -XX:CompileOnly=Test --add-modules=ALL-DEFAULT jdk.compiler/com.sun.tools.javac.launcher.Main Test.java
............
Current CompileTask:
C2:   2363  161   !b        Test::mainTest (536 bytes)

Stack: [0x00007f137d147000,0x00007f137d248000],  sp=0x00007f137d241ff0,  free space=1003k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x14b5f27]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x187  (loopnode.cpp:5856)
V  [libjvm.so+0x14b66e2]  PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0xb2
V  [libjvm.so+0x14b7058]  PhaseIdealLoop::build_and_optimize()+0x4f8
V  [libjvm.so+0xaff221]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x261
V  [libjvm.so+0xafb9f3]  Compile::Optimize()+0xe53
V  [libjvm.so+0xafdcad]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x15ad
V  [libjvm.so+0x90e3b5]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x675
V  [libjvm.so+0xb0c1fc]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb1c
V  [libjvm.so+0xb0cfc8]  CompileBroker::compiler_thread_loop()+0x5a8
V  [libjvm.so+0x106ca00]  JavaThread::thread_main_inner()+0x230
V  [libjvm.so+0x1a6cae0]  Thread::call_run()+0x100
V  [libjvm.so+0x1708723]  thread_native_entry(Thread*)+0x103

And one more, same issue: The CastII can be improved after an OpaqueZeroTripGuard node is removed. The CountedLoop phi type range and the loop entry CastII have no overlapping range anymore and we replace the Phi with top, leading to a broken graph again (malformed control flow assert) $ java -Xcomp -XX:CompileOnly=Reduced4::test -XX:-TieredCompilation Reduced4.java
02-05-2023
Attached another fuzzer failure (Reduced3.java) with the same problem: After loop opts, a OpaqueZeroTripGuard node is removed and as a result a CastII can improve its type in such a way that it becomes top because its input is not in this range. But the If does not die. We are left with an If node with a single IfProj output and hit the malformed graph assert recently added. $ java -XX:-RangeCheckElimination -Xcomp -XX:CompileOnly=Reduced3 -XX:-TieredCompilation Reduced3.java
02-05-2023
Test.java and its reduced version Reduced.java trigger the same bug as in JDK-8290850 (attached them also to that bug). However, the second test Test2.java with its reduced version Reduced2.java trigger a different problem very similar to JDK-8272562 but in this case, we are not sinking cast nodes out of the loop but they are already out of the loop. So, we are facing the exact same problem as described in https://github.com/openjdk/jdk/pull/5199#pullrequestreview-735143057 (test case of JDK-8272562). Since this is a very rare case and a fix is difficult/complex, I'm deferring this bug to JDK 21.
22-11-2022
ILW = C2 assertion failure due to bad graph, single Java Fuzzer test, use -XX:-SplitIfBlocks or disable compilation of affected method = HLM = P3
16-09-2022

Duplicate :	JDK-8321097 - C2: Broken graph due to dying Cast nodes while control cannot be removed
Relates :	JDK-8252372 - Check if cloning is required to move loads out of loops in PhaseIdealLoop::split_if_with_blocks_post()
Relates :	JDK-8272562 - C2: assert(false) failed: Bad graph detected in build_loop_late