-
Enhancement
-
Resolution: Fixed
-
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