RFR: 8365047: Remove exception handler stub code in C2 [v4]

[Andrew Dinn]

On Wed, 17 Sep 2025 06:15:25 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Ruben has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Offset the deoptimization handler entry point
>>    
>>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>>  - Revert "Ensure stub code is not adjacent to a call"
>
> on s390, I see couple of test failure with: 
> 
> 
> #  Internal Error (/home/amit/jdk/src/hotspot/share/code/nmethod.cpp:669), pid=574704, tid=574714
> #  guarantee(pd != nullptr) failed: scope must be present
> 
> # Problematic frame:
> # V  [libjvm.so+0x11253f4]  nmethod::scope_desc_at(unsigned char*)+0x14c
> 
> 
> BT:
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x11253f4]  nmethod::scope_desc_at(unsigned char*)+0x14c  (nmethod.cpp:669)
> V  [libjvm.so+0x159b46c]  compiledVFrame::compiledVFrame(frame const*, RegisterMap const*, JavaThread*, nmethod*)+0x6c  (vframe_hp.cpp:305)
> V  [libjvm.so+0x158f354]  vframe::new_vframe(frame const*, RegisterMap const*, JavaThread*) [clone .part.0]+0x5c  (vframe.cpp:75)
> V  [libjvm.so+0x825f42]  Deoptimization::fetch_unroll_info_helper(JavaThread*, int)+0x222  (deoptimization.cpp:517)
> V  [libjvm.so+0x827214]  Deoptimization::fetch_unroll_info(JavaThread*, int)+0x64  (deoptimization.cpp:299)
> v  ~DeoptimizationBlob 0x000003ffa064fb92
> J 265 c2 java.net.URL.<init>(Ljava/lang/String;Ljava/lang/String;ILjava/lang/String;Ljava/net/URLStreamHandler;)V java.base at 26-internal (417 bytes) @ 0x000003ffa066b08c [0x000003ffa066a680+0x0000000000000a0c]
> J 256 c2 sun.net.www.ParseUtil.fileToEncodedURL(Ljava/io/File;)Ljava/net/URL; java.base at 26-internal (90 bytes) @ 0x000003ffa06688a0 [0x000003ffa0668740+0x0000000000000160]
> j  jdk.internal.loader.URLClassPath.toFileURL(Ljava/lang/String;)Ljava/net/URL;+13 java.base at 26-internal
> j  jdk.internal.loader.URLClassPath.<init>(Ljava/lang/String;Z)V+96 java.base at 26-internal
> j  jdk.internal.loader.ClassLoaders.<clinit>()V+153 java.base at 26-internal
> v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ffa0500adc
> C  0x000003ffb07ff840
> V  [libjvm.so+0xbec91a]  JavaCalls::call(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x42  (javaCalls.cpp:323)
> V  [libjvm.so+0xb9a602]  InstanceKlass::call_class_initializer(JavaThread*)+0x2ba  (instanceKlass.cpp:1713)
> V  [libjvm.so+0xb9dcec]  InstanceKlass::initialize_impl(JavaThread*)+0x60c  (instanceKlass.cpp:1321)
> V  [libjvm.so+0xb9e2ea]  InstanceKlass::initialize(JavaThread*)+0xb2  (instanceKlass.cpp:819)
> V  [libjvm.so+0xf337f6]  LinkResolver::resolve_static_call(CallInfo&, LinkInfo const&, bool, JavaThread*)+0xce  (linkResolver.cpp:1115)
> V  [libjvm.so+0xf33ad0]  LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle const&, int, JavaThread*)+0x88  (linkResolver.cpp:1744)
> V  [libjvm.so+0xf377e4]  LinkRes...

@offamitkumar That error means one of two different things. It could mean that the pc pulled out of the compiledVFrame and passed into nmethod::scope_desc_at is invalid (i.e. does not lie in the range of the nmethod code). Alternatively, it could be that the pc is correct but array of PcDesc objects installed when the nmethod was created does not contain an entry for that pc.
The former problem would indicate that the frame code or frame unroll helper need updating to deal with the change in how the the deopt stub is entered. The latter would indicate some issue at compile time recording the entry into the deopt stub from the handler stub embedded at the end of the method.
The best way to find out is to reproduce the error in a debug build and see what happens when nmethod::scope_desc_at calls nmethod::pc_desc_at.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3322876364