RFR: 8318694: [JVMCI] disable can_call_java in most contexts for libjvmci compiler threads [v2]

[Doug Simon]

On Fri, 27 Oct 2023 17:14:58 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR reduces the context in which a libjvmci CompilerThread can make a Java call. By default, a CompileThread for a JVMCI compiler can make Java calls (as jarjvmci only works that way). When libjvmci calls into the VM via a CompilerToVM native method, it enters a scope where Java calls are disabled until either the call returns or a nested scope is entered that re-enables Java calls. The latter is required for the Truffle use case described in [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694) as well as for a few other VM entry points where libgraal currently still requires the ability to make Java calls (e.g. to load the Java classes used for boxing primitives). We may be able to eventually eliminate all need for libgraal to make Java calls but this PR is a first step in the right direction.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CompilerThreadCanCallJava scope must enclose the JVMCIEnv scope

src/hotspot/share/classfile/javaClasses.cpp line 2456:

> 2454:       print_stack_element_to_stream(st, bte._mirror, bte._method_id, bte._version, bte._bci, bte._name);
> 2455:     }
> 2456:     if (THREAD->can_call_java()) {

This allows `java_lang_Throwable::print_stack_trace` to be used in contexts where Java calls cannot be made.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16383#discussion_r1374905848