JDK-8231223 : C2's conditional move optimization fails with assert(bol->Opcode() == Op_Bool) failed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-09-19
  • Updated: 2022-06-27
  • Resolved: 2019-09-26
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 13 JDK 14
11.0.6-oracleFixed 13.0.4Fixed 14 b17Fixed
Related Reports
Relates :  
Description
#  Error: assert(bol->Opcode() == Op_Bool) failed

Current CompileTask:
C2:    388    2    b        Test2::test (86 bytes)

Stack: [0x00007fbfa0626000,0x00007fbfa0727000],  sp=0x00007fbfa0721080,  free space=1004k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1874417]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x2c7
V  [libjvm.so+0x187527f]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f
V  [libjvm.so+0xb4f4c0]  report_vm_error(char const*, int, char const*, char const*, ...)+0x100
V  [libjvm.so+0x12989c8]  PhaseIdealLoop::conditional_move(Node*)+0x2d8
V  [libjvm.so+0x1299d13]  PhaseIdealLoop::split_if_with_blocks_pre(Node*)+0xa3
V  [libjvm.so+0x129b59c]  PhaseIdealLoop::split_if_with_blocks(VectorSet&, Node_Stack&, bool)+0x10c
V  [libjvm.so+0x12927d2]  PhaseIdealLoop::build_and_optimize(bool, bool, bool)+0x10b2
V  [libjvm.so+0xa735e8]  Compile::Optimize()+0xbd8
V  [libjvm.so+0xa74a64]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xfc4
V  [libjvm.so+0x876771]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0xd1
V  [libjvm.so+0xa81ad3]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x403
V  [libjvm.so+0xa82af7]  CompileBroker::compiler_thread_loop()+0x377
V  [libjvm.so+0x17b9717]  JavaThread::thread_main_inner()+0x2c7
V  [libjvm.so+0x17b9a59]  JavaThread::run()+0x239
V  [libjvm.so+0x14c3fc0]  thread_native_entry(Thread*)+0x100
Comments
Fix Request (13u) This fixes C2 miscompilation. Patch applies cleanly to 13u, tier1 passed
18-05-2020

Seems to be introduced in 10 with JDK-8176506, linking up. Does not seem to affect 8u: the new regression test does not fail there.
08-10-2019

Fix Request (11u) This fixes C2 miscompilation, and keeps codebases in sync (I see 11.0.6-oracle). Patch applies cleanly to 11u, new test fails without the patch and passes with it, tier1, tier2, ctw tests pass with it.
04-10-2019

URL: https://hg.openjdk.java.net/jdk/jdk/rev/d322bf161e31 User: thartmann Date: 2019-09-26 07:16:38 +0000
26-09-2019

ILW = Crash during compilation, easy to reproduce but edge case, -XX:ConditionalMoveLimit=0 = HLM = P3
20-09-2019

Summary: After a series of loop optimizations, a skeleton range check predicate ends up with both if projections being wired to an uncommon trap region and is then considered by the conditional move optimization because the region has a suitable phi user: https://bugs.openjdk.java.net/secure/attachment/84924/graph_conditional_move.png The conditional move optimization then asserts because the range check If has an Opaque4Node input instead of a BoolNode. I propose to simply bail out in this case. Details: One of the switch branches in the inner loop gets predicated and after unrolling both loops, the other branches are found to be dead. As a result, the passing projection of the skeleton range check predicate does not point to the loop (body) anymore but to the uncommon trap as well. The generated code will immediately deoptimize but recompilation will then be more conservative. http://cr.openjdk.java.net/~thartmann/8231223/webrev.00/
20-09-2019