RFR(XL): 8199712: Flight Recorder

[David Holmes]

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