RFR (XS): 8155721: Sparse remset wastes half of entry memory

Thomas Schatzl thomas.schatzl at oracle.com
Mon May 2 14:03:57 UTC 2016


Hi Mikael,

On Mon, 2016-05-02 at 13:05 +0200, Mikael Gerdin wrote:
> Hi Thomas,
> 
> On 2016-05-02 12:17, Thomas Schatzl wrote:
> > 
> > Hi all,
> > 
> >    can I have reviews for this pretty small change that (basically)
> > halves memory usage of the sparse prt?
> > 
> > Looking through the code showed that G1 allocates
> > capacity SparsePRTEntrys (the container for the cards for a
> > particular
> > region), but already expands the hash table at capacity/2+1. So
> > almost
> > half of these SparsePRTEntrys are never used and need not be
> > allocated/cleared/etc.
> > 
> > This also uncovered a off-by-one bug in RSHashTable::alloc_entry()
> > that
> > was benign before but caused crashes when allocating just what is
> > required.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8155721
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8155721/webrev/
> Good catch,
> however
> 
> I'm not sure I'm fond of keeping the inverse of the occupancy factor.
> I think the code would be a bit clearer if we made it a floating
> point 
> number.
> 
> Also, I think it should be CapitalizedCamelCase since it's a
> constant.

I made it a floating point number, but in return precalculate the
num_entries value to avoid any issues due to rounding etc.

http://cr.openjdk.java.net/~tschatzl/8155721/webrev.0_to_1 (diff)
http://cr.openjdk.java.net/~tschatzl/8155721/webrev.1

Testing:
jprt, gcbasher with VerifyRememberedSets

Thanks,
  Thomas



More information about the hotspot-gc-dev mailing list