Need comments on JEP-158: Unified JVM Logging

[Fredrik Arvidsson]

Hi Mario, thanks for the feedback!

Pleas see my comments in-lined below.

On 2014-05-16 13:41, Mario Torre wrote:
> On Fri, 2014-05-16 at 11:45 +0100, Richard Warburton wrote:
>> Hi,
> Hi all,
>
> I share this same doubts, and I'm also a bit confused.
>> 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.
I posted an answer to Richards mail earlier, I don't know if you’ve had 
time to read it yet. I hope my answer describes an alternative way of 
having fine grained control of logging using sub 
loggers/components/categories.
> This would be very nice.
>
> I think this JEP pretty much works in the same direction as 167. I
> believe the ultimate goal should be to have some kind of DTRACE/STAP
> feature where user could enable/disable a specific probe/set of probes
> at runtime and get events from those, while JVM/Serviceability developer
> could easily add probes and instrumentation to the code in a standard
> way with a proper structure (which should be efficient also).
>
> If I understand correctly, this JEP tries to implement the logging part
> of such infrastructure (as you say in Non-Goals).
>
> I would not do this, though:
>
> "Logging messages are in human-readable plain text"
The 'human-readable' is a part of the goal for this JEP. This JEP set up 
a goal to have an few adapters implemented. StdOut, StdErr and file. 
Other types of adapters might have other ways of representing the logged 
information though.
>
> This should be part of the logging backend, which may be part of the
> framework and so still be a goal in a sense, but I would rather keep it
> separated from the logging infrastructure itself, which is what I would
> spend more time defining.
>
> Looks to me that the concept of adapters is very interesting, but
> applies to the "act of logging" itself. For instance, if you log a
> thread state change event, this would end up in the adapter, whose job
> is to put it, say, in a file, rather than in the syslog, etc.
Adapters are logging backends and the API between the logger and the 
adapter does not dictate in what way, or in which form the logged 
information or any decorations will be output. It is up to the adapter 
implementation to decide if the logged information should be put in an 
asynchronous FIFO queue before output or if to do it in a blocking 
fashion like the file-adapter.
> I would go a bit further though, defining a specific protocol where
> those events are accumulated before being consumed by the adapter, this
> protocol should allow for minimum overhead, for instance, all events
> will be directed to a memory buffer, a separate adapter thread will read
> this buffer and take away in FIFO order, etc..
Asynchronous logging is not always something you want in the scope of 
this JEP. When doing post-mortem analysis for example you most probably 
want to be as sure as possible that all logs have been flushed to an 
external media when a process crashes or happens to end up exiting on an 
assert. With the adapter design it is however up to the implementer to 
decide what, where and when to flush things.
Even if we will go to great lengths trying to keep this implementation 
as non-intrusive and lean as possible it is not intended to be a trace 
logging framework having extremely low overhead like the JFR/JEP-167 
solution.
>
> Not sure if this is part of this JEP, but sounds a more interesting and
> useful thing to do (I was hoping to see this in JEP 167, but apparently
> this is not what happens there).
>
> Cheers,
> Mario
>
Cheers

/Fredrik

// Adding back hotspot-dev at openjdk.java.net //