Updates to JEP-158: JVM Unified Logging are coming...

Fredrik Arvidsson fredrik.arvidsson at oracle.com
Fri Apr 17 09:29:58 UTC 2015

Ill try to reply in-line below.

On 2015-04-17 10:27, Mattis Castegren wrote:
> Ok. One risk I see would be that you would forget "base tags". For example, if you write a lot of code in g1, it would be easy to log something as only "g1", not including the "gc" tag. For us in Sustaining, that could lead to us having to use long verbose lines in order to get everything. This is something we had in older versions of JRockit, where you had your "favorite" verbose line that included tons of modules, like gc, yc, pausetime, compaction etc.
Of course there is a risk that people would forget to add a tag. But I 
can't see that this risk is very high. Logging code has to be put 
through code review just like any other change and we just have to pay 
extra attention to this in the beginning i guess. Using the hierarchical 
scheme there is also a risk that the logging topic is set to the wrong one.

There are no recommendations right now on what tags to create or use in 
the logging code. We will work with all groups trying to establish some 
guidelines I guess to have tag names consistent.

If we see a real need to have 'meta-tags' consisting of several other 
tags we could introduce something like that I'm sure, but this is just 
something we have discussed briefly.

There will also be a way to list all existing 'tag combinations' used in 
the code in runtime. This could maybe be used to spot the ones that are 
potentially wrong?
> If the recommendation is to ALWAYS include "gc" if you log something to "g1", wouldn't it make sense to make "g1" a subset of "gc"? Otherwise you would have to copy boilerplate code to include all the tags in your current area, like
> log ("gc,g1,g1_init", ...)
> If you forget it in one place, and we want to gather full information from a run, we would have to ask customers to run with "Xverbose:gc,g1,g1_init,g1_other_module,..."
Yes, this would be the way to handle missed tags in the code. I can't 
see that there is another way really :(

> Kind Regards
> /Mattis
> -----Original Message-----
> From: Fredrik Arvidsson
> Sent: den 17 april 2015 10:14
> To: Mattis Castegren; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers
> Subject: Re: Updates to JEP-158: JVM Unified Logging are coming...
> Hi Mattis
> The hierarchical structure is gone. Each log line in the code should
> contain all tags related to the message logged.
> In your example below the line would be printed just like before since
> the log call contains the gc tag.
> All tags will be defined in a single source file. The available tags
> will just like before be enumerable in runtime.
> /Fredrik
> On 2015-04-17 09:55, Mattis Castegren wrote:
>> Hi
>> Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like
>> log("gc,g1,init", <message>)?
>> Also, will all tags be defined in one file so that you can see which modules exists?
>> Kind Regards
>> /Mattis
>> -----Original Message-----
>> From: Fredrik Arvidsson
>> Sent: den 17 april 2015 09:33
>> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers
>> Subject: Updates to JEP-158: JVM Unified Logging are coming...
>> Hi
>> We are planning to release an updated version of JEP-158 very soon. The
>> work to update this JEP has been going on for some time and we now feel
>> we are ready to present it to a wider audience.
>> The JEP for JVM Unified Logging was created back in February 2012. The
>> requirements for the API and implementation were heavily influenced by
>> the logging functionality in JRockit JVM. The JEP was updated and
>> refined in mid 2014 and eventually targeted for JDK 9 in late 2014:
>> https://bugs.openjdk.java.net/browse/JDK-8046148
>> During the review process of the JEP some concerns were voiced about the
>> chosen API and functionality but the conclusion was that the proposal
>> would work, and the JEP was targeted for JDK 9 and the implementation
>> work was started.
>> Early 2015 during pre-reviews and presentations of the API and
>> implementation concerns were again raised about the formulation of the
>> JEP, this time with greater force. At this point we decided to take a
>> time-out and investigate our options going forward.
>> The time-out led to a modified proposal that can be found here:
>> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html
>> and with some illustrations here:
>> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png
>> So what have we changed, and why?
>> In short we have switched from using an hierarchical log subject layout
>> to something that could be best described as a tag based solution.
>> The main reason for the change of the logging API is that we have found
>> that some logging can't easily be ordered under a single hierarchical
>> subject but can belong to multiple subjects/areas. One example of this
>> is logging in the 'metaspace' code. The functionality in the 'metaspace
>> area' can be called from both GC and Runtime code. Another example is
>> class-unloading. There are more examples on this of course, but these
>> two we think are very clear and easy to understand.
>> The core functionality of the logging framework is not changed that much
>> from the earlier proposal. We have tried to make it leaner and not as
>> verbose (functionality wise) as before. The scope of the implementation
>> has been narrowed down some to enable us to deliver good value as soon
>> as possible.
>> Our plan is as follows:
>> After getting initial feedback from the community about the new proposal
>> we will update the JEP description. We aim to do this early next week.
>> We are planning to use the JDK9 sandbox repository during development.
>> This enables us who are implementing it to work in an efficient way and
>> at the same time it allows any interested party to try out and follow
>> the work during the implementation phase.
>> More information about the sandbox repository name and other
>> practicalities will follow shortly.
>> Cheers
>> Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.

More information about the hotspot-dev mailing list