RFR: bug: Timely Reducing Unused Committed Memory

[Thomas Schatzl]

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.

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.

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

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