RFR: 8161265: [JVMCI] EnableJVMCI should only be required when its not implied by other flags

[Christian Thalinger]

> On Jul 12, 2016, at 11:20 PM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> The -XX:+EnableJVMCI option 1) unlocks code paths in the VM related to JVMCI and 2) is required to unlock all other JVMCI options. However, 1 could be achieved by specific JVMCI options without requiring 2. Since JVMCI is experimental, these options already require -XX:+UnlockExperimentalVMOptions. Having to unlock them twice is redundant and makes for unnecessarily long command lines. For example:
> 
> java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler ...
> 
> could be:
> 
> java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler ...
> 
> This webrev removes the need for specifying -XX:+EnableJVMCI for these options:
> 
> UseJVMCICompiler

Totally makes sense for this one.

> JVMCITraceLevel
> JVMCICounterSize
> JVMCICountersExcludeCompiler
> JVMCIUseFastLocking
> JVMCINMethodSizeLimit
> TraceUncollectedSpeculations

Not so sure about these.

On a related note, all except two JVMCI-related options have “JVMCI” in their names.  Maybe these should follow suit:

PrintBootstrap
TraceUncollectedSpeculations

Thinking about it, if we are going to integrate this change the remaining two options should have JVMCI in their names.  Otherwise it is confusing that TraceUncollectedSpeculations (which seems unrelated) enables JVMCI.

> 
> It also significantly simplifies the logic for checking consistency for JVMCI options. The trade off is that when new JVMCI options are added, the logic in JVMCIGlobals::check_jvmci_flags_are_consistent needs to be updated.
> 
> Lastly, I took this opportunity to remove the CodeInstallSafepointChecks option as it should always be true.
> 
> https://bugs.openjdk.java.net/browse/JDK-8161265
> http://cr.openjdk.java.net/~dnsimon/8161265/
> 
> -Doug