There is a trade off in the heap sizing heuristics that is difficult to get right. The more aggressively we increase the heap the better throughput we get but this comes at the cost of memory footprint.
Currently the heap sizing is based on the GCTimeRatio which means that the heap sizing is affected by how long the GC pauses are. Any changes that reduce or increase the GC pauses will also affect the heap sizing. This in turn means that we get throughput or footprint regressions reported on startup benchmarks even if the only change we have done is to the GC pause. See for example: JDK-8056957.
To mitigate this problem it seems like a good idea to investigate how we want the heap sizing to behave. If we can come up with a clearer policy it will be easier to foresee effects of changes and also easier to evaluate whether changes are bugs or just expected behavior.
Currently the heap sizing is based on the GCTimeRatio which means that the heap sizing is affected by how long the GC pauses are. Any changes that reduce or increase the GC pauses will also affect the heap sizing. This in turn means that we get throughput or footprint regressions reported on startup benchmarks even if the only change we have done is to the GC pause. See for example: JDK-8056957.
To mitigate this problem it seems like a good idea to investigate how we want the heap sizing to behave. If we can come up with a clearer policy it will be easier to foresee effects of changes and also easier to evaluate whether changes are bugs or just expected behavior.
- duplicates
-
JDK-8058952 G1 sizing policy increases heap according to gc time ratio too aggressively
- Closed