The Compile_lock is needed for add_to_hierarchy where the implementor is set but reading the implementor embedded fields uses load_acquire and manages unloaded classes.

    InstanceKlass* InstanceKlass::implementor() const {
      InstanceKlass* volatile* ik = adr_implementor();
      if (ik == nullptr) {
        return nullptr;
      } else {
        // This load races with inserts, and therefore needs acquire.
        InstanceKlass* ikls = Atomic::load_acquire(ik);
        if (ikls != nullptr && !ikls->is_loader_alive()) {
          return nullptr; // don't return unloaded class
        } else {
          return ikls;
        }
      }
    }

The field is monotonically proceeds from nullptr to unique implementor, then the holder class if more than one implementor. And stale values can only cause recompilations which are unavoidable in case of racing.

The Compile_lock on access may have been the result of how the code used to work before [~eosterlund] rewrote the subklass and sibling links, or an intermediate version from when we used Compile_lock for all of these fields.