JDK-4888056 : Reference clearing can be adaptive
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_2.5.1
  • CPU: generic
  • Submitted: 2003-07-09
  • Updated: 2013-11-01
  • Resolved: 2012-04-10
Related Reports
Relates :  
JDK-4918870 - Examine session cache implementation (sun.misc.Cache)
Relates :  
JDK-4806720 - RFE: hotspot client VM should not clear SoftReferences when heap is small
Description
Presently the clearing of soft references uses one of two policies
depending on the command line.  Neither is well understood.
In either case, references are sometimes cleared even when there 
is ample heap space.  This has been noted to reduce performance 
at startup, where some information (fonts?) is put in soft references 
but cleared before it gets used.

It would be better to have a single, well-understood policy.
Comments
SUGGESTED FIX A good solution might involve calculating the proportion of the heap that is occupied by objects only reachable from soft references. The rate of clearing could be adjusted to keep the proportion of the heap held by soft references at some desired level. A simpler, cream-skimming solution might be to just not clear references at all when the proportion of time in GC (or maybe proportion of heap commited) is below a threshold. This would allow applications that aren't pushing the envelope to retain soft references for a long time. ------------------- From DPS, 9/12/2003: Here's a different approach for RFE 4806720 (hotspot client VM should not clear SoftReferences when heap is small). I've made various hand-wavy proposals, suggesting that time is GC be taken into account, etc. Here's a specific, concrete proposal: "Soft references are cleared after surviving N old GCs." This has the desired property that it is proportional to GC pressure; if no GC is going on, soft references live forever. N could be the same between client and server, and simply set to be bigger than the number of full GCs we see in the startup benchmarks. The same value of N will still result in slower clearing rates on servers than clients, since they have more memory and therefore less frequent old gen collections. - dps ------------------
11-06-2004
EVALUATION Suggested fix is a start. Will need to discuss this with startup group. ==================== See also 4806720 RFE: hotspot client VM should not clear SoftReferences when heap is small ###@###.### 2003-08-20 ============================ The underlying problem is that the JVM doesn't have any idea (1) how much space will be freed by clearing any particular SoftReference, and (2) how much work it take for the user to rebuild any particular cleared SoftReference. So we fall back on LRU, which is not a great policy in all cases. It's unlikely that any single policy in the JVM is going to work well for all kinds of users. It's likely any given application will want a different policy for SoftReferences to different types. There be dragons. If an application knows that it will need a certain amount of heap just to get started, then it would do well to change the initial heap size with -Xms. (The default value for -Xms is also available for tweaking in each release. It's currently 2MB (640KB new, 1408KB old), on Windows.) The larger iniitial heap will not only avoid clearing SoftReferences, but also avoid collections altogether. The real solution is to have the application control which references are soft and which are strong. One suggestion is to have a Collections subclass that could toggle between soft and strong references. This would model the way one uses individual SoftReferences: when you are going to use a softly-referenced objects, you call get() on the reference to get a strong reference, which you use to operate on the object, and then drop the strong reference when you are done working with it. Similarly, a Collection could have methods to construct SoftReferences from its elements, and to null all the strong references once the SoftReferences are in place. The font table would then build itself with strong references, and when you thought you were past some "startup" phase, you could turn those into SoftReferences. When you wanted to work on the font table, you could get() all the strong reference back for the duration of the work. It's likely that LinkedHashMap can be pressed into service, since it already can maintain an LRU chain through the elements of the Map. It might also be useful to build a HashMap subclass that has a limited capacity: i.e., one that ejects victims if you try to insert too many elements into it. ###@###.### 2003-10-28 ================================
28-10-2003