JEP 132: More-prompt finalization

[Kim Barrett]

On May 31, 2015, at 3:32 PM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> So, for the curious, here's the improved prototype:
> 
>     http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.02/
> 
> And here are the improved benchmarks (with some results inline):
> 
>     http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/refproc/

While perusing the offered code (webrev.02) (not a careful review
yet), I think I've found a serious bug:

In Reference.java
in unhookPendingChunk
 253             // assert r.next == r;
 254             // move a chunk of pending/discovered references to a
 255             // temporary local r/next chain
...
 262                 rd.next = r;

I think that assertion suggested at line 253 does not hold, and line
262 may damage a queue.

The problem is that the application could explicitly enqueue a
reference while it is sitting in the pending list, waiting to be
processed. So the enqueue places the reference on the associated
queue's list, linked through the reference's next field. Then unhook
comes along and clobbers the reference's next field. Oops!

handlePendingChunk has similar problems with an application enqueue
before the reference has been "handled".

I haven't looked carefully at webrev.03, but at a quick glance it
looks like it has the same problem. (Which is what I expected, given
the description of the differences between webrev.02 and webrev.03.)

I'm not sure why unhook is using the next field at all, rather than
just continuing to use the discovered field. I've not studied this
idea carefully, but I think it might work to leave the chunks linked
through the discovered field until addChunk, with that being
responsible for self-looping the discovered field and transferring
linkage to the next field. That is, treat chunks as extensions of the
pending list until addChunk-time. There might be some that makes using
the discovered field that way a problem, but I'm not thinking of
anything right now.

Of course, this problem doesn't exist for FinalReference because
application code doesn't have access to them to perform the
problematic explicit enqueue.