RFR: 8358340: Support CDS heap archive with Generational Shenandoah

[Aleksey Shipilev]

On Mon, 2 Jun 2025 18:22:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Now that [JDK-8364111](https://bugs.openjdk.org/browse/JDK-8364111) is integrated, Generational Shenandoah can support CDS heap loads. This also allows Generational Shenandoah to work well with Leyden/AOT. We allocate things in young regions, and there is nothing else in the heap, so no card table updates are necessary.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` 
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:+ShenandoahVerify`

Debugging breadcrumbs: this seems to still fail intermittently:


$ CONF=linux-x86_64-server-fastdebug make test TEST=gc/shenandoah/TestAllocIntArrays.java JTREG=REPEAT_COUNT=10

#  Internal Error (/home/shade/trunks/jdk/src/hotspot/share/memory/iterator.inline.hpp:59), pid=1222144, tid=1222159
#  assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k)) failed: sanity: java.lang.module.ModuleDescriptor$Modifier

Stack: [0x000071e2112d3000,0x000071e2113d3000],  sp=0x000071e2113d1930,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x3bad37]  ClaimMetadataVisitingOopIterateClosure::do_klass(Klass*)+0x427  (iterator.inline.hpp:59)
V  [libjvm.so+0x1afeb11]  void InstanceMirrorKlass::oop_oop_iterate_bounded<narrowOop, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2> >(oop, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2>*, MemRegion)+0x9d1  (devirtualizer.inline.hpp:126)
V  [libjvm.so+0x1afec75]  void OopOopIterateBoundedDispatch<ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2> >::Table::oop_oop_iterate_bounded<InstanceMirrorKlass, narrowOop>(ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2>*, oop, Klass*, MemRegion)+0x65  (iterator.inline.hpp:182)
V  [libjvm.so+0x1af6285]  void ShenandoahScanRemembered::process_clusters<ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2> >(unsigned long, unsigned long, HeapWordImpl**, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)2>*, bool, unsigned int)+0x8d5  (iterator.inline.hpp:306)
V  [libjvm.so+0x1af0c8d]  ShenandoahScanRememberedTask::do_work(unsigned int)+0xb1d  (shenandoahScanRemembered.inline.hpp:359)
V  [libjvm.so+0x1af0e4c]  ShenandoahScanRememberedTask::work(unsigned int)+0xcc  (shenandoahScanRemembered.cpp:664)
V  [libjvm.so+0x1e52348]  WorkerThread::run()+0x88  (workerThread.cpp:69)
V  [libjvm.so+0x1cf321a]  Thread::call_run()+0xba  (thread.cpp:243)
V  [libjvm.so+0x17a78c8]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:868)
C  [libc.so.6+0x9caa4]


That assert seems to mean that the CLD for the class in question is `nullptr`.

All right, I think I found a non-Shenandoah bug: [JDK-8364111](https://bugs.openjdk.org/browse/JDK-8364111) :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25597#issuecomment-3114216592
PR Comment: https://git.openjdk.org/jdk/pull/25597#issuecomment-3117880099