JDK-8358340 : Support CDS heap archive with Generational Shenandoah
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-06-02
  • Updated: 2025-08-12
  • Resolved: 2025-08-01
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
26 b10Fixed
Related Reports
Blocks :  
JDK-8364111 - InstanceMirrorKlass iterators should handle CDS and hidden classes consistently
Blocks :  
JDK-8364212 - Shenandoah: Rework archived objects loading
Duplicate :  
JDK-8339182 - GenShen: Support for CDS in generational mode
Description
These tests are currently failing with Generational Shenandoah:

$ CONF=linux-x86_64-server-fastdebug make images test TEST=runtime/cds TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational"

...because we have this condition in shenandoahHeap.cpp:

  bool can_load_archived_objects() const override { return !ShenandoahCardBarrier; }

This is a safeguard from CDS loading the archive without looking back at card tables that we need for generational GC to work. But, this load happens naturally when all objects are still young, no GC have happened yet, so no card table updates are needed.
Comments
Changeset: 577ac061 Branch: master Author: Aleksey Shipilev <shade@openjdk.org> Date: 2025-08-01 06:28:29 +0000 URL: https://git.openjdk.org/jdk/commit/577ac0610a0c62d6a3f5501bb0d1bd45f8c47f22
01-08-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25597 Date: 2025-06-02 18:22:36 +0000
31-07-2025
[~wkemper] [~shade] There is a duplicate link to an open task here. Was the task or this bug meant to be closed as a duplicate of the other, or was the link meant to be a relates-to?
12-06-2025
There are weird failures if we do: bool can_load_archived_objects() const override { return true; } $ CONF=linux-x86_64-server-fastdebug make images test TEST=runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational" JTREG=REPEAT_COUNT=10 # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/memory/iterator.inline.hpp:58), pid=2066946, tid=2066956 # assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k)) failed: sanity # Stack: [0x00007ed49230b000,0x00007ed49240b000], sp=0x00007ed492409980, free space=1018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x3a84a6] ClaimMetadataVisitingOopIterateClosure::do_klass(Klass*)+0x66 (iterator.inline.hpp:58) V [libjvm.so+0x1ab7411] void InstanceMirrorKlass::oop_oop_iterate_bounded<narrowOop, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2> >(oop, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2>*, MemRegion)+0x9d1 (devirtualizer.inline.hpp:126) V [libjvm.so+0x1ab7575] void OopOopIterateBoundedDispatch<ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2> >::Table::oop_oop_iterate_bounded<InstanceMirrorKlass, narrowOop>(ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2>*, oop, Klass*, MemRegion)+0x65 (iterator.inline.hpp:181) V [libjvm.so+0x1aaeb85] void ShenandoahScanRemembered::process_clusters<ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2> >(unsigned long, unsigned long, HeapWordImpl**, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2>*, bool, unsigned int)+0x8d5 (iterator.inline.hpp:305) V [libjvm.so+0x1aa958d] ShenandoahScanRememberedTask::do_work(unsigned int)+0xb1d (shenandoahScanRemembered.inline.hpp:359) V [libjvm.so+0x1aa974c] ShenandoahScanRememberedTask::work(unsigned int)+0xcc (shenandoahScanRemembered.cpp:664) V [libjvm.so+0x1e00f58] WorkerThread::run()+0x88 (workerThread.cpp:69) V [libjvm.so+0x1ca07aa] Thread::call_run()+0xba (thread.cpp:243) V [libjvm.so+0x1768218] thread_native_entry(Thread*)+0x128 (os_linux.cpp:868) C [libc.so.6+0x9caa4]
03-06-2025