RFR: 8140348: Convert TraceSafepoint to Unified Logging

[Coleen Phillimore]

On 11/2/15 6:46 PM, Claes Redestad wrote:
>
> On 2015-11-02 23:35, David Holmes wrote:
>>> See the review thread for RFR: 8139564: Convert TraceDefaultMethods to
>>> Unified Logging
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-October/016059.html 
>>>
>>>
>>>
>>> Yes, we discussed this and decided to make all flags product pending 
>>> any
>>> problems discovered at a later time in the jdk9 release cycle.    
>>> Rachel
>>> is doing performance testing on each flag individually as converted, 
>>> but
>>> we could do a run at the end of the first set to be migrated, and 
>>> see if
>>> there are problems then.
>>
>> I'm concerned about the cumulative effects. I'm also concerned that 
>> even for non-product flags the logging will now have overheads in the 
>> product builds.
>>
>> David 
>
> I share David's concern.
>
> Did the previous discussion miss the log_develop method (defined in 
> hotspot/src/share/vm/logging/log.hpp and introduced by the UL JEP)? 
> This should properly elide logging code from product builds, and seems
> like the appropriate choice when moving develop flags to UL (unless 
> there's a real world story for making the specific logging hit product).
>
> I haven't seen serviceability indicate that this capability will be 
> removed or enable such logging in product builds. From the JEP:
>
> "Each log message has a logging /level/ associated with it. The 
> available levels are |error|, |warning|, |info|, |debug|, |trace| and 
> |develop| in increasing order of verbosity. The |develop| level is 
> only available in non-product builds."

No, we didn't miss the develop level (singular).  In general, 
serviceability and sustaining would prefer the flags to be available in 
product mode because it is usually quite difficult to get the customers 
to download and run a fastdebug jvm.

See the discussion in the link above.

thanks,
Coleen

> /Claes
>