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.
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.
- duplicates
-
JDK-8060697 G1: Investigate heap sizing heuristics
- Resolved
- relates to
-
JDK-7022456 G1: Significant memory footprint increase compared to other collectors during application startup
- Closed
-
JDK-8134643 mb/jvm/alloc/PostAllocationStores/testAllocation* fails with out of memory on windows
- Closed