RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics

Thomas Schatzl thomas.schatzl at oracle.com
Wed Jan 15 17:57:49 UTC 2020


On Wed, 2020-01-15 at 20:53 +0800, Liang Mao wrote:
> Hi Thomas,
> So G1 doesn't need to shrink below Xms if SoftMaxHeapSize is 
> below Xms, does it?

No, never shrink below MinHeapSize.

> Another question is that no matter we have an additional option we 
> had better have 2 criterions. The first is for urgent expansion that
> GCTimeRatio is quite low and concurrent expansion with frequent GCs 
> is more harmful and expansion should be done immediately. It's the
> current default flow as we found that 12 is a good number below which
> applications can obviously incur timeout errors. The second is to
> keep the GCTimeRatio and memory footprint in a balanced state so
> any adjustments are better to be concurrent. The original number 99
> fits well here. If we have only one option "GCTimeRatio", we might
> not be able to achieve both. Maybe we can have a LowGCTimeRatio below
> which suppose to be not acceptable and a HighTimeRatio which is
> certainly healthy. 

So far the change has been about shrinking the heap concurrently, and
not expansion.

Let's concentrate on the issue at hand, i.e. see how heap shrinking at
more places turns out. I believe there will be lots of tweaking needed
for this change to not show too many regressions in other applications.
Remember that the defaults should work well for a large body of
applications, not just a few. There may be knobs to tune it for others.

Then look concurrent expansion, at application phase changes in the
application, how to detect, and how to react best.

Just for reference, last time we changed the sizing algorithm it took a
few months to get it "right", with mostly improvements all around.


More information about the hotspot-gc-dev mailing list