[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: Updates to JEP-158: JVM Unified Logging are coming...
From: Thomas_Stüfe <thomas.stuefe () gmail ! com>
Date: 2015-04-18 18:02:45
Message-ID: CAA-vtUwv9yV78Y-8Q+477ywNuGQfxo_a_n9A8C976s9NgsTn4g () mail ! gmail ! com
[Download RAW message or body]
Hi Frederik,
I like this proposal a lot, especially the abandonment of a hierarchical
structure in favor of tags. In the SAPJVM we have a tracing system in many
details similar to the one proposed here. We will be probably abandon it
and switch to the official logging system once it is implemented in the
OpenJDK.
Some questions/remarks:
1 Will logging be available from native JDK code too, not only from within
the hotspot?
2 Will there a way to cover early logging? One common problem is logging
during initialization time of the VM, and there is always the problem
whether logging system is already initialized ("I don't see my trace - did
I just not hit it or was logging not up yet?"). Would be very nice if this
problem were covered, e.g. by capturing output in-memory and writing it out
delayed once logging subsystem is up.
3 A similar problem is that logging should use as little VM infrastructure
as possible, to make it possible to use it from all VM code.
If you agree with (2) and (3), it may make sense to add some explicit
requirements to the JEP.
4 "Stretch Goal: Ability to configure in which order decorations should be
printed"
In our tracing system we also have decorations, and we even added a feature
to give the user the ability to format it itself, by adding a format-string
like feature (-XtraceFormat="blabla @PID @TID @USER"). This looked like a
neat idea, but we found in practice over the years that this feature was
very rarely used. So maybe this stretch goal is not needed.
5 Would be nice to have short alternative names for the decorators, maybe
even single letters
6 "The different log levels should have guidelines that define the expected
performance overhead for the level. " It also may make sense to add guide
lines for the expected verbosity of log levels, either in terms of
datasize/time or messages/time.
I look forward to this logging system in practice!
Kind Regards, Thomas
On Fri, Apr 17, 2015 at 9:32 AM, Fredrik Arvidsson <
fredrik.arvidsson@oracle.com> wrote:
> 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.
>
[Attachment #3 (text/html)]
<div dir="ltr">Hi Frederik,<br><br>I like this proposal a lot, especially the \
abandonment of a hierarchical structure in favor of tags. In the SAPJVM we have a \
tracing system in many details similar to the one proposed here. We will be probably \
abandon it and switch to the official logging system once it is implemented in the \
OpenJDK. <br><br>Some questions/remarks:<br><br>1 Will logging be available from \
native JDK code too, not only from within the hotspot?<br><br>2 Will there a way to \
cover early logging? One common problem is logging during initialization time of the \
VM, and there is always the problem whether logging system is already initialized \
("I don't see my trace - did I just not hit it or was logging not up \
yet?"). Would be very nice if this problem were covered, e.g. by capturing \
output in-memory and writing it out delayed once logging subsystem is up.<br><br>3 A \
similar problem is that logging should use as little VM infrastructure as possible, \
to make it possible to use it from all VM code.<br><br>If you agree with (2) and (3), \
it may make sense to add some explicit requirements to the JEP. \
<div><br></div><div>4 "Stretch Goal: Ability to configure in which order \
decorations should be printed"<br>In our tracing system we also have \
decorations, and we even added a feature to give the user the ability to format it \
itself, by adding a format-string like feature (-XtraceFormat="blabla @PID @TID \
@USER"). This looked like a neat idea, but we found in practice over the years \
that this feature was very rarely used. So maybe this stretch goal is not \
needed.<br><br>5 Would be nice to have short alternative names for the decorators, \
maybe even single letters<br><br>6 "The different log levels should have \
guidelines that define the expected performance overhead for the level. " It \
also may make sense to add guide lines for the expected verbosity of log levels, \
either in terms of datasize/time or messages/time.<br><br>I look forward to this \
logging system in practice!<br><br>Kind Regards, \
Thomas<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div \
class="gmail_quote">On Fri, Apr 17, 2015 at 9:32 AM, Fredrik Arvidsson <span \
dir="ltr"><<a href="mailto:fredrik.arvidsson@oracle.com" \
target="_blank">fredrik.arvidsson@oracle.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi<br> <br>
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.<br> <br>
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:<br> <a \
href="https://bugs.openjdk.java.net/browse/JDK-8046148" \
target="_blank">https://bugs.openjdk.java.net/browse/JDK-8046148</a><br> <br>
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.<br> <br>
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.<br> <br>
The time-out led to a modified proposal that can be found here:<br>
<a href="http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html" \
target="_blank">http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html</a><br> \
and with some illustrations here:<br> <a \
href="http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png" \
target="_blank">http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png</a><br>
<br>
So what have we changed, and why?<br>
In short we have switched from using an hierarchical log subject layout to something \
that could be best described as a tag based solution.<br> <br>
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.<br> <br>
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.<br> <br>
Our plan is as follows:<br>
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.<br> 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.<br> \
<br> More information about the sandbox repository name and other practicalities will \
follow shortly.<br> <br>
Cheers<br>
Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.<br>
</blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic