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

[David Holmes]

On Thu, 30 Oct 2025 05:01:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sure. We can split the interval of time that create_vm is executing into two parts: before and after is_init_completed (where GC starts being allowed). Previously, throwing an exception during create_vm is caught and a pretty error message is shown before gracefully exiting. When using an exception mark, you get similar behaviour if an exception is caught in the first half (before GC is allowed), but a fatal crash after GC is allowed. This is an anomaly in the exception handling during initialization.
>> 
>> For the most part, I suspect the distinction has not mattered a lot; we have a minimum heap size and during normal circumstances, we should not get OOME during create_vm if the minimum heap size was successfully committed when setting up the GC. However, with the AOT cache, we are allocating more objects during vm creation, and hence I had to take a stance on whether configuring a too small heap to run with the AOT cache should result in a fatal error or a graceful exit. Existing tests expect a graceful exit, and it makes sense to me that a fatal error does not seem warranted just because the heap configuration is obviously too small.
>> 
>> Therefore, I ended up harmonising so the exception marks have more similar behaviour to exception handling on the main thread, resulting in a graceful exit if we have not even initialized the JVM yet at the point of an exception.
>
> It does kind of miss the connection that `vm_exit_during_initialization` is how we exit before vm init is completed. Of course we can debate what "completed" means and where we should draw that line - I think there are a number of things that happen after that point which perhaps need not. 
> EDIT: sent prematurely - sorry.

BTW relying on the `ExceptionMark` to catch and report an OOME that is (to a degree) expected, seems like a misuse of EM to me. I don't know which EM is involved but perhaps the right fix there is to not have the EM and instead check for the exception and "return" and let the launcher report the OOME directly?

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

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