JDK-8350580 shows that JDK-8346567 made a little behavioral change. Class unloading treats classes as two groups: still loaded and unloaded. For unloaded classes, it is important not to resurrect anything related to them, before we complete unloading and the classes fully disappear. This looks to be affecting Shenandoah, since its concurrent class unloading model relies on dead Java mirrors staying dead.

In the reproducer in JDK-8350580, it is clear that unloading code accidentally resurrects the dead/unmarked DynamicClass Java mirror when doing `Klass::modifier_flags()` in `JfrTypeSet::do_write_klass()`, which we enter to from class unloading code via `JfrTypeSet::on_unloading_classes()`.

Java mirror handle resolution includes LRB barrier for Shenandoah that resurrects the object unless the access is marked as AS_NO_KEEPALIVE. I see no reason not to read the Java mirror with AS_NO_KEEPALIVE for the purposes of getting the modifiers. Before JDK-8346567, we pulled class modifiers from the native `Klass*`, and so we bypassed this trouble.

But it is even worse: by the time we enter unloading, the Java mirror can be allocated over. Running the following test reliably fails OopHandle checks, because the Java mirror is already in empty region, ready to accept allocations:

$ CONF=linux-x86_64-server-fastdebug make images test TEST=jdk/jfr TEST_VM_OPTS=-XX:+UseShenandoahGC

# Internal Error (/home/shade/trunks/jdk/src/hotspot/share/oops/oopHandle.inline.hpp:48), pid=2502634, tid=2502680
# assert(oopDesc::is_oop_or_null(obj)) failed: Should be oop: 0x00000000f78bbf30
#

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x12db208] OopHandle::peek() const+0xc8 (oopHandle.inline.hpp:48)
V [libjvm.so+0x12d5d05] Klass::modifier_flags() const+0x25 (klass.inline.hpp:86)
V [libjvm.so+0x1069924] write_klass(JfrCheckpointWriter*, Klass const*, bool, int&)+0xd4 (jfrTypeSet.cpp:350)
V [libjvm.so+0x106fce7] JfrArtifactCallbackHost<Klass const*, CompositeFunctor<Klass const*, JfrTypeWriterHost<JfrPredicatedTypeWriterImplHost<Klass const*, SerializePredicate<Klass const*>, &(write__klass(JfrCheckpointWriter*, void const*))>, 183u>, KlassArtifactRegistrator> >::do_artifact(void const*)+0xe7 (jfrTypeSet.cpp:397)
V [libjvm.so+0xa22d02] ClassLoaderData::classes_do(void (*)(Klass*))+0x42 (classLoaderData.cpp:394)
V [libjvm.so+0xa3a5eb] ClassUnloadingContext::classes_unloading_do(void (*)(Klass*))+0x4b (classUnloadingContext.cpp:90)
V [libjvm.so+0x106f038] JfrTypeSet::serialize(JfrCheckpointWriter*, JfrCheckpointWriter*, bool, bool)+0x1148 (jfrTypeSet.cpp:558)
V [libjvm.so+0xfb0bd6] JfrCheckpointManager::on_unloading_classes()+0x66 (jfrCheckpointManager.cpp:630)
V [libjvm.so+0x1a5d012] SystemDictionary::do_unloading(GCTimer*)+0x432 (systemDictionary.cpp:1537)
V [libjvm.so+0x1911969] ShenandoahUnload::unload()+0xa9 (shenandoahUnload.cpp:151)
V [libjvm.so+0x18398cd] ShenandoahHeap::do_class_unloading()+0x1d (shenandoahHeap.cpp:1987)
V [libjvm.so+0x17b9788] ShenandoahConcurrentGC::entry_class_unloading()+0xd8 (shenandoahConcurrentGC.cpp:976)
V [libjvm.so+0x17bd825] ShenandoahConcurrentGC::collect(GCCause::Cause)+0x535 (shenandoahConcurrentGC.cpp:174)
V [libjvm.so+0x17ca348] ShenandoahControlThread::service_concurrent_normal_cycle(GCCause::Cause)+0xd8 (shenandoahControlThread.cpp:309)
V [libjvm.so+0x17caaef] ShenandoahControlThread::run_service()+0x33f (shenandoahControlThread.cpp:149)
V [libjvm.so+0xad792f] ConcurrentGCThread::run()+0x1f (concurrentGCThread.cpp:47)
V [libjvm.so+0x1aba3ae] Thread::call_run()+0xbe (thread.cpp:231)
V [libjvm.so+0x15d141b] thread_native_entry(Thread*)+0x12b (os_linux.cpp:877)