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

[Liang Mao]

Hi Thomas,

I just uploaded the new patch for SoftMaxHeapSize. The shrink works
 immediately. The concurrent uncommit will be in a different patch.

http://cr.openjdk.java.net/~luchsh/8236073.webrev.2/

Thanks,
Liang






------------------------------------------------------------------
From:MAO, Liang <maoliang.ml at alibaba-inc.com>
Send Time:2020 Jan. 16 (Thu.) 11:21
To:Thomas Schatzl <thomas.schatzl at oracle.com>; hotspot-gc-dev <hotspot-gc-dev at openjdk.java.net>
Subject:Re: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics

Hi Thomas,

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:)

Thanks,
Liang




------------------------------------------------------------------
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

Hi,

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.

Thanks,
  Thomas