RFR: 8140348: Convert TraceSafepoint to Unified Logging

[Mattis Castegren]

Hi

>From a Sustaining perspective, we of course prefer logging to be available in production builds. However, we understand that this has to be weighed against other team's concerns, for example performance.

Is the main concern that the checks to see if logging is turned on will give a performance overhead, and that the code will not be optimized as well?

If something is in an extremely hot code path, I understand the use of the production only verbose level. However, we appreciate having the lower verbose levels available in production builds as it means we can use it to debug issues on systems that cannot be run with fastdebug builds.

I would say, as a rule of thumb, completely from a Sustaining perspecitve:

Info or debug level should not give a substantial performance hit. We should be able to ask customers to run these levels in production without too much concern (more than possibly log file sizes).

Trace output may give performance impacts, and should be tested first before putting in a production system.

If logging is turned off, it should not give noticeable performance impact. If it does, we understand the use of the develop level. To me, the only time the develop level should be used is when we have strong reason to believe it will give a noticeable performance impact even when turned off.

Kind Regards
/Mattis


-----Original Message-----
From: Coleen Phillimore 
Sent: den 3 november 2015 01:15
To: Claes Redestad; David Holmes; hotspot-runtime-dev at openjdk.java.net; Mattis Castegren
Subject: Re: RFR: 8140348: Convert TraceSafepoint to Unified Logging



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-Octo
>>> ber/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
>