-
Enhancement
-
Resolution: Fixed
-
P4
-
17, 21, 22
-
b15
As seen in JDK-8313081, accidentally passing nullptr Mutex to MutexLocker would just silently avoid the lock.
There are a few places in Hotspot where we pass nullptr to simulate re-entrancy and/or conditionally take the lock. Those places can be more explicit, and the default MutexLocker can disallow nullptrs for extra safety.
I have a prototype for this, WIP.
There are a few places in Hotspot where we pass nullptr to simulate re-entrancy and/or conditionally take the lock. Those places can be more explicit, and the default MutexLocker can disallow nullptrs for extra safety.
I have a prototype for this, WIP.
- relates to
-
JDK-8222811 Consolidate MutexLockerEx and MutexLocker
- Resolved
-
JDK-8313081 MonitoringSupport_lock should be unconditionally initialized after 8304074
- Resolved
-
JDK-8313210 Zip_lock can be uninitialized on some paths
- Closed
-
JDK-8322853 Should use ConditionalMutexLocker in NativeHeapTrimmerThread::print_state
- Resolved
(1 links to)