JDK-8058952 : G1 sizing policy increases heap according to gc time ratio too aggressively
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8u40,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2014-09-23
  • Updated: 2015-12-09
  • Resolved: 2015-12-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Duplicate :  
Relates :  
Relates :  
G1 increases the heap when the actual gc time ratio (as calculated as ratio between gc pauses and mutator operation in the last 10 gc intervals) exceeds a threshold (either GCTimeRatio or some other ratio specified e.g. by GCPauseIntervalMillis and MaxGCPauseMillis).

If so, G1 increases the heap.

There is a potential problem with the current mechanism: so in collection X G1 noticed that the GC took too much time, e.g. 10.7% which iswasover an example threshold of 10%. Now G1 increases the heap by some percentage.
At collection X+1 the gc time ratio may still be over the threshold at X+1 (say, 10.4%); since the actual pause time ratio is mostly dominated by earlier intervals that did not take the heap increase into account, G1 will still think that the actual gc time is too high, expanding the heap further and further.

However, a single heap expansion might have been sufficient to decrease the actual gc time ratio sufficiently, hence using too much space for no particular reason.
Duplicate of fixed JDK-8060697.

In CMM experiment run by Dana Liu, I have found that her benchmark has live data size around ~250MB. On the command line, this was specified: -Xms500m -Xmx2500m Parallel GC has expanded the heap to 1.4GB while G1 has expanded it to 2.3GB.

JDK-7022456 extensively describes the problem. This change needs to be carefully evaluated.

ILW: I: medium -> G1 uses too much memory (or low?) L: medium -> only when actually resizing memory, i.e. when Xms != Xmx W: high -> none -> P3

Bengt suggested to reset the values in the gctimeratio array after the heap has been increased.