RFR: 8143157: Convert TraceVMOperation to Unified Logging

kirk.pepperdine at gmail.com kirk.pepperdine at gmail.com
Thu Nov 19 08:48:49 UTC 2015


Hi David,

>>>> 
>> You enable the logging with "-Xlog:vmoperation=debug". If you leave of
>> the "=<level>" portion, it is by default parsed as "=info". We don't
>> believe this vmoperation logging needs to come out by default in the
>> case where someone asks for "-Xlog:all", so we put it one level below.
> 
> <sigh> So does -Xlog:all signify all tags at info level or ???
> 
> I think this is real conceptual problem with the UL framework. I should be able to define the info/trace/debug levels for a given tag, without having to think about how they interact with a "log all" request.

This has been one of my concerns about UL since the initial JEP and why I was speaking towards UL being tag based instead of level based. Now, IMO, UL is backwards in that it is geared towards levels but that is confused with tags. Being geared towards tags with levels would have created less of a conceptual problem. And, it is more inline with how other messaging systems work (given that logging is a specialization of messaging).

>> Thanks for voicing your concern. The justification for this tag being
>> product is that it could be useful to helping diagnose user problems, it
>> does not slow performance when off, and it minimally increases the size
>> of the code. If any of these prove to be false in aggregated logging
>> options, we can move it to develop level during code freeze.
> 
> You could make that argument for every piece of logging and end up with a very simple flat logging system. :) It is all very subjective of course.

Agreed, slippery slope but in this case I’m happy that we will now have access to this type of information in production environments. What we currently have are indications of a problem without any real means of seeing what the problem is.

My rule of thumb for using log levels is
debug - detailed information that a developer needs. It would have limited value to diagnosing problems in production systems
warning - defensive action needed to be taken, or an action couldn’t be taken to avert something bad from happening
info - an event occurred (such as jvm operation, GC, safe-point, CHA event…..)

I would not want “all" to include “debug”. So, not exactly the hierarchical escalation that is being forced on us.

Kind regards,
Kirk



More information about the serviceability-dev mailing list