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