RFR: 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports [v2]

[Doug Simon]

On Wed, 25 Nov 2020 21:16:51 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> `JVMCIGlobals::check_jvmci_supported_gc` is incorrect in that it hard codes the GCs supported by JVMCI which not something JVMCI itself can accurately answer. What's more, the upcall into JVMCI Java code to get the right answer cannot be made here as it is too early in the VM boot process. There's not even a `JavaThread` available yet. This code should be removed and let Graal exit the VM with an error should it be used in conjunction with a GC it does not support. For example:
>> Error occurred during initialization of VM
>> JVMCI Compiler does not support selected GC: epsilon gc
>> 
>> Moving the check to later in the VM bootstrap doesn't really work either as it imposes the overhead of initializing JVMCI and Graal eagerly.
>> This means a conflict between GC and JVMCI compiler cannot be finessed by overriding the compiler selection to use a non-JVMCI compiler. It's a fatal VM error, just like selecting multiple GCs on the command line is.
>> 
>> If you agree with that, then I think the proposed PR is the right approach. We could revert to the version that leaves the JVMCI specific logic in `WB_IsGCSupported` but as I stated, that means `GCConfig::is_gc_supported` can give a wrong answer.
>
> I think you merged 2 things into this PR which made me confused. The title says that Graal should specify which GC it supports (new JVMCI API). But your description is about fixing Graal testing with different GCs. Yes, they are connected but I think they should be reviewed separately.
> 
> The reason currently we test Graal supported GC in C++ code during VM startup is because we want to avoid executing application in Interpreter and bailout later when Graal is loaded to compile a hot method. Note, Graal in JDK is loaded on first compilation request.
> To get answer from Graal about GC you would have to load and initialize it very early which will affect startup (even with libgraal).
> 
> To add new JVMCI API just to resolve testing issues is overkill for me.

Now I'm confused ;-) The title and description of this PR don't mention Graal at all. While Graal is obviously the concrete JVMCI compiler motivating this change, the problem relates to any Java based JVMCI compiler. This is why an API change is needed.

I understand the motivation for wanting to test which GCs are supported by JVMCI in C++ code during VM startup. But I don't think that can justify giving a wrong answer. What happens when support for ZGC is added to Graal? The VM will incorrectly exit during startup based on the current code.

With JVMCI, the problem of delayed VM exit upon misconfiguration already exists. For example, an incorrectly specified or unrecognized `-Dgraal.*` option will only be detected when compiling the first method with Graal (i.e. when Graal is lazily initialized). Maybe I'm missing something, but why is this a real problem? Does it matter whether the VM exits after 1ms of execution or 500ms?

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

PR: https://git.openjdk.java.net/jdk/pull/1423