On 06/20/2012 02:07 PM, Kirk Pepperdine wrote:
Hi Staffan,
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.
agreed, levels is brain dead simple but at the same time.... it is brain dead..
where as tag based systems might be a bit more difficult to admin... but I
would argue that they are also simple and certainly more powerful.
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.
This is great start on the path to tag based logging
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.
And this is where things jump the rails IMHO.
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.
An idea here would be to categorize each message into a bunch of
categories. Say for example we have a log message which is categorized
as: GC_INFO, TENUERED, SOMETHING_ELSE.
By default the message should trigger if any of those flags have been
set. But it would also be possible to say -Xverbose:gc_info,!tenured
which could force everything with TENURED to not trigger.
Trickier to implement, but kind of enables both an easy
-Xverbose:gc_info and a pretty fine grained system for people who want
to write long and complicated command lines.
/R
If would be unfortunate if there was no way to see only GC messages without
having to eat the tenuring records. As described this isn't a tag system, or an
aspect oriented log system, it's still levels. I guess it would be good to have
connivence tags that turned on a bundle of other tags. that way people who like
error, warning, info fine, finner and finest can have it that way. Where as
those that want to turn on logging for a particular aspect can just get to
those messages. This makes more sense for GC logging but I think it also makes
more sense for HotSpot also. In that environment there are things that I might
only want at a debug level but if I turn on a debug level log I might get a ton
of other unintended stuff with it. If I can specify a tag (like I can currently
do with the current set of JVM flags) then I can get the data I need.
I see this level of granularity somewhat important given that I often have to
dig into production environments where everyone is very sensitive to the
possible latency that maybe induced. It's often very comforting to say I can
turn this on, we get this small amount of data that is very relevant to the
problem at hand without flooding the system with tons and tons of messages that
simply take up disk bandwidth and disk space.
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.
Hopefully this last description fixes things ;-)
Cheers,
Kirk
