RFR: 8140348: Convert TraceSafepoint to Unified Logging (original) (raw)

Coleen Phillimore coleen.phillimore at oracle.com
Tue Nov 3 00:15:13 UTC 2015

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 logdevelop 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

More information about the hotspot-runtime-dev mailing list