RFR (M): 8047328: Improve memory usage for cards in SparsePRTEntry
Thomas Schatzl
thomas.schatzl at oracle.com
Tue May 10 13:39:29 UTC 2016
Hi all,
On Mon, 2016-05-02 at 16:04 +0200, Thomas Schatzl wrote:
> Hi all,
>
> can I have reviews for this change that cuts SparsePRTEntry usage
> by
> half (asymptotically at least :) )?
>
> This change is based on a change from A. Sjöberg (which will be
> credited by me), where instead of having special -1 entries in the
> SparsePRTEntry array of cards, use a dedicated next-pointer for
> storing
> where to put the next card.
>
> This allows us to internally use uint16_t's instead of CardIdx_t's
> (which are 32 bit) for storing.
>
> This also limits the max region size to 32M: there is an assert that
> checks that - unfortunately it is not possible to have a
> STATIC_ASSERT
> here, as HeapRegionBounds::MAX_REGION_SIZE is private.
> If you think that it is worth to have a static assert, at the cost of
> exposing that member (or has another idea on how to do that without
> adding too many dependencies somewhere), I would be happy to change
> the
> code accordingly.
>
> This reduces memory usage of sparse prt entries, and also somewhat
> speeds up searching and iterating entries.
>
> There are no significant throughput gains for that change though, but
> the memory savings (particularly on large heaps) are nice to have.
>
> (Even in the worst case, i.e. very small default number of cards in a
> SparsePRTEntry we are not worse than before in that regard).
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8047328
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8047328/webrev/
> Testing:
> jprt, vm.gc, perf benchmarks
Erik had a look at the change offline and suggested to remove some
changes that are not absolutely necessary and detract from the
important points.
New webrevs at
http://cr.openjdk.java.net/~tschatzl/8047328/webrev.0_to_1 (diff)
http://cr.openjdk.java.net/~tschatzl/8047328/webrev.1 (full)
Testing: another jprt run.
Thanks,
Thomas
More information about the hotspot-gc-dev
mailing list