Integrated: 8338538: [JVMCI] Allow HotSpotJVMCIRuntime#getJObjectValue to be called by a HotSpot CompileBroker compiler thread

Tomáš Zezula duke at openjdk.org
Mon Aug 26 16:53:07 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 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).

This pull request has now been integrated.

Changeset: a15af699
Author:    Tomáš Zezula <tomas.zezula at gmail.com>
Committer: Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a15af6998e8f7adac2ded94ef5a47e22ddb53452
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8338538: [JVMCI] Allow HotSpotJVMCIRuntime#getJObjectValue to be called by a HotSpot CompileBroker compiler thread

Reviewed-by: dnsimon

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

PR: https://git.openjdk.org/jdk/pull/20620


More information about the hotspot-compiler-dev mailing list