RFR: 8336663: [JVMCI] VM Crash on ZGC due to incompatible handle returned by HotSpotJVMCIRuntime#getJObjectValue

[Erik Österlund]

On Wed, 17 Jul 2024 20:48:16 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> The `HotSpotJVMCIRuntime#getJObjectValue` method returns a real JNI local handle instead of a JVMCI handle to prevent random crashes on ZGC.
>
> Would you mind explaining on a higher level what this code tries to do? If I understand the fix correctly, we are creating a hotspot JNI local from some Graal constant with getJObjectValue and expose a raw pointer to the HotSpot JNI handle to the caller. Looking at the only use I can find for this API, that raw pointer is then used to create yet another JNI local by calling NewLocalRef in some JNI environment. That seems either redundant, if it's the HotSpot JNI environment (as we just created a JNI local handle), or possibly dangerous if this is some libgraal JNI environment instead, as resolving the JNI local handle is only allowed when the thread is in the in_vm state. Otherwise the reference might become invalid between creating the JNI handle and resolving it in libgraal which is running in_native from HotSpot point of view. What am I missing?

> @fisk 
> 
> 
> 
> > Looking at the only use I can find for this API, that raw pointer is then used to create yet another JNI local by calling NewLocalRef in some JNI environment. That seems either redundant,
> 
> 
> 
> Yes, it's now redundant. The original `getJObjectValue` method returned a JVMCI handle, whose lifecycle was tied to the lifecycle of given `IndirectHotSpotObjectConstantImpl`. To remove this limitation, we created a new JNI local reference. With the changes introduced in this pull request, the `NewLocalRef` call should be removed.

Ah, okay. I guess you will fix that separately in the Graal repo. Good.

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

PR Comment: https://git.openjdk.org/jdk/pull/20219#issuecomment-2237141910