Re: G1 patch of elastic Java heap

[Liang Mao]

Hi Ruslan and OpenJDK developers,

I noticed this difference too. The softmx in OpenJ9 seems to not allow the application beyong
the new limit while JDK-8222145 treats the SoftMaxHeapSize as a *soft* limit which can be 
exceeded. Personally I prefer the former a little bit. But introducing another name seems more
confused to users. Maybe use an option to control? Like "bool SoftMaxHeapSizeOOM" ?

Thanks,
Liang






------------------------------------------------------------------
From:Ruslan Synytsky <rs at jelastic.com>
Send Time:2019 Oct. 15 (Tue.) 06:46
To:hotspot-gc-dev at openjdk.java.net openjdk.java.net <hotspot-gc-dev at openjdk.java.net>; "MAO, Liang" <maoliang.ml at alibaba-inc.com>; Thomas Schatzl <thomas.schatzl at oracle.com>
Subject:Re: G1 patch of elastic Java heap

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