Hi Kirk,
20 jun 2012 kl. 10:33 skrev Kirk Pepperdine <k...@kodewerk.com
<mailto:k...@kodewerk.com>>:
Hi Jesper,
On 2012-06-20, at 9:32 AM, Jesper Wilhelmsson wrote:
Hi Kirk,
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.
I'm not only interested in GC but I'm using GC as an exemplar
Ok, sorry! I just assumed that since you wrote to the GC list instead of the
list specified in the JEP.
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.
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.
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.
I'm not sure I understand how the structure of the VM will prevent people from
using the logs efficiently.
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.
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
-Xverbose:gc=info,gc.tenuring=debug
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
-Xverbose:gc.tenuring
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.
What I did here was to extend the module system. That is completely separate
from the logging levels.
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.
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.
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.
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.
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.
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.
Obviously aspects could cut through other parts of the VM as well, not just GC
logging. Is this roughly what you are looking for?
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.
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.
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.
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.
/Jesper
Regards,
Kirk
/Jesper
On 2012-06-20 07:28, Kirk Pepperdine wrote:
Hi Jesper,
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.
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.
Regards,
Kirk
On 2012-06-20, at 1:03 AM, Jesper Wilhelmsson wrote:
Hi Kirk,
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.
A typical command line could look like
|
-Xverbose:gc=debug,finalizer=info,compiler,alloc,cookies=trace|
/Jesper
On 2012-06-19 23:44, Kirk Pepperdine wrote:
Hi,
I see the logging framework JEP finally was published. This is great news.
I'd like to comment on this quality
"Logging is performed at different levels: error, warning, info, debug,
trace"
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.
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.
Kind regards,
Kirk Pepperdine
<jesper_wilhelmsson.vcf>
<jesper_wilhelmsson.vcf>
