JEP 158

[Kirk Pepperdine]

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/403184e8/attachment.htm>