-
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
-