Found by Olivier Mattmann <olivier.mattmann@bluewin.ch> during work on this Master thesis where he is working on a fuzzer for C2 ( JDK-8370562).

After integration of JDK-8342382 the attached reproducer TestNotLongReduced.java started failing on the OSR-compilation of the TestNotLongReduced.test method:

java -Xbatch -XX:-TieredCompilation -XX:CompileCommand=compileonly,TestNotLongReduced.test TestNotLongReduced.java

# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/jdk/src/hotspot/share/opto/type.hpp:2210), pid=252145, tid=252160
# assert(_base == Long) failed: Not a Long
#
# JRE version: Java(TM) SE Runtime Environment (27.0) (fastdebug build 27-internal-mhassig.open)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 27-internal-mhassig.open, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x67f18e] Type::is_long() const [clone .part.0] [clone .isra.0]+0x2e

Current CompileTask:
C2:1969 107 % b TestNotLongReduced::test @ 85 (118 bytes)

Stack: [0x00007f5c9b2f4000,0x00007f5c9b3f4000], sp=0x00007f5c9b3eecd0, free space=1003k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x67f18e] Type::is_long() const [clone .part.0] [clone .isra.0]+0x2e (type.hpp:2210)
V [libjvm.so+0x68011a] fold_subI_no_underflow_pattern(Node*, PhaseGVN*)+0x2ba (type.hpp:2210)
V [libjvm.so+0x189158d] PhaseIterGVN::transform_old(Node*)+0xbd (phaseX.cpp:668)
V [libjvm.so+0x18960b5] PhaseIterGVN::optimize()+0xc5 (phaseX.cpp:1054)
V [libjvm.so+0xbb50a2] PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x672 (loopnode.hpp:1344)
V [libjvm.so+0xbabe61] Compile::optimize_loops(PhaseIterGVN&, LoopOptsMode)+0xb1 (compile.cpp:2266)
V [libjvm.so+0xbaed8f] Compile::Optimize()+0xcbf (compile.cpp:2515)
V [libjvm.so+0xbb1f33] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x2023 (compile.cpp:860)
V [libjvm.so+0x9cc6e8] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x498 (c2compiler.cpp:147)
V [libjvm.so+0xbc1420] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x780 (compileBroker.cpp:2345)
V [libjvm.so+0xbc2c80] CompileBroker::compiler_thread_loop()+0x530 (compileBroker.cpp:1989)
V [libjvm.so+0x1124d7b] JavaThread::thread_main_inner()+0x13b (javaThread.cpp:776)
V [libjvm.so+0x1ba9036] Thread::call_run()+0xb6 (thread.cpp:242)
V [libjvm.so+0x17fe7d8] thread_native_entry(Thread*)+0x118 (os_linux.cpp:860)

Since this failure has nothing to do with G1 barriers, my next best guess would be JDK-8303466 that introduced fold_subI_no_underflow and its callers. The G1 changes probably lifted the bug into the light. But this paragraph is pure speculation on my part.

Other attached tests
 - TestNotLong.java: unreduced fuzzer output, reproduces with `-XX:-TieredCompilation -XX:CompileCommand=compileonly,TestNotLong.test` after at most 20 repetitions
 - TestOtherNotLong.java & TestOtherNotLongReduced.java: Failed at one point (some later 26 builds) with `-Xbatch -XX:-TieredCompilation`, but do not fail anymore for 27+1.