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

[Kirk Pepperdine]

Hi Chris,

I just looked at the comments from John Rose. His concern is how UL will manage multi-line log entries. The other concern that came out of John’s comments reminded me of a number of engagements where logging rates created a synchronization bottleneck in the async appender in Log4J. I’ve run into similar problems with other logging frameworks.

As it stands Censum is able to cope with mixed output that has been redirected from stdout. However that turning parsing the logs into a run to failure activity where failure is the longest path through the code. So, more garbage == longer time to parse. I don’t know if JITWatch can do something similar but I suspect you should be able to piece something together that works similarly so if a file contains other unrelated records you should be able to pass over them without harm.

Kind regards,
Kirk

> On Sep 9, 2015, at 1:22 PM, Chris Newland <cnewland at chrisnewland.com> 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?
> 
> Thanks,
> 
> Chris
> 
> On Wed, September 9, 2015 10:36, Kirk Pepperdine wrote:
>> Hi Chris,
>> 
>> 
>> My understanding is that current log formats won稚 change unless the
>> authors of the log messages decide to change it them selves. I致e already
>> started making changes to Censum痴 parsers in preparation for the
>> impending mess that will come as users start to sort out how to best use
>> it. I知 happy to share some thoughts with you if you like.
>> 
>> I知 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
>>>>> 
>>>>> 
>>> 
>> 
>> 
> 
>