On 01/07/2016 02:18 AM, William ML Leslie wrote:
On 7 January 2016 at 07:34, Peter Levart <peter.lev...@gmail.com> wrote:
ClassValue API could use a different strategy and reference the cached
instance of type T from ClassValue<T> instance instead, but then you would
have a problem with ClassValue instances reachable from other class loaders
than the cached instances of type T.
Is the problem with this strategy [together with a
java.util.WeakHashMap] that without this strong reference to the Class
object, the Class itself could be collected?
ClassValue API maps a pair (Class, ClassValue) -> cached instance. The
cached instance is "retrievable" if and only if both parts of the pair
(Class, ClassValue) can be produced. As soon as either Class key or
ClassValue instance becomes unreachable, the cached instance could
become unreachable too as it is clearly not "retrievable" any more. But
the cached instance must be kept reachable while it is still possible to
produce both parts of the pair (Class, ClassValue). So ClassValue API
chooses to make a strong link from Class key to cached instance.
Alternative strategy would be for API to make a strong link from
ClassValue instance to cached instance. Either case has it's drawback.
The current ClassValue strategy has drawback when the cached instance
directly or indirectly references the ClassValue instance it was
constructed in (the case of the failing test in this thread). The cached
instance lifetime is then bound to the lifetime of the Class key.
The alternative strategy has drawback when the cached instance directly
of indirectly references the Class key it was constructed for. The
cached instance lifetime is then bound to the lifetime of the ClassValue
There's no way out short of choosing the right strategy for the task at
hand. And I showed in the last post how to effectively transform current
strategy to the alternative strategy by introducing an indirection to
the cached value through a WeakReference and making a strong link from
ClassValue instance to cache value at the same time.
P.S. With Ephemerons, I think the general solution would be possible.
mlvm-dev mailing list