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

[Axel Boldt-Christmas]

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

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

I think the allocation which we hit where we changed this was:
```c++
void MonitorDeflationThread::initialize() {
  EXCEPTION_MARK;

  const char* name = "Monitor Deflation Thread";
  Handle thread_oop = JavaThread::create_system_thread_object(name, CHECK);


Which seemed like the wrong place to get a fatal, given that we use `vm_exit_during_initialization` if we fail to get the native thread resources.

But maybe you are right that we should not use ExceptionMark in code which is used during initialisation and handle it explicitly. (We currently do this for most if not all of our early runtime threads). Most places seems to be during startup where we setup where we initialise subsystems. This seems to have been a convenient way to call `vm_exit_during_initialization`.

A lot of places which are not initialisation code end their scope with something like this:
```c++
if (HAS_PENDING_EXCEPTION) {
  CLEAR_PENDING_EXCEPTION;
  [...]
}

Which seems to indicate that the property they were looking for is to check that there are no pending exception when entering the scope.

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

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