Need comments on JEP-158: Unified JVM Logging

[Fredrik Arvidsson]

Hi Chris

You will find my comments in-line below.

On 2014-05-17 09:47, Chris Newland wrote:
> Hi Fredrik,
>
> The discussion I had with David Holmes and John Rose on hotspot-dev back
> in February might be relevant to this JEP:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012718.html
I will use some time to read this discussion. Thanks.
> I'm the author of a JITWatch[1], a JIT compiler log analysis tool which
> relies on -XX:+TraceClassLoading -XX:+LogCompilation -XX:+PrintAssembly
> all being present in hotspot.log
>
> Occasionally the lack of thread safety in the VM logging presents me with
> jumbled output:
>
> [Entry Point]
> [Constants]
>     # {method} 'ind
> <writer thread='3340'/>
> [Loaded sun.nio.cs.ThreadLocalCoders from C:\Program
> Files\Java\jre7\lib\rt.jar]
> <writer thread='2660'/>
> exOf' '(II)I' in 'java/lang/String'
>     # this:     ecx       = 'java/lang/String'
>     # parm0:    edx       = int
>     # parm1:    [sp+0x20]   = int  (sp of caller)
>     0x009e07e0: nop
>
> The JEP goal of no interleaving would fix this problem but if the locking
> adds too much cost/complexity then John's suggestion of tagging partial
> lines would be a great help to log tool writers.
There could be several reasons for the current logs to be interleaved I 
think. One reason can be that the lowest level log writing primitives 
aren't thread safe themselves.
A second reason can be that the current log framework doesn’t provide 
any form of log transactions making it easy for developer to implement 
the logging in a way that guarantees non partial lines in the log.
JEP-158 tries to address both of these reasons. Thread safety issues can 
be addressed using the leanest locking/critical section technique we can 
have. This might have different solutions depending on platform and log 
adapter in question. The 'broken up log code' is addressed with our log 
transaction which enables the developer to split the actual line of 
logging in to several calls to the log API. The log line is then 
committed to the underlying framework to be written all at once.
>
> Otherwise my only comment is that the goals look like a massive
> improvement to current VM logging but for post-execution log tool writers
> it is also useful for end users to be able to easily locate and load a
> single log file.
This really captures the intent of JEP-158 I think. We want to have a 
common framework for logging so that all output can be formatted the 
same well defined way, and we want to be able to have a single entry of 
configuration letting users configuring all logging in a consolidated 
and clear way.
> Kind regards,
>
> Chris
>
> [1] https://github.com/AdoptOpenJDK/jitwatch
>
Cheers

/Fredrik