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

[Chris Newland]

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