OopStorage::release locks its allocation mutex when the block containing the released entry (or entries) is transitioning from full to not full, or from not empty to empty.  When those transitions occur the block is added to the allocation list or moved to the end of the allocation list, respectively.  The allocation mutex is locked to protect that linked list manipulation.

JNI global and weak global references are now (JDK-8194312) implemented using OopStorage.  This has resulted in a change of locking behavior.  Previously, the release of such a reference did not involve any locking.  Because of this change of lock usage we ran into nested lock rank ordering failures (JDK-8195979).

Those failures can be worked around by adjusting the ranks of the various JNI mutexes.  However, the necessary ranking turns out to be below "special" (since the Patching_lock is one of the problem cases, and it is ranked "special"), and that doesn't seem ideal.

Another approach would be to have the patching code defer the handle release until it has exited the Patching_lock context.  That looks somewhat difficult and probably ugly, and only addresses this particular case.  There may be other rank order problems introduced by the newly introduced potential locking on handle release.

A better solution would be to eliminate the locking in handle release altogether.