The `HotSpotJVMCIRuntime#getJObjectValue` method is currently invoked in two distinct scenarios:

Truffle Compiler Thread: 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 Thread: 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.