JDK-8290850 : C2: create_new_if_for_predicate() does not clone pinned phi input nodes resulting in a broken graph
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,18,19,20
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2022-07-21
  • Updated: 2022-12-19
  • Resolved: 2022-12-08
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 20
17.0.7-oracleFixed 20 b27Fixed
Related Reports
Relates :  
Relates :  
Description
The following test failed in the JDK19 CI:

applications/javafuzzer/BigTest.java

Here are snippets from the hs_err_pid22431.log:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S8380/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/88248b69-8047-48f5-b430-1f3ab95724f1/runs/d2b0a451-db74-42e5-988b-bdc60803b0cd/workspace/open/src/hotspot/share/opto/loopnode.cpp:5856), pid=22431, tid=22444
#  assert(false) failed: Bad graph detected in build_loop_late
#
# JRE version: Java(TM) SE Runtime Environment (19.0+32) (fastdebug build 19-ea+32-2213)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-ea+32-2213, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x14cc687]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x187

<snip>

---------------  T H R E A D  ---------------

Current thread (0x00007fc8882e1360):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=22444, stack(0x00007fc861dfe000,0x00007fc861eff000)]


Current CompileTask:
C2:   2644   77    b  4       Test::mainTest (505 bytes)

Stack: [0x00007fc861dfe000,0x00007fc861eff000],  sp=0x00007fc861ef8fa0,  free space=1003k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x14cc687]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x187
V  [libjvm.so+0x14cce42]  PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0xb2
V  [libjvm.so+0x14cd8d7]  PhaseIdealLoop::build_and_optimize()+0x617
V  [libjvm.so+0xb05d5a]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x27a
V  [libjvm.so+0xb02587]  Compile::Optimize()+0x1027
V  [libjvm.so+0xb04710]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1520
V  [libjvm.so+0x91bd7a]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x62a
V  [libjvm.so+0xb13278]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xbb8
V  [libjvm.so+0xb14268]  CompileBroker::compiler_thread_loop()+0x6f8
V  [libjvm.so+0x1aa2258]  JavaThread::thread_main_inner()+0x238
V  [libjvm.so+0x1aad8f0]  Thread::call_run()+0x100
V  [libjvm.so+0x175e844]  thread_native_entry(Thread*)+0x104
Comments
Changeset: 49b86224 Author: Christian Hagedorn <chagedorn@openjdk.org> Date: 2022-12-08 11:23:42 +0000 URL: https://git.openjdk.org/jdk/commit/49b86224aacc7fd8b4d3354a85d72ef636a18a12
08-12-2022

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/11452 Date: 2022-12-01 12:26:56 +0000
01-12-2022

Attached another test case Test-3.java with its reduced version Reduced-3.java taken from JDK-8293941: $ java -Xcomp -XX:CompileOnly=Reduced -XX:-TieredCompilation Reduced.java
22-11-2022

All 3 cases are related and reveal the same problem which is, however, unrelated to JDK-8288941. These cases can be traced back to the RFE to sink nodes out of a loop (JDK-8252372). They are closely related to JDK-8271954 but do not apply to loop unswitching but to loop predication instead. I think we can reuse parts of the fix for this new case here. Updated ILW = C2 assertion due to broken graph, only few fuzzer generated tests, use -XX:-SplitIfBlocks or disable compilation of affected method = HLM = P3
22-11-2022

Reduced.java is a reduced version of Test.java: $ java -Xcomp -XX:-TieredCompilation -XX:CompileOnly=Reduced Reduced.java Reduced-1.java is a reduced version of Test-1.java: $ java -Xcomp -XX:CompileOnly=Reduced Reduced-1.java Reduced-2.java is a reduced version of Test-2.java $ java -Xcomp -XX:CompileOnly=Reduced Reduced-2.java
22-11-2022

I attached another JavaFuzzer found test (Test-1.java) that triggers the same assert. I traced it back to JDK-8273612 in JDK 18 b18 but that patch only changed the behavior with -Xcomp.
25-07-2022

[~chagedorn], it looks like it could be a duplicate of JDK-8288941.
22-07-2022

ILW = same as JDK-8288941 = P3
22-07-2022