RFR: 8188055: (ref) Add Reference.refersTo predicate

[Kim Barrett]

> On Apr 8, 2020, at 12:19 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> I agree with Gil on this point.   `PhantomReference::get` always returns null.   The intent behavior of `ref.refersTo(obj)` is the same as `ref.get() == obj`.    Gil's proposed option to have `refersTo(obj)` to return true only if obj is null is a reasonable one.
> 
> If `PhantomReference::get` were to change to have the same behavior as other references some day, then `PhantomReference::refersTo` would be updated at that time (but no proposal doing that at the moment).
> 
> Mandy

I disagree.

Prior to JDK-8071507, PhantomReference.get was needed to prevent
access to the possibly reclaimable referent. That's even mentioned in
the PhantomReference class documentation (the final paragraph; maybe
that should have been modified as part of JDK-8071507).

Not that PhantomReference.get has ever been an air-tight wall, as
things like Unsafe, reflection, and perhaps others (JVMTI?) might
still provide access or information (JDK-8168804). But after
JDK-8071507 there's at least no longer any risk of those avenues
providing access to a referent after the PhantomReference has been
notified and any associated cleanup triggered by that notification
has been performed.

I think we should remove PhantomReference.get, and have been
discussing this with Mandy. (Note that there are some technical
details that make that more difficult to implement than simply
removing the method; C2 is a pain.) That method prevents the use of
PhantomReference in contexts that would benefit from its different
liveness behavior from WeakReference with respect to finalization. For
example, consider a PhantomReference variant of the existing
java.util.WeakHashMap.

Then, in a world without finalization (I should live so long), we
could collapse the hierarchy down because there would no longer be any
difference between WeakReference and PhantomReference.

Even before any future removal of PhantomReference.get I think
refersTo should not be tied to Reference.get behavior. It's intended
that refersTo() not call get() (and that probably ought to be stated
explicitly, similarly to how Reference.clear is explicitly not called
by the GC to clear references). If it calls get then it affects
SoftReferences as well, again potentially extending the lifetimes of
objects unrelated to the one in hand.