G1 patch of elastic Java heap

[Ruslan Synytsky]

HardMaxHeapSize sounds logical to me, so we will have SoftMaxHeapSize and
HardMaxHeapSize - easier to understand and remember.
Regards
-- 
Ruslan Synytsky

On Tue, 15 Oct 2019 at 04:12, Per Liden <per.liden at oracle.com> wrote:

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