JDK-8350576 : C2: assert(false) failed: reduction has ctrl or bad vector_input
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 22,24,25
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2025-02-24
  • Updated: 2025-05-27
  • Resolved: 2025-05-27
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.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8352893 - C2: OrL/INode::add_ring optimize (x | -1) to -1
Relates :  
JDK-8357816 - Add test from JDK-8350576
Relates :  
JDK-8319372 - C2 compilation fails with "Bad immediate dominator info"
Relates :  
JDK-8352893 - C2: OrL/INode::add_ring optimize (x | -1) to -1
Description
The attached Java Fuzzer test fails with the following assertion after JDK-8319372 which removed some type optimization for CastII nodes (probably unrelated but triggering the issue):

$ java -XX:CompileCommand=compileonly,*Test*::* -Xbatch -XX:-TieredCompilation Test.java
$ java -XX:CompileCommand=compileonly,*Reduced*::* -Xbatch -XX:-TieredCompilation Reduced.java

Output:
 520  Replicate  === _ 81  [[ 523 538 626 693 694 775 776 777 778 ]]  #vectory<J,4> !orig=[522],[463],[413],[131] !jvms: Reduced::test @ bci:19 (line 10)
 626  AddReductionVL  === _ 693 520  [[ 523 ]] no_strict_order !orig=523,[462],[412],[132] !jvms: Reduced::test @ bci:20 (line 10)
 523  AddReductionVL  === _ 626 520  [[ 806 134 559 551 ]] no_strict_order !orig=[462],[412],[132] !jvms: Reduced::test @ bci:20 (line 10)

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (c:\sb\prod\1739659512\workspace\open\src\hotspot\share\opto\loopopts.cpp:4584), pid=13500, tid=13964
#  assert(false) failed: reduction has ctrl or bad vector_input
#
# JRE version: Java(TM) SE Runtime Environment (25.0+11) (fastdebug build 25-ea+11-LTS-1137)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-ea+11-LTS-1137, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0xbf948a]  PhaseIdealLoop::move_unordered_reduction_out_of_loop+0x9fa
.............
Command Line: -Xmx1G -XX:+IgnoreUnrecognizedVMOptions -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,*Test*::* -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:StressSeed=1648090214 -Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressIGVN -XX:+StressCCP -XX:+StressMacroExpansion -XX:+VerifyLoopOptimizations -XX:VerifyIterativeGVN=10 -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=c:\ade\mesos\work_dir\jib-master\install\jdk\23\37\bundles\windows-x64\jdk-23_windows-x64_bin.zip\jdk-23 -Djava.io.tmpdir=c:\sb\prod\1739777846\testoutput\test-support\jtreg_closed_test_hotspot_jtreg_applications_javafuzzer_BigTest_java\tmp -XX:+CreateCoredumpOnCrash Test
.............
C2:1224    3 %  b        Test::lMeth @ 51 (187 bytes)

Stack: [0x000000cfd6700000,0x000000cfd6800000],  sp=0x000000cfd67fb700,  free space=1005k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xbf948a]  PhaseIdealLoop::move_unordered_reduction_out_of_loop+0x9fa  (loopopts.cpp:4584)
V  [jvm.dll+0xbcb07b]  PhaseIdealLoop::build_and_optimize+0x11bb  (loopnode.cpp:4988)
V  [jvm.dll+0x55c3cc]  Compile::Optimize+0xb4c  (compile.cpp:2418)
V  [jvm.dll+0x559396]  Compile::Compile+0x1096  (compile.cpp:849)
V  [jvm.dll+0x460c69]  C2Compiler::compile_method+0x179  (c2compiler.cpp:144)
V  [jvm.dll+0x5772ba]  CompileBroker::invoke_compiler_on_method+0x7aa  (compileBroker.cpp:2331)
V  [jvm.dll+0x57480b]  CompileBroker::compiler_thread_loop+0x33b  (compileBroker.cpp:1976)
V  [jvm.dll+0x8c22b2]  JavaThread::thread_main_inner+0x282  (javaThread.cpp:777)
V  [jvm.dll+0xfb1114]  Thread::call_run+0x1b4  (thread.cpp:236)
V  [jvm.dll+0xd72791]  thread_native_entry+0xe1  (os_windows.cpp:566)
C  [ucrtbase.dll+0x26b4c]  (no source info available)
C  [KERNEL32.DLL+0x14cb0]  (no source info available)
C  [ntdll.dll+0x7ecdb]  (no source info available)
Comments
Makes sense. I filed JDK-8357816 for the test integration and will close this as duplicate.
27-05-2025
[~thartmann] This should now be fixed with JDK-8352893. But we could convert this into a starter task to add the attached test as a JTREG test.
26-05-2025
I'm moving this to tbd. If we find other Fuzzer failures after JDK-8352893, then we have to reconsider. But in my understanding, the assert is there to reveal missing optimizations, and in product we just do not optimize and continue compiling safely.
25-03-2025
So, here my second step of analysis: Generally, the assumption of the assert is that we should not be reducing things that come strictly from outside the loop, because we could do the reduction more smartly, i.e. possibly even without the loop. The reduction used to have a dependency on "i", and so the computation is loop dependent and we vectorize. But after vectorization, OrVNode::Identity realizes that the OrV has an all ones (all -1 elements) input, which means the result is all -1, i.e. all loop independent. And so we now lost the "i" depenedence, and hit the assert in "move_unordered_reduction_out_of_loop". I have done an initial experiment, and filed JDK-8352893: we can already optimize the scalar "x + -1" to "-1", and then we would avoid the issue, i.e. we would never generate a reduction with loop independent inputs. Hitting this assert leads to an optimization bailout, so it is harmless. And I would prefer not to remove the assert, because it showed us a missing optimization, and may show us similar issues in the future.
25-03-2025
First analysis: It seems that the expression "x | -1" does not get idealized, but the vectorized version does! OrVNode::Identity checks for is_all_ones_vector and replaces "x | Replicate(-1)" with "-1". Before this, the dependency on "x" kept the input inside the loop, after this, it only depends on the replicated constant, which is outside the loop! That creates a shape that has not existed before. Still, I think we can remove the assert and just do "move_unordered_reduction_out_of_loop" even when the vector input is outside the loop.
25-03-2025
ILW = Assertion failure when trying to move reduction out of a loop - harmless in product due to bailout from optimization, single Java Fuzzer case, disable compilation or use -XX:-UseSuperWord = HLM = P3
24-02-2025