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

[Alan Bateman]

On 21/02/2018 07:27, David Holmes wrote:
> :
>
> Proposed Changes:
> =================
>
> We propose that only "product" and "manageable" flags should be 
> considered part of the "official interface" and subject to the full 
> CSR process.
>
> For the other flags, given their nature as part of the "unofficial 
> interface", we feel the CSR process is not needed and the code review 
> process gives sufficient visibility to the change.
The proposal to track additions/changes to product and manageable 
options looks reasonable. It's more than I expected to be honest as 
we've always had undocumented product options used in deployments.

Also the proposal to not track develop or notproduct options looks 
reasonable too.

I just skimmed the G1 chapter of the GC tuning guide where it documents 
-XX:+UnlockExperimentalVMOptions and several experimental G1 options. 
Given "Experimental" in the unlock option name then I think the proposal 
to not CSR experimental options is okay. There may be a few places where 
docs need to make it very clear that experimental options may obsolete 
or expire without first being deprecated.

I'm less sure about diagnostics options.  I just skimmed the 
documentation for the `java` launcher where it lists many -XX options. I 
don't think this is the right documentation page for these options but 
that's a different discussion. One of the options listed is 
-XX:+LogCompilation which of course needs -XX:+UnlockDiagnosticVMOptions 
to unlock. This leads me to options such as LogFile and LogVMOutput, 
both legacy now, but I'll bet there are many existing deployments using 
these options. So while I think your proposal is okay, I think we will 
need to be careful a small number of existing and legacy diagnostic 
options, some of these may need a CSR and/or release note to create 
awareness of a change.

-Alan