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

[Doug Simon]

On Sun, 29 Oct 2023 20:39:47 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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   allow JavaCalls in HotSpotConstantPool.callSystemExit

With GraalVM, we're doing a lot more testing with product builds than fastdebug builds as the majority of checks are done at the Java level and fastdebug just slows everything down. In that testing context, guarantees are much more useful. Given the importance of the "can_call_java" invariant, would you agree that converting these 3 specific assertions to guarantees is justified?

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

PR Comment: https://git.openjdk.org/jdk/pull/16383#issuecomment-1788559705