JDK-8272562 : C2: assert(false) failed: Bad graph detected in build_loop_late
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-08-17
  • Updated: 2023-11-30
  • Resolved: 2021-09-29
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 17 JDK 18
17.0.2Fixed 18 b18Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
The attached Java Fuzzer test starts to fail after JDK-8252372. This bug is different from JDK-8271954 but fails with the same assertion:

To reproduce:

$ java -Xmx1G Test.java (fails intermittently)
$ java -XX:CompileOnly=Reduced -XX:-TieredCompilation -Xbatch  Reduced.java (always fails)

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/ff806ead-2cac-495d-9cbc-62116f99bf14-S13890/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/e1985841-cb1f-4767-b2e4-927825614993/runs/9fce6d83-2b2c-4178-b4c4-97cbe003ff2d/workspace/open/src/hotspot/share/opto/loopnode.cpp:5343), pid=24365, tid=24378
#  assert(false) failed: Bad graph detected in build_loop_late
#
# JRE version: Java(TM) SE Runtime Environment (17.0+35) (fastdebug build 17+35-LTS-2724)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17+35-LTS-2724, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1322da7]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x307
............
Command Line: -Xmx1G Test
............
Current thread (0x00007fd7a8481e10):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=24378, stack(0x00007fd78c2fe000,0x00007fd78c3ff000)]


Current CompileTask:
C2:    659  284 % !   4       Test::vMeth @ 86 (273 bytes)

Stack: [0x00007fd78c2fe000,0x00007fd78c3ff000],  sp=0x00007fd78c3f9310,  free space=1004k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1322da7]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x307
V  [libjvm.so+0x132324a]  PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0xba
V  [libjvm.so+0x1323bb7]  PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x507
V  [libjvm.so+0xa377da]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x2da
V  [libjvm.so+0xa340f5]  Compile::Optimize()+0x14f5
V  [libjvm.so+0xa35c78]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, bool, DirectiveSet*)+0x1618
V  [libjvm.so+0x84b116]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x646
V  [libjvm.so+0xa45cc1]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb71
V  [libjvm.so+0xa46968]  CompileBroker::compiler_thread_loop()+0x5a8
V  [libjvm.so+0x18dca01]  JavaThread::thread_main_inner()+0x271
V  [libjvm.so+0x18e3ff0]  Thread::call_run()+0x100
V  [libjvm.so+0x15a9cf4]  thread_native_entry(Thread*)+0x104

Comments
Fix request (17u): The bug leads to an assert during C2 compilation (regression in JDK 17). The fix is low risk (bailout from optimization) and has been tested in the JDK 18 for a while and with tier1-3 in JDK 17u. The patch applies cleanly.
11-10-2021

Changeset: 980c50dc Author: Roland Westrelin <roland@openjdk.org> Date: 2021-09-29 14:51:33 +0000 URL: https://git.openjdk.java.net/jdk/commit/980c50dc607e60e12879bd6fb7ff4034469e88d8
29-09-2021

I coincidentally found the same fix as JDK-8271600 for which a PR is currently open. An explanation is posted as comment to the PR: https://github.com/openjdk/jdk/pull/5199#pullrequestreview-735143057
23-08-2021

It's unrelated. This bug is caused by JDK-8252372 which is an optimization in split if and does not reproduce with -XX:-SplitIfBlocks while JDK-8272574 crashes with -XX:-SplitIfBlocks.
18-08-2021

ILW = C2 assertion failure, found with single Java Fuzzer test, use -XX:-SplitIfBlocks = HLM = P3
18-08-2021

Could this be related to JDK-8272574?
18-08-2021