[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.


More information about the core-libs-dev mailing list