Soft References... are they working as intended?

John Hendrikx hjohn at xs4all.nl
Sat Aug 18 05:06:46 PDT 2012


I've come to the conclusion that SoftReferences in the current hotspot 
implementation are suffering from some problems.

I'm running the latest Java 7, with default gc settings and a very 
modest heap space of 256 MB.

On this heap I have on the order of 50-60 large objects that are 
referenced by SoftReference objects.  Each object is a few megabytes in 
size (they are decoded JPEG images).

At any given time, only 10 of these images have strong references to 
them, totalling no more than 50-60 MB of heap space, the other 200 MB of 
space is only soft referenced.

It is said that SoftReferences are guaranteed to get cleared before heap 
space runs out, yet in certain extreme circumstances one of the 
following can happen:

1) 90% of the time, when under high memory pressure (many images loaded 
and discarded), the VM gets really slow and it seems that some threads 
get stuck in an infinite loop.  What is actually happening is that the 
GC will run for long periods in a row (upto a few minutes, consuming one 
CPU core) before the program gets unstuck and it finally noticed it can 
clear some SoftReference objects.

It is possible that the GC has trouble deciding which SoftReferences can 
be cleared because many of them had (upto a few seconds ago) strong 
references to them, which themselves may not have been marked as garbage 
yet.

So it recovers, but it is taking so much time to do it that users will 
think the program is stuck.

2) The rest of the time it actually will throw an out of heap space 
exception, despite there being SoftReference objects that could have 
been cleared.  This usually happens after a long pause as well.

Can anyone confirm that these problems exists, and perhaps advice a 
course of action?

I really don't want to have to 2nd guess the GC about which images 
should be discarded, but it looks like I will have no choice but to 
limit this Image cache manually to some reasonable value to avoid the GC 
getting stuck for long periods.

Best regards,
John Hendrikx





More information about the hotspot-gc-use mailing list