RFR: 8338538: [JVMCI] Allow HotSpotJVMCIRuntime#getJObjectValue to be called by a HotSpot CompileBroker compiler thread [v2]
Doug Simon
dnsimon at openjdk.org
Mon Aug 26 15:54:03 UTC 2024
On Sun, 18 Aug 2024 17:20:26 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 a HotSpot CompileBroker 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).
>
> Tomáš Zezula has updated the pull request incrementally with one additional commit since the last revision:
>
> Updated comment in getObjectValue.
>
> Co-authored-by: Douglas Simon <doug.simon at oracle.com>
Marked as reviewed by dnsimon (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/20620#pullrequestreview-2261027154
More information about the graal-dev
mailing list