JEP 158

Fri Aug 17 19:44:26 UTC 2012

I don't think the JEP has been updated, only published. I have not had time to do any changes to it.

/Staffan

On 10 jul 2012, at 17:16, Kirk Pepperdine <kirk at kodewerk.com> wrote:

> Hi Staffan,
> 
> I've noticed that the specification has been updated but still contains the hierarchical level system.  Is it your intention to maintain level in the specification?
> 
> Regards,
> Kirk
> 
> On 2012-06-20, at 12:50 PM, Staffan Larsen wrote:
> 
>> Hi,
>> 
>> Thanks for the feedback! 
>> 
>> It is going to be hard to find the right balance between a system that provides great power and one that is simple to use and to implement. In general, I will lean more towards making it simple, but I want to make sure we cover the major use cases as well.
>> 
>> It looks like there are three possible ways to select log messages being discussed here. I'd like to discuss how to solve your problem for each one.
>> 
>> 1) Selection based on component/level. (This is what is described in the JEP.)
>> In this case we can have any number of components. So we can have gc and tenuring as different component. They will each have a level associated with them. However there is no relationship between the gc and the tenuring component, so to enable both you need to say -Xverbose:gc,tenuring. To only enable tenuring you can say -Xverbose:tenuring. To enable all gc messages, except tenuring you say -Xverbose:gc.
>> 
>> 2) Selection based on component/level where the component is a hierarchy.
>> In this case the different steps in the hierarchy can have different levels associated with them, but if there is no explicit level associated, the parent level will be used. So to enable both tenuring and gc you would say -Xverbose:gc. To enable only gc you would say -Xverbose:gc,gc.tenuring=none (I made up the 'none' level). To enable only tenuring you would say -Xverbose:gc.tenuring.
>> 
>> 3) Selection based on tags. 
>> In this case log messages are associated with a set of tags instead of a component/level tuple. You select messages by specifying tags you want to see. I imagine that in this case the tenuring messages would be tagged with both the gc and the tenuring tags, but that there would be other messages tagged with gc only. To enable gc and tenuring you would say -Xverbose:gc,tenuring. To enable all gc messages you say -Xverbose:gc. There is no way to see only gc messages without seeing the tenuring messages.
>> 
>> Is this a fair description of the different ways? I'm especially interested in the last one - I'm not sure I captured your idea correctly there.
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> On 20 jun 2012, at 09:32, 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 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>
>>>> 
>>> <jesper_wilhelmsson.vcf>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120817/bc46e4b2/attachment.htm>