RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor

[Per Liden]

Hi David,

On 8/2/19 1:03 AM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8228857
> webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/

src/hotspot/os/posix/os_posix.hpp
---------------------------------
As far as I recall, the macos bug is only related to the lifecycle of 
condvars (not mutexes). Is that correct?

If so, PlatformMutex could just always own a plain pthread_mutex_t, and 
the PLATFORM_MONITOR_IMPL_INDIRECT stuff could be moved to 
PlatformMonitor to and only deal with the lifecycle of the 
pthread_cond_t. That way the PlatformMutex would not carry the 
burden/cost for working around the condvar bug, which would make 
PlatformMutex even more attractive as a replacement/backing for ZLocks.

How does that sound?

cheers,
Per

> 
> As suggested by Per Liden when PlatformMonitor was introduced by 
> JDK-8210832 we should refactor PlatformMonitor into a simpler 
> PlatformMutex extended by PlatformMonitor. That would potentially allow 
> other synchronization objects e.g. Zlocks, to be replaced by a suitable 
> PlatformX class, and allows us to redefine JVM_RawMonitor support to use 
> it (forthcoming change).
> 
> The refactoring would be obvious and simple if not for the macOS PThread 
> allocation bug workaround. I had to change the Posix variant so that we 
> only use the Impl helper class on macOS, so that we can separate the 
> allocation of the pthread_mutex_t and pthread_cond_t. For macOS both get 
> allocated in the PlatformMutex.
> 
> There are not actual usage changes in this RFE.
> 
> Testing: mach5 tiers 1-3
> 
> Thanks,
> David
> -----