There's code in class loading that takes the Compile_lock when updating the SystemDictionary like:

    { // Grabbing the Compile_lock prevents systemDictionary updates
      // during compilations.
      MutexLocker mu(THREAD, Compile_lock);
      update_dictionary(THREAD, loaded_class, loader_data);
    }

The system dictionary is a concurrent hashtable and is also protected by the SystemDictionary_lock for writes, so shouldn't need the Compile_lock.  The compiler ci code (and jvmci) code takes out the Compile_lock to read the system dictionary to see if the class is loaded, but briefly and doesn't hold the lock while compiling so the class could be loaded before or after the ci code reads it.

I was concerned by this code because when loading a class, we used to have
   {
        MutexLocker ml(Compile_lock);
        add_to_hierarchy();
        update_dictionary();
    }

But JDK-8300926 moved add_to_hierarchy outside of this code block.  add_to_hierarchy needs the Compile_lock because the Compile_lock is also the lock for dependencies, but now it releases the compile lock before updating the dictionary.

Even with the Compile_lock around the update_dictionary() if there's an assert to verify that everything in the hierarchy (subclass, sibling and implementor) is also found in the dictionary, it could fire depending on timing.  But nothing in dependencies does that.

Still the Compile_lock doesn't help.  There used to be a notice_modifications() call that would be a short cut for dependencies that was set during system dictionary updates and read using the Compile_lock.  That code is now gone.