JDK-8372645 : Parallel: Crash during initialization with -UseCompressedOops
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 26
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-11-27
  • Updated: 2025-11-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26Unresolved
Related Reports
Causes :  
JDK-8365932 - Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC
Relates :  
JDK-8372540 - Test gc/arguments/TestSerialHeapSizeFlags.java crashes with AOT: Not an oop
Description
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.
Comments
Currently running a quick test where we expand the card table before we publish the "end" for eden, to make sure the other threads can't allocate before the card table has been resized as well. Have not been able to reproduce with such a change.
27-11-2025