RFR: 8210832: Remove sneaky locking in class Monitor

[Patricio Chilano]

Hi all,

Please review the following patch:

Bug URL: https://bugs.openjdk.java.net/browse/JDK-8210832
Webrev: http://cr.openjdk.java.net/~pchilanomate/8210832/v01/webrev/

The current implementation of native monitors uses a technique that we 
name "sneaky locking" to prevent possible deadlocks of the JVM during 
safepoints. The implementation of this technique though introduces a 
race when a monitor is shared between the VMThread and non-JavaThreads. 
This patch aims to solve that problem and at the same time simplify the 
code.

The proposal is based on the introduction of the new class 
PlatformMonitor, which serves as a wrapper for the actual 
synchronization primitives in each platform (mutexes and condition 
variables). Most of the API calls can thus be implemented as simple 
wrappers around PlatformMonitor, adding more assertions and very little 
extra metadata.
To be able to remove the lock sneaking code and at the same time avoid 
deadlocking scenarios, we combine two techniques:

-When a JavaThread that has just acquired the lock, detects there is a 
safepoint request in the ThreadLockBlockInVM destructor, it releases the 
lock before blocking at the safepoint. After resuming from it, the 
JavaThread will have to acquire the lock again.

- In the ThreadLockBlockInVM constructor for the Monitor::wait() method, 
in order to avoid blocking we allow for a possible safepoint request to 
make progress but without letting the JavaThread block for it (since we 
would be stopped by the destructor anyways). We also do that for the 
Monitor::lock() case although no deadlock is being prevented there.

The ThreadLockBlockInVM jacket is a new ThreadStateTransition class used 
instead of the ThreadBlockInVM one. This allowed more flexibility to 
handle the two techniques mentioned above. Also, ThreadBlockInVM calls 
SafepointMechanism::block_if_requested() which creates some problems 
when trying to allow safepoints to continue without stopping, since that 
method not only checks for safepoints but also processes handshakes.

In terms of performance, benchmarks show very similar results to what we 
have now.

So far mach5 hs-tier1-6 on Linux, OS X, Windows and Solaris have been 
tested.

Thanks,
Patricio