On Thu, 30 Oct 2025 08:43:28 GMT, Erik Österlund <[email protected]> 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
