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

[Doug Simon]

> On 14 Jul 2016, at 20:11, Christian Thalinger <cthalinger at twitter.com> wrote:
> 
>> 
>> On Jul 13, 2016, at 10:24 AM, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>>> 
>>> On 13 Jul 2016, at 21:36, Doug Simon <doug.simon at oracle.com> wrote:
>>> 
>>>> 
>>>> 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.
>> 
>> Done - I updated the original web rev.
> 
> Generally it looks good now but...  Your patch definitely makes the logic simpler but it also adds this dependency:
> +// IMPLEMENTATION NOTE: When adding to the set of JVMCI options, ensure
> +// JVMCIGlobals::check_jvmci_flags_are_consistent is adjusted appropriately
> Not sure if that is a step forward.

Compared to the logic that was there, it’s a huge step forward! There’s so few flags and they’re very unlikely to change that I think the trade off is worth it.

If there was some easy way to get the number of flags created by JVMCI_FLAGS, we could add an assert in JVMCIGlobals::check_jvmci_flags_are_consistent against an EXPECTED_JVMCI_FLAGS constant. That would be sufficient as removal of a flag will cause a compilation error, and addition of a flag (without adjusting EXPECTED_JVMCI_FLAGS) will cause a guarantee failure. The only problem is that I don’t see how to get the number of flags created by JVMCI_FLAGS.

-Doug