RFR (L): 8046148: JEP 158 Unified JVM Logging (original) (raw)

Vitaly Davidovich vitalyd at gmail.com
Fri Sep 11 15:07:28 UTC 2015

So perhaps ClassLoading is too coarse a tag then? If you did have a tag per class loading, unloading, constraints, etc are there also verbosity levels within each?

sent from my phone On Sep 11, 2015 10:12 AM, "Max Ockner" <max.ockner at oracle.com> wrote:

TL;DR at the bottom. I have encountered some of the same issues with "levels" as many of the other responders. Approximately half of the runtime team's logging plans (all of the command line options) are made significantly more complicated by the way levels are set up. The other half of our logging requirements actually fit very well with levels. First I'll mention the pain points of converting to Unified Logging. UL wants me to organize my logging messages by subsystem (tag), which I completely agree with. However, each subsystem is only allowed 5 nested logging commands even though it is most common that a single subsystem has several disjoint types of logging going on. Here is an example in which it makes more sense to split a subsystem into 5 different tags than it does to use levels: We have a ClassLoading system with quite a lot of stuff that can be logged. ClassLoading, ClassUnloading, ClassLoaderData, LoaderConstraints, ClassLoadingPreorder, and a couple more. If we want all of these logging options to be accessible through the ClassLoading tag (which we absolutely do want), then we will need to assign one logging feature per level. So which one is Trace level? That is, which feature do we only want to see if everything else is being printed as well? What if we want to use print LoaderConstraints on its own? With the given design, you can't separate different types of logging in this way without having entirely different tags. Because of this, the runtime team plans to use a large number of tags (more than 75 different tags) despite having nowhere close to that many subsystems. There are also many instances of logging options being called with "Verbose" or "WizardMode", which is analogous to setting level=trace. An undesirable side effect of this is if we want logging option X to have a default output and a more verbose output, then option X in its plain form is forced to have a level lower than trace. We have had to compromise some of the logging functionality so far by combining Verbose and WizardMode so that there is at most one level of super verbose info above any command line option. Of course, it would be nice to condense a lot of these options into single logging statements for their respective subsystems, but this would majorly affect the existing Java code for a lot of our customers as well as a lot of developers. On a more positive note, our error and warning level logging messages fit much better into the UL framework since the subsystem and severity of the error naturally imply which tag and level should be used. TL;DR: -Levels help with structuring a lot of runtime's logging messages. -Levels create undesirable constraints on some (half) of runtime's logging messages. -If users and developers weren't already using our command line options in such delicate ways, it would be much easier for runtime to bite the bullet and completely adhere to the tag=subsystem convention. - Unified Logging is good. I hope this helps. Max Ockner

More information about the hotspot-dev mailing list