On Wed, 29 Oct 2025 08:01:42 GMT, Erik Österlund <[email protected]> wrote:
>> src/hotspot/share/utilities/exceptions.cpp line 559:
>>
>>> 557: Handle exception(_thread, _thread->pending_exception());
>>> 558: _thread->clear_pending_exception(); // Needed to avoid infinite
>>> recursion
>>> 559: if (is_vm_created()) {
>>
>> Can you explain this change please.
>
> 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. And you are changing the
init sequence in other ways that need examining.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2476425572
