<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">On 10/14/25 1:16 AM, María Arias de
Reyna Dominguez wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAH4CYDXsz-fvCiVQoxpF1pa9Kxfc+5tCgdYpCpwP_K8ivnAG0w@mail.gmail.com">
<div dir="ltr">
<div>Hi!</div>
<div><br>
</div>
<div>With this patch, it shows more elements than before, but
still, training data is suspiciously disappearing:
MethodCounters, MethodData, MethodTrainingData, and
KlassTrainingData. Most of the Adapters are gone too along
with some TypeArrays and a few Symbols.</div>
<div><br>
</div>
</div>
</blockquote>
<p>Thanks Maria and Ashutosh for finding the bug about unregistered
classes and providing the fix. I've created the following bug to
track this issue.<br>
<br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8369856">https://bugs.openjdk.org/browse/JDK-8369856</a><br>
<br>
I'll try to integrate the fix as well as adding a jtreg test case
for it.<br>
<br>
I'll also take a look about why some AdapterHandlerEntry are
missing. For HelloWorld, the assembly phase log shows 313 items
but production log shows only 49 items.</p>
<p>For MethodCounters, MethodData, MethodTrainingData, and
KlassTrainingData, I think one reason is that objects for excluded
classes were not removed, so they were printed during AOT cache
creation. In the production run, these objects are not reachable
so they are not discovered by AOTMapLogger. I filed the following
bug for removing these objects:</p>
<p><a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8369857">https://bugs.openjdk.org/browse/JDK-8369857</a></p>
<p>Thanks</p>
<p>- Ioi</p>
<blockquote type="cite" cite="mid:CAH4CYDXsz-fvCiVQoxpF1pa9Kxfc+5tCgdYpCpwP_K8ivnAG0w@mail.gmail.com">
<div dir="ltr">
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">Cheers!<br>
María.</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Mon, Oct 13, 2025 at
12:01 PM Andrew Dinn <<a href="mailto:adinn@redhat.com" moz-do-not-send="true" class="moz-txt-link-freetext">adinn@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
09/10/2025 20:25, Ashutosh Mehra wrote:<br>
> I am able to reproduce the problem Maria is seeing.<br>
> Digging deeper it looks like when the map is generated
during the <br>
> production run, the VM skips classes loaded by the custom
loaders.<br>
> VM gets the list of classes using <br>
> SystemDictionaryShared::get_all_archived_classes <<a href="https://github.com/" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/</a>
<br>
>
openjdk/jdk/blob/1992b69a4794d1f2f65eaeb6dbb1e1e23a948b6e/src/hotspot/
<br>
>
share/classfile/systemDictionaryShared.cpp#L1419-L1423>
which only <br>
> iterates through the classes loaded by built-in loaders.<br>
> With the following patch, I am able to get all the
classes in the map <br>
> file generated in the prod run:<br>
> <br>
> diff --git
a/src/hotspot/share/classfile/systemDictionaryShared.cpp b/ <br>
> src/hotspot/share/classfile/systemDictionaryShared.cpp<br>
> index b092e71f4e7..7e71dbefbfb 100644<br>
> ---
a/src/hotspot/share/classfile/systemDictionaryShared.cpp<br>
> +++
b/src/hotspot/share/classfile/systemDictionaryShared.cpp<br>
> @@ -1420,6 +1420,9 @@ void <br>
> SystemDictionaryShared::get_all_archived_classes(bool
is_static_archive, Gr<br>
>
get_archive(is_static_archive)->_builtin_dictionary.iterate([&]
<br>
> (const RunTimeClassInfo* record) {<br>
> classes->append(record->klass());<br>
> });<br>
> +
get_archive(is_static_archive)->_unregistered_dictionary.iterate([&]
<br>
> (const RunTimeClassInfo* record) {<br>
> + classes->append(record->klass());<br>
> + });<br>
> }<br>
> <br>
> class SharedDictionaryPrinter : StackObj {<br>
> <br>
> @Ioi Lam <mailto:<a href="mailto:ioi.lam@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">ioi.lam@oracle.com</a>> Do
you think we should do this?<br>
<br>
I am not sure if your patch is exactly what we want -- Ioi
needs to <br>
answer that. However, I think it is important that the map
file shows <br>
*all* the metadata that resides in the archive, including any
metadata <br>
Klass and related structures that arecan be loaded via the
unregistered <br>
dictionary.<br>
<br>
This will be metadata for an app class that was not loaded via
the <br>
bootstrap, module or system loader and hence one that cannot
be <br>
associated with AOT linkage, profile data or compiled code. <br>
Nevertheless, the presence of a Klass and associated
Method/ConstMethod <br>
+ field data means that loading of the class in a production
run can <br>
bypass all the bytecode processing normally needed to create
that <br>
metadata. The user needs to be able to observe that this basic
level of <br>
optimization is still available via the AOT cache i.e. that
they still <br>
retain the benefits that were present under CDS even though
the extra <br>
AOT benefits are ruled out.<br>
<br>
regards,<br>
<br>
<br>
Andrew Dinn<br>
-----------<br>
<br>
</blockquote>
</div>
</blockquote>
</body>
</html>