JEP 158

[Jesper Wilhelmsson]

Hi Kirk,

20 jun 2012 kl. 10:33 skrev Kirk Pepperdine <kirk at kodewerk.com 
<mailto:kirk at 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120620/ad664e64/attachment.htm>