[jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing
This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&p...) 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 ------------- Commit messages: - JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing Changes: https://git.openjdk.java.net/jdk17/pull/183/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=183&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225667 Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 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
On Wed, 30 Jun 2021 18:24:24 GMT, Mandy Chung <mchung@openjdk.org> wrote:
This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&p...) 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.
Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/183
On Wed, 30 Jun 2021 18:24:24 GMT, Mandy Chung <mchung@openjdk.org> wrote:
This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&p...) 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.
Changes requested by kbarrett (Reviewer). 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/ src/java.base/share/classes/java/lang/System.java line 1867:
1865: * the change of reachability in any particular number of objects 1866: * or any particular number of {@link java.lang.ref.Reference Reference} 1867: * objects be cleared and enqueued.
Similar suggestion here as for Runtime.gc. ------------- PR: https://git.openjdk.java.net/jdk17/pull/183
On Wed, 30 Jun 2021 21:29:17 GMT, Kim Barrett <kbarrett@openjdk.org> 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
This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&p...) 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.
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
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung <mchung@openjdk.org> wrote:
This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&p...) 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.
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
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung <mchung@openjdk.org> wrote:
This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&p...) 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.
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
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung <mchung@openjdk.org> wrote:
This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&p...) 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.
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
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung <mchung@openjdk.org> wrote:
This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&p...) 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.
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: * <p>
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
On Fri, 2 Jul 2021 08:40:42 GMT, Peter Levart <plevart@openjdk.org> 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: * <p>
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
On Fri, 2 Jul 2021 08:52:28 GMT, Peter Levart <plevart@openjdk.org> 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: * <p>
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
On Fri, 2 Jul 2021 08:58:35 GMT, Peter Levart <plevart@openjdk.org> 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
On Wed, 30 Jun 2021 18:24:24 GMT, Mandy Chung <mchung@openjdk.org> wrote:
This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&p...) 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.
This pull request has now been integrated. Changeset: 3a690240 Author: Mandy Chung <mchung@openjdk.org> URL: https://git.openjdk.java.net/jdk17/commit/3a690240336bda8582a15ca52f4dcb78be... Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod 8225667: Clarify the behavior of System::gc w.r.t. reference processing Reviewed-by: rriggs, kbarrett, tschatzl ------------- PR: https://git.openjdk.java.net/jdk17/pull/183
participants (5)
-
Kim Barrett
-
Mandy Chung
-
Peter Levart
-
Roger Riggs
-
Thomas Schatzl