[PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)
David M. Lloyd
david.lloyd at redhat.com
Tue Mar 3 22:01:40 UTC 2009
On 03/03/2009 02:17 PM, Bob Lee wrote:
> On Tue, Mar 3, 2009 at 11:43 AM, David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
> No, actually what I've implemented *exactly* matches this
> definition: a mapping where the value is held strongly until the key
> is known to be garbage collected (even when the value has a
> reference back to the key). The only difference between what I've
> done and a "real" ephemeron is that presumably a "real" ephemeron
> will be able to associate the value with ANY object, without there
> having to be a field for the value on that object (this is what
> they're referring to by "association type").
> Maybe an example will clarify. We have a child class loader that
> associates a value with a Class from the parent class loader. With your
> approach, the parent class loader has a strong reference to the value.
> If the value strongly references a class from the child class loader,
> the child class loader will not be able to be reclaimed (unless you
> explicitly clear which would defeat the purpose of this construct).
> Unlike your solution, if we use an ephemeron, there would be no strong
> reference from the parent class loader, so the child class loader can be
> reclaimed. Make sense?
Yes, I see what you're saying. The issue is mitigated by having a
separate, dedicated key object (in this case, the class local variable
itself). The only reason you'd have to fall back on explicit clearing is
if you set up your value to have a strong reference back to the class-local
itself. As long as you don't do that, then the value can still be cleared
when the class-local key is GC'd. Now that's the point of using a separate
key object here - to decrease the likelihood of that reference structure
from existing. If you *do* need to keep a reference back to the key from
the value (even indirectly), you can usually make it a WeakReference and
thus avoid a problem. The breakdown point here is when the ClassLocal is
stored on a static field, thus tying its lifetime to that of the class.
This is when you can only use explicit clearing to fix things - you'd be
back to the original problem again otherwise.
It is possible to rearrange things a little more to make the case slightly
less likely, but not eliminate it 100%. Even a native ephemeron
implementation would have to be able to take into account isolating values
that are only reachable from ephemeron keys which are in turn reachable
only from other ephemeron keys in order to avoid the same trap.
In any case, like I said, moving to "real" ephemerons once they're
available is a simple change, and it would be nice to have this ability
sooner (by JDK7 possibly) rather than later (JDK8 or later). I think the
semantics as they stand would be sufficient for many uses (certainly all
the published use cases I could find).
More information about the core-libs-dev