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

[Marcus Larsson]

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