Does -XX:SoftRefLRUPolicyMSPerMB affect OutOfMemoryError behavior?
If an object is softly reachable and it has not yet exceeded the time limit specified by the-XX:SoftRefLRUPolicyMSPerMB parameter, will it still be garbage collected before an OutOfMemoryError occurs?
In other words, if I set-XX:SoftRefLRUPolicyMSPerMB to a very large number (what is the maximum value for this parameter?) will I get the desired effect of SoftReferences not being garbage collected until they are needed to be cleared to avoid an OutOfMemoryError?
[494 byte] By [
cegreya] at [2007-10-3 1:16:10]
Hi,My understanding (underpinning my heavy use of SoftReference for cacheing!) is that OOM will not be thrown until all SoftReferences have been cleared to recover memory, and this should be regardless of any value that has been set for the parameter you
DamonHD is exactly right. The intent is that an OOM will be thrown
only if the allocation request cannot be satisfied even after all
SoftReferences have been cleared.
Note that there was a bug in this area, CR 4896986, which
was fixed a while ago. Please make sure you are using a
version of the JDK that includes the fix for 4896986.
If you still believe that an OOM is being prematurely thrown,
and have a test case, please file a bug via the links from
developer.sun.com/services including your test case
and full JDK version and platform information.
Thanks for the responses.
I am using Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
I have not had a problem with the JVM throwing an OOM error. My problem is the opposite: SoftReferences that I use in a cache were being cleared even though there was plenty of memory available. I was looking for a way to keep the SoftReference im memory longer. Ideally, I would like them to stay in memory until the GC needs to clear them to avoid an OOM error. Setting -XX:SoftRefLRUPolicyMSPerMB=100000 seems to help.
Do you know what the maximum value is for -XX:SoftRefLRUPolicyMSPerMB?
Hi,
If you are using the CMS GC (-Xincgx/-Xconcgc or the equivalent) then be aware that there seems to be a bug in reference processing that has SoftReference values cleared far too quickly. Try, just as a test of this suggestion, using the default (serial) collector and see if the problem goes away. If so then you can turn off parallel reference handling and keep CMS (I don't have the flag in front of me).
Rgds
Damon
>
> If you are using the CMS GC (-Xincgx/-Xconcgc or the
> equivalent) then be aware that there seems to be a
> bug in reference processing that has SoftReference
> values cleared far too quickly. Try, just as a test
> of this suggestion, using the default (serial)
> collector and see if the problem goes away. If so
> then you can turn off parallel reference handling and
> keep CMS (I don't have the flag in front of me).
>
Once again Damon is exactly right. The bug he had in
mind is CR 6432517, which is fixed in Mustang b88 and
in JDK 5 update 9. Note that the bug was present only when
you enable parallel reference processing with CMS.
The default setting with CMS is _not_ to enable parallel
reference processing.
I was only using the default GC settings. Since "-XX:SoftRefLRUPolicyMSPerMB=100000" seems to help, I should in theory set the value to the largest possible value to achieve the desired behavior of keeping SoftReferences in memory as long as possible and to only remove them when it is necessary to avoid an OOM error.
Thanks
Initially we were getting OOM errors but with the increase of -Xmx its fine. Now the issue is that we are getting tenured messages initially our SoftRef is set to 0-XX:SoftRefLRUPolicyMSPerMB =0 so can u guide as to what should be the right value for this attribute.
