With JDK-8293336, it's possible to for CDS archive an Java heap object X which is an instance of a hidden class C, where C is designated to be loaded by the app class loader.

(This happens when an indy bytecode for a lambda expression in the application code has been linked ahead-of-time).

However, during early VM bootstrap, before the app class loader is instantiated, it may be possible a GC (or a heap verification, triggered by -XX:VerifyArchivedFields=2, for example) to happen. The collector scans reachable objects and sees the object X (which is reachable via an AOT-resolved entry in the constant pool of an application class), and tries to access the ClassLoaderData of class X in this function:

inline void ClaimMetadataVisitingOopIterateClosure::do_cld(ClassLoaderData* cld) {
  cld->oops_do(this, _claim);
}

At this point, because C is not yet loaded, it has a null cld. The function will crash.

The proposal is to add a null check to handle this special case for CDS.

inline void ClaimMetadataVisitingOopIterateClosure::do_cld(ClassLoaderData* cld) {
  if (cld != nullptr) {
    // Could be null during early VM bootstrap for archived heap objects whose
    // class has not yet been loaded by CDS.
    cld->oops_do(this, _claim);
  }
}