[jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]

Peter Levart plevart at openjdk.java.net
Fri Jul 2 08:47:03 UTC 2021


On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung <mchung at openjdk.org> 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:      * <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


More information about the core-libs-dev mailing list