On Thu, 30 Nov 2023 22:39:26 GMT, Brent Christian <bchri...@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
