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