JDK-8325494 : C2: Broken graph after not skipping CastII node anymore for Assertion Predicates after JDK-8309902
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 21,22,23
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-02-08
  • Updated: 2024-06-24
  • Resolved: 2024-04-17
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 JDK 23
21.0.5-oracleFixed 23 b19Fixed
Related Reports
Blocks :  
Blocks :  
Relates :  
Relates :  
Description
JDK-8309902 removed code to skip a CastII node for the Initialized Assertion Predicate expression to fix a bug since it was not evident that the CastII is still required for correctness. 

I now found a fuzzer case which can be traced back to JDK-8309902, i.e. that we would still require to skip the CastII node. In the test case, we do not skip the CastII node when initializing an Assertion Predicate and as a result, the Assertion Predicate is not folded away.

We might need to revisit the fix of JDK-8309902.

Note that (at least after an initial analysis) the full fix for missing Assertion Predicates (JDK-8288981) does not help here since we have an Assertion Predicate in place - but it's unable to fold the dead path away.

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

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S9853/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/56009ff3-1ef9-43a1-9ae7-76a9d407dde0/runs/c23ecd31-3420-4318-b56a-b489ae5be3b0/workspace/open/src/hotspot/share/opto/loopopts.cpp:1675), pid=78706, tid=78753
#  assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect
#
# JRE version: Java(TM) SE Runtime Environment (23.0+7) (fastdebug build 23-ea+7-448)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 23-ea+7-448, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x12c2f48]  PhaseIdealLoop::try_sink_out_of_loop(Node*)+0xbb8
...........
Command Line: -XX:CompileCommand=quiet -XX:-TieredCompilation -Xcomp -XX:CompileOnly=Test::* Test
...........
Current CompileTask:
C2:655    6    b        Test::lMeth (286 bytes)

Stack: [0x00007f0104e00000,0x00007f0104f00000],  sp=0x00007f0104efa9c0,  free space=1002k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x12c2f48]  PhaseIdealLoop::try_sink_out_of_loop(Node*)+0xbb8  (loopopts.cpp:1675)
V  [libjvm.so+0x12c3023]  PhaseIdealLoop::split_if_with_blocks_post(Node*)+0x83
V  [libjvm.so+0x12c3896]  PhaseIdealLoop::split_if_with_blocks(VectorSet&, Node_Stack&)+0x96
V  [libjvm.so+0x12b64a7]  PhaseIdealLoop::build_and_optimize()+0xe87
V  [libjvm.so+0x9f3f08]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x388
V  [libjvm.so+0x9ecb55]  Compile::optimize_loops(PhaseIterGVN&, LoopOptsMode)+0x75
V  [libjvm.so+0x9ef301]  Compile::Optimize()+0xe21
V  [libjvm.so+0x9f2924]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1b44
V  [libjvm.so+0x846ce5]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1d5
V  [libjvm.so+0x9fe61c]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x92c
V  [libjvm.so+0x9ff2a8]  CompileBroker::compiler_thread_loop()+0x468
V  [libjvm.so+0xec18dc]  JavaThread::thread_main_inner()+0xcc
V  [libjvm.so+0x17ae046]  Thread::call_run()+0xb6
V  [libjvm.so+0x14b43b7]  thread_native_entry(Thread*)+0x127
Comments
[jdk21u-fix-request] Approval Request from Martin Should get backported for parity with 21.0.5-oracle. Applies cleanly, but I have disabled a part of an assertion because it needs JDK-8305636 which is not supposed to go into 21.0.5. This backport is very small, has been reviewed and tier 1-4 have passed. The included test fails without this fix and passes with it.
20-06-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/734 Date: 2024-06-17 15:58:39 +0000
17-06-2024

This also needs infrastructure from JDK-8305636.
18-04-2024

That's right: JDK-8319372 is the one that allows making that change (and then not running into JDK-8309902).
17-04-2024

Help me understand this. AFAICS, this change effectively reverts JDK-8309902. So how does it not re-introduce the bug fixed by JDK-8309902? From the PR comments, I gather JDK-8319372 might have resolved the issue: "The change from 8282592 caused issues because we used to narrow the type of a cast based on the condition that guards it. That was removed by 8319372." Is this correct? If so, we want this fix in JDK 21u+.
17-04-2024

Changeset: 9fd78022 Author: Roland Westrelin <roland@openjdk.org> Date: 2024-04-17 15:25:41 +0000 URL: https://git.openjdk.org/jdk/commit/9fd78022b19149ade40f92749f0b585ecfd41410
17-04-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18724 Date: 2024-04-10 13:41:11 +0000
10-04-2024

[~roland] since you worked on JDK-8309902, do you want to have a look at that?
08-02-2024

ILW = Broken graph leading to assertion failure, single fuzzer test, disable compilation of affected test = HLM = P3
08-02-2024