In the following code, I suggest to change the assert to a guarantee.

inline ClassLoaderData *ClassLoaderDataGraph::find_or_create(Handle loader, TRAPS) {
  assert(loader() != NULL,"Must be a class loader");
  // Gets the class loader data out of the java/lang/ClassLoader object, if non-null
  // it's already in the loader_data, so no need to add
  ClassLoaderData* loader_data= java_lang_ClassLoader::loader_data(loader());
  if (loader_data) {
     return loader_data;
  }
  return ClassLoaderDataGraph::add(loader, false, THREAD);
}

This guarantee should also check that the classloader is an oop. It should be something like this:
guarantee(loader() != NULL && loader()->is_oop(), "loader must be oop");

We struggled for a long time with an internal stress bug (which could not be run with the fastdebug build) where the JVM was crashing during GC because the object it was looking at had a pointer to a bad klass. The core file analysis showed that the classloader object in the klass was not a valid Oop and we suspected that the classloader object that the JVM received from Java land during class initialization was not a valid object. Unfortunately the problem stopped reproducing and we could not try a run with the above assert changed to guarantee.

I think having a guarantee here ensuring that the classloader is a valid oop will help catch the errors at an early stage during the run rather than crashing the JVM later on in the GC.