On Thu, 30 Oct 2025 05:22:33 GMT, David Holmes <[email protected]> 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
