RFR (XS): 8014890 : Reference queues may return more entries than expected (original) (raw)
Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Jun 19 14:20:10 UTC 2013
- Previous message: RFR (XS): 8014890 : Reference queues may return more entries than expected
- Next message: RFR (XS): 8014890 : Reference queues may return more entries than expected
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 06/19/2013 06:09 PM, Thomas Schatzl wrote:
With that notion in mind, I start to wonder if we just need to move the check in enqueue() down into the synchronized(lock), and extend it to capture NULL:
--- a/src/share/classes/java/lang/ref/ReferenceQueue.java Mon Jun 17 16:28:22 2013 +0400 +++ b/src/share/classes/java/lang/ref/ReferenceQueue.java Wed Jun 19 17:53:24 2013 +0400 @@ -56,8 +56,9 @@ boolean enqueue(Reference<? extends T> r) { /* Called only by Reference class */ synchronized (r) { - if (r.queue == ENQUEUED) return false; synchronized (lock) { + if (r.queue == ENQUEUED || r.queue == NULL) + return false; r.queue = ENQUEUED; r.next = (head == null) ? r : head; head = r; Will it be equivalent to what Thomas is trying to accomplish? Yes, this is equivalent. Instead of checking the separate ENQUEUED and NULL values I simply used an "r.queue != this" check which would get both cases. R.queue cannot have other values than ENQUEUED, NULL or the queue's value set at initialization.
Yeah, for my taste, explicitly checking for ENQUEUED || NULL declares the intent more clearly. YMMV, though. I'm OK with plumbing the hole... your style. :)
-Aleksey.
- Previous message: RFR (XS): 8014890 : Reference queues may return more entries than expected
- Next message: RFR (XS): 8014890 : Reference queues may return more entries than expected
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]