Troublesome reflection-cached SoftReferences

[Peter B. Kessler]

Charles Oliver Nutter wrote:
> I've run into a case in JRuby where a reflected method is keeping alive 
> a class, and that class references a large graph of JRuby objects. The 
> reflected method is off an anonymous interface implementation we create 
> at runtime. In order for that implementation to construct additional 
> Ruby objects, it has to reference an instance of our org.jruby.Ruby 
> class, which in turn references all globally-scoped data, and basically 
> keeps a lot of stuff alive.
> 
> The SoftReference appears to be part of the root set, and holds only an 
> array of Constructor objects. Given a bit of time, this reference is 
> cleared and the graph goes with it. But doing repeated redeploys of a 
> JRuby application can fill up the heap before those soft references get 
> a chance to clear.
> 
> So my questions:
> 
> * Is there any way to force the internal reflection caches to flush 
> themselves? It's very inconvenient that the cache is keeping alive a 
> class that should be dead.
> 
> * Is there any way to force an early SoftReference cleanup, before their 
> time has expired?

If you can get to the SoftReference objects, you can call java.lang.ref.Reference.clear() on them.  That way they won't hold on to their referent until the SoftReference policy clears them.

I'm with Ramki though: all the SoftReferences should be cleared by the collector before it throws OOME at you.

			... peter

> * Does anyone else find this caching behavior irritating?
> 
> - Charlie
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use