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

[David Holmes]

Hi Joe,

On 28/02/2018 9:13 AM, joe darcy wrote:
> 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?

That sounds fine. I'll find out how to write to our wiki.

Thanks,
David

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