Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Tue, 19 Mar 2024 00:40:02 GMT, Y. Srinivas Ramakrishna
wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> further tweaks to reachability
>
> src/java.base/share/classes/java/lang/ref/package-info.java line 137:
>
>> 135: *
>> 136: * A reachable object is any object that can be accessed in
>> any potential
>> 137: * continuing computation from any live thread (as stated in {@jls
>> 12.6.1}).
>
> This seems like somewhat loose and sloppy wording to me. "Any potential
> continuing computation"? "Any live thread"? Could you share a pointer to JLS
> 12.6.1 being referenced here?
The phrase "live thread" is used in a number of places in the API docs to mean
a Thread that has been started and not has not terminated. The `@jls` tag will
create a link in the generated javadoc. If it helps, then it could also link to
Thread::isAlive.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1529527453
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Tue, 19 Mar 2024 22:26:22 GMT, Stuart Marks wrote: >> 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. > > I don't think changing "any" to "some" is helpful. I think "any" is ambiguous > regarding meaning universal or existential strength. The sense used here is, > considering the possible future execution paths of a thread, if any of them > accesses the object, that object is reachable. In other words, it means "any > one" and not "all". OK, no worries; will let you decide what makes sense. Thanks! - PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1531559810
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Tue, 19 Mar 2024 22:19:50 GMT, David Holmes wrote: >> 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. I don't think changing "any" to "some" is helpful. I think "any" is ambiguous regarding meaning universal or existential strength. The sense used here is, considering the possible future execution paths of a thread, if any of them accesses the object, that object is reachable. In other words, it means "any one" and not "all". - PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1531198317
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Tue, 19 Mar 2024 16:38:49 GMT, Y. Srinivas Ramakrishna 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
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Tue, 19 Mar 2024 16:20:55 GMT, Y. Srinivas Ramakrishna wrote: >> https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.html#jls-12.6.1 >> >>> A reachable object is any object that can be accessed in any potential >>> continuing computation from any live thread. >> >> It may be "loose" because the devil is in the details when it comes to >> reachability, but I disagree that it is "sloppy". This expresses >> reachability in simple terms, as a "first-order" or "Newtonian" model. There >> are of course "Quantum" effects that need to be dealt with in practice. The >> JLS alludes to this with: >>> Optimizing transformations of a program can be designed that reduce the >>> number of objects that are reachable to be less than those which would >>> naively be considered reachable. > > 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. - PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1530731176
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Tue, 19 Mar 2024 02:53:37 GMT, David Holmes wrote:
>> src/java.base/share/classes/java/lang/ref/package-info.java line 137:
>>
>>> 135: *
>>> 136: * A reachable object is any object that can be accessed in
>>> any potential
>>> 137: * continuing computation from any live thread (as stated in {@jls
>>> 12.6.1}).
>>
>> This seems like somewhat loose and sloppy wording to me. "Any potential
>> continuing computation"? "Any live thread"? Could you share a pointer to JLS
>> 12.6.1 being referenced here?
>
> https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.html#jls-12.6.1
>
>> A reachable object is any object that can be accessed in any potential
>> continuing computation from any live thread.
>
> It may be "loose" because the devil is in the details when it comes to
> reachability, but I disagree that it is "sloppy". This expresses reachability
> in simple terms, as a "first-order" or "Newtonian" model. There are of course
> "Quantum" effects that need to be dealt with in practice. The JLS alludes to
> this with:
>> Optimizing transformations of a program can be designed that reduce the
>> number of objects that are reachable to be less than those which would
>> naively be considered reachable.
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.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1530705355
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Tue, 19 Mar 2024 00:40:02 GMT, Y. Srinivas Ramakrishna
wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> further tweaks to reachability
>
> src/java.base/share/classes/java/lang/ref/package-info.java line 137:
>
>> 135: *
>> 136: * A reachable object is any object that can be accessed in
>> any potential
>> 137: * continuing computation from any live thread (as stated in {@jls
>> 12.6.1}).
>
> This seems like somewhat loose and sloppy wording to me. "Any potential
> continuing computation"? "Any live thread"? Could you share a pointer to JLS
> 12.6.1 being referenced here?
https://docs.oracle.com/javase/specs/jls/se21/html/jls-12.html#jls-12.6.1
> A reachable object is any object that can be accessed in any potential
> continuing computation from any live thread.
It may be "loose" because the devil is in the details when it comes to
reachability, but I disagree that it is "sloppy". This expresses reachability
in simple terms, as a "first-order" or "Newtonian" model. There are of course
"Quantum" effects that need to be dealt with in practice. The JLS alludes to
this with:
> Optimizing transformations of a program can be designed that reduce the
> number of objects that are reachable to be less than those which would
> naively be considered reachable.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1529617062
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Thu, 14 Mar 2024 23:23:07 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing
>> occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the
>> registered cleaning action.
>>
>> This will bring Cleaner in line (or close) with the memory visibility
>> guarantees made for finalizers in [JLS
>> 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object
>> to the start of a finalizer (§12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one
> additional commit since the last revision:
>
> further tweaks to reachability
src/java.base/share/classes/java/lang/ref/package-info.java line 137:
> 135: *
> 136: * A reachable object is any object that can be accessed in any
> potential
> 137: * continuing computation from any live thread (as stated in {@jls
> 12.6.1}).
This seems like somewhat loose and sloppy wording to me. "Any potential
continuing computation"? "Any live thread"? Could you share a pointer to JLS
12.6.1 being referenced here?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1529523835
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Sat, 16 Mar 2024 04:20:44 GMT, Stuart Marks wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> further tweaks to reachability
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 402:
>
>> 400: * method is called, the garbage collector may already be in the
>> process of
>> 401: * (or already completed) clearing and/or enqueueing this reference.
>> 402: *
>
> Either this is an extra blank line, or you need a `` here.
Removed the blank line; I thought it looked better for the API note to be a
single paragraph.
> src/java.base/share/classes/java/lang/ref/Reference.java line 496:
>
>> 494: * Actions in a thread prior to calling
>> 495: * {@code enqueue} successfully
>> 496: * > href="{@docRoot}/java.base/java/util/concurrent/package-summary.html#MemoryVisibility">happen-before
>
> Editorial. The text here says
>
>> Actions in a thread prior to calling `enqueue` successfully _happen-before_
>> the reference is removed...
>
> This could be confusing, because "successfully" might be read to modify
> "happen-before". This raises questions such as "Is it possible for something
> to happen-before unsuccessfully?" Of course you want "successfully" to modify
> "enqueue" because you're relying on the definition of "successful" given
> previously. Suggest rewording:
>
>> Actions in a thread prior to successful calls to `enqueue` _happen-before_
>> the reference is removed...
Updated, though I made it singular ("a successful call to enqueue"), since we
talk about "the" reference being removed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1529365850
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1529364758
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Sat, 16 Mar 2024 04:21:55 GMT, Stuart Marks wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> further tweaks to reachability
>
> src/java.base/share/classes/java/lang/ref/package-info.java line 127:
>
>> 125: * thread prior to a {@link Reference#reachabilityFence
>> Reference.reachabilityFence(x)}
>> 126: * happen-before cleanup code for {@code x} runs on the cleaner
>> thread.
>> 127: *
>
> Extra blank line or need ``.
Removed
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1529361892
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Wed, 31 Jan 2024 01:13:18 GMT, Brent Christian wrote: >> src/java.base/share/classes/java/lang/ref/package-info.java line 109: >> >>> 107: * >>> 108: * The clearing of a reference by the garbage collector >>> happens-before >>> 109: * the garbage collector enqueues the reference. >> >> 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
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
On Thu, 14 Mar 2024 23:23:07 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing
>> occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the
>> registered cleaning action.
>>
>> This will bring Cleaner in line (or close) with the memory visibility
>> guarantees made for finalizers in [JLS
>> 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object
>> to the start of a finalizer (§12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one
> additional commit since the last revision:
>
> further tweaks to reachability
src/java.base/share/classes/java/lang/ref/Reference.java line 402:
> 400: * method is called, the garbage collector may already be in the
> process of
> 401: * (or already completed) clearing and/or enqueueing this reference.
> 402: *
Either this is an extra blank line, or you need a `` here.
src/java.base/share/classes/java/lang/ref/Reference.java line 496:
> 494: * Actions in a thread prior to calling
> 495: * {@code enqueue} successfully
> 496: * href="{@docRoot}/java.base/java/util/concurrent/package-summary.html#MemoryVisibility">happen-before
Editorial. The text here says
> Actions in a thread prior to calling `enqueue` successfully _happen-before_
> the reference is removed...
This could be confusing, because "successfully" might be read to modify
"happen-before". This raises questions such as "Is it possible for something to
happen-before unsuccessfully?" Of course you want "successfully" to modify
"enqueue" because you're relying on the definition of "successful" given
previously. Suggest rewording:
> Actions in a thread prior to successful calls to `enqueue` _happen-before_
> the reference is removed...
src/java.base/share/classes/java/lang/ref/package-info.java line 127:
> 125: * thread prior to a {@link Reference#reachabilityFence
> Reference.reachabilityFence(x)}
> 126: * happen-before cleanup code for {@code x} runs on the cleaner
> thread.
> 127: *
Extra blank line or need ``.
src/java.base/share/classes/java/lang/ref/package-info.java line 146:
> 144: *
> 145: * An object is strongly reachable if it can be accessed
> without
> 146: * traversing the referent of a Reference object.
Here, we want the definition of "strongly reachable" to build on the JLS
definition of "reachable" quoted above. Suggest something like
> An object is **strongly reachable** if it is reachable and if it can be
> accessed without traversing the referent of a Reference object.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1527074234
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1527080061
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1527074924
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1527076814
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
> Classes in the `java.lang.ref` package would benefit from an update to bring > the spec in line with how the VM already behaves. The changes would focus on > _happens-before_ edges at some key points during reference processing. > > A couple key things we want to be able to say are: > - `Reference.reachabilityFence(x)` _happens-before_ reference processing > occurs for 'x'. > - `Cleaner.register()` _happens-before_ the Cleaner thread runs the > registered cleaning action. > > This will bring Cleaner in line (or close) with the memory visibility > guarantees made for finalizers in [JLS > 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): > _"There is a happens-before edge from the end of a constructor of an object > to the start of a finalizer (§12.6) for that object."_ Brent Christian has updated the pull request incrementally with one additional commit since the last revision: further tweaks to reachability - Changes: - all: https://git.openjdk.org/jdk/pull/16644/files - new: https://git.openjdk.org/jdk/pull/16644/files/603ff4dc..4d6f1dce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16644=12 - incr: https://webrevs.openjdk.org/?repo=jdk=16644=11-12 Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16644.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644 PR: https://git.openjdk.org/jdk/pull/16644
