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

[Bob Lee]

On Mon, Mar 2, 2009 at 10:37 PM, David M. Lloyd <david.lloyd at redhat.com>wrote:

> If not, then there is no automatic solution possible, even with special VM
> ephemeron support (this basically IS an ephemeron implementation, after all,
> albeit a specialized one).


Actually, your approach is not the same as an ephemeron at all. See
http://en.wikipedia.org/wiki/Ephemeron:

"Here, the registry (a third party) will hold onto the association itself
which would require manual removal from the registry (instead of automated
garbage collection). *While this problem can be always be solved in any
given concrete situation by using one of the various weak association types,
choosing the 'right' kind of association depends on a variety of factors
some of which can change dynamically.*

Ephemerons solve this problem by defining that the 'contents' (value) of an
Ephemeron will be held strongly until the key is known to be garbage
collected. From then on, the contents of the ephemeron will be held weakly.
Therefore, the contents of an ephemeron can only become eligible for garbage
collection if and only if the key is garbage collectable which is the exact
behavior which we would observe for an instance variable of the object."
All you've done is chosen a different weak association type. You're chosen
type works in some situations, but it breaks others. Ephemerons work (in the
sense that they're cleared automatically) in all situations. This can't be
emulated in the libraries.


>  When I started this thread, I was content with solving the simpler case: a
>> library loaded in the parent class loader associating data with classes
>> loaded in a child loader. This is solvable at the library level and doesn't
>> require explicit clearing. If I want a library loaded in the child class
>> loader to store information about classes from the parent loader, I can just
>> keep strong references to the Class objects because I know that the child
>> loader will be reclaimed before the parent loader.
>>
>
> When would that situation actually arise, just out of curiosity?  In terms
> of specific use case I mean.


I run into this all the time: a library (like Dynaop, Guice or Google
Collections) is in the system classpath (or maybe even an EAR class loader)
and holds a reference to a class in a web app classloader and prevents the
web app from being unloaded.


> I think you're confusing the requirement for explicit clearing when the
> value changes or becomes obsolete with automatic collection of the keys.
> Implicitly clearing the value in this situation can *never* work - not with
> ephemerons, not without a psychic GC - because the application is always
> holding only a weak reference to the value *already*.  The whole point was
> to add a strong reference to the value from the classloader; how can the GC
> determine when you don't need that particular value anymore?
>

The Class is the ephemeron key, and the GC knows it can clear the ephemeron
when the Class is no longer strongly referenced outside of the ephemeron
value.

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