UseGCOverheadLimit for G1

[Man Cao]

Hi Thomas,

Yes, I totally agree that refactoring code related to UseAdaptiveSizePolicy
and UseGCOverheadLimit would be ideal for the long term. They should be
independent of each other. I created:
https://bugs.openjdk.java.net/browse/JDK-8212206

I wasn't sure if it is encouraged to do such refactoring to code used by
ParallelGC. Good to know that it is encouraged!

-Man


On Mon, Oct 15, 2018 at 2:01 AM Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:

> 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()
> method?
>
> 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.
>
> Thanks,
>   Thomas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181015/993e0329/attachment.htm>