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

[Bob Lee]

On Tue, Mar 3, 2009 at 11:43 AM, David M. Lloyd <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?

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090303/b330540d/attachment.html>