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