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