Bug ID: JDK-8280799 С2: assert(false) failed: cyclic dependency prevents range check elimination

JDK-8280799 : С2: assert(false) failed: cyclic dependency prevents range check elimination

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

Priority: P3
Status: Resolved
Resolution: Fixed

Submitted: 2022-01-27
Updated: 2023-08-09
Resolved: 2022-02-14

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

Related Reports

Relates :	JDK-8281811 - assert(_base == Tuple) failed: Not a Tuple after JDK-8280799
Relates :	JDK-8283834 - Unmappable character for US-ASCII encoding in TestPredicateInputBelowLoopPredicate
Relates :	JDK-8272574 - C2: assert(false) failed: Bad graph detected in build_loop_late
Relates :	JDK-8314024 - SIGSEGV in PhaseIdealLoop::build_loop_late_post_work due to bad immediate dominator info
Relates :	JDK-8282592 - C2: assert(false) failed: graph should be schedulable
Relates :	JDK-8291919 - [11u] High compiler native memory consumption after JDK-8279219

Description

Reliably reproduces in 11u after JDK-8272574 backport, but maybe it affects mainline too:

$ CONF=linux-x86_64-normal-server-fastdebug make run-test TEST=jdk/javadoc/doclet/ TEST_VM_OPTS="-XX:+UseParallelGC"

#  Internal Error (/home/shade/trunks/shipilev-jdk11u-dev/src/hotspot/share/opto/loopPredicate.cpp:675), pid=116243, tid=119644
#  assert(false) failed: cyclic dependency prevents range check elimination, idx: offset 6068, offset_ctrl 2894, predicate_proj 2892


Current CompileTask:
C2:  37659 6256       4       jdk.javadoc.internal.doclets.toolkit.util.DocLink::relativizeAgainst (90 bytes)

Stack: [0x00007f1b557e0000,0x00007f1b558e1000],  sp=0x00007f1b558d9f40,  free space=999k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1b3a43a]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x1ca
V  [libjvm.so+0x1b3b5a5]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x35
V  [libjvm.so+0xbfb55a]  report_vm_error(char const*, int, char const*, char const*, ...)+0x10a
V  [libjvm.so+0x13a3ba9]  IdealLoopTree::is_range_check_if(IfNode*, PhaseIdealLoop*, Invariance&, ProjNode*) const [clone .part.0]+0x3c9
V  [libjvm.so+0x13a697e]  PhaseIdealLoop::loop_predication_impl_helper(IdealLoopTree*, ProjNode*, ProjNode*, CountedLoopNode*, ConNode*, Invariance&, Deoptimization::DeoptReason)+0x37e
V  [libjvm.so+0x13a845e]  PhaseIdealLoop::loop_predication_impl(IdealLoopTree*) [clone .part.0]+0x50e
V  [libjvm.so+0x13a92a9]  IdealLoopTree::loop_predication(PhaseIdealLoop*)+0x109
V  [libjvm.so+0x13a91e9]  IdealLoopTree::loop_predication(PhaseIdealLoop*)+0x49
V  [libjvm.so+0x13a91e9]  IdealLoopTree::loop_predication(PhaseIdealLoop*)+0x49
V  [libjvm.so+0x13a91e9]  IdealLoopTree::loop_predication(PhaseIdealLoop*)+0x49
V  [libjvm.so+0x13a91e9]  IdealLoopTree::loop_predication(PhaseIdealLoop*)+0x49
V  [libjvm.so+0x13ece96]  PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x1266
V  [libjvm.so+0xb0d7f7]  Compile::optimize_loops(int&, PhaseIterGVN&, LoopOptsMode) [clone .part.0]+0x307
V  [libjvm.so+0xb11dcf]  Compile::Optimize()+0xd0f
V  [libjvm.so+0xb13ddc]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x1aec
V  [libjvm.so+0x8ee144]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x334
V  [libjvm.so+0xb246f0]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x540
V  [libjvm.so+0xb25d98]  CompileBroker::compiler_thread_loop()+0x678
V  [libjvm.so+0x1a6ebc2]  JavaThread::thread_main_inner()+0x252
V  [libjvm.so+0x1a67dfb]  Thread::call_run()+0x7b
V  [libjvm.so+0x164eb26]  thread_native_entry(Thread*)+0x116



==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/langtools/jdk/javadoc/doclet             187   177     0    10 <<
==============================
TEST FAILURE

Comments

[~clanger] I didn't realize it was required. Done now.
13-04-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk11u-dev/pull/1035 Date: 2022-04-13 11:11:16 +0000
13-04-2022
[~roland], I think this backport is viable for 11u. However, I'd like to ask you to open the PR(s) before requesting it. Hence, for the time being I'm removing the fix-request label to get the item off the maintainers list until then.
13-04-2022
Fix Request (11u): I'd like to backport this change because we hit that failure in our testing (the bug was actually filed against 11 initially). It applies cleanly. tier1 test passes. I'll backport JDK-8281811 and JDK-8283834 as well. JDK-8282592 is not directly related so I'll skip that backport at least for now.
11-04-2022
I've created dependent PRs for the related fixes. (The 4th one is already in 17.0.2.) Note that Oracle will probably ignore the Shenandoah fix for 17.0.4-oracle.
31-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk17u-dev/pull/310 Date: 2022-03-30 10:27:46 +0000
30-03-2022
[17u] There seem to be follow up fixes. Are they needed? Should we wait a bit with this change?
30-03-2022
Fix Request (17u): Should get backported for parity with 17.0.4-oracle. Applies cleanly. Test has passed.
30-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk18u/pull/74 Date: 2022-03-29 15:57:37 +0000
29-03-2022
Fix Request (JDK 18u) Fixes an assert in C2. The fix is medium risk and applies cleanly. Already tested and about to be backported to Oracle JDK 17u. Tier 1-3 testing is running for JDK 18u.
29-03-2022
Changeset: 1ef45c5b Author: Roland Westrelin <roland@openjdk.org> Date: 2022-02-14 08:35:53 +0000 URL: https://git.openjdk.java.net/jdk/commit/1ef45c5bbdeb4e1ca65c6d8f3ac1568a6951f3a7
14-02-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/7319 Date: 2022-02-02 10:38:11 +0000
02-02-2022
ILW = missing optimization/assert in debug build; at least 1 reproducer; no workaround = MMH = P3
28-01-2022
I could reproduce a similar failure with mainline (custom test case) and the same fix works for mainline and the 11 failure.
28-01-2022