RFR: bug: Timely Reducing Unused Committed Memory
thomas.schatzl at oracle.com
Mon Oct 8 14:06:13 UTC 2018
here's the promised patch based on latest discussions:
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
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
Please check whether all this still fits your use case :)
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>
> > 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.
> > cheers,
> > rodrigo
> > > And also, other users having opinions are very welcome :)
> > >
> > > Thanks,
> > > Stefan
> > > >
> > > > --
> > > > Ruslan
> > > > CEO @ Jelastic
More information about the hotspot-gc-dev