JDK-8268883 : C2: assert(false) failed: unscheduable graph
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,18
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2021-06-16
  • Updated: 2021-11-12
  • Resolved: 2021-07-06
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 b30Fixed 18Fixed
Related Reports
Relates :  
JDK-8273954 - Regression 8% on Mac and 6% Windows on MonteCarlo
Relates :  
JDK-8267687 - ModXNode::Ideal optimization is better than Parse::do_irem
Relates :  
JDK-8271056 - C2: "assert(no_dead_loop) failed: dead loop detected" due to cmoving identity
Description
The attached Java Fuzzer tests starts to fail after JDK-8267687 with the following assertion failure:

To reproduce:
$ java -Xcomp -XX:-TieredCompilation -XX:CompileOnly=Test Test.java
$ java -Xcomp -XX:-TieredCompilation - XX:CompileOnly=Reduced -XX:CompileCommand=dontinline,Reduced::vMeth Reduced.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/3c846bae-ce30-4a97-93ee-9fef4497ccb6-S79067/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/be546687-12db-4ded-a96b-86062b189919/runs/56ca4e2d-638a-4f38-8b25-3d968f5f0d09/workspace/open/src/hotspot/share/opto/gcm.cpp:276), pid=21370, tid=21386
#  assert(false) failed: unscheduable graph
#
# JRE version: Java(TM) SE Runtime Environment (17.0+26) (fastdebug build 17-ea+26-LTS-2439)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-ea+26-LTS-2439, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xd2ccc2]  assert_dom(Block*, Block*, Node*, PhaseCFG const*)+0x1b2
............
Command Line: -Xmx1G -Xcomp -Xbatch -XX:-TieredCompilation -XX:CompileOnly=Test -XX:CompileCommand=quiet Test
............
Current thread (0x00007f799047fc30):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=21386, stack(0x00007f79720f8000,0x00007f79721f9000)]


Current CompileTask:
C2:   7475   64   !b        Test::mainTest (910 bytes)

Stack: [0x00007f79720f8000,0x00007f79721f9000],  sp=0x00007f79721f3cf0,  free space=1007k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xd2ccc2]  assert_dom(Block*, Block*, Node*, PhaseCFG const*)+0x1b2
V  [libjvm.so+0xd2e448]  PhaseCFG::schedule_early(VectorSet&, Node_Stack&)+0x598
V  [libjvm.so+0xd374c5]  PhaseCFG::global_code_motion()+0x295
V  [libjvm.so+0xd3b551]  PhaseCFG::do_global_code_motion()+0x51
V  [libjvm.so+0xa1cbf3]  Compile::Code_Gen()+0x293
V  [libjvm.so+0xa2818f]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x164f
V  [libjvm.so+0x84959a]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1ea
V  [libjvm.so+0xa38a89]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xfb9
V  [libjvm.so+0xa397f8]  CompileBroker::compiler_thread_loop()+0x5a8
V  [libjvm.so+0x18b2e91]  JavaThread::thread_main_inner()+0x271
V  [libjvm.so+0x18baa90]  Thread::call_run()+0x100
V  [libjvm.so+0x15872b4]  thread_native_entry(Thread*)+0x104
Comments
Verified by launching compiler/c2/TestCondAddDeadBranch.java in mach5 in JDK17 ATR configuration. Also checked there are no failures in CI
09-08-2021
Changeset: 6d8fc724 Author: Roland Westrelin <roland@openjdk.org> Date: 2021-07-06 06:47:45 +0000 URL: https://git.openjdk.java.net/jdk17/commit/6d8fc7249a3a1a2350c462f9c4fe38377856392f
06-07-2021
[~roland] Thanks, please go ahead.
30-06-2021
[~yyang] I've started to investigate it. I'm not sure what's going on at this point. Would you like me to take it over?
29-06-2021
[~roland] Thanks for the explanation. The problem is, ConvL2I is initially a type of int, then its type is narrowed(raise_bottom_type) to int:1..54 immediately. But later, its input is transformed to a different node 705#ConL(long:0). When we compute ConvL2I::Value then, a Type::TOP is returned. ---- Detail: 4434 ConvL2I === _ 4433 [[]] Type:int 4434 ConvL2I === _ 4433 [[]] Type:int:1..54 Pop 4434 ConvL2I === _ 4433 [[ 4441 4440 ]] Type:int:1..54 ... Pop 4433 RShiftL === _ 705 2106 [[ 4434 ]] Type:long < long:0..715827882:www < 4433 RShiftL === _ _ _ [[]] > long:0 705 ConL === 0 [[ 3871 2297 2294 712 4451 4434 ]] Type:long:0 ... Pop 4434 ConvL2I === _ 705 [[ 4441 4440 ]] Type:int:1..54 < int:1..54:www < 4434 ConvL2I === _ _ [[]] > top 1 Con === 0 [[]] Type:top
29-06-2021
[~yyang] to mirror ConvI2LNode::Value() that does that. Why would they not behave the same? In any case, the resulting type of ConvL2I is the intersection of _type and the its input's type. That's the whole point of having a _type field. So the type of the result of the ConvL2I can be narrowed further.
28-06-2021
Bringing in [~roland] here, for above question.
28-06-2021
I'd like to give a detailed analysis in PR, but before that, I want to make sure this is a reasonable fix... It seems that a ConvL2I node is incorrectly transformed to 1#Con(Top) unreachable node during IGVN, and finally leads to unscheduable graph in GCM phase. @roland, do you have any comments on why you change bottom_type() to ti->filter(_type) in https://github.com/openjdk/jdk/commit/3d460bd2? I don't see any guarantees to ensure that type of in(1) contains ConvL2I->_type in common cases. In this case, ConvL2I->_type is int:1..54 and its in(1) is type of long:0, so ConvL2I::Value gets a Type::TOP: ConvL2I->_type => int:1..54 ConvL2I->in(1) => long:0 ti => int:0 ti->dual() => int:0 _type->dual() => int:54..1 ti->filter(_type) => ti->dual()->meet(_type->dual())->dual() => int:1..0 => hi<lo, gets Type::Top Restoring original code in ConvL2INode::Value solves this problem, but I'm not sure if you have other concerns about it. --- IGVN process: At first, in(1) of 4434#ConvL2I is 4433#RShiftL, Pop 4434 ConvL2I === _ 4433 [[ 4441 4440 ]] Type:int:1..54 During IGVN, its input is transformed to 705#ConL, Pop 4433 RShiftL === _ 705 2106 [[ 4434 ]] Type:long < long:0..715827882:www < 4433 RShiftL === _ _ _ [[]] [324204433] > long:0 705 ConL === 0 [[ 3871 2297 2294 712 4451 4434 ]] Type:long:0 So in(1) of 4434#ConvL2I becomes 705#ConL, finally 4434#ConvL2I is transformed to 1#Con(Top), that's not what we expect. Pop 4434 ConvL2I === _ 705 [[ 4441 4440 ]] Type:int:1..54 < int:1..54:www < 4434 ConvL2I === _ _ [[]] [324204434] !orig=[4437],[4436],[4427] > top 1 Con === 0 [[]] Type:top
28-06-2021
Starts to fail after JDK-8267687. [~yyang] can you take a look at it?
16-06-2021
ILW = C2 assertion failure in global code motion (recent regression in JDK 17 b26), with single (so far) Java Fuzzer test, disable compilation of affected method = HMM = P2
16-06-2021