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 <[email protected]> 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> >> >
