<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><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Cheers!<br>María.<a href="mailto:ariasdereyna@redhat.com" target="_blank"></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">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">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">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>