RFR: 8340733: Add scope for relaxing constraint on JavaCalls from CompilerThread [v3]
Doug Simon
dnsimon at openjdk.org
Fri Oct 4 15:34:36 UTC 2024
On Fri, 4 Oct 2024 15:25:13 GMT, Tomáš Zezula <duke at openjdk.org> wrote:
>> [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694) limited the ability for JVMCI CompilerThreads to make Java upcalls. This is to mitigate against deadlock when an upcall does class loading. Class loading can easily create deadlock situations in -Xcomp or -Xbatch mode.
>>
>> However, for Truffle, upcalls are unavoidable if Truffle partial evaluation occurs as part of JIT compilation inlining. This occurs when the Graal inliner sees a constant Truffle AST node which allows a Truffle-specific inlining extension to perform Truffle partial evaluation (PE) on the constant. Such PE involves upcalls to the Truffle runtime (running in Java).
>>
>> This PR provides the escape hatch such that Truffle specific logic can put a compiler thread into "allow Java upcall" mode during the scope of the Truffle logic.
>
> Tomáš Zezula has updated the pull request incrementally with one additional commit since the last revision:
>
> UseJVMCINativeLibrary check must be guarded by JVMCI_ONLY.
src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 193:
> 191: __block_can_call_java = CompilerThread::cast(thread)->can_call_java(); \
> 192: } else { \
> 193: __block_can_call_java = false; \
For non-CompilerThreads, `__block_can_call_java` should be true I think since they are not affected by `-Xcomp` or `-Xbatch`. A TruffleCompileThread is such a thread.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21285#discussion_r1787892422
More information about the hotspot-compiler-dev
mailing list