[11] RFR(L) 8184349: There should be some verification that EnableJVMCI is disabled if a GC not supporting JVMCI is selected

Tobias Hartmann tobias.hartmann at oracle.com
Wed Jun 13 07:28:41 UTC 2018


Hi Vladimir,

this looks good to me (nice refactoring!) but I would suggest to wait for another review.

Thanks,
Tobias

On 04.05.2018 00:12, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8184349/webrev.02/
> https://bugs.openjdk.java.net/browse/JDK-8184349
> 
> 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 [1]. 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 [2] I will fix after this.
> 
> Tested tier1,tier2,tier2-graal
> 


More information about the hotspot-dev mailing list