Proposal: Clarifying the CSR rules for dealing with various kinds of -XX flags for hotspot

[David Holmes]

Hi Joe,

On 27/02/2018 11:11 AM, Joseph D. Darcy wrote:
> Hi David,
> 
> On 2/23/2018 10:08 PM, David Holmes wrote:
>> Hi Joe,
>>
>> On 24/02/2018 9:53 AM, Joseph D. Darcy wrote:
>>> Hello,
>>>
>>> Catching up on email, I think the general thrust of the proposal is 
>>> reasonable, but I have a few questions and comments.
>>>
>>> First, what is the full space of kinds of builds, product XOR debug?
>>
>> First distinction is product vs development
>>
>> Development can then be: fastdebug (aka debug), slowdebug, or 
>> optimized (the exact definition of which I can't recall but this is a 
>> build variation we are removing anyway).
> 
> Okay.
> 
>>
>>> What syntactic conventions, if any, distinguish all these kinds of 
>>> flags? Are product and manageable "-X" and all the others "-XX"? 
>>> (I've previously suggested in jest that a "-XXX" prefix be used for 
>>> less wholesome options.)
>>
>> There are no syntactic distinctions - these are all -XX flags, 
>> regardless of whether product or development, experimental etc. That 
>> is the long standing convention for hotspot specific flags.
>>
>>> If so, rather than reading of the general CSR guidelines and 
>>> concluding "[the guidelines] places all [HotSpot] -XX options into 
>>> the same CSR basket," an alternative observation might be the HotSpot 
>>> naming conventions choose to put multiple distinct kinds of options 
>>> into the same small namespace. 
>>
>> We only have one namespace for hotspot options.
>>
>>> Do options commonly move between categories as part of their 
>>> lifecycle (e.g. experimental -> product, etc.)?
>>
>> Not commonly. An experimental flag may become product if the 
>> experimental feature is adopted - that would of course have a CSR 
>> request at that point. Sometimes a product flag can be reclassified as 
>> develop, or vice-versa - both of which would again require CSR 
>> requests as they involve a product flag. Most commonly flags stay in 
>> their initial category.
>>
> 
> Here is a possible alternative long-term arrangement for your 
> consideration: the debug-ness, experimental-ness, etc. is encoded into 
> the name of the option, instead of -XX:FooBarBaz, something like 
> -XX:ExperFooBarBaz, or -XX:DebugFooBarBaz, etc.

Certainly if we were starting from scratch I'd be looking at a much more 
versatile format for flags, including effective namespaces. As to 
whether we're likely to invest effort in this area ... for now the main 
goal is to bring the number of flags under control.

> In the mean time, I think the proposal put forward is acceptable.

Thanks! So do we have a process here? Wait a week for any objections, 
then write this up on the CSR wiki somewhere ?

Cheers,
David
-----

> Cheers,
> 
> -Joe