RFR: 8338538: [JVMCI] Allow HotSpotJVMCIRuntime#getJObjectValue to be called by host compiler threads.
Doug Simon
dnsimon at openjdk.org
Sun Aug 18 13:57:47 UTC 2024
On Sun, 18 Aug 2024 13:11:24 GMT, Tomáš Zezula <duke at openjdk.org> wrote:
> The `HotSpotJVMCIRuntime#getJObjectValue` method is currently invoked in two distinct scenarios:
>
> Truffle Compiler: In this scenario, the method is called by a Truffle compiler thread. This thread is an ordinary Java thread that enters the shared library compiler (libgraal) via a Java native method call. Consequently, it always has a valid `JavaFrameAnchor` when invoking `HotSpotJVMCIRuntime#getJObjectValue` within the shared library compiler.
>
> Host Compiler: In the second scenario, the method is called by the host compiler thread while inlining a Truffle call target into a host method. Here, the compiler thread is a JavaThread in the `_thread_in_vm` state before entering the shared library compiler (libgraal) and does not have a `JavaFrameAnchor`.
>
> The `HotSpotJVMCIRuntime#getJObjectValue` method currently supports only the first scenario by asserting that the caller has a `JavaFrameAnchor`. However, this method should be adapted to also support the second scenario, where the caller thread lacks a `JavaFrameAnchor` but has an explicitly pushed JNI handle block. It is crucial that the `HotSpotJVMCIRuntime#getJObjectValue` method ensures it does not use the top-most `JNIHandleBlock`, which is never released. Utilizing this block for Java constants could potentially lead to memory leaks in the Java heap. To accommodate both scenarios, the method should be modified to allow execution also by threads without a `JavaFrameAnchor` provided they have an explicitly pushed JNI handle block.
>
> Implementation Details: The method determines whether the caller thread has pushed a JNI handle block by using `THREAD->active_handles()->pop_frame_link()`. The `pop_frame_link` is set when [JavaThread::push_jni_handle_block](https://github.com/openjdk/jdk/blob/bd4160cea8b6b0fcf0507199ed76a12f5d0aaba9/src/hotspot/share/runtime/javaThread.cpp#L1360) is called and is reset in [JavaThread::pop_jni_handle_block](https://github.com/openjdk/jdk/blob/bd4160cea8b6b0fcf0507199ed76a12f5d0aaba9/src/hotspot/share/runtime/javaThread.cpp#L1371). Each active JavaThread has a non-null `_active_handles` pointer, which is initialized in [JavaThread::run](https://github.com/openjdk/jdk/blob/bd4160cea8b6b0fcf0507199ed76a12f5d0aaba9/src/hotspot/share/runtime/javaThread.cpp#L730).
Marked as reviewed by dnsimon (Reviewer).
src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 713:
> 711: C2V_VMENTRY_0(jlong, getJObjectValue, (JNIEnv* env, jobject, jobject constant_jobject))
> 712: requireNotInHotSpot("getJObjectValue", JVMCI_CHECK_0);
> 713: // Ensure that we are not using the top-most JNIHandleBlock, which is never released.
Suggestion:
// Ensure that current JNI handle scope is not the top-most JNIHandleBlock as handles
// in that scope are only released when the thread exits.
-------------
PR Review: https://git.openjdk.org/jdk/pull/20620#pullrequestreview-2244319995
PR Review Comment: https://git.openjdk.org/jdk/pull/20620#discussion_r1720983156
More information about the hotspot-compiler-dev
mailing list