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

Kim Barrett kim.barrett at oracle.com
Tue Feb 2 00:05:10 UTC 2016


> On Jan 31, 2016, at 4:19 AM, Peter Levart <peter.levart at 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/




More information about the hotspot-gc-dev mailing list