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

Fix the biased-locking code in ObjectSynchronizer::FastHashCode

    XMLWordPrintable

    Details

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

      Description

      During the review for JDK-8250606 it was noted that the biased-locking section of FastHashCode contained a similar assertion regarding execution at a safepoint:

            // Relaxing assertion for bug 6320749.
            assert(Universe::verify_in_progress() ||
                   !SafepointSynchronize::is_at_safepoint(),
                   "biases should not be seen by VM thread here");

      which gives the impression that it is okay to execute this code block at a safepoint if verify_in_progress(0 is true. But if we examine the next line of code:

        BiasedLocking::revoke(hobj, JavaThread::current());

      we find that at a safepoint:
      a) JavaThread::current() will assert because the current thread will be the VMThread; and
      b) BiasedLocking::revoke itself contains an assertion that it is not invoked at a safepoint.

      In practice there is no issue with revoking the bias at a safepoint, we just have to use the right code to do so (as done elsewhere in the same file):

      if (SafepointSynchronize::is_at_safepoint()) {
        BiasedLocking::revoke_at_safepoint(hobj);
      } else {
        BiasedLocking::revoke(hobj, self);
      }

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              dholmes David Holmes
              Reporter:
              dholmes David Holmes
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: