RFR: 8140348: Convert TraceSafepoint to Unified Logging (original) (raw)
Claes Redestad claes.redestad at oracle.com
Mon Nov 2 23:46:52 UTC 2015
- Previous message: RFR: 8140348: Convert TraceSafepoint to Unified Logging
- Next message: RFR: 8140348: Convert TraceSafepoint to Unified Logging
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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."
/Claes
- Previous message: RFR: 8140348: Convert TraceSafepoint to Unified Logging
- Next message: RFR: 8140348: Convert TraceSafepoint to Unified Logging
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]