JDK-8370943 added the ability to expand the heap for Serial and Parallel without having to GC during early startup (before is_init_completed). The expansion code was written with the assumption that it is performed in a safepoint.

We have currently observed one crash related to the fact that top is updated before we setup the card table. But we can also see that the synchronisation between expansion and allocation is not correct.

#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/opt/mach5/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S17025/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/66544a37-8d82-44d2-baba-cfb77bed4677/runs/b41cee45-bdee-47c7-a4ef-f7270171ec3d/workspace/open/src/hotspot/share/runtime/handles.cpp:40), pid=1525655, tid=1525673
# assert(oopDesc::is_oop(obj)) failed: not an oop: 0x0000726079973a90
#
# JRE version: Java(TM) SE Runtime Environment (26.0+26) (fastdebug build 26-ea+26-2591)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-ea+26-2591, mixed mode, sharing, tiered, compressed class ptrs, serial gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0xff7baa] HandleArea::allocate_handle(oop)+0x14a
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E" (or dumping to /opt/mach5/mesos/work_dir/slaves/526fbd26-20de-495c-9a19-a04adc16f7d1-S37660/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/1ca2faaf-4c16-4cb6-858c-566318d522e4/runs/3d3a0b04-1f15-4868-8396-e6dd9b9044ec/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_gc/scratch/4/core.1525655)
#
# If you would like to submit a bug report, please visit:
# https://bugreport.java.com/bugreport/crash.jsp
#

--------------- S U M M A R Y ------------

Command Line: -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=/opt/mach5/mesos/work_dir/jib-master/install/jdk/25/37/bundles/linux-x64/jdk-25_linux-x64_bin.tar.gz/jdk-25 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/526fbd26-20de-495c-9a19-a04adc16f7d1-S37660/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/1ca2faaf-4c16-4cb6-858c-566318d522e4/runs/3d3a0b04-1f15-4868-8396-e6dd9b9044ec/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_gc/tmp -XX:-UseCompressedOops -XX:-ZapUnusedHeapArea -XX:-VerifyBeforeExit -XX:+UseSerialGC -XX:InitialHeapSize=1024K

Host: AMD EPYC 7J13 64-Core Processor, 12 cores, 23G, Ubuntu 24.04.3 LTS
Time: Tue Nov 25 14:07:45 2025 UTC elapsed time: 0.148629 seconds (0d 0h 0m 0s)

--------------- T H R E A D ---------------

Current thread (0x00007260d004dff0): JavaThread "AOTThread" [_thread_in_vm, id=1525673, stack(0x00007260d52fd000,0x00007260d53fd000) (1024K)]

Stack: [0x00007260d52fd000,0x00007260d53fd000], sp=0x00007260d53fba50, free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xff7baa] HandleArea::allocate_handle(oop)+0x14a (handles.cpp:40)
V [libjvm.so+0x980dd0] Handle::Handle(Thread*, oop)+0x80 (handles.inline.hpp:42)
V [libjvm.so+0x1a2c6c3] StringTable::intern(oop, JavaThread*)+0xa3 (stringTable.cpp:497)
V [libjvm.so+0x7051eb] AOTStreamedHeapLoader::IterativeObjectLoader::materialize_range(int, int, JavaThread*)+0x46b (aotStreamedHeapLoader.cpp:634)
V [libjvm.so+0x705cf4] AOTStreamedHeapLoader::IterativeObjectLoader::materialize_next_batch(JavaThread*)+0x244 (aotStreamedHeapLoader.cpp:710)
V [libjvm.so+0x706808] AOTStreamedHeapLoader::materialize_early(JavaThread*)+0xb8 (aotStreamedHeapLoader.cpp:750)
V [libjvm.so+0x70727f] AOTStreamedHeapLoader::materialize_objects()+0x7f (aotStreamedHeapLoader.cpp:857)
V [libjvm.so+0x7260f9] AOTThread::aot_thread_entry(JavaThread*, JavaThread*)+0x9 (aotThread.cpp:111)
V [libjvm.so+0x11214cb] JavaThread::thread_main_inner()+0x13b (javaThread.cpp:776)
V [libjvm.so+0x1b9b7f6] Thread::call_run()+0xb6 (thread.cpp:242)
V [libjvm.so+0x17f6d38] thread_native_entry(Thread*)+0x118 (os_linux.cpp:862)
C [libc.so.6+0x9caa4]