G1 patch of elastic Java heap

Per Liden per.liden at oracle.com
Tue Oct 15 08:12:15 UTC 2019


Hi,

On 10/15/19 8:10 AM, Liang Mao wrote:
> 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" ?

I personally think the OpenJ9 softmx option is misnamed, as it's not a 
*soft* limit, but a *hard* limit. Hotspot's SoftMaxHeapSize is *soft* by 
design. Today's hard limit in Hotspot is of course MaxHeapSize (-Xmx). 
The only problem is that isn't not a manageable flag so it can't be 
changed at runtime. Making it manageable is tricky for GCs that size 
data structures at startup based on MaxHeapSize. One option could be to 
simply reject changes to MaxHeapSize unless the currently used GC 
declares that it supports changing it. Another option could be to keep 
MaxHeapSize as is, and introduce a separate flag (e.g. HardMaxHeapSize 
or CurrentMaxHeapSize). In that case MaxHeapSize would act as the upper 
limit for a the "hard limit" flag.

cheers,
Per

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



More information about the hotspot-gc-dev mailing list