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