Need comments on JEP-158: Unified JVM Logging

[Mario Torre]

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.

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"

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.

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..

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