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

[Doug Simon]

> On 13 Jul 2016, at 20:32, Christian Thalinger <cthalinger at twitter.com> wrote:
> 
> 
> 
>> 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.

Ok, Tom also commented offline that these should still require EnableJVMCI. That is, EnableJVMCI is still explicitly required to enable hosted-only JVMCI compilation. I can see why this makes sense and am preparing another webrev now.

> 
> 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.

Given that I’m changing track to only have UseJVMCICompiler imply EnableJVMCI, I think we can leave these option names as they are, at least PrintBootstrap. That said, I don’t feel strongly either way.

-Doug