RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]

[Stuart Marks]

On Wed, 31 Jan 2024 01:13:18 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ref/package-info.java line 109:
>> 
>>> 107:  *
>>> 108:  * <li>The clearing of a reference by the garbage collector <i>happens-before</i>
>>> 109:  * the garbage collector enqueues the reference.</li>
>> 
>> Is it worth specifying this middle step? Is there a way to tell that something has been enqueued without removing the reference or calling the deprecated (and very dubious) isEnqueued method? Could we just remove this paragraph, and instead start the next one with "The clearing of a reference by the garbage collector ..."
>
> Here, we are building a chain of _happens-befores_ that reaches from RF to dequeue (and on, to the running of the cleaning action, in the case of Cleaner).
> 
> A ref can also be cleared by a call to clear(), but that has no memory consistency effects.
> 
> So I think it's worth clarifying here that ref-clearing only forms a "link" in the _happens-before_ chain **_when performed by the GC_**.

I had also wondered why we don't just have a single edge GC-clear _happens-before_ dequeue. The reason is that there is a potential gap between GC-clear and GC-enqueue, during which some application thread can call the `enqueue` method. If the application thread's call successfully enqueues the ref, the HB edge is between the application thread's prior actions and the dequeue, and this **breaks** the HB chain that started at `reachabilityFence` and that would follow GC's actions. Thus, to keep the chain intact, GC must clear the ref and also successfully enqueue the ref.

This is rather more complex than I would have liked. It would be nicer if clear-and-enqueue were atomic (either performed by GC, or performed by an application thread's call to `enqueue`, and not a mixture). However, this isn't supported by the specification, and the implementations I'm aware of don't do this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1527092160