-
Enhancement
-
Resolution: Fixed
-
P2
-
None
As announced by Doug Lea on
https://concurrency.markmail.org/thread/kfdv6tg3tnutl4ts
```
The java.util.concurrent.locks classes were among the first classes
written for j.u.c, and were in increasing need of attention as new
low-level support and new techniques became available. I did a
reimplementation of most internals, keeping most of the same basic
algorithms. Among other improvements, most locks (including
ReentrantLock) and Conditions are now a bit faster, which also makes
most BlockingQueues etc faster. Even StampedLock got a refresh; it is
still our fastest and in many cases best lock. On the other hand,
prospects for improving ReentrantReadWriteLock are not good, mainly
because of the read-reentrancy requirements. (Even if you cannot replace
usages with StampedLock, you may be able to use: ReadWriteLock r = new
StampedLock().asReadWriteLock()).
```
We want to be able to make (careful!) use of relaxed atomics introduced in recent jdk releases.
We want to prepare for the Loom project. Loom changes the cost model of spinning/blocking and strongly prefers use of j.u.c. locks over builtin locks (in 2019).
https://concurrency.markmail.org/thread/kfdv6tg3tnutl4ts
```
The java.util.concurrent.locks classes were among the first classes
written for j.u.c, and were in increasing need of attention as new
low-level support and new techniques became available. I did a
reimplementation of most internals, keeping most of the same basic
algorithms. Among other improvements, most locks (including
ReentrantLock) and Conditions are now a bit faster, which also makes
most BlockingQueues etc faster. Even StampedLock got a refresh; it is
still our fastest and in many cases best lock. On the other hand,
prospects for improving ReentrantReadWriteLock are not good, mainly
because of the read-reentrancy requirements. (Even if you cannot replace
usages with StampedLock, you may be able to use: ReadWriteLock r = new
StampedLock().asReadWriteLock()).
```
We want to be able to make (careful!) use of relaxed atomics introduced in recent jdk releases.
We want to prepare for the Loom project. Loom changes the cost model of spinning/blocking and strongly prefers use of j.u.c. locks over builtin locks (in 2019).
- csr for
-
JDK-8230240 AQS and lock classes refresh
- Closed
- relates to
-
JDK-8231031 runtime/ReservedStack/ReservedStackTest.java fails after jsr166 refresh
- Resolved
-
JDK-8231032 ThreadMXBean locking tests fail after JSR 166 refresh
- Resolved
-
JDK-8231036 vmTestbase monitoring tests fail after JSR 166 refresh
- Resolved
-
JDK-8317960 [17u] Excessive CPU usage on AbstractQueuedSynchronized.isEnqueued
- Resolved