[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