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

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.

More information about the core-libs-dev mailing list