RFR (S): 8073632: Make auxiliary data structures know their own translation factor
Thomas Schatzl
thomas.schatzl at oracle.com
Wed Apr 22 09:02:44 UTC 2015
Hi Stefan,
On Wed, 2015-04-22 at 10:21 +0200, Stefan Karlsson wrote:
> Hi Thomas,
>
> On 2015-04-22 09:56, Thomas Schatzl wrote:
> >> can I have reviews for this change that cleans up recent changes to
> >> memory management in G1. In particular, for every class that represents
> >> an auxiliary data structure in G1 it adds (and then uses) a specific
> >> function that returns the "heap mapping factor" (the amount of bytes a
> >> particular byte of that data structure corresponds in the java heap).
> >> This method is then used instead of gathering it from various places
> >> when allocating that data structure.
> >>
> >> CR:
> >> https://bugs.openjdk.java.net/browse/JDK-8073632
> >>
> >> Webrev:
> >> http://cr.openjdk.java.net/~tschatzl/8073632/webrev/
>
> http://cr.openjdk.java.net/~tschatzl/8073632/webrev/src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp.frames.html
>
> Why is this implemented as a call into G1BlockOffsetSharedArray?
>
> 157 // Returns how many bytes of the heap a single byte of the Card
> Table corresponds to.
> 158 static size_t heap_map_factor() {
> 159 return G1BlockOffsetSharedArray::heap_map_factor();
> 160 }
You are correct, that is unnecessary. It is better to use
CardTableModRefBS::card_size.
Fixed in
http://cr.openjdk.java.net/~tschatzl/8073632/webrev.1
Diff webrev:
http://cr.openjdk.java.net/~tschatzl/8073632/webrev.0_to_1
Thanks,
Thomas
More information about the hotspot-gc-dev
mailing list