<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div>Hi Kirk,<br>
<br>
</div>
<div>20 jun 2012 kl. 10:33 skrev Kirk Pepperdine <<a
href="mailto:kirk@kodewerk.com">kirk@kodewerk.com</a>>:<br>
<br>
</div>
<blockquote type="cite">
<div>Hi Jesper,
<div><br>
<div>
<div>On 2012-06-20, at 9:32 AM, Jesper Wilhelmsson wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> Hi Kirk,<br>
<br>
I'm CC'ing serviceability on this since this is really
their JEP and discussions around it should go on the
serviceability list, even though it seems you are mainly
interested in GC logging at this point.<br>
</div>
</blockquote>
<div><br>
</div>
I'm not only interested in GC but I'm using GC as an
exemplar</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Ok, sorry! I just assumed that since you wrote to the GC list
instead of the list specified in the JEP.</div>
<div><br>
<blockquote type="cite">
<div>
<div>
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
I understand what you want and I see that the logging
level won't help us get there. I don't agree that the
logging we have today can't fit nicely into a
hierarchical scheme though, it just needs to be more
fine grained to achieve what you want.<br>
</div>
</blockquote>
<div><br>
</div>
I think to do this you have to assume structure which may
or may not apply to everyone. In this case I'd rather drop
the assumption and work towards a solution that doesn't
prevent but enables.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<span class="Apple-style-span" style="-webkit-tap-highlight-color:
rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color:
rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color:
rgba(77, 128, 180, 0.230469); ">Well, the structure is there in
the VM. We can't really take that away. Tenuring is and will
most likely always be part of the GC.</span></div>
<div><span class="Apple-style-span"
style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969);
-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469);
-webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);">I'm
not sure I understand how the structure of the VM will prevent
people from using the logs efficiently.<br>
</span></div>
<div><span class="Apple-style-span"
style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969);
-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469);
-webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);"><br>
</span>
<blockquote type="cite">
<div>
<div>
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
We can be pretty generous with modules and in
principal have one module for each verbose flag that
exists today. Personally I don't think that is a good
idea, but it certainly is possible. I would rather
like to propose a different solution.<br>
<br>
How about we have a gc module that can be filtered
based on different sub modules. The sub modules could
be fairly close to the existing verbose flags that
exists today if that turns out to be a good way to
divide information. It could look like this<br>
<br>
-Xverbose:gc=info,gc.tenuring=debug<br>
<br>
to set regular gc verbose to info level (I would say
that is close to PrintGC) and turn on more detailed
logging for tenuring. Or<br>
<br>
-Xverbose:gc.tenuring<br>
</div>
</blockquote>
<div><br>
</div>
I predicted that you'd come back with the way to shoehorn
the problem into leveling. I don't really see this as an
appropriate solution as in this case because tenuring
distribution is only one aspect of logging. Maybe that's
what I we need, a new term for logging.. I'll call this
Aspect Oriented Logging which I see as being completely
different than hierarchical logging which is the quagmire
we've been stuck in for far too long.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>What I did here was to extend the module system. That is
completely separate from the logging levels.</div>
<div><br>
</div>
<blockquote type="cite">
<div>
<div>
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> that could be
equal to what that flag prints today. Let's see what
the serviceability team thinks since they are the ones
who will actually implement this in the end.<br>
<br>
Another solution that I don't really like but guess is
easier to implement is to add the current verbose flag
to the actual message so that the logs can be filtered
based on that. But this will clutter the messages and
we would still have the problem to decide on which
level things should get logged.<br>
</div>
</blockquote>
<div><br>
</div>
IMHO, we don't have a good taxonomy for logging categories
and instead of over-reaching and forcing one on everybody,
why not come to a specification that would allow groups to
define their own. So again, I ask the question, what would
the specification look like with levels taken out.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Well, if you remove the levels from the current specification
you'd be left with just the modules. That would work I guess,
but it would be a slightly less powerful logging framework. Let
me describe what I think that you want to achieve. Please
correct me if I'm wrong.</div>
<div><br>
</div>
<div>You'd like to specify that you are for instance interested in
tenuring. The logs that you are interested in in this case
should contain information about heap, eden and survivor sizes.
They should contain tenuring threshold and information about
objects that has been tenured like number of objects and their
sizes etc. And maybe some more stuff.<br>
</div>
<div><br>
</div>
<div>A different aspect could be that you are interested in
fragmentation. Again you'd like information about heap sizes,
free memory in different areas, sizes of the individual free
areas and their count. Maybe some timestamps that could tell you
how long ago an area was compacted etc.</div>
<div><br>
</div>
<div>Obviously aspects could cut through other parts of the VM as
well, not just GC logging. Is this roughly what you are looking
for?</div>
<div><br>
</div>
<div>To be able to achieve this we would have to divide all
verbose data into different categories and have a mechanism to
based on the aspect select the correct categories for output.</div>
<div><br>
</div>
<div>I would say that this is exactly what we can achieve with the
proposed logging framework. The only difference is that the user
is able to pick and choose exactly what information to include
instead of just having an aspect that will give a predefined set
of logging events. We could easily provide a set of predefined
config files that selects different logging modules based on the
desired aspect.</div>
<div><br>
</div>
<div>If we add the levels into this we could also specify that
some aspect would like to provide very detailed information
about something while a different aspect could satisfy for a
less detailed overview of that particular something.</div>
<div><br>
</div>
<div>If this was not at all what you wanted please let me know.
Examples of what you'd like to see would be much appreciated.</div>
<div>/Jesper</div>
<br>
<blockquote type="cite">
<div>
<div>
<div><br>
</div>
<div>Regards,</div>
<div>Kirk</div>
<div><br>
</div>
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> /Jesper<br>
<br>
<br>
On 2012-06-20 07:28, Kirk Pepperdine wrote:
<blockquote
cite="mid:1BC2C076-7066-406A-87B2-A6F4618B7ECC@kodewerk.com"
type="cite">Hi Jesper,
<div><br>
</div>
<div>I did read the spec and I do like the ability
to specify the "component" that you'd like to log
information from. So I feel that is a great
improvement over the (broken) pattern established
in every major logging Java framework. I'm going
to stick to GC logging just because I've spent so
much time puzzling over them and adjusting my
parser to deal with all the changes that have
continuously crept into them. While 'm certainly
not going to argue for keeping the current GC
logging framework what I will say is that it's not
all bad in that the flags that have been provided
to me are almost always semantically meaningful in
that they tell me what I'm going to see. In this
spirit I'd like to see a category like
TenuringDetails for example. Is this information
INFO, DEBUG, or TRACE? hard to say but it's
clearly TenuringDetails and so this is a
subcategory that I'd like to define and it's
clearly not a subcategory that you'd want to
define a generalize logging framework. And it is
here that this specification over-reaches. It
tries to define logging categories that are not
only are devoid of meaning, they assume a
hierarchical structure to them. Going back to GC
logging I would argue that while there is some
hierarchy in there, most of the messages don't
nicely fit into this imposed hierarchical
developer centric list of categories.</div>
<div><br>
</div>
<div>I think we could easily both agree that it
would be ridiculous for me to ask that you add
PrintTunuring to the list of levels yet that is
exactly what I want. So I guess what I'm asking
is, what would the spec look like if you removed
the log levels from it and allowed me to define my
own or to not even use levels at all.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Kirk</div>
<div><br>
</div>
<div>On 2012-06-20, at 1:03 AM, Jesper Wilhelmsson
wrote:</div>
<div>
<div><br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> Hi
Kirk,<br>
<br>
To select what should be logged there should
be logging modules. A module could be for
example class loading, gc, jit compiler etc.
The logging level is just a way to control
how much logging you want. Setting gc=info
would give you some basic gc logging while
gc=debug would give you more detailed info.<br>
<br>
A typical command line could look like<br>
<pre><code>
-Xverbose:gc=debug,finalizer=info,compiler,alloc,cookies=trace</code></pre>
/Jesper<br>
<br>
<br>
On 2012-06-19 23:44, Kirk Pepperdine wrote:
<blockquote
cite="mid:25BA359D-58E7-48F3-9575-E555A31FE3C2@kodewerk.com"
type="cite">Hi,
<div><br>
</div>
<div>I see the logging framework JEP
finally was published. This is great
news.</div>
<div><br>
</div>
<div>I'd like to comment on this quality</div>
<div><br>
</div>
<div><span style="color: rgb(0, 0, 0);
font-family: 'Bitstream Vera Sans',
'Luxi Sans', Verdana, Arial,
Helvetica; font-size: 14px;
font-style: normal; font-variant:
normal; font-weight: normal;
letter-spacing: normal; line-height:
13px; orphans: 2; text-align:
-webkit-auto; text-indent: 0px;
text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;
display: inline !important; float:
none; ">"Logging is performed at
different levels: error, warning,
info, debug, trace"</span></div>
<div><span style="color: rgb(0, 0, 0);
font-family: 'Bitstream Vera Sans',
'Luxi Sans', Verdana, Arial,
Helvetica; font-size: 14px;
font-style: normal; font-variant:
normal; font-weight: normal;
letter-spacing: normal; line-height:
13px; orphans: 2; text-align:
-webkit-auto; text-indent: 0px;
text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;
display: inline !important; float:
none; "><br>
</span></div>
<div><span style="color: rgb(0, 0, 0);
font-family: 'Bitstream Vera Sans',
'Luxi Sans', Verdana, Arial,
Helvetica; font-size: 14px;
font-style: normal; font-variant:
normal; font-weight: normal;
letter-spacing: normal; line-height:
13px; orphans: 2; text-align:
-webkit-auto; text-indent: 0px;
text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;
display: inline !important; float:
none; "><span class="Apple-style-span"
style="font-family: Helvetica;
line-height: normal; font-size:
medium; ">If we accept the problems
associated with level based logging,
these name work for generic
frameworks such as Log4J and JDK
logging. However, the names are
meaningless in that they carry no
semantic context with what would be
logged. The nice thing about the
current set of flags is they convey
the information that will be
printed.</span></span></div>
<div><span style="color: rgb(0, 0, 0);
font-family: 'Bitstream Vera Sans',
'Luxi Sans', Verdana, Arial,
Helvetica; font-size: 14px;
font-style: normal; font-variant:
normal; font-weight: normal;
letter-spacing: normal; line-height:
13px; orphans: 2; text-align:
-webkit-auto; text-indent: 0px;
text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;
display: inline !important; float:
none; "><span class="Apple-style-span"
style="font-family: Helvetica;
line-height: normal; font-size:
medium; "><br>
</span></span></div>
<div><span style="color: rgb(0, 0, 0);
font-family: 'Bitstream Vera Sans',
'Luxi Sans', Verdana, Arial,
Helvetica; font-size: 14px;
font-style: normal; font-variant:
normal; font-weight: normal;
letter-spacing: normal; line-height:
13px; orphans: 2; text-align:
-webkit-auto; text-indent: 0px;
text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;
display: inline !important; float:
none; "><span class="Apple-style-span"
style="font-family: Helvetica;
line-height: normal; font-size:
medium; ">On the question of log
levels. I was hoping that we would
have learned from the follies of
using level based logging instead of
a digital or tag based system. IOWs
a on or off different aspects
without having to eat the whole
elephant of records that some
developer arbitrarily decided should
be dumped at a particular log level.
One can level tags.. but you can't
get tags or digital behaviour from
levels.</span></span></div>
<div><span style="color: rgb(0, 0, 0);
font-family: 'Bitstream Vera Sans',
'Luxi Sans', Verdana, Arial,
Helvetica; font-size: 14px;
font-style: normal; font-variant:
normal; font-weight: normal;
letter-spacing: normal; line-height:
13px; orphans: 2; text-align:
-webkit-auto; text-indent: 0px;
text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;
display: inline !important; float:
none; "><span class="Apple-style-span"
style="font-family: Helvetica;
line-height: normal; font-size:
medium; "><br>
</span></span></div>
<div><span style="color: rgb(0, 0, 0);
font-family: 'Bitstream Vera Sans',
'Luxi Sans', Verdana, Arial,
Helvetica; font-size: 14px;
font-style: normal; font-variant:
normal; font-weight: normal;
letter-spacing: normal; line-height:
13px; orphans: 2; text-align:
-webkit-auto; text-indent: 0px;
text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;
display: inline !important; float:
none; "><span class="Apple-style-span"
style="font-family: Helvetica;
line-height: normal; font-size:
medium; ">Kind regards,</span></span></div>
<div><span style="color: rgb(0, 0, 0);
font-family: 'Bitstream Vera Sans',
'Luxi Sans', Verdana, Arial,
Helvetica; font-size: 14px;
font-style: normal; font-variant:
normal; font-weight: normal;
letter-spacing: normal; line-height:
13px; orphans: 2; text-align:
-webkit-auto; text-indent: 0px;
text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;
display: inline !important; float:
none; "><span class="Apple-style-span"
style="font-family: Helvetica;
line-height: normal; font-size:
medium; ">Kirk Pepperdine</span></span></div>
</blockquote>
</div>
<span><jesper_wilhelmsson.vcf></span></blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<span><jesper_wilhelmsson.vcf></span></blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</body>
</html>