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>
