RFR (XS): JDK-8204084: Remove the G1RSBarrierRegionFilter develop flag
Thomas Schatzl
thomas.schatzl at oracle.com
Wed May 30 10:36:31 UTC 2018
Hi again,
I re-added the comments and updated the webrev. They were just not
worth for me arguing about.
Thanks,
Thomas
On Wed, 2018-05-30 at 12:26 +0200, Aleksey Shipilev wrote:
> On 05/30/2018 12:23 PM, Thomas Schatzl wrote:
> > On Wed, 2018-05-30 at 12:15 +0200, Aleksey Shipilev wrote:
> > > On 05/30/2018 12:08 PM, Thomas Schatzl wrote:
> > > > can I have reviews for this small change that removes the
> > > > G1RSBarrierRegionFilter develop flag from G1 code that is
> > > > implemented in a very incomplete way, and since I do not see a
> > > > point fixing that I suggest removing it.
> > > >
> > > > CR:
> > > > https://bugs.openjdk.java.net/browse/JDK-8204084
> > > > Webrev:
> > > > http://cr.openjdk.java.net/~tschatzl/8204084/webrev/
> > >
> > > Yup. Amusingly, this filter is implemented in shared C1 [1] and
> > > C2
> > > [2] code, where the performance does matter, and it is not hooked
> > > up
> > > to the flag :) It might indeed make little sense to perform
> > > this filtering in arch-specific interpreter barriers.
> > >
> > > I think you want to remove the comments like:
> > >
> > > 273 // Does store cross heap regions?
> > > 274 // It does if the two addresses specify different grain
> > > addresses.
> > >
> > > 222 // Crosses regions, storing NULL?
> >
> > I removed the comments and updated the webrev in-place.
>
> Wait a minute, I need to wake up. I thought you are removing the
> filters themselves, but you only
> make them unconditional! So the comments are actually okay to keep.
> Sorry for the fuss.
>
> -Aleksey
>
More information about the hotspot-gc-dev
mailing list