[PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) (original) (raw)

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 mailing list