On Wed, 29 Jul 2026 09:23:49 GMT, Per Minborg <[email protected]> wrote:
>> This PR proposes to improve the handling of the fields in >> `LazyCollections.Mutexes` so that it becomes more evident that there are no >> races. It is also proposed to add a defensive check of `mutexes` so that it >> is obvious to a reader that the `Unsafe` operation does not operate on >> `null`. Furthermore, it is proposed to remove the extra `AtomicInteger` >> object and use an `int` field directly. >> >> Please note that there is no (known) error in how the class `Mutexes` works. >> This PR only makes it more explicit and efficient. So, for example, we do >> not have to backport this PR. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Fix comment src/java.base/share/classes/java/util/LazyCollections.java line 625: > 623: UNSAFE.putReferenceVolatile(mutexes, offset, TOMB_STONE); > 624: // This access mode provides both acquire and release > ordering which is > 625: // needed here. Can you elaborate on this. AFAICS you need strong ordering between the setting of a TOMB_STONE and the null'ing of `mutexes`, but as both of those are volatile writes you implicitly have that. The counter decrement needs to be atomic for correctness of the null'ing logic, but the implicit acquire/release of that atomic op seem irrelevant to anything except the atomic op itself. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32070#discussion_r3679647623
