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

Bob Lee crazybob at crazybob.org
Tue Mar 3 20:17:06 UTC 2009

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>

More information about the core-libs-dev mailing list