The ZHeapIterator has it's own way to traverse the object graph. However, the way it deals with the Klasses and CLDs differ from the regular GCs. One example is that it visits all CLDs, which might included CLDs that are about to get removed by the concurrent unloading.

Today encountered an assert because of this behavior:

assert(ZAddress::is_marked(addr)) failed: Should be marked

Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x18069ee] unsigned long ZBarrier::mark<false, true>(unsigned long)+0x1de
V [libjvm.so+0x87e9b7] ZBarrier::load_barrier_on_oop_field_preloaded(oop volatile*, oop)+0x67
V [libjvm.so+0x87f124] AccessInternal::PostRuntimeDispatch<ZBarrierSet::AccessBarrier<1097812ul, ZBarrierSet>, (AccessInternal::BarrierType)2, 1097812ul>::oop_access_barrier(void*)+0x64
V [libjvm.so+0x11334db] Klass::java_mirror() const+0x1b
V [libjvm.so+0xd3f080] KlassInfoTable::lookup(Klass*)+0x60
V [libjvm.so+0xd3f229] KlassInfoTable::record_instance(oop)+0x39
V [libjvm.so+0xd43fda] RecordInstanceClosure::do_object(oop)+0x9a
V [libjvm.so+0x1829967] void ZHeapIterator::objects_do<true>(ObjectClosure*)+0x157
V [libjvm.so+0x1824d6f] ZHeap::object_iterate(ObjectClosure*, bool)+0x6f
V [libjvm.so+0xd425c8] HeapInspection::heap_inspection(outputStream*)+0x378
V [libjvm.so+0xcddb66] VM_GC_HeapInspection::doit()+0x86
V [libjvm.so+0x1786a33] VM_Operation::evaluate()+0x143
V [libjvm.so+0x17b6175] VMThread::evaluate_operation(VM_Operation*) [clone .constprop.66]+0x145
V [libjvm.so+0x17b6bee] VMThread::loop()+0x74e
V [libjvm.so+0x17b6f6a] VMThread::run()+0xca
V [libjvm.so+0x16ceea6] Thread::call_run()+0xf6
V [libjvm.so+0x13ecd4e] thread_native_entry(Thread*)+0x10e

Fortunately, I already had a patch intended for JDK 14, to solve this problem and add more precise verification of roots and objects. Since that patch solves the underlying problem, the suggestion is to push it to JDK 13.