Bug ID: JDK-8280600 C2: assert(!had_error) failed: bad dominance

JDK-8280600 : C2: assert(!had_error) failed: bad dominance

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 17,18,19

Priority: P3
Status: Resolved
Resolution: Fixed

Submitted: 2022-01-25
Updated: 2022-05-05
Resolved: 2022-02-02

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 17	JDK 18	JDK 19
17.0.4-oracleFixed	18.0.2Fixed	19 b08Fixed

Related Reports

Duplicate :	JDK-8280587 - C2: assert(inner->is_valid_counted_loop(T_INT) && inner->is_strip_mined()) failed: OuterStripMinedLoop should have been removed
Relates :	JDK-8252372 - Check if cloning is required to move loads out of loops in PhaseIdealLoop::split_if_with_blocks_post()
Relates :	JDK-8283386 - C2: JavaFX application crashes in PhaseIdealLoop::build_loop_late_post_work
Relates :	JDK-8281117 - Add regression test for JDK-8280587
Relates :	JDK-8259609 - C2: optimize long range checks in long counted loops
Relates :	JDK-8282592 - C2: assert(false) failed: graph should be schedulable

Description

The attached fuzzer test fails starts to fail after JDK-8259609 (just reveals an existing bug, see comments) with the following assertion:

To reproduce:
$ java -Xcomp -XX:CompileOnly=Test Test.java
$ java -Xcomp -XX:CompileOnly=Reduced Reduced.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/ff806ead-2cac-495d-9cbc-62116f99bf14-S13969/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/7ba0f8d2-063a-4d17-9102-79bc486a843e/runs/cd3aa16d-01e2-42b3-89ad-9b0251a5fc3b/workspace/open/src/hotspot/share/opto/loopnode.cpp:5287), pid=23515, tid=23528
#  assert(!had_error) failed: bad dominance
#
# JRE version: Java(TM) SE Runtime Environment (18.0+32) (fastdebug build 18-ea+32-2068)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 18-ea+32-2068, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1391942]  PhaseIdealLoop::compute_lca_of_uses(Node*, Node*, bool)+0x6e2
.........
Command Line: -Xmx1G -Xcomp -Xbatch -XX:CompileOnly=Test -XX:CompileCommand=quiet Test
.........
Current CompileTask:
C2:    879   63   !b  4       Test::mainTest (516 bytes)

Stack: [0x00007fa7e0760000,0x00007fa7e0861000],  sp=0x00007fa7e085ae60,  free space=1003k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1391942]  PhaseIdealLoop::compute_lca_of_uses(Node*, Node*, bool)+0x6e2
V  [libjvm.so+0x1391dc0]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x2a0
V  [libjvm.so+0x13922ca]  PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0xba
V  [libjvm.so+0x1392d52]  PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x622
V  [libjvm.so+0xa8f490]  PhaseIdealLoop::verify(PhaseIterGVN&)+0x2a0
V  [libjvm.so+0xa8a459]  Compile::Optimize()+0x8e9
V  [libjvm.so+0xa8cdfe]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x159e
V  [libjvm.so+0x8a5684]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x664
V  [libjvm.so+0xa9d0f8]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc88
V  [libjvm.so+0xa9deb8]  CompileBroker::compiler_thread_loop()+0x648
V  [libjvm.so+0x192750a]  JavaThread::thread_main_inner()+0x25a
V  [libjvm.so+0x192f8d0]  Thread::call_run()+0x100
V  [libjvm.so+0x16103d4]  thread_native_entry(Thread*)+0x104

Comments

A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk18u/pull/68 Date: 2022-03-29 15:25:47 +0000
29-03-2022
Fix Request (JDK 18u) Fixes an assert in C2. The fix is low risk and applies cleanly. Already tested and backported to Oracle JDK 17u. Tier 1-3 testing is running for JDK 18u.
29-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk17u-dev/pull/297 Date: 2022-03-29 12:56:02 +0000
29-03-2022
Fix Request (17u): Should get backported for parity with 17.0.4-oracle. Applies cleanly. Test has passed.
29-03-2022
Changeset: de826ba1 Author: Roland Westrelin <roland@openjdk.org> Date: 2022-02-02 08:01:00 +0000 URL: https://git.openjdk.java.net/jdk/commit/de826ba18a5e98586029581c2d4bcd27334fbdd1
02-02-2022
The fix could be backported into 18u after push and testing in JDK 19.
01-02-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/7307 Date: 2022-02-01 15:03:33 +0000
01-02-2022
Thanks Roland for analyzing it further. As discussed offline, the fix is not simple and could be risky. Given that we are in RDP 2 now and that JDK-8252372 was added in JDK 17 (i.e. not a recent regression), we agreed to defer this bug and update its ILW: Updated ILW = C2 assertion due to dominance failure, only single test and not recent regression, disable compilation of affected method = HLM = P3
26-01-2022
This appears to happen as a side effect of the following changes: https://github.com/openjdk/jdk/commit/82f4aacb42e60e9cd00e199703a869e7ad4465ff#diff-6a59f91cb710d682247df87c75faf602f0ff9f87e2855ead1b80719704fbedff in IdealLoopTree::policy_range_check() So it's not directly related to long range checks in long counted loops. AFAICT, instead, it's another bug caused by 8252372 (Check if cloning is required to move loads out of loops in PhaseIdealLoop::split_if_with_blocks_post()).
26-01-2022
Targetting to JDK 18 as this is a recent regression from JDK 18. [~roland] can you have a look at it?
25-01-2022
ILW = C2 assertion due to dominance failure, only single test but recent regression, disable compilation of affected method = HMM = P2
25-01-2022