On Wed, 19 Jan 2022 10:44:57 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
> > So, this patch is fine for making ClassCache more robust as a re-usable > > component inside JDK (checking for non-null return of computeValue). The > > 2nd change, that apparently shields against unbounded accumulation of > > garbage, might not be enough in the sense that when garbage accumulated > > without bounds, there would be not progress. So before the patch, we would > > at least get an OOME and the loop would end. Now the loop could spin > > indefinitely. So perhaps we must rather prevent this from happening in some > > other way... I have an idea. Stay tuned. > > I think playing the catch-up race with GC (which we will eventually win, IMO) > is better than obscure OOME. Note this matches other places we do the > weak-reference loops, for example in `MethodType`: > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/MethodType.java#L1390-L1401 I do think that processing enqueued references more promptly is a correct move, so I don't oppose this patch. I'm merely saying that the concern about indefinite growing of reference queue is the same as concern about indefinite looping. In normal circumstances neither would be a problem. But if we are considering special circumstances, we could as well fix both potential problems. For example, if construction of `CacheRef` object that stays referenced by ClassCache is guaranteed to be followed by at least one `.get()` invocation, the following variant of CacheRef would guarantee progress: private static class CacheRef<T> extends SoftReference<T> { private Class<?> type; private T referent; CacheRef(T referent, ReferenceQueue<T> queue, Class<?> type) { super(referent, queue); this.referent = referent; this.type = type; } @Override public T get() { T referent = this.referent; if (referent == null) { return super.get(); } else { this.referent = null; return referent; } } } WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/7092
