RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v10]
Erik Österlund
eosterlund at openjdk.org
Tue Oct 28 19:21:24 UTC 2025
On Tue, 28 Oct 2025 17:29:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
>> I was sort of thinking that there might be more AOT cache work that could benefit from concurrency, other than object loading. That's why I named it a bit more generically. Does that make sense? Otherwise, I'm open to renaming it.
>
> There is an other AOT thread `TrainingReplayThread` (also JavaThread) which has loop to process AOT dependencies for classes which were initialized.
> And we have 2 AOT compiler threads (for C1 and C2) to load AOT code.
> As you see we have specialized threads for AOT work.
>
> May be I can use this AOTthread for AOT code preloading (AOTCodeCache::preload_code()) which is currently done in main thread.
Yes, I am hoping so!
>> Both flags are diagnostic flags as I don't think ordinary users have any business fiddling with them. The AOTStreamableObjects flag controls whether dumping will dump the GC agnostic streaming format or not. Not setting it implies we will use streaming when compressed oops is off.
>>
>> As for AOTEagerlyLoadObjects, enabling it when loading a streamable object archive means all objects will be materialized upfront, instead of using concurrent materialization. This is enabled automatically if the environment has one core or less available. At that point, concurrency won't help much, and just getting it over with is a good idea.
>>
>> But yeah, as a user, you shouldn't really have to fiddle with these at all. They are there for benchmarking the differences.
>
> Got it. Thanks you.
> An other question: does it mean that if streamable objects are in AOT cache we can't use mmap for them?
> So everything is defined during assembly phase which approach is used: streaming or mmap. Right?
Yes that's right.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2470773277
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2470769763
More information about the hotspot-dev
mailing list