Skip to content
This repository has been archived by the owner. It is now read-only.

JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing #183

Closed
wants to merge 2 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
@@ -655,6 +655,10 @@ public Process exec(String[] cmdarray, String[] envp, File dir)
* There is no guarantee that this effort will recycle any particular
* number of unused objects, reclaim any particular amount of space, or
* complete at any particular time, if at all, before the method returns or ever.
* There is also no guarantee that this effort will determine
* the change of reachability in any particular number of objects,
* or that any particular number of {@link java.lang.ref.Reference Reference}
* objects will be cleared and enqueued.
* <p>
Copy link
Contributor

@plevart plevart Jul 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Contributor

@plevart plevart Jul 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, "determine" seems to have both meanings:
https://www.google.com/search?q=determine
So by the 2nd meaning, it is good.

Copy link
Contributor

@plevart plevart Jul 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... 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.

Copy link
Member Author

@mlchung mlchung Jul 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

* The name {@code gc} stands for "garbage
* collector". The Java Virtual Machine performs this recycling
@@ -1861,6 +1861,11 @@ public static void exit(int status) {
* There is no guarantee that this effort will recycle any particular
* number of unused objects, reclaim any particular amount of space, or
* complete at any particular time, if at all, before the method returns or ever.
* There is also no guarantee that this effort will determine
* the change of reachability in any particular number of objects,
* or that any particular number of {@link java.lang.ref.Reference Reference}
* objects will be cleared and enqueued.
*
* <p>
* The call {@code System.gc()} is effectively equivalent to the
* call: