JDK-8288112 : C2: Error: ShouldNotReachHere() in Type::typerr()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 19
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-06-09
  • Updated: 2022-07-27
  • Resolved: 2022-07-14
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 19 JDK 20
19 b32Fixed 20Fixed
Related Reports
Duplicate :  
JDK-8288903 - ShouldNotReachHere() in Type::typerr() after 8284960
Relates :  
JDK-8284960 - Integration of JEP 426: Vector API (Fourth Incubator)
Relates :  
JDK-8290034 - Auto vectorize reverse bit operations.
Description
The attached Java Fuzzer test fails after JDK-8284960 (Ihe integration of JEP 426: Vector API (Fourth Incubator)):

To reproduce

$ javac FuzzerUtils.java 
$ java -Xcomp -XX:CompileOnly=Test Test.java
$ java -Xcomp -XX:CompileOnly=Reduced Reduced.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/779adf21-f3e5-4e6a-a889-8cc0f9bc6fbb-S66862/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/e7a5f059-99c2-4c80-b089-a6e1a468a184/runs/f86e41f7-d216-4fe3-8825-70c90f059250/workspace/open/src/hotspot/share/opto/type.cpp:1164), pid=12242, tid=12255
#  Error: ShouldNotReachHere()
#
# JRE version: Java(TM) SE Runtime Environment (19.0+25) (fastdebug build 19-ea+25-1892)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-ea+25-1892, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1a9c469]  Type::typerr(Type const*) const+0x79
...........
Command Line: -Xmx1G -Xcomp -Xbatch -XX:CompileOnly=Test -XX:CompileCommand=quiet Test
...........
Current CompileTask:
C2:    311   14    b  4       Test::vMeth1 (262 bytes)

Stack: [0x00007fe8656d2000,0x00007fe8657d3000],  sp=0x00007fe8657cd4d0,  free space=1005k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1a9c469]  Type::typerr(Type const*) const+0x79
V  [libjvm.so+0x1a9ebbb]  TypeVect::xmeet(Type const*) const+0x1eb
V  [libjvm.so+0x1aa3e93]  Type::meet_helper(Type const*, bool) const+0x73
V  [libjvm.so+0x63bfd9]  AddNode::add_of_identity(Type const*, Type const*) const+0x39
V  [libjvm.so+0x63c1f8]  AddNode::Value(PhaseGVN*) const+0xe8
V  [libjvm.so+0x17bd373]  PhaseIterGVN::transform_old(Node*)+0x233
V  [libjvm.so+0x17b64ee]  PhaseIterGVN::optimize()+0x6e
V  [libjvm.so+0xae290a]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x65a
V  [libjvm.so+0xaded57]  Compile::Optimize()+0x1027
V  [libjvm.so+0xae0ee0]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1520
V  [libjvm.so+0x8f826a]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x62a
V  [libjvm.so+0xaef9a8]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xbb8
V  [libjvm.so+0xaf0998]  CompileBroker::compiler_thread_loop()+0x6f8
V  [libjvm.so+0x1a6c1ac]  JavaThread::thread_main_inner()+0x23c
V  [libjvm.so+0x1a77690]  Thread::call_run()+0x100
V  [libjvm.so+0x1729454]  thread_native_entry(Thread*)+0x104
Comments
Another failure mode that triggered with a recent JavaFuzzer generated test: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (workspace/open/src/hotspot/share/opto/type.hpp:1807), pid=47415, tid=47428 # assert(_base == FloatCon) failed: Not a FloatCon # # JRE version: Java(TM) SE Runtime Environment (20.0+7) (fastdebug build 20-ea+7-317) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+7-317, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x19ce35c] SubFNode::sub(Type const*, Type const*) const+0x9c Current CompileTask: C2: 169 74 !b 4 Test::mainTest (779 bytes) Stack: [0x00007f0ba6e83000,0x00007f0ba6f84000], sp=0x00007f0ba6f7e540, free space=1005k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x19ce35c] SubFNode::sub(Type const*, Type const*) const+0x9c V [libjvm.so+0x17d7763] PhaseIterGVN::transform_old(Node*)+0x233 V [libjvm.so+0x17d083e] PhaseIterGVN::optimize()+0x6e V [libjvm.so+0xb12cfa] PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x65a V [libjvm.so+0xb0f0a7] Compile::Optimize()+0x1027 V [libjvm.so+0xb112d0] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x15c0 V [libjvm.so+0x921593] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x683 V [libjvm.so+0xb20048] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xbb8 V [libjvm.so+0xb21008] CompileBroker::compiler_thread_loop()+0x6c8 V [libjvm.so+0x106d3a8] JavaThread::thread_main_inner()+0x238 V [libjvm.so+0x1a8bee0] Thread::call_run()+0x100 V [libjvm.so+0x174f014] thread_native_entry(Thread*)+0x104 I verified that this patch fixes the issue.
18-07-2022
Changeset: fd89ab8d Author: Jatin Bhateja <jbhateja@openjdk.org> Date: 2022-07-14 01:46:11 +0000 URL: https://git.openjdk.org/jdk19/commit/fd89ab8dacda1d6af5bd4be57a83362c8cdd5e20
14-07-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk19/pull/128 Date: 2022-07-08 21:57:33 +0000
08-07-2022
Found and attached another fuzzer failure (Reduced2.java) which is probably the same issue but with a different manifestation: $ java -Xcomp -XX:CompileOnly=Reduced2 Reduced2.java Crashes with: assert(_base == Int) failed: Not an Int
05-07-2022
Comments from JDK-8288903 from Dean: Error mixing types: vectory[8]:{int} and int:0 The assert is because AddI(LoadI, ConI) is replaced with AddI(LoadVector, ConI) and then AddNode::add_of_identity() causes TypeVect::xmeet() to be called with types vectory[8]:{int} and int:0. I'm not an expert on this code, but I think the problem is ReverseBytesV was introduced, but SuperWord::output() does not recognize Op_ReverseBytes{I,L,S,US}. There may be a similar problem with ReverseV and Reverse{I,L}.
27-06-2022
ILW = C2 assertion in AddNode::Value() with vectors, single Java fuzzer test, workaround: -XX:DisableIntrinsic=_reverseBytes_i = HLM = P3
27-06-2022
Confirming I can reproduce for commit https://github.com/openjdk/jdk/commit/6f6486e97743eadfb20b4175e1b4b2b05b59a17a, and it does not reproduce for the parent commit.
09-06-2022