Troublesome reflection-cached SoftReferences

[Y. Srinivas Ramakrishna]

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?
>   

You can try -XX:SoftRefLRUPolicyMSPerMB=0 , which is kind of a sledgehammer
to clear soft refs the first time GC sees them (making them behave, in 
essence, like weak references)
> * Does anyone else find this caching behavior irritating?
>   
The policy is to clear a soft ref if it has not been accessed 
"recently". The "recency threshold metric"
itself is computed as SoftRefLRUPolicyMSPerMB * FreeMemory following 
last major collection, so
that as heap pressure increases we should be clearing soft refs more 
agressively albeit still in an
LRU fashion.

Could it be the case that your soft ref is accessed very frequently, so 
never falls below the computed
recency threshold?

In any event, the JVM spec guarantees that all soft refs that are not 
strongly reachable
will be cleared before an OOM is issued., I trust your issue is one of 
performance badness
on account of a large heap, not an OOM?

thanks.
-- ramki
> - 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