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

[David Holmes]

On Thu, 30 Oct 2025 06:59:49 GMT, Erik Österlund <eosterlund at openjdk.org> 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