RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v13]

[Vladimir Kozlov]

On Thu, 30 Oct 2025 08:43:28 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> Interesting. So the idea is that we should at the time of the `set_init_completed();` call determine if we have a correct configuration and exit gracefully there, expecting that all future init code should succeed, and if it does not we throw a fatal. 
>> 
>> Currently we have a lot of "graceful" exits in initialisation code which runs between init completed and successfully returning from `Threads::create_vm`, but OOME was not one of them.
>
>> I think the thought process here was that we should "never" get exceptions during these parts of VM init because the minimum heap size should ensure the VM can safely init. Hence getting an actual exception was indeed a "fatal error" because something was misconfigured - hence the EM. With AoTOC that may no longer be the case.
> 
> Yeah I suspected that was the case. And that previously made sense - throwing would most likely be a bug in the JVM before. But with AOT objects, we no longer have such a minimal heap size, and it is unlikely that the cause of the OOME is a bug in the JVM, and much more likely that the heap was too small to accomodate the AOT cache objects.

We can record minimum heap size in AOT Cache header (if we don't do that already, @iklam ?) during assembly phase when we **DO** have space for all AOT objects. And during production startup, when we open AOT cache, we can check that specified heap size >= size we had in assembly phase. If it is not we can report it and not use AOT cache as we do when specified VM settings does not match.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2478778179