> On Apr 8, 2020, at 12:19 PM, Mandy Chung <mandy.ch...@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.
