> 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!
