While investigating JDK-8372540 I found that a similar problem occurs with Parallel. When we run with -UseCompressedOops we will use the new object streaming AOT cache which allocates more during startup. This relies on the GCs being able to expand the heap/young generation during initialization.

This can be reproduced by running:
while jdk-26/fastdebug/bin/java -XX:-UseCompressedOops -XX:+UseParallelGC -XX:InitialHeapSize=1m -Xmx1002M -version; do date; done

Top of hs_err:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x000072d0c85140ba, pid=1691641, tid=1691643
#
# JRE version: (26.0+25) (fastdebug build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-ea+25-2529, mixed mode, sharing, tiered, compressed class ptrs, parallel gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x7140ba] AccessInternal::PostRuntimeDispatch<CardTableBarrierSet::AccessBarrier<2383942ul, CardTableBarrierSet>, (AccessInternal::BarrierType)1, 2383942ul>::oop_access_barrier(oop, long, oop)+0x18a
#
# Core dump will be written. Default location: /home/sjohanss/repos/openjdk/core.1691641
#
#

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

Command Line: -XX:-UseCompressedOops -XX:+UseParallelGC -XX:InitialHeapSize=1m -Xmx1002M

Host: fearofthedark, Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz, 40 cores, 62G, Ubuntu 24.04.1 LTS
Time: Thu Nov 27 08:11:56 2025 CET elapsed time: 0.052675 seconds (0d 0h 0m 0s)

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

Current thread (0x000072d0c002ccd0): JavaThread "Unknown thread" [_thread_in_vm, id=1691643, stack(0x000072d0c7c17000,0x000072d0c7d17000) (1024K)]

Stack: [0x000072d0c7c17000,0x000072d0c7d17000], sp=0x000072d0c7d12dc0, free space=1007k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x7140ba] AccessInternal::PostRuntimeDispatch<CardTableBarrierSet::AccessBarrier<2383942ul, CardTableBarrierSet>, (AccessInternal::BarrierType)1, 2383942ul>::oop_access_barrier(oop, long, oop)+0x18a (cardTableBarrierSet.inline.hpp:39)
V [libjvm.so+0x70be36] AOTStreamedHeapLoader::TracingObjectLoader::drain_stack(Stack<AOTHeapTraversalEntry, (MemTag)13>&, JavaThread*)+0x1d6 (accessBackend.hpp:421)
V [libjvm.so+0x70c43c] AOTStreamedHeapLoader::TracingObjectLoader::materialize_object_transitive(int, Stack<AOTHeapTraversalEntry, (MemTag)13>&, JavaThread*)+0x1ec (aotStreamedHeapLoader.cpp:517)
V [libjvm.so+0x70c614] AOTStreamedHeapLoader::TracingObjectLoader::materialize_root(int, Stack<AOTHeapTraversalEntry, (MemTag)13>&, JavaThread*)+0x44 (aotStreamedHeapLoader.cpp:524)
V [libjvm.so+0x70cabd] AOTStreamedHeapLoader::materialize_root(int)+0x3ed (aotStreamedHeapLoader.cpp:1060)
V [libjvm.so+0x70cd6b] AOTStreamedHeapLoader::get_root(int)+0x11b (aotStreamedHeapLoader.cpp:1075)
V [libjvm.so+0x102299f] HeapShared::get_root(int, bool)+0x16f (heapShared.cpp:455)
V [libjvm.so+0x14cba7d] Klass::archived_java_mirror()+0x2d (klass.cpp:930)
V [libjvm.so+0x110f02a] java_lang_Class::restore_archived_mirror(Klass*, Handle, Handle, Handle, JavaThread*)+0xca (javaClasses.cpp:1231)
V [libjvm.so+0x14d03bc] Klass::restore_unshareable_info(ClassLoaderData*, Handle, JavaThread*)+0x74c (klass.cpp:903)
V [libjvm.so+0x1080701] InstanceKlass::restore_unshareable_info(ClassLoaderData*, Handle, PackageEntry*, JavaThread*)+0x81 (instanceKlass.cpp:2823)
V [libjvm.so+0x1b4054a] SystemDictionary::load_shared_class(InstanceKlass*, Handle, Handle, ClassFileStream const*, PackageEntry*, JavaThread*)+0x16a (systemDictionary.cpp:1132)
V [libjvm.so+0x1b40cf7] SystemDictionary::load_instance_class_impl(Symbol*, Handle, JavaThread*)+0x5a7 (systemDictionary.cpp:1285)
V [libjvm.so+0x1b3e32c] SystemDictionary::load_instance_class(Symbol*, Handle, JavaThread*)+0x1c (systemDictionary.cpp:1357)
V [libjvm.so+0x1b3ed04] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, JavaThread*)+0x834 (systemDictionary.cpp:699)
V [libjvm.so+0x101e5e3] HeapShared::resolve_or_init(Klass*, bool, JavaThread*)+0x103 (systemDictionary.hpp:103)
V [libjvm.so+0x102455b] HeapShared::resolve_or_init_classes_for_subgraph_of(Klass*, bool, JavaThread*)+0x22b (heapShared.cpp:1480)
V [libjvm.so+0x10249d0] HeapShared::resolve_classes_for_subgraphs(JavaThread*, ArchivableStaticFieldInfo*)+0xb0 (heapShared.cpp:1316)
V [libjvm.so+0x1bf286f] Universe::genesis(JavaThread*)+0xff (universe.cpp:451)
V [libjvm.so+0x1bf6fc5] universe2_init()+0x35 (universe.cpp:1119)
V [libjvm.so+0x1073069] init_globals2()+0x9 (init.cpp:173)
V [libjvm.so+0x1bbb4cf] Threads::create_vm(JavaVMInitArgs*, bool*)+0x3af (threads.cpp:622)
V [libjvm.so+0x123ebe4] JNI_CreateJavaVM+0x54 (jni.cpp:3621)
C [libjli.so+0x3e7f] JavaMain+0x8f (java.c:1506)
C [libjli.so+0x8099] ThreadJavaMain+0x9 (java_md.c:646)
C [libc.so.6+0x9ca94]

siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x000072d0c799f000

From what I can tell there is nothing preventing another thread from allocating after eden has been expanded but before the card-table has been expanded to cover the new part of the heap.