RFR: 8071507: (ref) Clear phantom reference as soft and weak references do
peter.levart at gmail.com
Thu Dec 3 13:01:28 UTC 2015
Kudos for finding an observable change in behavior. Although the
specification could also be read in a way so that this would not be
observable. Originally it states:
"Unlike soft and weak references, phantom references are not
automatically cleared by the garbage collector as they are enqueued. *An
object that is reachable via phantom references will remain so* until
all such references are cleared or themselves become unreachable."
I read this as: "... An object that is reachable via phantom references
will remain phantom reachable ..."
If phantom-reachable objects have links among them, this doesn't make
them strongly reachable.
So I would argue that when both roots to O1 and O2 (in the test) are
finally removed, O1 and O2 should be considered phantom-reachable,
regardless of the link from O1 -> O2. When root to O2 is removed before
the 2nd GC round, P2 should be notified as O2 transitions from reachable
-> phantom reachable. This is no different from the situation when both
roots to O1 and O2 are removed at the same time before a GC round: both
P1 and P2 are notified.
Anyway, this change is good. I would only rephrase this statement in
package-info.java a bit:
96 * Soft and weak references are automatically cleared by the collector
97 * before being added to the queues with which they are
registered, if any,
98 * hence they need not be registered with a queue in order to be
99 * Phantom references, by contrast, do not allow their referents to be
100 * retrieved, so they must be registered with a queue.
Perhaps to something like:
Soft, weak and phantom references are automatically cleared by the
collector before being added to the queues with which they are
registered, if any. While Soft and weak references allow access to the
referent before they are cleared, and hence need not be registered with
a queue in order to be useful, Phantom references prevent access to the
referent and are only useful when registered with a queue.
On 12/02/2015 07:37 PM, Kim Barrett wrote:
> Please review this change to PhantomReference processing, changing the
> GC-based notification to automatically clear the referent.
> This change provides performance benefits by eliminating the work
> involved in keeping the otherwise inaccessible referent objects alive,
> as required by the existing specification. This not only immediately
> removes some work, but may enable further performance improvements.
> It also allows the referent objects to be immediately reclaimed in
> the GC cycle in which they were determined to be inaccessible, rather
> than lingering as a form of floating garbage until the application
> deals with the notified reference.
> This change results in a behavioral change to application code, as
> demonstrated by the associated test. Under the old specification, a
> reference R with referent X may be kept alive because it is referenced
> by an otherwise inaccessible referent Y of phantom reference P. This
> will result in X being treated as strongly referenced and prevent R
> from being notified, even if R is a phantom reference and X has become
> inaccessible to the application. With this change, Y is reclaimed
> when it becomes inaccessible and P is notified, and no longer prevents
> X from itself becoming a candidate for reclaimation once it is no
> longer accessible to the application. While this is a change in
> behavior, it seems unlikely to affect applications negatively.
> jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev