<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 9/19/25 1:14 AM, María Arias de
Reyna Dominguez wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAH4CYDX6bGfd_rGZ+1Fwpn3EeKhL7h_Kka-E892xu6bPp84Juw@mail.gmail.com">
<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" moz-do-not-send="true" class="moz-txt-link-freetext">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>
</div>
</div>
</div>
</div>
</blockquote>
<p>The logs in HotSpot generally have two (sometimes overlapping)
purposes:</p>
<p>- For HotSpot developers to debug the implementation</p>
<p>- For users to gain insight about what the JVM is doing.</p>
<p> I think many of the logs in the former group won't be very
interesting to most users. One example would be the memory ranges
you quoted below.</p>
<br>
<blockquote type="cite" cite="mid:CAH4CYDX6bGfd_rGZ+1Fwpn3EeKhL7h_Kka-E892xu6bPp84Juw@mail.gmail.com">
<div dir="ltr">
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">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>
</div>
</div>
</div>
</div>
</blockquote>
<p>These can be fixed by combining the output into:</p>
<p>[info][aot ] Allocated 218321 RW objects)<br>
[info][aot ] Allocated 432657 RO objects)<br>
</p>
<p>I think this particular case probably won't be very useful to the
end user. It might be better for your tool to parse -Xlog:aot+map
and give both summary views (how many objects) and detailed views
(info about each object, or groups of objects, etc).</p>
<p>Also, we could use -Xlog:aot+map as the main gateway for
displaying information to the user. For example, we could add a
summary section to count the number of all objects, the number of
objects for each type, etc).</p>
<blockquote type="cite" cite="mid:CAH4CYDX6bGfd_rGZ+1Fwpn3EeKhL7h_Kka-E892xu6bPp84Juw@mail.gmail.com">
<div dir="ltr">
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">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>
</div>
</div>
</div>
</div>
</blockquote>
<p>In this particular case, the 16,5% is produced by printing the
number as %.2d. In some locales, the decimal point is the ","
character, while in other locales (such as US, it's printed as
".").</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAH4CYDX6bGfd_rGZ+1Fwpn3EeKhL7h_Kka-E892xu6bPp84Juw@mail.gmail.com">
<div dir="ltr">
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">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" moz-do-not-send="true" class="moz-txt-link-freetext">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>
</div>
</div>
</blockquote>
<p>CSV styles would be easier to parse but would be harder to read
(and harder to generate as you'd need to worry about quoting the
comma character.</p>
<p>Overall, I think we need to decide what information is useful for
the user, and then only change those logs (if necessary) for
better parsing. We probably don't want to change all the existing
logs (there are too many of them).</p>
<p></p>
<p><br>
</p>
<p>Thanks</p>
<p>- Ioi</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAH4CYDX6bGfd_rGZ+1Fwpn3EeKhL7h_Kka-E892xu6bPp84Juw@mail.gmail.com">
<div dir="ltr">
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<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>
</blockquote>
</body>
</html>