JEP 158

[Kirk Pepperdine]

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

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

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

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

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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120620/4b927fbd/attachment-0001.html