RFR (S): 8069760: When iterating over a card, G1 often iterates over much more references than are contained in the card

[Thomas Schatzl]

Hi all,

  can I have reviews for the following small change that fixes two
serious performance problems with scanning cards during refinement and
the update RS phase?

What happens is that (1) the first object into a card is iterated twice,
and (2) that the first object reaching into the card to scan is always
iterated in full. (1) is a day-one bug, the other has been introduced in
7u4. 

We noticed that particularly in loads with large reference arrays the
update RS phase has been very spiky, sometimes a thread has been in this
phase for more than a second, which came and went. This held up other
threads from progressing.

The change simply refactors the responsible code so that those two
situations cannot occur any more, and is (imo) more readable.

In fact, with this change, some microbenchmarks double their throughput,
and in more real-world'ish applications with large reference arrays it
reduces total gc pause time by 10-20%, and decreases refinement threads
cpu usage by around the same amount.

This seems to be the only case during iteration where these particular
problems may occur, i.e. I browsed through the corresponding HeapRegion
methods a little.

There is still lots of minor cruft in that code. I filed a few follow-up
CRs to clean up that.

There does not seem to be a performance impact on benchmarks that do not
use object arrays, or use only some.

CR:
https://bugs.openjdk.java.net/browse/JDK-8069760

Webrev:
http://cr.openjdk.java.net/~tschatzl/8069760/webrev/

Testing:
nosql, dev-submit performance testing (specj*), vm.quick.testlist, jprt.

Other performance runs requested, but since this is an obvious
performance bug, I do not see a problem not waiting for them.

Thanks,
  Thomas