Hi Richard, thanks for the feedback.
In the JEP I tried to explain the concept of 'sub' loggers but I did not
put in anything about the intent of having them. I think that your
requirement easily could be solved using sub loggers, or sub components
if you like that wording better.
Loggers are ordered in an hierarchical tree where 'gc' might be the root
for all logging in the gc 'area'. The 'details', 'cause' and 'safepoint'
content types could be translated in to sub loggers to the 'gc' logger.
By setting log level for the separate sub loggers to enable logging I
cant see that you would not be able to get the filtering you want. By
using log levels wisely you will be able to get even more control over
what gets output in the logs. The above was a much simplified example,
in reality you would probably have a more elaborate tree of gc loggers.
There is nothing in the logger three hierarchy approach that implies
that they should be big blocks of stuff.
Logging topics, tags, or markers were something we considered at the
beginning of the design phase but we came to the conclusion that we
probably could solve the requirements by using sub loggers instead.
Please tell me if you don't think this approach would work, and in that
case why.
Regards
/Fredrik
// Adding back hotspot-dev.openjdk.java.net //
On 2014-05-16 12:45, Richard Warburton wrote:
Hi,
Please help me review this updated version of the JEP-158 Unified
JVM Logging that was pushed today to the JEP repository.
Since the service posting the JEPs to
http://openjdk.java.net/jeps/ site seems to be non working at the
moment I am linking directly to the HG repository instead.
The updated JEP can be found here in raw markdown format:
http://hg.openjdk.java.net/jep/jeps/file/b04a394c4df4/jep-158.md
Primarily I would like to have feedback on the overall
functionality scope, the logging API and the command line argument
format. All type of comments are of course welcome, but I would
like to stay away from any implementation specifics at this point.
At the moment the GC logs have a way of filtering the content
semantically, based upon the content itself. For example flags like
PrintGCDetails, PrintGCCause, PrintSafepointStatistics offer control
over what I can see based upon what I want to see. I may have
misinterpreted the wording of the JEP and I'd love to be corrected if
this is the case, but it looks like moving to levels is a backwards
step over this type of control. It means that you can only enable or
disable logging in big locksteps and that each level of logging needs
to have a set of things associated with it.
I'm not saying that an abstract framework should depend upon the
details of the different components but if you had component definable
markers for the type of information in order to offer more fine
grained control I think it would be a most appreciated. That way
something like a GC logger could define its own markers for details,
cause, application stopped time, safepoints etc. An end user who is
trying to diagnose a specific problem could leave their gc logger at
warning, but also then has the option to enable a specific marker for
something like application stopped time which is probably a lower
level than warning.
regards,
Richard Warburton
http://insightfullogic.com
@RichardWarburto <http://twitter.com/richardwarburto>
