RFR: bug: Timely Reducing Unused Committed Memory

Rodrigo Bruno rbruno at gsd.inesc-id.pt
Thu Oct 4 12:06:03 UTC 2018

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!


> And also, other users having opinions are very welcome :)
> Thanks,
> Stefan
> >
> > --
> > Ruslan
> > CEO @ Jelastic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181004/095c521b/attachment.htm>

More information about the hotspot-gc-dev mailing list