RFR: 8132984: incorrect type for Reference.discovered
Peter Levart
plevart at openjdk.java.net
Mon Jan 18 17:28:57 UTC 2021
On Sat, 26 Dec 2020 03:25:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> Please review this change which fixes the type of the private
> Reference.discovered field. It was Reference<T>, but that's wrong because
> it can be any Reference object.
>
> I've changed it to Reference<?> and let that flow through, updating some
> other variables that were previously somewhat incorrectly typed (usually
> with an Object type parameter). The interesting change is to the
> ReferenceQueue.enqueue parameter, which is now also Reference<?>.
>
> This ultimately end up with a provably safe and correct, but uncheckable,
> cast in ReferenceQueue.enqueue.
>
> An alternative might be to use a raw type for the discovered field, but I
> think that ends up with more @SuppressWarnings of various flavors. I think
> the unbounded wildcard approach is clearer and cleaner.
>
> Note that all of the pending list handling, including the discovered field,
> could be moved into a non-public, non-generic, sealed(?) base class of
> Reference<T>. The pending list handling has nothing to do with the generic
> parameter T.
>
> Testing:
> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)
Hi Kim,
If you introduce a private method in Reference:
private void enqueueFromPending() {
var q = queue;
if (q != ReferenceQueue.NULL) q.enqueue(this);
}
...and use it Reference.processPendingReferences while loop like this:
if (ref instanceof Cleaner) {
...
} else {
ref.enqueueFromPending();
}
Then you can keep the signature of `ReferenceQueue.enqueue(Reference<? extends T> r)` and no unchecked casts are needed there.
But what you have is OK and much better than what was before.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1897
More information about the core-libs-dev
mailing list