On Thu, 30 Oct 2025 06:35:31 GMT, Axel Boldt-Christmas <[email protected]>
wrote:
>> 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.
FWIW the first instance of this I observed was our compiler threads. But yeah
the practice to do this seems to be there for several JVM internal threads, but
it does cause a nasty fatal error during initialization that I just wanted to
smoothen out.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2476631489
