RFR: 8072777: java/lang/ref/ReferenceEnqueuePending.java: some references aren't queued

[Mandy Chung]

> On Feb 1, 2016, at 4:05 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
>> But this could be an opportunity to also clean-up the code a bit. The checkResult method has an 'obj' parameter whose purpose is not immediately obvious. […]
>> 
>> I don't know why such complications are necessary. Is the test supposed to also verify the requirement that a Reference whose referent is kept strongly reachable will not be enqueued?
> 
> I was wondering about the odd stuff around obj as well. I don't think
> it is an attempt to "also verify the requirement that a Reference
> whose referent is kept strongly reachable will not be enqueued".
> Rather, I think it is a kludgy way to avoid having the final weaky be
> sometimes enqueued and sometimes not, depending on compiler
> optimizations.
> 

What you described matches what I understand.

> Using Reference.reachabilityFence to keep obj and weaky live across
> the checkResult as you suggested is one way to accomplish that, though
> keeping only the final obj alive (as in the existing code) suffices to
> keep the final weaky from being notified.  I think reachabilityFence
> and a better comment would be clearer though, so changing accordingly.
> 

Glad to see the old way keeping an object being GC’ed or optimized out replaced.

> New webrevs:
> full: http://cr.openjdk.java.net/~kbarrett/8072777/webrev.01/
> incr: http://cr.openjdk.java.net/~kbarrett/8072777/webrev.01.inc/


Looks good.
Mandy