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

[Bob Lee]

David,

Here's the problem I'd like to see solved: enable a library to hold an
indirect reference to a Class without preventing that Class's loader from
being reclaimed. The reclamation should happen automatically when the loader
is not otherwise strongly referenced.

You added a further requirement: the class-local value should not prevent
the library's loader from being reclaimed. For example, if code loaded in a
child class loader stores a value (which strongly references a Class in the
child loader) in a Class from the parent loader, the class-local value in
the parent-loaded Class should not prevent the child loader from being
reclaimed.

Your solution is to explicitly clear the class-local value (for every class
regardless of its loader), but doesn't that fail to solve the original
problem? If you're going to explicitly clear anyway, why do you need this
mechanism in the first place?

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.

Your problem can't be solved at the library level (without explicit
clearing, which defeats the purpose of this construct). Ephemerons are the
only viable solution that I know of.

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