<div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Hi!<br><br>As I mentioned yesterday, I am working on a tool (interactive console) to analyze what is inside the AOT cache, why and when the elements were added (or not), and if there's anything that can be done to improve it. </div><div dir="ltr"><br></div><div dir="ltr">It can be found here: <a href="https://github.com/Delawen/leyden-analyzer">https://github.com/Delawen/leyden-analyzer</a><br>Warning: very much work in progress, I am changing the way the commands work almost everyday as I add more commands and more data and I don't like how it is shown :) <br><br>But when analysing logs I found out there are several cases in which it is difficult to parse it automatically. I am using a consumer that goes line by line, and sometimes you need some context to know what is happening. A very clear example:<br><br>[info][aot       ] Allocating RW objects ...<br>[info][aot       ] done (218321 objects)<br>[info][aot       ] Allocating RO objects ...<br>[info][aot       ] done (432657 objects)<br><br>I guess there are not many parallel things happening at this time on the JVM, but if any other log message gets in between, that would be chaotic. A human may get it, a machine will find it confusing.<br><br>Also, there are some lines that can be parsed, but need "special treatment" like for example this line that has a comma inside the content of a comma-separated list of values:<br><br>[info][aot       ] Class  CP entries = 127257, archived =  20941 ( 16,5%), reverted =      0<br><br>Then there are other inconsistencies that are not that problematic but fixing them could make parsing the log easier. For example, see the following lines, which have similar information but displayed on very different ways:<br><br>[info][aot       ] Reserved output buffer space at 0x00007f5702e00000 [1084227584 bytes]<br>[info][aot] Reserved archive_space_rs [0x0000000057000000 - 0x000000005c000000] (83886080) bytes (includes protection zone)<br>[info][aot] Reserved class_space_rs   [0x000000005c000000 - 0x000000009c000000] (1073741824) bytes<br>[info][aot] Mapped static  region #0 at base 0x0000000057001000 top 0x0000000058fbe000 (ReadWrite)<br>[info][aot       ] Heap range = [0x00000000e0000000 - 0x0000000100000000]<br>[info][aot       ] Shared file region (rw) 0: 31818032 bytes, addr 0x0000000800001000 file offset 0x00001000 crc 0xc67c8575<br><br>In my opinion, it would make sense to have a common way of writing region addresses so the parser only needs to implement one way of parsing it. And this was a very obvious case, but I'm sure there are others out there that would benefit from some guidelines on how to output data.<br><br>I intend to improve the log messages to make it easier to parse (while not breaking the human-readable side) following suggestions from <a href="https://cr.openjdk.org/~jrose/jvm/parsing-logs.html">https://cr.openjdk.org/~jrose/jvm/parsing-logs.html</a> which I found very complete. </div><div dir="ltr"><br></div><div>Do we have a "good-practices guideline for OpenJDK developers" on how to write log messages? If not, do I start one? Where?</div><div dir="ltr"><br>Should I add new log messages instead of modifying the existing ones in case someone is already parsing them? As an intermediate step before "deprecating" the current messages.<br><br>Some of the things I already have in mind: <br> - Better "CSV-style" lists of data<br> - Try to keep context in the same line (if you read a line alone, you should understand it)<br> - Be more consistent in using "=" or ":" when specifying values (like "[info][aot] Core region alignment: 4096" versus "Selected AOTMode=record because AOTCacheOutput is specified")<br> - Be more consistent in general with similar type of data and similar messages<br><br></div><div>What do you think?</div><div dir="ltr"><br>Cheers!<br>María Arias de Reyna Domínguez<br>Senior Software Engineer<br>She / Her / Hers</div></div></div></div>