> On Feb 4, 2016, at 3:38 PM, Mandy Chung <mandy.ch...@oracle.com> wrote:
> 
> 
>> On Feb 1, 2016, at 4:05 PM, Kim Barrett <kim.barr...@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

Thanks!

Reply via email to