The proposal is to add `Atomic<T>`, where `T` is a supported atomic type as before. Then incrementally replace (most) uses of that idiom with uses of this new type. "Most" because it is expected there will be some small residue where use of the `Atomic<T>` class isn't appropriate. One example is BitMap, which provides some atomic operations but where it would not be appropriate to change the underlying data to be an array of `Atomic<bm_word_t>`. Another example is the atomic functions in the `Copy` class.
- blocks
-
JDK-8372564 Convert StringDedup to use Atomic<T>
-
- Open
-
-
JDK-8371923 Update LockFreeStack for Atomic<T>
-
- Resolved
-
-
JDK-8371956 Convert OopStorage to use Atomic<T>
-
- Resolved
-
-
JDK-8371965 Convert TaskQueueSuper to use Atomic<T>
-
- Resolved
-
-
JDK-8372240 Convert FreeListAllocator to use Atomic<T>
-
- Resolved
-
-
JDK-8372251 Convert PartialArrayStepper/State to use Atomic<T>
-
- Resolved
-
-
JDK-8372565 Convert SATBMarkQueue to use Atomic<T>
-
- Resolved
-
-
JDK-8372650 Convert GenericWaitBarrier to use Atomic<T>
-
- Resolved
-
- is blocked by
-
JDK-8367014 Rename class Atomic to AtomicAccess
-
- Resolved
-
- relates to
-
JDK-8247213 G1: Reduce usage of volatile in favour of Atomic operations
-
- Open
-
- links to
-
Commit(master)
openjdk/jdk/10220ed0
-
Review(master)
openjdk/jdk/27462
-
Review(master)
openjdk/jdk/27539