-
Enhancement
-
Resolution: Unresolved
-
P2
-
hs24, hs25
-
generic
-
generic
HotSpot has issues with memory pressure when using fully-expanded heaps and lots of soft references.
Assume we have a 10GB heap (Xms == Xmx). With a default NewRatio, we'll have a 6.6 GB old gen and a 3.3 GB new gen. After a full GC, we might end up with old gen containing 6.5GB. The next young collection will promote more than .1GB, causing yet another full GC. Just enough gets cleared to handle the promotion from young gen, but old gen still 6.5 GB or so filled. So the next young gen collection will still cause a full GC to handle the promoted objects. And so on...performance will be terrible because we do a full GC every time the young gen fills up.
When LRUMaxHeapPolicy::setup calculates the interval used to determine if a softreference should be free, it uses the MaxHeap (10GB) - the amount of used space at the last GC (6.5 GB). So the free space is calculated to be 3.5GB (3.333 from young gen, .1 from old gen). No soft reference that has been touched in the last 3500 seconds -- almost a full hour -- will be eligible to be collected, despite that fact that we are really severely constrained for memory.
This can be tuned a little bit by aggressively setting SoftRefLRUPolicyMSPerMB, though there is such a large amount of free MB from the young generation that we effectively end up turning off softref caching. plus it is quite awkward to tune an obscure setting like that for a common case; when we are constrained for memory, we should do something to discard more aggressively. One simple thought is to calculate the free space based on the size of the OldGen in this case.
Assume we have a 10GB heap (Xms == Xmx). With a default NewRatio, we'll have a 6.6 GB old gen and a 3.3 GB new gen. After a full GC, we might end up with old gen containing 6.5GB. The next young collection will promote more than .1GB, causing yet another full GC. Just enough gets cleared to handle the promotion from young gen, but old gen still 6.5 GB or so filled. So the next young gen collection will still cause a full GC to handle the promoted objects. And so on...performance will be terrible because we do a full GC every time the young gen fills up.
When LRUMaxHeapPolicy::setup calculates the interval used to determine if a softreference should be free, it uses the MaxHeap (10GB) - the amount of used space at the last GC (6.5 GB). So the free space is calculated to be 3.5GB (3.333 from young gen, .1 from old gen). No soft reference that has been touched in the last 3500 seconds -- almost a full hour -- will be eligible to be collected, despite that fact that we are really severely constrained for memory.
This can be tuned a little bit by aggressively setting SoftRefLRUPolicyMSPerMB, though there is such a large amount of free MB from the young generation that we effectively end up turning off softref caching. plus it is quite awkward to tune an obscure setting like that for a common case; when we are constrained for memory, we should do something to discard more aggressively. One simple thought is to calculate the free space based on the size of the OldGen in this case.
- relates to
-
JDK-8215232 Make soft reference reclamation more aggressive during concurrent marking
- Open
-
JDK-8215298 Set default value of SoftRefLRUPolicyMSPerMB to be more aggressive
- Open