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>
