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

[Ioi Lam]

On Thu, 30 Oct 2025 16:31:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> 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.

The AOT cache knows what objects (and their individual sizes) are archived. However, with streaming, the exact heap size needed to materialize all the archived objects depends on the GC type and GC tuning parameters. For example, a region-based GC could segregate objects by their sizes, so there will be an overhead (unused space in the segregated regions) that's hard to calculate unless you do a pre-scan of all the archived objects.

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

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