G1 patch of elastic Java heap

[Ruslan Synytsky]

Dear Liang and Thomas, thank you for your contribution to Java elasticity.

I would like to pay attention to the softmx option which is planned to be
renamed to SoftMaxHeapSize as I understand. According to the feedback in
another thread, if the memory usage reaches the softmx limit then JVM will
throw OOM Error. It differs from the logic described at
https://bugs.openjdk.java.net/browse/JDK-8222145. Personally I believe OOM
Error inside JVM is a little bit safer approach compared to the potential
termination of java process by OOM Killer. But how can we avoid confusions?
Should we use different naming?

Thanks
-- 
Ruslan Synytsky

Date: Mon, 14 Oct 2019 11:52:19 +0800
> Subject: Re: G1 patch of elastic Java heap
> 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
>
>
>