RFR: 8059066: CardTableModRefBS might commit the same page twice
kim.barrett at oracle.com
Mon Oct 27 22:40:28 UTC 2014
On Oct 24, 2014, at 8:54 AM, Erik Helin <erik.helin at oracle.com> wrote:
> Fortunately for us, we only have have two committed regions (anyone, please correct me if I'm wrong here) and two covering regions, since we only have two generations. Unfortunately, CardTableModRefBS was probably used for the train collector and therefore (unnecessary) tries to support n generations.
> In the case of at most two committed regions and no subsets, I believe that my proposed fix will work (I should have mentioned all this is in the original RFR). What do you think? Should we add asserts that checks that the number of committed regions are at most two?
The relevant function for the number of covered/committed regions
seems to be CollectorPolicy::create_rem_set(), which has an
G1's call to create_rem_set() passes literal 2 for that argument.
The other caller of create_rem_set() is
GenCollectedHeap::initialize(), where the value of that argument is
computed by GenCollectedHeap::allocate().
GenCollectedHeap::allocate() iterates over the _gen_specs, summing the
result of _gen_specs[i].n_covered_regions(). Although that function
is virtual, it appears to have only the one definition in
GenCollectedHeap, which returns always returns 1. So the result of
that summing iteration should be the number of elements in _gen_specs,
which should be the number of generations, which is (soon to be)
always 2 for relevant collectors. [I'm not sure all collectors have
2, since a simple non-generational collector wouldn't and I thought we
still had one of those lurking in the code base, though I could easily
be wrong about that. But I would guess that a non-generational
collector wouldn't have, or wouldn't use, a remembered set.]
However, GenCollectedHeap::allocate() then unconditionally adds 2 to
that value; see lines 179-181
179 // Needed until the cardtable is fixed to have the right number
180 // of covered regions.
181 n_covered_regions += 2;
I have no idea what that's about yet. But it looks like, for non-G1
generational collectors the value will actually be 4 rather than 2. I
haven't actually verified that with executing code though.
More information about the hotspot-gc-dev