[9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

[David Holmes]

Peter has highlighted the risk with anything but the most minimal of 
changes - the more you say the more likely you are saying something that 
is incorrect. Reachability and the GC relationship to it is extremely 
complex and can't be summarised in a few words.

I would go back to the original simple suggestion to just add "detected":

http://cr.openjdk.java.net/~zmajo/8169000/webrev.00

"If a registered reference is detected as unreachable itself, then it 
will never be enqueued."

--

That removes any expectation that you can determine whether or not it 
will be unreachable based on looking at the source code or reasoning 
about the bytecodes.

Cheers,
David
-----


On 17/11/2016 2:37 AM, Peter Levart wrote:
> Hi,
>
> On 11/16/2016 05:09 PM, Peter Levart wrote:
>>>
>>> http://cr.openjdk.java.net/~zmajo/8169000/webrev.03/
>>
>> "If a registered reference ceases to be strongly reachable itself (not
>> by examining the source code but by looking at the actual state of the
>> VM at runtime), it will never be enqueued."
>>
>> I think this is wrong wording. A Reference object may cease to be
>> strongly reachable for some time (even by looking at the actual state
>> of the VM at runtime) and then regain strong reachability and then be
>> enqueued. If during the period that a Reference object is not strongly
>> reachable (even by looking at the actual state of the VM at runtime),
>> GC is not run, the Reference object will not be discovered as not
>> being strongly reachable and VM will not clear any Soft or Weak
>> references having the Reference object as a referent and consequently
>> the program will be able to regain strong reachability to it.
>
>
> A counter example: A Reference object may cease to be strongly reachable
> by becoming softly reachable. The JVM may even discover it to be softly
> reachable (looking at the actual state of the VM at runtime), but by
> policy, VM may also see that is has not been softly reachable long
> enough and so it will not clear the SoftReference but instead rather
> enqueue the SoftReference's referent (our PhantomReference object):
>
> public class SoftlyReachablePhantomReference {
>
>     static ReferenceQueue<Object> rq = new ReferenceQueue<>();
>     static Reference<PhantomReference<Object>> refRef;
>
>     public static void main(final String[] args) throws Exception {
>         refRef = new SoftReference<>(
>             new PhantomReference<>(
>                 new Object(),
>                 rq
>             )
>         );
>         // <- here
>         System.gc();
>         Reference rmRef = rq.remove(1000);
>         if (rmRef == null) {
>             System.out.println("PhantomReference NOT enqueued");
>         } else {
>             System.out.println("PhantomReference enqueued");
>         }
>     }
> }
>
>
> Running with -Xcomp, the above program will print: "PhantomReference
> enqueued". By just swapping SoftRererence with WeakReference:
>
>
> public class WeaklyReachablePhantomReference {
>
>     static ReferenceQueue<Object> rq = new ReferenceQueue<>();
>     static Reference<PhantomReference<Object>> refRef;
>
>     public static void main(final String[] args) throws Exception {
>         refRef = new WeakReference<>(
>             new PhantomReference<>(
>                 new Object(),
>                 rq
>             )
>         );
>         // <- here
>         System.gc();
>         Reference rmRef = rq.remove(1000);
>         if (rmRef == null) {
>             System.out.println("PhantomReference NOT enqueued");
>         } else {
>             System.out.println("PhantomReference enqueued");
>         }
>     }
> }
>
>
> ...the program will print: "PhantomReference NOT enqueued".
>
> This is all expected and by the spec.
>
> Peter
>