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

[David Holmes]

On Tue, 19 Mar 2024 16:38:49 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Sorry, my use of words was sloppy here. I think I did mean loose or somewhat informal and therefore slippery.
>> 
>> What I was saying is that using terms such as "any continuing computation" doesn't make sense because this is referring to a current state of the computation. I'm not sure what "any continuing computation" from a state is because the concept of what constitutes the notion of "a continuing computation" has not been defined before. To me it sounds like a computation tree with nodes as state and transitions as edges and a continuing computation as a path through that tree into the future. The way it is written then, it sounds to the naive reader, or to me at least, as if the object is perpetually reachable by every thread always. I assume I am misinterpreting the intention of the writing, but it sounds too loose for a definition being invoked here in the javadoc. May be it can be tightened up a bit.
>> 
>> Could one state instead that "An object is reachable at a given state when some thread is able to access the object through a sequence of steps starting at that state without other threads taking any steps."  ? Or something along those lines? Or at least something tighter than the current wording that is somewhat too loose.
>
> In fact, it appears as if the problem is with the use of "any", which is universal in strength, whereas the intention here is existential in strength (as suggested by. my wording). Indeed, you might achieve the same effect by replacing "any" with "some" so that:
> 
> "An object is reachable if it can be accessed in some continuing computation from some live thread."
> 
> You needn't even say live because dead threads can neither take steps nor continue participating in the computation nor can they "access" objects for whatever informal notion of access. The "some continuing computation" subsumes "potential" (as in a possible future) so potential can be dropped.

I think you are overthinking this somewhat Ramki. I don't see a practical (non discrete-math) distinction between "some" and "any", so would not object to that single word change if it helps. But "potential" should remain as it covers branching in the program whereby if we proceed down one branch an object remains reachable, whereas if we precede down another then it may not.

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

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