JDK-8309268 : C2: "assert(in_bb(n)) failed: must be" after JDK-8306302
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 21
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2023-06-01
  • Updated: 2023-07-12
  • Resolved: 2023-06-05
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
21 b26Fixed
Related Reports
Relates :  
Description
The attached Java Fuzzer test starts to fail after JDK-8306302:

To reproduce:
$ java -Xcomp -XX:CompileOnly=Test Test.java
$ java -Xcomp -XX:CompileOnly=Reduced Reduced.java
$ java -Xcomp -XX:CompileOnly=Test Test2.java
$ java -Xcomp -XX:CompileOnly=Reduced2 Reduced2.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S179616/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/6b808a31-80b5-48ac-8f1e-28ee5f1e1ca0/runs/ae4fea3e-315f-4e68-a48b-478764fcfcf2/workspace/open/src/hotspot/share/opto/superword.hpp:402), pid=2102908, tid=2102923
#  assert(in_bb(n)) failed: must be
#
# JRE version: Java(TM) SE Runtime Environment (21.0) (fastdebug build 21-internal-LTS-2023-05-30-2140444.coleen.phillimore.21jmethodid-cache)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-internal-LTS-2023-05-30-2140444.coleen.phillimore.21jmethodid-cache, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x171c17e]  SuperWord::bb_idx(Node const*) const+0x4e
...........
Command Line: -Xmx1G -Xcomp -Xbatch -XX:CompileOnly=Test -XX:CompileCommand=quiet -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=/opt/mach5/mesos/work_dir/jib-master/install/jdk/20/36/bundles/linux-x64/jdk-20_linux-x64_bin.tar.gz/jdk-20 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S179893/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2ed49270-04df-4db4-8bc3-81f8d37a701b/runs/fe3fe1ea-a469-43e4-aa21-69d5274f57f1/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_javafuzzer_MediumTest_java/tmp Test
............
Current CompileTask:
C2:   1047   71   !b  4       Test::vMeth (466 bytes)

Stack: [0x00007fcf8c0fa000,0x00007fcf8c1fb000],  sp=0x00007fcf8c1f4eb0,  free space=1003k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x171c17e]  SuperWord::bb_idx(Node const*) const+0x4e  (superword.hpp:402)
V  [libjvm.so+0x171c2a1]  SuperWord::velt_type(Node*)+0x11  (superword.hpp:430)
V  [libjvm.so+0x17122e1]  SuperWord::compute_vector_element_type()+0x451  (superword.cpp:3711)
V  [libjvm.so+0x171b458]  SuperWord::SLP_extract()+0x368  (superword.cpp:606)
V  [libjvm.so+0x171b7a9]  SuperWord::transform_loop(IdealLoopTree*, bool)+0x219  (superword.cpp:178)
V  [libjvm.so+0x1297696]  PhaseIdealLoop::build_and_optimize()+0x1096  (loopnode.cpp:4655)
V  [libjvm.so+0x9f3296]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x306  (loopnode.hpp:1121)
V  [libjvm.so+0x9ef78a]  Compile::Optimize()+0x104a  (compile.cpp:2156)
V  [libjvm.so+0x9f1f15]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1aa5  (compile.cpp:839)
V  [libjvm.so+0x84bbb4]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x3c4  (c2compiler.cpp:118)
V  [libjvm.so+0x9fdeb0]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00  (compileBroker.cpp:2265)
V  [libjvm.so+0x9fed38]  CompileBroker::compiler_thread_loop()+0x618  (compileBroker.cpp:1944)
V  [libjvm.so+0xeb6b9c]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:719)
V  [libjvm.so+0x1796d6a]  Thread::call_run()+0xba  (thread.cpp:217)
V  [libjvm.so+0x1496e1c]  thread_native_entry(Thread*)+0x11c  (os_linux.cpp:775)
Comments
The fix for this bug is integrated in jdk-21+26-2255.
05-06-2023

Changeset: 22a9a86b Author: Emanuel Peter <epeter@openjdk.org> Date: 2023-06-05 06:43:13 +0000 URL: https://git.openjdk.org/jdk/commit/22a9a86be088a3e92b231e7180a134f63716cc87
05-06-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/14268 Date: 2023-06-01 16:19:41 +0000
02-06-2023

Reduced.java -> Simple1.java ./java -Xcomp -XX:CompileCommand=compileonly,Simple1::test -XX:+TraceLoopOpts -XX:+TraceSuperWord -XX:-TieredCompilation Simple1.java This is definately a regression to JDK-8306302. The issue is that I expect the left input to the comparison to come from within the loop. But in Simple1.java we can see that the float-constant is from outside the loop. The assert is triggered when I ask for the velt_type of the inputs to the comparison. Solution: one of the two inputs must come from inside the loop, otherwise the compare would float outside the loop, and also the bool would float outside the loop. So I just need to check which one is in the loop, and take that one's velt_type.
01-06-2023

[~epeter] can you have a look?
01-06-2023

ILW = Assertion failure in Superword, two fuzzer test failures and recent regression, -XX:-UseSuperWord or disable compilation of affected method = HMM = P2
01-06-2023