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

Erik Österlund eosterlund at openjdk.org
Thu Oct 30 08:46:29 UTC 2025


On Thu, 30 Oct 2025 07:49:08 GMT, Axel Boldt-Christmas <aboldtch 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.
>
> 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.

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

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


More information about the hotspot-dev mailing list