RFR (L): 8046148: JEP 158 Unified JVM Logging (original) (raw)

Marcus Larsson marcus.larsson at oracle.com
Wed Sep 9 14:05:00 UTC 2015

On 2015-09-09 13:22, Chris Newland wrote:

Thanks for the offer Kirk, I'd definitely be interested in hearing your thoughts.

Marcus, my headache with the existing logging is different VM sources colliding, resulting in split lines that I can't deterministically reassemble. I believe this is caused by no locking around the tty. Will this problem be solved by unified logging when there is a single destination?

The UL framework only supports writing of complete log lines. Some of the existing code prints parts of its log lines in chunks directly to the tty, which means that such logging can be interleaved by other writes to the tty causing split lines. This code will have to be reworked during the migration to the UL framework so that only complete lines are logged. Once this is done, there should be no split lines in the log anymore, so in a sense the problem will be resolved with UL. :)

Thanks, Marcus

Thanks, Chris On Wed, September 9, 2015 10:36, Kirk Pepperdine wrote: Hi Chris,

My understanding is that current log formats won’t change unless the authors of the log messages decide to change it them selves. I’ve already started making changes to Censum’s parsers in preparation for the impending mess that will come as users start to sort out how to best use it. I’m happy to share some thoughts with you if you like. I’m not so happy with the mixing of levels and tags and decorators and the other things in there. High performance journaling requires that you get out of the way and stay out of the way. Adding all this extra formatting and bits definitely puts you in the way. However, having a unified logging framework is long overdue so.. we can go back and forth on the details of the implementation but the general direction is good. Regards, Kirk

On Sep 9, 2015, at 10:36 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:

Hi, On 2015-09-09 09:48, Chris Newland wrote: Hi Marcus,

Thanks for your answers. The nested XML structure of LogCompilation supports the description of arbitrarily complicated JIT parsing chains. The JIT compiler can log the start of a compilation with an opening XML tag and then hand off to the various subsystems (inlining, escape analysis, reg alloc etc.) which output child XML nodes and once they return the parent tag is closed. Do you have any thoughts on how this could be acheived in a non-XML format? Kind regards, Chris I'm not suggesting we go away from the XML format, I just mean that the current XML-producing code could be modified to use the unified logging as its output instead of a file. UL could be happily unaware of the fact that XML is being written to some log file, and there won't be any need to implement XML support in the UL framework itself. Thanks, Marcus Once implemented, will the current output formats still be available? Currently there is no specific support for XML output in the unified logging framework. Output can be directed either to stdout, stderr or plain text files. I'm not entirely sure how the migration of the XML logging will be done. Perhaps it will be preceded by an RFE to add better support for XML outputs in the unified logging framework, or it might just be treated as a regular text file. Thanks, Marcus

More information about the hotspot-dev mailing list