When resolving classes through the constant pool, we need to return the same error as a previous resolution because of JVMS 5.4.3:

"If an error occurs during resolution of the symbolic reference, then it is either (i) an instance of IncompatibleClassChangeError (or a subclass); (ii) an instance of Error (or a subclass) that arose from resolution or invocation of a bootstrap method; or (iii) an instance of LinkageError (or a subclass) that arose because class loading failed or a loader constraint was violated. The error must be thrown at a point in the program that (directly or indirectly) uses the symbolic reference.

Subsequent attempts to resolve the symbolic reference always fail with the same error that was thrown as a result of the initial resolution attempt. If the symbolic reference is to a dynamically-computed constant, the bootstrap method is not re-executed for these subsequent attempts."

When loading classes in parallel, if a class loader changes the class bytes so that the second attempt succeeds, the constant pool entry that records the first failure can be overwritten and succeed. Which due to timing, violates this rule.

Before permgen elimination, the constant pool was locked for the update at the end of loading, but it was changed to be unlocked, which could cause this stomp.

Old code used to recheck for error before updating the constant pool entry:
    } else {
      ObjectLocker ol (this_oop, THREAD);
      // Only updated constant pool - if it is resolved.
      do_resolve = this_oop->tag_at(which).is_unresolved_klass();
      if (do_resolve) {
        this_oop->klass_at_put(which, k());
      }
    }