AOT Map changes during production run

[ioi.lam at oracle.com]

On 10/14/25 1:16 AM, María Arias de Reyna Dominguez wrote:
> Hi!
>
> 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.
>
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.

https://bugs.openjdk.org/browse/JDK-8369856

I'll try to integrate the fix as well as adding a jtreg test case for it.

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.

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:

https://bugs.openjdk.org/browse/JDK-8369857

Thanks

- Ioi

> Cheers!
> María.
>
>
> On Mon, Oct 13, 2025 at 12:01 PM Andrew Dinn <adinn at redhat.com> wrote:
>
>     On 09/10/2025 20:25, Ashutosh Mehra wrote:
>     > I am able to reproduce the problem Maria is seeing.
>     > Digging deeper it looks like when the map is generated during the
>     > production run, the VM skips classes loaded by the custom loaders.
>     > VM gets the list of classes using
>     > SystemDictionaryShared::get_all_archived_classes
>     <https://github.com/
>     >
>     openjdk/jdk/blob/1992b69a4794d1f2f65eaeb6dbb1e1e23a948b6e/src/hotspot/
>
>     > share/classfile/systemDictionaryShared.cpp#L1419-L1423> which only
>     > iterates through the classes loaded by built-in loaders.
>     > With the following patch, I am able to get all the classes in
>     the map
>     > file generated in the prod run:
>     >
>     > diff --git
>     a/src/hotspot/share/classfile/systemDictionaryShared.cpp b/
>     > src/hotspot/share/classfile/systemDictionaryShared.cpp
>     > index b092e71f4e7..7e71dbefbfb 100644
>     > --- a/src/hotspot/share/classfile/systemDictionaryShared.cpp
>     > +++ b/src/hotspot/share/classfile/systemDictionaryShared.cpp
>     > @@ -1420,6 +1420,9 @@ void
>     > SystemDictionaryShared::get_all_archived_classes(bool
>     is_static_archive, Gr
>     >  get_archive(is_static_archive)->_builtin_dictionary.iterate([&]
>     > (const RunTimeClassInfo* record) {
>     >         classes->append(record->klass());
>     >       });
>     > +
>      get_archive(is_static_archive)->_unregistered_dictionary.iterate([&]
>     > (const RunTimeClassInfo* record) {
>     > +    classes->append(record->klass());
>     > +  });
>     >   }
>     >
>     >   class SharedDictionaryPrinter : StackObj {
>     >
>     > @Ioi Lam <mailto:ioi.lam at oracle.com> Do you think we should do this?
>
>     I am not sure if your patch is exactly what we want -- Ioi needs to
>     answer that. However, I think it is important that the map file shows
>     *all* the metadata that resides in the archive, including any
>     metadata
>     Klass and related structures that arecan be loaded via the
>     unregistered
>     dictionary.
>
>     This will be metadata for an app class that was not loaded via the
>     bootstrap, module or system loader and hence one that cannot be
>     associated with AOT linkage, profile data or compiled code.
>     Nevertheless, the presence of a Klass and associated
>     Method/ConstMethod
>     + field data means that loading of the class in a production run can
>     bypass all the bytecode processing normally needed to create that
>     metadata. The user needs to be able to observe that this basic
>     level of
>     optimization is still available via the AOT cache i.e. that they
>     still
>     retain the benefits that were present under CDS even though the extra
>     AOT benefits are ruled out.
>
>     regards,
>
>
>     Andrew Dinn
>     -----------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20251014/f931dc72/attachment.htm>