AOT Map changes during production run

María Arias de Reyna Dominguez mariasde at redhat.com
Thu Oct 9 07:25:12 UTC 2025


Hi Ashutosh,

Training run:
$ grep '@@ Class ' aot.map | wc -l
10884

Production run:
$ grep '@@ Class ' aot.map | wc -l
3431

And the sizes of the map file are different:
$ du -sh aot.map*
331M aot.map
391M aot.map.0
394M aot.map.1

The aot.map is the production run. The file aot.map.1 is the training run.

The aot.map.0 is for app.aot.config (app.aot is how I call my aot cache):
$ cat aot.map.0 | head
AOT cache map for app.aot.config
[header             0x0000000000000000 - 0x00000000000003d8       984 bytes]
$ grep '@@ Class ' aot.map.0 | wc -l
10606

I'm using a locally build version of Java, that's true:
$ java --version
openjdk 26-internal 2026-03-17
OpenJDK Runtime Environment (build 26-internal-adhoc.delawen.jdk)
OpenJDK 64-Bit Server VM (build 26-internal-adhoc.delawen.jdk, mixed mode,
sharing)

Build from:
$ git log | head
commit 4b4d0cd35a32448e4b056109c502af2765766432
Author: Johny Jose <johny.jose at oracle.com>
Date:   Tue Oct 7 13:13:42 2025 +0000

    8365398: TEST_BUG:
java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing
intermittently

    Reviewed-by: msheppar, smarks, jpai

I'm confused :)

On Wed, Oct 8, 2025 at 6:31 PM Ashutosh Mehra <asmehra at redhat.com> wrote:

> Hi Maria,
> This is strange. I tried the same using the JavacBench app and didn't see
> this discrepancy in the map file generated by the assembly phase and the
> production run.
> You may have already checked it but just to confirm if run "grep '@@ Class
> ' t.log | wc -l" on the map file, do you see the same difference?
>
> Thanks,
> - Ashutosh Mehra
>
>
> On Wed, Oct 8, 2025 at 4:36 AM María Arias de Reyna Dominguez <
> mariasde at redhat.com> wrote:
>
>> Hi!
>>
>> I have a question.  I did a training run and generated what looks like a
>> valid cache.
>>
>> Summary of the number of elements (for certain types of elements) the map
>> contains:
>> ```
>> Classes in AOT Cache: 10.885
>> Methods in AOT Cache: 121.393
>>   -> ConstMethods: 121.293
>>   -> MethodCounters: 6.530
>>   -> MethodData: 4.127
>> ConstantPool: 10.197
>>   -> ConstantPoolCache: 10.197
>> ```
>>
>> And then I did a production run using the generated cache, which replaced
>> the `aot.map` with a new one that is much smaller:
>>
>> ```
>> Classes in AOT Cache: 3.431
>> Methods in AOT Cache: 38.359
>>   -> ConstMethods: 38.359
>>   -> MethodCounters: 0
>>   -> MethodData: 0
>> ConstantPool: 3.067
>>   -> ConstantPoolCache: 3.067
>> ```
>>
>> As you can see, there are a lot of missing elements!
>>
>> If I check the md5sum of the actual cache file before and after the
>> production run, it stays the same. It is the AOT Cache Map which changes.
>> Is that... supposed to happen?
>>
>> Maybe it is a bug related to https://bugs.openjdk.org/browse/JDK-8362566
>> ?
>>
>> Both map files start with `AOT cache map for app.aot`, it is not the map
>> file for the `app.aot.config` that appears during the training run.
>>
>> Both the training and the run were the same: just spin up an Infinispan
>> server and shut it down after a few seconds. But I guess that's irrelevant
>> because the aot cache file is exactly the same.
>>
>> I could stop generating the aot map file on the production run because
>> there is no need for it, but I forgot to remove it... and then this
>> happened.
>>
>> Kind regards,
>> María Arias de Reyna Domínguez
>> Senior Software Engineer
>> She / Her / Hers
>> ariasdereyna at redhat.com
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20251009/7057c5de/attachment.htm>


More information about the leyden-dev mailing list