RFR (XS): 8201365: Remove G1Policy::should_process_references()
Thomas Schatzl
thomas.schatzl at oracle.com
Wed Apr 11 09:34:37 UTC 2018
Hi Aleksey,
On Tue, 2018-04-10 at 16:18 +0200, Aleksey Shipilev wrote:
> On 04/10/2018 04:06 PM, Thomas Schatzl wrote:
> > Hi,
> >
> > On Tue, 2018-04-10 at 15:31 +0200, Aleksey Shipilev wrote:
> > > On 04/10/2018 02:26 PM, Thomas Schatzl wrote:
> > > > CR:
> > > > https://bugs.openjdk.java.net/browse/JDK-8201365
> > > > Webrev:
> > > > http://cr.openjdk.java.net/~tschatzl/8201365/webrev/
> > >
> > > Patch looks good.
> > >
> > > But, don't you actually want to control refprocessing, especially
> > > when pause times are concerned?
> >
> > the removed code does not control reference processing at all, it
> > simply always enables it; this is some renmant of some removed
> > closed code. The change is simple enough to be added again if
> > somebody wants to experiment with that.
> >
> > Regarding pause times, in the future all but the parts that
> > actually copy data (finalizers) for global reference processing
> > could be done concurrently too.
> >
> > Maybe at some point in the future finalizers will be removed (they
> > are deprecated already), so that issue may go away.
> >
> > Only clearing out referent fields may be predictable enough for the
> > reference processing after young gcs (or moving it to some
> > concurrent phase too).
>
> OK, I see. I was asking that because we have Shenandoah users who
> control reference processing frequency, and thus balance pause times
> when refprocessing is not yet concurrent. I would understand
> if that is ruled not to be the priority in current G1.
nobody from us is working on reference processing frequency control
as this change suggests right now, I am also not aware of anybody
requesting it. I filed JDK-8201419 though for later reference.
I also forgot to thank you for your review - thanks!
Thanks,
Thomas
More information about the hotspot-gc-dev
mailing list