RFR(L) 8184349: There should be some verification that EnableJVMCI is disabled if a GC not supporting JVMCI is selected
igor.veresov at oracle.com
Wed Jun 13 20:06:44 UTC 2018
I think if the future it would make more sense to be able to ask a JVMCI compiler what GCs does it support. But since there is just one implementation of a JVMCI compiler I guess it doesn’t matter much for now.
> On May 3, 2018, at 3:12 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> Recent testing problem after Graal dropped CMS (throw exception) made this RFE more urgent. I decided to fix it.
> The main fix is for JVMCI to check if GC is supported and exit VM with error if not . It is called from Arguments::apply_ergo() after GC is selected in GCConfig::initialize().
> Main changes are refactoring.
> I used this opportunity (inspired by GCConfig) to move compiler related code from arguments.cpp file into compilerDefinitions.* files. And renamed it to compilerConfig.*.
> Two new CompilerConfig methods check_comp_args_consistency() and CompilerConfig::ergo_initialize() are called from arguments.cpp.
> The rest are test fixing. Mostly to not run CMS GC with Graal JIT.
> One test CheckCompileThresholdScaling.java was modified because I skipped scaling compiler threshold in Interpreter mode (CompileThreshold = 0).
> For tests which use CMS I added @requires !vm.graal.enabled.
> Unfortunately I did not fix all tests which use CMS. Some tests have several @run commands for each GC. And some tests fork new process to test different GCs. Changes for those tests are more complicated and I filed follow up bug 8202611  I will fix after this.
> Tested tier1,tier2,tier2-graal
>  http://cr.openjdk.java.net/~kvn/8184349/webrev.02/src/hotspot/share/jvmci/jvmci_globals.cpp.udiff.html
>  https://bugs.openjdk.java.net/browse/JDK-8202611
More information about the hotspot-dev