Need comments on JEP-158: Unified JVM Logging

[Fredrik Arvidsson]

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>

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