JEP 158

[Jesper Wilhelmsson]

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 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.

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

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.
/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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120620/ebf0d09d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jesper_wilhelmsson.vcf
Type: text/x-vcard
Size: 251 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120620/ebf0d09d/jesper_wilhelmsson.vcf>