Java Reference
In-Depth Information
To reclaim soft references more frequently, decrease the value of the SoftRefLRUPoli-
cyMSPerMB flag. Setting that value to 500 means that a JVM with a 4 GB heap that is 75%
full will reclaim objects not accessed in the past 512 seconds.
Tuning this flag is often necessary if the heap fills up quickly with soft references. Say that
the heap has 2 GB free and the application starts to create soft references. If it creates 1.7 GB
of soft references in less than 2,048 seconds (roughly 34 minutes), none of those soft referen-
ces will be eligible to be reclaimed. There will be only 300 MB of space left in the heap for
other objects; GC will occur quite frequently as a result (yielding very bad overall perform-
ance).
If the JVM completely runs out of memory or starts thrashing too severely, it will clear all
soft references, since the alternative would be to throw an OutOfMemoryError . Not throwing
the error is good, but indiscriminately throwing away all the cached results is probably not
ideal. Hence, another time to lower the SoftRefLRUPolicyMSPerMB value is when the refer-
ence processing GC logs indicates that a very large number of soft references are being
cleared unexpectedly. As discussed in GC overhead limit reached , that will only occur after
four consecutive full GC cycles (and only if other factors apply).
On the other side of the spectrum, a long-running application can consider raising that value
if two conditions are met:
▪ There is a lot of free heap available.
▪ The soft references are infrequently accessed.
That is a quite unusual situation. It is similar to a situation discussed about setting GC
policies: you may think that if the soft reference policy value is increased that you are telling
the JVM to discard soft references only as a last resort. That is true, but you've also told the
JVM not to leave any headroom in the heap for normal operations, and you are quite likely to
end up spending too much time in GC instead.
The caution, then, is not to use too many soft references, since they can easily fill up the en-
tire heap. This caution is even stronger than the caution against creating an object pool with
too many instances: soft references work well when the number of objects is not too large.
Otherwise, consider a more traditional object pool with a bounded size, implemented as an
LRU cache.
Search WWH ::




Custom Search