Skip to content
This repository was archived by the owner on Sep 2, 2022. It is now read-only.
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.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions src/java.base/share/classes/java/lang/Runtime.java
Original file line number Diff line number Diff line change
Expand Up @@ -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

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

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

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
Expand Down
5 changes: 5 additions & 0 deletions src/java.base/share/classes/java/lang/System.java
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down