UseGCOverheadLimit for G1

Thomas Schatzl thomas.schatzl at
Mon Oct 15 09:01:44 UTC 2018

Hi Man,

On Fri, 2018-10-12 at 10:47 -0700, Man Cao wrote:
> Sounds good. I'll take a stab at it.
> Does initiating the AdaptiveSizePolicy class for G1, or create a
> subclass G1AdaptiveSizePolicy sound like an acceptable high-level
> approach?
> I know it is a non-goal to make UseAdaptiveSizePolicy work for G1,
> but most logic for UseGCOverheadLimit is in the AdaptiveSizePolicy
> class.
> This seems the approach that reuse most existing code and does not
> affect ParallelGC.
> A side story is that we have a Google-local patch since JDK6 that
> makes UseGCOverheadLimit work properly for CMS.
> UseAdaptiveSizePolicy doesn't work and is disabled by default for
> CMS, but UseGCOverheadLimit depends on logic in the
> CMSAdaptiveSizePolicy class (which was removed in JDK9) to properly
> collect major GC overhead.

Your short paragraph simply sound to me that the GC overhead limit
checking is misplaced in the AdaptiveSizePolicy class.

Since the code is also basically very much geared to a two-generation
heap setup, we should not put it into e.g. CollectorPolicy either.

What do you think about factoring out this code into a single class to
be reused by the generational collectors? It gets fed using some
sample() methods (for young and full gc each; feel free to adjust the
name) by the collectors, and provides the recent average costs (I saw
that AdaptiveSizePolicy uses them) and that check_gc_overhead_limit()

Then this functionality could also be used properly by CMS in all of
its modes, i.e. whether using AdaptiveSizePolicy or not I believe.

Note that above is based on some quick look at the code, there might be
complications as usual :) But importing AdaptiveSizePolicy wholesale
into G1 seems very ugly.


More information about the hotspot-gc-dev mailing list