/*
 * 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".