RFR: bug: Timely Reducing Unused Committed Memory

[Ruslan Synytsky]

Hi Thomas, thank you for the patch.

On Mon, 8 Oct 2018 at 17:06, Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:

> Hi all,
>
>   here's the promised patch based on latest discussions:
>
> http://cr.openjdk.java.net/~tschatzl/jelastic/pgc-webrev.3/webrev/
>
> It is based on "6490394: G1: Allow heap shrinking / memory unmapping
> after reclaiming regions during Remark", that is out for review now.
>
> As for the options, they were named as follows:
>
> G1PeriodicGCInterval: Number of milliseconds after a previous GC to
> wait before triggering a periodic gc. A value of zero disables
> periodically enforced gc cycles.


> (Note that I just found out when copy&pasting this description from the
> g1_globals file that the text I there needs fixing - I will do that
> asap :))
>
> G1PeriodicGCInvokesConcurrent: Determines the kind of periodic GC. Set
> to true to have G1 perform a concurrent GC as periodic GC, otherwise
> use a STW Full GC.
>
Is concurrent enabled by default? If not, then why not?


>
>
> G1PeriodicGCSystemLoadThreshold: Maximum recent system wide system load
> at which G1 triggers a periodic GC. A load above this value cancels a
> given periodic GCs. A value of zero disables this check.
>
Maybe a clear mention of loadavg in the description can help to avoid
potential confusions around system load definition.


> The policy has been implemented so that any reason to not start a
> periodic collection right now will cancel the current attempt - another
> attempt will be made after G1PeriodicGCInterval ms. This is different
> to suppress the periodic gc until the next time the conditions are met.
>
> From a default values POV, periodic gcs will be on by default with an
> interval of 5mins. This should be fairly non-intrusive for all but
> exceptional cases.
>
> Please check whether all this still fits your use case :)
>
Looks good for me. Thanks again.

Btw, we have got an approved session at OracleCode about JVM elasticity
https://oracle.rainfocus.com/widget/oracle/oow18/catalogcodeone18?search=elastic%2Bjvm.
I'm planning to bring up topics about general benefits, available options
with different GCs and JVMs, specifics of running elastic JVM in
containers, elaboration of possible further improvements. Please join the
session for a live talk.

Regards


>
> Thanks,
>   Thomas
>
> On Thu, 2018-10-04 at 15:27 +0300, Ruslan Synytsky wrote:
> >
> >
> > On Thu, 4 Oct 2018 at 15:06, Rodrigo Bruno <rbruno at gsd.inesc-id.pt>
> > wrote:
> > > Hi Stefan,
> > >
> > >
> > > Stefan Johansson <stefan.johansson at oracle.com> escreveu no dia
> > > quarta, 3/10/2018 à(s) 21:18:
> > > > We discussed this a bit further today and I'll try to summarize
> > > > what we currently think is the way forward and what a first
> > > > version should include:
> > > > * Periodic concurrent cycles (which after JDK-6490394 will
> > > > uncommit memory) are on by default, but will only trigger if no
> > > > other GC has occurred during the interval. The length of the
> > > > interval should be controlled by a flag and if set to -1, the
> > > > periodic GCs will be turned off. The name should probably be
> > > > something other than GCFrequency, like PeriodicGCInterval or so.
> > > > This will be similar to what currently is called
> > > > CMSTriggerInterval for CMS.
> > > > * You can also control the periodic GCs by specifying a system
> > > > average load threshold, which the current avg load must be under
> > > > for a periodic  GC to occur. This value will not be consider by
> > > > default, and I think we  should try to come up with at more
> > > > describing name than MaxLoadGC.
> > > > * The code checking if a periodic GC should trigger will be added
> > > > to the already existing G1YoungRemSetSamplingThread. This thread
> > > > currently is pretty idle and there are ideas around removing it,
> > > > but if that is done we can move the idle-checking code then.
> > > > * If you want the periodic GC to be a full collection, there will
> > > > be a flag to control this.
> > > >
> > > > Those were the key parts in our discussion, and I think Thomas
> > > > plans to update his webrev in a few days or so. Does this still
> > > > sound like a good starting point?
> > > >
> > >
> > > Sounds great for me!
> > >
> >
> > No objections on my side too.
> > Regards
> > > cheers,
> > > rodrigo
> > >
> > > > And also, other users having opinions are very welcome :)
> > > >
> > > > Thanks,
> > > > Stefan
> > > > >
> > > > > --
> > > > > Ruslan
> > > > > CEO @ Jelastic
> >
> >
>
>
>

-- 
Ruslan
CEO @ Jelastic <https://jelastic.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181008/96587157/attachment.htm>