There are a number of deadlock detection/safepoint safety checks involving the 'special' lock rank. Some of these look a bit weird because they compare if rank == special rather than rank <= special. We must not forget there are special locks below the rank 'special', that are equally as special.

It is also weird that try_lock (which will never block) performs checks about safepoint-safety. That seems wrong.

Similarly, it is weird that wait() unconditionally checks that there are no 'special' locks taken because that is unsafe when blocking. That check should only be performed if wait is done with safepoint checks.

The MutexLocker and MutexLockerEx classes perform some checks whether the lock being grabbed is 'special', but the conditions do not match the conditions checked for in the underlying lock() implementations called. lock() checks for rank <= special, but MutexLocker checks for rank == special.

The Thread::check_for_valid_safepoint_state function checks for valid safepoint states. If there could be a potential vm operation after this check, it scans all mutexes checking that there are no locks taken that could block the VM. Ranks that are == special are considered implicitly being allowed to block the vm. But this should really be <= special.

And if it is true that special blocks implicitly are always considered as being allowed to block the VM, then it should not be allowed to create special locks with the allow_vm_block property set to false, as that would be a violation of that assumption.

There might be more issues, so it would be good with some kind of investigation into what we are doing in our deadlock detection/safepoint safety checks and why.

Improving the deadlock detection checks will allow currently incorrectly constrained code due to false positives to move around more freely.