JDK-4806720 : RFE: hotspot client VM should not clear SoftReferences when heap is small
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2003-01-23
  • Updated: 2003-10-29
  • Resolved: 2003-10-29
Related Reports
Relates :  
JDK-4888056 - Reference clearing can be adaptive
Description
It was noticed during start-up of a very small client UI application on
Solaris SPARC that SoftReferences that had just been created were cleared
as soon as a GC came along. This is because:

"The client JVM prefers to flush SoftReferences rather than
growing the heap; the server JVM prefers growing the heap to
flushing SoftReferences"

This RFE requests implementation in the client VM of a heuristic that
below some (TBD) heap size the heap grow rather than clear SoftReferences 
Otherwise caches cleared during GUI start-up will just slow down start-up
as such work will likely need to be re-done before very long at all.
Comments
EVALUATION This might be done by counting the SoftReferences as a fraction of the heap, and not clearing them if they are a small percentage. Redoing the whole SoftReference policy based on the -client flag might be another possibility, but much more work (and much more tuning). ###@###.### 2003-03-11 ---------------------------------------------------------------- Have we considered rewriting the code in question to not cache data until first use? This is a start up footprint and time win. Also, it is likely by the time of first use that the heap will be large enough to hold the references without them being immediately being cleared. ###@###.### 2003-08-20 ================================= You mean the caches created during GUI start-up? You misunderstand. They are NOT eagerly created, they are created only on first use but GC is so insistent on clearing references they are cleared before 2nd use so need to be re-created. ###@###.### 2003-08-20 =========================== See bug 4888056 for a more extensive evaluation, workarounds, etc. Among the problems is that we don't know what fraction of the heap any particular SoftReference is holding on to. (Further, we don't know how expensive it is for the user to reconstruct any particular SoftReference.) So we are missing the crucial information we need to make this decision well: so we back off to LRU, which is not a great policy in all cases. There is a knob: -XX:SoftRefLRUPolicyMSPerMB= which allows the user to specify the relationship between the number of megabytes of free heap (committed but unused heap) and the milliseconds since the last use of the SoftReference. The default value is 1000, so if there is 1MB of free heap, then SoftReferences used in the last second won't be cleared. If you want less aggressive SoftReference clearing, you can raise the value on the command line. If you know you are going to need a certain size heap to get your application started, then you should also (probably first!) consider increasing the initial heap size, -Xms, since that will not only preserve your SoftReferences, but also avoid collections altogether. The default value of -Xms varies from platform to platform, but is available for tweaking for each release. All we need to change it is a recommendation from the performance team (and approval of the relevant bodies). I'd rather not add another obscure command line option to the JVM (-XX:MinHeapBeforeSoftReferencesCleared= ?) if the existing options can be used to solve the problem. ###@###.### 2003-10-28 ===========================
28-10-2003