RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

Peter Levart peter.levart at gmail.com
Thu Dec 3 13:01:28 UTC 2015


Hi Kim,

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



Regards, Peter

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.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8071507
>
> Webrevs:
> http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/
> http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/
>
> Testing:
> jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK)
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20151203/7319ee9b/attachment.htm>


More information about the hotspot-gc-dev mailing list