Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]
On Fri, 2 Jul 2021 08:58:35 GMT, Peter Levart wrote: >> Well, "determine" seems to have both meanings: >> https://www.google.com/search?q=determine >> So by the 2nd meaning, it is good. > > ... and considering the "Schrödinger's cat", even the 1st interpretation is > correct. You can't know whether the cat is dead or not until you "determine" > it's death. This does not mean that you killed it though. I think "determine" sounds right to me. "detect" is another possibility but does not apply well in "this effort" as the subject. This is another way to explain it. During the execution, there are a number of reachability decision points. At each reachability decision point, the references are checked. GC determines if the reachability of the referent has changed to the value corresponding to the type of the reference (softly weakly, or phantom reachable), then it clears and enqueues the reference. - PR: https://git.openjdk.java.net/jdk17/pull/183
Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]
On Fri, 2 Jul 2021 08:52:28 GMT, Peter Levart wrote:
>> src/java.base/share/classes/java/lang/Runtime.java line 662:
>>
>>> 660: * or that any particular number of {@link java.lang.ref.Reference
>>> Reference}
>>> 661: * objects will be cleared and enqueued.
>>> 662: *
>>
>> Hi Mandy,
>> I'm not a native speaker so this might be wrong thinking: The word
>> "determine" feels to me like saying "cause". But running System.gc never
>> actually causes the change of reachability (well it does, when the Reference
>> object is cleared, the reachability of referent changes from
>> Weakly/Softly/Phantom-reachable to unreachable, but I don't think you had
>> that in mind. Or did you?). What would you say about using word "detect"
>> instead? Please others, do say if my thinking is wrong...
>
> Well, "determine" seems to have both meanings:
> https://www.google.com/search?q=determine
> So by the 2nd meaning, it is good.
... and considering the "Schrödinger's cat", even the 1st interpretation is
correct. You can't know whether the cat is dead or not until you "determine"
it's death. This does not mean that you killed it though.
-
PR: https://git.openjdk.java.net/jdk17/pull/183
Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]
On Fri, 2 Jul 2021 08:40:42 GMT, Peter Levart wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Kim's suggestion on the wording
>
> src/java.base/share/classes/java/lang/Runtime.java line 662:
>
>> 660: * or that any particular number of {@link java.lang.ref.Reference
>> Reference}
>> 661: * objects will be cleared and enqueued.
>> 662: *
>
> Hi Mandy,
> I'm not a native speaker so this might be wrong thinking: The word
> "determine" feels to me like saying "cause". But running System.gc never
> actually causes the change of reachability (well it does, when the Reference
> object is cleared, the reachability of referent changes from
> Weakly/Softly/Phantom-reachable to unreachable, but I don't think you had
> that in mind. Or did you?). What would you say about using word "detect"
> instead? Please others, do say if my thinking is wrong...
Well, "determine" seems to have both meanings:
https://www.google.com/search?q=determine
So by the 2nd meaning, it is good.
-
PR: https://git.openjdk.java.net/jdk17/pull/183
Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung wrote:
>> This spec clarification is a follow-up to
>> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320)
>> w.r.t. reference processing. Since there is no guarantee for any memory
>> reclamation by the invocation of `System::gc`, the spec should also clarify
>> that there is no guarantee in determining the change of reachability of any
>> objects or any particular number of `Reference` objects be enqueued and
>> cleared.
>>
>> CSR:
>>https://bugs.openjdk.java.net/browse/JDK-8269690
>
> Mandy Chung has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Kim's suggestion on the wording
src/java.base/share/classes/java/lang/Runtime.java line 662:
> 660: * or that any particular number of {@link java.lang.ref.Reference
> Reference}
> 661: * objects will be cleared and enqueued.
> 662: *
Hi Mandy,
I'm not a native speaker so this might be wrong thinking: The word "determine"
feels to me like saying "cause". But running System.gc never actually causes
the change of reachability (well it does, when the Reference object is cleared,
the reachability of referent changes from Weakly/Softly/Phantom-reachable to
unreachable, but I don't think you had that in mind. Or did you?). What would
you say about using word "detect" instead? Please others, do say if my thinking
is wrong...
-
PR: https://git.openjdk.java.net/jdk17/pull/183
Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung wrote: >> This spec clarification is a follow-up to >> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) >> w.r.t. reference processing. Since there is no guarantee for any memory >> reclamation by the invocation of `System::gc`, the spec should also clarify >> that there is no guarantee in determining the change of reachability of any >> objects or any particular number of `Reference` objects be enqueued and >> cleared. >> >> CSR: >>https://bugs.openjdk.java.net/browse/JDK-8269690 > > Mandy Chung has updated the pull request incrementally with one additional > commit since the last revision: > > Kim's suggestion on the wording Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/183
Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung wrote: >> This spec clarification is a follow-up to >> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) >> w.r.t. reference processing. Since there is no guarantee for any memory >> reclamation by the invocation of `System::gc`, the spec should also clarify >> that there is no guarantee in determining the change of reachability of any >> objects or any particular number of `Reference` objects be enqueued and >> cleared. >> >> CSR: >>https://bugs.openjdk.java.net/browse/JDK-8269690 > > Mandy Chung has updated the pull request incrementally with one additional > commit since the last revision: > > Kim's suggestion on the wording Marked as reviewed by tschatzl (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/183
Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung wrote: >> This spec clarification is a follow-up to >> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) >> w.r.t. reference processing. Since there is no guarantee for any memory >> reclamation by the invocation of `System::gc`, the spec should also clarify >> that there is no guarantee in determining the change of reachability of any >> objects or any particular number of `Reference` objects be enqueued and >> cleared. >> >> CSR: >>https://bugs.openjdk.java.net/browse/JDK-8269690 > > Mandy Chung has updated the pull request incrementally with one additional > commit since the last revision: > > Kim's suggestion on the wording Looks good. - Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/183
Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]
> This spec clarification is a follow-up to > [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) > w.r.t. reference processing. Since there is no guarantee for any memory > reclamation by the invocation of `System::gc`, the spec should also clarify > that there is no guarantee in determining the change of reachability of any > objects or any particular number of `Reference` objects be enqueued and > cleared. > > CSR: >https://bugs.openjdk.java.net/browse/JDK-8269690 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Kim's suggestion on the wording - Changes: - all: https://git.openjdk.java.net/jdk17/pull/183/files - new: https://git.openjdk.java.net/jdk17/pull/183/files/e9765984..020a2d7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=183&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=183&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk17/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/183/head:pull/183 PR: https://git.openjdk.java.net/jdk17/pull/183
Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]
On Wed, 30 Jun 2021 21:29:17 GMT, Kim Barrett wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Kim's suggestion on the wording
>
> src/java.base/share/classes/java/lang/Runtime.java line 661:
>
>> 659: * the change of reachability in any particular number of objects
>> 660: * or any particular number of {@link java.lang.ref.Reference
>> Reference}
>> 661: * objects be cleared and enqueued.
>
> perhaps
> s/number of objects or any/number of objects, or that any/
> s/objects be/objects will be/
That may be clearer. Updated.
-
PR: https://git.openjdk.java.net/jdk17/pull/183
