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

[Brent Christian]

On Thu, 30 Nov 2023 22:39:26 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> IMO, the core of the semantics here are that the reachabilityFence() call happens before clearing or enqueueing of any References to the argument. I think it's the call itself, not the end of the argument.s scope (which may not even make sense) that matters here.
>> 
>> Perhaps reachabilityFence(x) should also happen before any objects that are definitely reachable from x (JLS 12.6.2) at that point are cleared or enqueued. That is not completely clear to me, since it impacts the legality of dead field elimination. And it would be nice to get rid of 12.6.2.
>
> The existing docs refer to "invocation" of this method. I've continued with that, and in general have kept this at a bit higher level, in order to simplify understanding.
> 
> I'm open to more detailed wording, if it would improve understandability, (or if what I have is not functionally accurate).

> Perhaps reachabilityFence(x) should also happen before any objects that are definitely reachable from x (JLS 12.6.2) at that point are cleared or enqueued.

I don't think we need to extend this to objects reachable from x.

Consider what I consider to be the primary scenario - x has resources to cleanup after it becomes unreachable.

x may refer to a variety of other objects; some will be the resources needing cleanup, others may be ordinary, non-resource objects.

For proper cleanup, resource objects **_already_** must remain reachable longer than x (so their cleanup can be performed even after x is unreachable). Cleaner takes care of this for you (The Cleaner instance keeps a reference to the registered "cleaning action", which refers to the resources). Or, one must roll their own if using Reference+ReferenceQueue directly.

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

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