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

[David M. Lloyd]

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).

- DML