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-...@openjdk.java.net //
