- 
    Enhancement 
- 
    Resolution: Fixed
- 
     P4 P4
- 
    12
- 
        b07
Alternatively, one should identify all such locks, and ensure that Java threads never block at safepoints while holding them (_no_safepoint_check_flag). While it seems as though this could increase the time to reach a safepoint (or at least increase the mean, if not the variance), the latter approach might make for a cleaner, more maintainable JVM design.
- duplicates
- 
                    JDK-8170643 Remove mixed-size accesses to the LockWord -           
- Closed
 
-         
- 
                    JDK-8217755 SuspendThread might hang expecting lock in JavaThread::is_ext_suspend_completed -           
- Closed
 
-         
- relates to
- 
                    JDK-5030646 CMS: atg crashed with fastdebug build on rhas_3.0 SP1 -           
- Closed
 
-         
- 
                    JDK-8213137 Remove static initialization of monitor/mutex instances -           
- Resolved
 
-         
- 
                    JDK-8213105 Reorder methods in mutex.cpp so related ones are near each other -           
- Closed
 
-         
- 
                    JDK-8219642 ciReplay loads wrong data when MethodData size changes -           
- Resolved
 
-         
- 
                    JDK-8256383 PlatformMutex::try_lock has different semantics on Windows and Posix -           
- Resolved
 
-         
- 
                    JDK-8218975 Bug in macOSX kernel's pthread support -           
- Closed
 
-         
- 
                    JDK-8219448 split-if update_uses accesses stale idom data -           
- Closed
 
-         
- 
                    JDK-8230292 Handshakes can live-lock causing a stack overflow. -           
- Closed
 
-         
- 
                    JDK-8214174 runtime/handshake/HandshakeWalkSuspendExitTest.java failed with timeout -           
- Closed
 
-         
- 
                    JDK-8074355 make MutexLocker smarter about non-JavaThreads -           
- Resolved
 
-