> On Jan 31, 2016, at 4:19 AM, Peter Levart <peter.lev...@gmail.com> wrote: > > Hi Kim,
Hi Peter - Thanks for looking at this. > This change will make it practically impossible to miss the enqueued > references. Good. That’s the goal. > 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. 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. New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8072777/webrev.01/ incr: http://cr.openjdk.java.net/~kbarrett/8072777/webrev.01.inc/
