RFR(XL): 8199712: Flight Recorder

[Karen Kinnear]

David,

I am arguing for 2-step - going straight to Obsolete - since 
1) they have already checked with the community about willingness to move from the existing tracing to free use of JFR.
2) there is not a clean way to have both the old tracing and the new jfr in the same repository

So I would recommend Obsolete - you have removed the functionality - but give a grace period to remove the flags,
so put the flags back in in obsolete status so they warn but do not prevent starting the application.

In my mind the Obsolete stage marks the separation of the existence of the flag from the effects.

thanks,
Karen

> On May 4, 2018, at 2:31 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Erik,
> 
> Wearing my CSR hat at the moment ...
> 
> On 4/05/2018 1:36 AM, Erik Gahlin wrote:
>> On 2018-05-02 00:08, Karen Kinnear wrote:
>>> 2. Code removed two command line flags: EnableTracing and UseLockedTracing
>>>  with product flags, the normal approach is to deprecate
>>>  given they now do nothing, I would strongly recommend that you Obsolete before removing
>>> i.e. accept the flags, but do not do anything for 1 release, to allow script migration. Expire the flags
>>> in the next release. So test that you get a warning if you use them for JDK 11.
>>> 
>>> Note: CSR says EnableTracing flag is removed -> please update CSR for both to be made obsolete
>>> 
>> I will update the CSR and the code, but shouldn't we use Expired, since the feature is removed.
>> (If somebody actually built something on top of -XX:EnableTracing you want it to fail fast. Starting the JVM even though the feature is removed is hiding problems, which may make things worse at a later stage.)
> 
> To me that argues more for the full deprecation process. If someone has built something on top of EnableTracing then we should not be ripping it out from under them. We need to separate the existence of the flag from its affects on mainline hotspot code. To that end the flag can be marked deprecated so that anyone using it is made aware of the intent to remove it - at which point they can make their case for keeping it, or choose to maintain it downstream. At the same time the JFR implementation is free to do nothing in response to the flag being set - if that is a change in JFR's behaviour then that would be a topic for the JFR release note entry.
> 
> Granted this does seem an unusual circumstance.
> 
> Cheers,
> David