On Thu, 30 Oct 2025 06:59:49 GMT, Erik Österlund <[email protected]> wrote:
>> 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.
I think the thought process here was that we should "never" get exceptions
during these parts of VM init because the minimum heap size should ensure the
VM can safely init. Hence getting an actual exception was indeed a "fatal
error" because something was misconfigured - hence the EM. With AoTOC that may
no longer be the case.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2476671384
