If there was to be a GC that did not support JVMCI, it would be desirable that if such a GC was selected, sanity checks should make sure that create_vm can not successfully return with EnableJVMCI set.

This RFE comes from the reasoning in JDK-8184269. This is a snippet from the email conversation when this was discussed, where a check was removed that was previously made during JVMCI bootstrapping called when Graal is bootstrapping, checking that the currently selected BarrierSet is known to support JVMCI:

<EMAIL>
> One thing - we may want to preserve JVMCI_ERROR() to check known by Graal concrete barriers.
I did think about the JVMCI_ERROR() check. Here is a summary of my thoughts:
1) The current check is strange. It explicitly does not complain if the ModRef barrier set is selected. However, that is not a concrete barrier set and if it was indeed found to be the selected barrier set, it would most definitely be an error, and the JVM would arguably not work.
2) I do not think that the error checking for finding incompatible barrier sets should be done here in the first place. It should be done earlier.
Current collectors all support JVMCI. If a hypothetical new GC did not support JVMCI, e.g., does not provide enough information to JVMCI to make it possible for JVMCI compilers to JIT bytecode, and a user selects that hypothetical GC in combination with e.g. -XX:+UseJVMCICompiler, then that is already an invalid JVM argument combination, and it should not even be possible to create_vm with invalid JVM arguments.
Therefore, I think such sanity checking for JVMCI compliance should be done earlier in the bootstrapping during argument parsing, so that once bootstrapping is done, the invariant that we have a sane GC and compiler combination is already established. Then when this code is run, we already know that the user has selected a GC compatible with JVMCI, rather than sprinkling the code after create_vm with error checks, checking for conditions due to invalid JVM arguments that should never have been allowed.
3) The contract in hotspot is between the GC and JVMCI, not Graal. That is, the question we should ask ourselves in hotspot during this bootstrapping is whether a GC provides enough information to JVMCI to allow external JIT compilation, not whether Graal will do the right thing. Then it has to be the responsibility of external JITs like Graal to correctly detect what GCs it supports, rather than for the GCs to detect what external compilers it supports through JVMCI.

Due to the above reasoning, I believe it is best not to perform the sanity check here that a valid BarrierSet was provided. If an invalid GC and compiler combination exists, then that should be validated before create_vm succeeds during argument parsing, if such invalid combinations are introduced. And after bootstrapping, we should be able to trust that we do not at runtime need to detect incompatible BarrierSet and compiler combinations.
</EMAIL>