The initial conversion of TraceStartupTime, which uses TraceTime, to use Unified Logging, highlighted some problems in the way TraceTime interacted with UL.
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/017960.html
There should a way to interact with UL in a generic way using an arbitrary log tag and log level, rather than hard coding things. The macro-plus-template-based nature of the UL API makes this somewhat non-obvious, but there should be a way to do it.
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/018015.html
"I'm leaning towards a solution similar to what Kim suggested, where it's
not necessary for the timer to have such detailed knowledge of the
logging framework. You could even avoid the unnecessary buffering
happening in the streams by using a function pointer directly to the
appropriate Log::write function, similar to how logStream is implemented
today. Both of these approaches also allows for tag combinations to be
used, which is a limitation of the current proposal (can only specify a
single tag)."
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/017960.html
There should a way to interact with UL in a generic way using an arbitrary log tag and log level, rather than hard coding things. The macro-plus-template-based nature of the UL API makes this somewhat non-obvious, but there should be a way to do it.
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/018015.html
"I'm leaning towards a solution similar to what Kim suggested, where it's
not necessary for the timer to have such detailed knowledge of the
logging framework. You could even avoid the unnecessary buffering
happening in the streams by using a function pointer directly to the
appropriate Log::write function, similar to how logStream is implemented
today. Both of these approaches also allows for tag combinations to be
used, which is a limitation of the current proposal (can only specify a
single tag)."