RFR: 8143157: Convert TraceVMOperation to Unified Logging

[Rachel Protacio]

Hello!

On 11/19/2015 3:48 AM, kirk.pepperdine at gmail.com wrote:
> 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.
Just want to make sure we're all on the same page. Your rules of thumb 
are pretty accurate. The levels are as follows (directly from 
logLevel.hpp) and aggregate the levels below them:

    //  develop - A non-product level that is finer than trace.
    //            Should be used for really expensive and/or
    //            extensive logging, or logging that shouldn't
    //            or can't be included in a product build.
    //
    //  trace   - Finest level of logging in product builds.
    //            Use for extensive/noisy logging that can
    //            give slow-down when enabled.
    //
    //  debug   - A finer level of logging. Use for semi-noisy
    //            logging that is does not fit the info level.
    //
    //  info    - General level of logging. Use for significant
    //            events and/or informative summaries.
    //
    //  warning - Important messages that are not strictly errors.
    //
    //  error   - Critical messages caused by errors.


"Info" is default, which would include only the levels "warning", 
"error", and "info".

I used "-Xlog:all" as an example; it's not inherently central to the 
purpose of levels. It means print logging for all tags. But by not 
specifying a level, you get "info", which does not have "debug."
Rachel
>
> Kind regards,
> Kirk
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20151119/f505a5bf/attachment.html>