Re: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics
maoliang.ml at alibaba-inc.com
Thu Jan 16 03:21:13 UTC 2020
Yes. We can focus on the current concurrent shrinking for now.
You are right that changing the default behavior will be sensitive
since you need to cover all types of applications including
throughput and low-latency while our previous patch is mostly
designed for low-latency. We'll figure this out later:)
From:Thomas Schatzl <thomas.schatzl at oracle.com>
Send Time:2020 Jan. 16 (Thu.) 01:57
To:"MAO, Liang" <maoliang.ml at alibaba-inc.com>; hotspot-gc-dev <hotspot-gc-dev at openjdk.java.net>
Subject:Re: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics
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
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