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

Ensure consistency of Monitor/Mutex lock acquisitions in relation to safepoint protocol

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P3
    • Resolution: Duplicate
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
      None

      Description

      /*
       * Ensure consistency of Monitor/Mutex lock acquisitions
       * for Java Threads running inside the VM.
       *
       * If a thread has already acquired lock(s) using
       * "Mutex::_no_safepoint_check_flag" (effectively going outside the
       * safepoint protocol), the thread should be disallowed to acquire any
       * additional lock which _is_ participating in the safepoint protocol.
       *
       * If a "safepoint protocol aware" lock is contended, and the thread entering
       * is unable to "fast acquire" the lock using cas/try_spin,
       * it will need to block/park. Blocking on a contended lock involves a
       * state transition and a potential SafepointSynchronize::block() call.
       * Transitioning to a blocked state still holding "Mutex::_no_safepoint_check_flag"
       * acquired locks is allowed, but is *very* deadlock prone.
       *
       * The effect of allowing this state to happen without checking is subtle
       * and hard to debug since a problem might only appear under heavy load and
       * only in situations with increased concurrency levels (product builds).
       *
       */

      Add debug assertions that enforce correct usages of the Mutex::_no_safepoint_check_flag when taking multiple locks.

      If a lock has already been acquired by a thread by passing the Mutex::_no_safepoint_check_flag to circumvent the safepoint protocol, the thread must *not* be allowed to attempt taking a lock on which it *might* block ( a lock which was not acquired by passing Mutex::_no_safepoint_check_flag in its acquisition operation), as such a lock would be participating in the safepoint protocol.

      The suggestion leverages much of the existing code targeting lock order enforcement - this is an additive change to also add invariant checking on "lock acquisition modes".

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                mockner Max Ockner (Inactive)
                Reporter:
                mgronlun Markus Grönlund
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: