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

[joe darcy]

Hi David,

In terms of how the documentation of this should be structured, I think 
the details of the HotSpot policy should be written up in a 
HotSpot-specific area, such as HotSpot wiki 
(https://wiki.openjdk.java.net/display/HotSpot/Main). Afterward, the CSR 
documentation can be amended to refer to this policy by reference.

What do you think?

Thanks,

-Joe


On 2/26/2018 5:48 PM, David Holmes wrote:
> 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