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