Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8262377

Parallel class resolution loses constant pool error

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 17
    • Fix Version/s: 17
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b14

      Description

      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());
            }
          }

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              coleenp Coleen Phillimore
              Reporter:
              coleenp Coleen Phillimore
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: