[PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)
David M. Lloyd
david.lloyd at redhat.com
Fri Feb 27 18:40:21 UTC 2009
On 02/27/2009 12:10 PM, Bob Lee wrote:
> I have a simpler and more secure solution. I just need one method on
> ClassLoader:
>
> public class ClassLoader {
> public void keepReferenceTo(Object o) { ... }
> ...
> }
>
> The ClassLoader would keep a strong reference to the passed reference
> indefinitely (using some sort of minimal memory footprint, wait-free
> data structure internally). We could add a convenience method to
> Class, too, but it would just delegate to the same method on the
> Class's loader.
>
> Now, my library code can just keep a weak reference to the object, and
> I know it won't be cleared until the class loader is reclaimed.
Seems like a reasonable alternate approach, *however* I think there ought
to be a way to clear the reference as well, which would complicate matters
a little with respect to the internal data structure.
I felt I could get away with simply using a synchronized weak hash map on
the Class (with a vague intention of using Reference*Map that I expect will
appear in the JDK sometime soon-ish) because it's reasonably granular, but
this simple idea probably won't work if everything is stuck on the
ClassLoader due to contention problems. So while your solution is simpler
and more elegant in a lot of ways, from a usage perspective at least, it
prohibits a simple two-hour solution like mine. :)
Though it would be easy enough to whip up a simple
synchronized-identity-hash-set first implementation, and let the
concurrency-interest maniacs like you have a crack at making it superfast;
I'd be willing to do that much at least. But I'm just not sure it'll be
possible to avoid contention problems - call it a gut feeling.
My solution is based mainly on existing ideas/usage patterns in the JDK;
that's why I went the route that I did.
Another advantage to your approach is that it doesn't grow Class, which is
what bothered me the most about my solution... though that could be a
simple solution to the granularity/contention issue (put the
method/structure on each Class instead of the ClassLoader), but is the
benefit worth the cost? Upon reflection though, is the cost even that
great? Adding annotations had a greater cost than adding a single
reference field would.
- DML
More information about the core-libs-dev
mailing list