On 03/03/2009 02:17 PM, Bob Lee wrote:
On Tue, Mar 3, 2009 at 11:43 AM, David M. Lloyd <david.ll...@redhat.com
<mailto:david.ll...@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).
- DML
