Re: G1 patch of elastic Java heap

[Liang Mao]

Hi Thomas,

Thank you for the recognition:) Since we both agree on some clear specific points,
 I will try to extract them from current implementation and create a patch in OpenJDK
upstream branch so we can continue discussion on the code level.

Thanks,
Liang






------------------------------------------------------------------
From:Thomas Schatzl <thomas.schatzl at oracle.com>
Send Time:2019 Oct. 12 (Sat.) 23:00
To:"MAO, Liang" <maoliang.ml at alibaba-inc.com>; hotspot-gc-dev <hotspot-gc-dev at openjdk.java.net>
Subject:Re: G1 patch of elastic Java heap

Hi,

On Sat, 2019-10-12 at 19:51 +0800, Liang Mao wrote:
> Hi Thomas,
> 
> The manual generation limit can be put aside currently since we know
> it might not be so general for a GC. We can focus on how to change
> heap size and return memory in runtime first. 
> 
> GCTimeRatio is a good metric to measure the health of a Java
> application and I have considered to use that. But finally I chose
> a simple way just like the periodic old GC. Guarantee a long 
> enough young GC interval is an alternative way to make sure the
> GCTimeRatio at a heathy state. 
> I'm absolutely ok to use GCTimeRatio instead of the fixed young GC
> interval. This part is same to ZGC or Shenandoah for how to balance
> the desired memory size and GC frequency. I'm open to  any good
> solution and we are already in the same page for this issue
> I think:)

+1

> A big difference of our implementation is evaluating heap resizing in
> any young GC instead of a concurrent gc cycle which I think is
> swifter and more immmediate. The concurrent map/unmap 
> mechanism gets rid of the additional pause time. My thought is the
> heap shrink/expand can be all determined in young GC pause and
> performed in concurrent thread which could exclude the 
> considerable time cost by OS interface. Most of our Java users are
> intolerant to those pause pikes caused by page fault which can be up
> to seconds. And we also found the issue of time cost by map/unmap in
> ZGC.
>
> A direct advantage of the young GC resizing and concurrent memory
> free machanism is for implementing SoftMaxHeapSize. The heap size can
> be changed after last mixed GC. The young GC won't have longer
> pause and the memory can be freed concurrently without side effect.

Agree and agree. Both evaluating and giving back memory at any gc
sounds nice, and doing that without incurring the costs in the pause is
even better :)

Thanks,
  Thomas