Summary:
AArch64 binds some trampoline call-sites early, thanks to its is_always_within_branch_range() check. This allows a false positive match with a trampoline stub during code buffer expansion in rare situations.

Original description:
We have been seeing some errors in constantPool being reported as unexpected bytecodes during testing in Graal CI contexts. All runs have been running C2 as top tier compiler (without Graal) so we believe this is an upstream bug.

The errors are always in constantPool.cpp:706 but the bytecodes differ.

An example error

Unexpected bytecode: 188
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (constantPool.cpp:706), pid=7132, tid=7133
# Error: ShouldNotReachHere()
#
# JRE version: Java(TM) SE Runtime Environment (22.0+25) (build 22+25-jvmci-b01)

with the stack
Stack: [0x0000ffffa4e10000,0x0000ffffa500e000], sp=0x0000ffffa500a1b0, free space=2024k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x5c2c24] ConstantPool::klass_ref_at(int, Bytecodes::Code, JavaThread*)+0x184 (constantPool.cpp:706)
V [libjvm.so+0xa3e268] LinkResolver::resolve_method_statically(Bytecodes::Code, constantPoolHandle const&, int, JavaThread*)+0x54
V [libjvm.so+0x421fb4] Bytecode_invoke::static_target(JavaThread*)+0xa4
V [libjvm.so+0xc360d8] SharedRuntime::find_callee_info_helper(vframeStream&, Bytecodes::Code&, CallInfo&, JavaThread*)+0x3f8
V [libjvm.so+0xc36238] SharedRuntime::find_callee_info(Bytecodes::Code&, CallInfo&, JavaThread*)+0x68
V [libjvm.so+0xc3635c] SharedRuntime::resolve_sub_helper(bool, bool, JavaThread*)+0xcc
V [libjvm.so+0xc3653c] SharedRuntime::resolve_helper(bool, bool, JavaThread*)+0x3c
V [libjvm.so+0xc36a2c] SharedRuntime::resolve_opt_virtual_call_C(JavaThread*)+0x3c
v ~RuntimeStub::resolve_opt_virtual_call 0x0000ffff9002c210
J 3293 c2 jdk.tools.jlink.plugin.ResourcePoolEntry.write(Ljava/io/OutputStream;)V jdk.jlink@22 (24 bytes) @ 0x0000ffff90c03c20 [0x0000ffff90bfff80+0x0000000000003ca0]
J 3249 c1 jdk.tools.jlink.internal.ImageFileCreator$$Lambda+0x00000240010f66a0.accept(Ljava/lang/Object;)V jdk.jlink@22 (12 bytes) @ 0x0000ffff89288458 [0x0000ffff892881c0+0x0000000000000298]
J 3279% c2 java.util.ArrayList.forEach(Ljava/util/function/Consumer;)V java.base@22 (74 bytes) @ 0x0000ffff90bc17bc [0x0000ffff90bc16c0+0x00000000000000fc]
j jdk.tools.jlink.internal.ImageFileCreator.generateJImage(Ljdk/tools/jlink/internal/ResourcePoolManager;Ljdk/tools/jlink/internal/BasicImageWriter;Ljdk/tools/jlink/internal/ImagePluginStack;Ljava/io/DataOutputStream;)Ljdk/tools/jlink/plugin/ResourcePool;+147 jdk.jlink@22
j jdk.tools.jlink.internal.ImageFileCreator.writeImage(Ljava/util/Set;Ljava/nio/ByteOrder;)V+39 jdk.jlink@22
j jdk.tools.jlink.internal.ImageFileCreator.create(Ljava/util/Set;Ljava/nio/ByteOrder;Ljdk/tools/jlink/internal/ImagePluginStack;)Ljdk/tools/jlink/internal/ExecutableImage;+17 jdk.jlink@22
j jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(Ljdk/tools/jlink/internal/ImagePluginStack;)Ljdk/tools/jlink/internal/ExecutableImage;+15 jdk.jlink@22
j jdk.tools.jlink.internal.ImagePluginStack.operate(Ljdk/tools/jlink/internal/ImagePluginStack$ImageProvider;)V+2 jdk.jlink@22
j jdk.tools.jlink.internal.JlinkTask.createImage(Ljdk/tools/jlink/internal/Jlink$JlinkConfiguration;)V+141 jdk.jlink@22
j jdk.tools.jlink.internal.JlinkTask.run([Ljava/lang/String;)I+433 jdk.jlink@22
j jdk.tools.jlink.internal.Main.run(Ljava/io/PrintWriter;Ljava/io/PrintWriter;[Ljava/lang/String;)I+37 jdk.jlink@22
j jdk.tools.jlink.internal.Main.main([Ljava/lang/String;)V+23 jdk.jlink@22
v ~StubRoutines::call_stub 0x0000ffff8fff0154
V [libjvm.so+0x7fb738] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x218
V [libjvm.so+0x899bc4] jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) [clone .constprop.1]+0x234
V [libjvm.so+0x89b9ec] jni_CallStaticVoidMethod+0xec
C [libjli.so+0x510c] JavaMain+0xdec
C [libjli.so+0x79ec] ThreadJavaMain+0xc
C [libpthread.so.0+0x7ddc] start_thread+0xb4
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v ~RuntimeStub::resolve_opt_virtual_call 0x0000ffff9002c210
J 3293 c2 jdk.tools.jlink.plugin.ResourcePoolEntry.write(Ljava/io/OutputStream;)V jdk.jlink@22 (24 bytes) @ 0x0000ffff90c03c20 [0x0000ffff90bfff80+0x0000000000003ca0]
J 3249 c1 jdk.tools.jlink.internal.ImageFileCreator$$Lambda+0x00000240010f66a0.accept(Ljava/lang/Object;)V jdk.jlink@22 (12 bytes) @ 0x0000ffff89288458 [0x0000ffff892881c0+0x0000000000000298]
J 3279% c2 java.util.ArrayList.forEach(Ljava/util/function/Consumer;)V java.base@22 (74 bytes) @ 0x0000ffff90bc17bc [0x0000ffff90bc16c0+0x00000000000000fc]
j jdk.tools.jlink.internal.ImageFileCreator.generateJImage(Ljdk/tools/jlink/internal/ResourcePoolManager;Ljdk/tools/jlink/internal/BasicImageWriter;Ljdk/tools/jlink/internal/ImagePluginStack;Ljava/io/DataOutputStream;)Ljdk/tools/jlink/plugin/ResourcePool;+147 jdk.jlink@22
j jdk.tools.jlink.internal.ImageFileCreator.writeImage(Ljava/util/Set;Ljava/nio/ByteOrder;)V+39 jdk.jlink@22
j jdk.tools.jlink.internal.ImageFileCreator.create(Ljava/util/Set;Ljava/nio/ByteOrder;Ljdk/tools/jlink/internal/ImagePluginStack;)Ljdk/tools/jlink/internal/ExecutableImage;+17 jdk.jlink@22
j jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(Ljdk/tools/jlink/internal/ImagePluginStack;)Ljdk/tools/jlink/internal/ExecutableImage;+15 jdk.jlink@22
j jdk.tools.jlink.internal.ImagePluginStack.operate(Ljdk/tools/jlink/internal/ImagePluginStack$ImageProvider;)V+2 jdk.jlink@22
j jdk.tools.jlink.internal.JlinkTask.createImage(Ljdk/tools/jlink/internal/Jlink$JlinkConfiguration;)V+141 jdk.jlink@22
j jdk.tools.jlink.internal.JlinkTask.run([Ljava/lang/String;)I+433 jdk.jlink@22
j jdk.tools.jlink.internal.Main.run(Ljava/io/PrintWriter;Ljava/io/PrintWriter;[Ljava/lang/String;)I+37 jdk.jlink@22
j jdk.tools.jlink.internal.Main.main([Ljava/lang/String;)V+23 jdk.jlink@22
v ~StubRoutines::call_stub 0x0000ffff8fff0154

We have seen different bytecodes reported: 187,188,33, but the location and error are always the same. We dont have a reproducer sadly - it happens transiently and not often enough to know whats causing it.