RFR [L][3/7]: 8197850: Calculate liveness in regions during marking

[Thomas Schatzl]

Hi all,

  can I have reviews for this change that calculates the liveness in
regions (below nTAMS) during marking?

This is required to be more clever about selecting the regions G1 is
going to rebuild the remembered sets for (i.e. the well-known
G1MixedGCLiveThresholdPercent threshold).

This slows down the marking part of the concurrent phase a bit, but all
alternatives were worse:

- initially rebuild everything and then drop remembered sets for
regions for too highly occupied regions at cleanup: wastes lots of
space and memory maintaining these superfluous remembered sets.

- choose regions using previous marking cycle data: this is generally
not a good idea if your marking cycles are infrequent (which should be
the normal case), as it tends to make too few regions available for
evacuation (e.g. eager reclaim may already reclaim a lot). I.e. you
need extra headroom, or be more aggressive with rebuilding.

The main change, next to the calls that add the liveness to some
internal data structure every time an object is marked, is some per-
thread cache that (G1RegionMarkStatsCache). It helps decreasing the
synchronization overhead the (atomic) increments in the global result
cause.

It is a very simple fixed size hashmap where increments to the same
entries are collected, and on collision evicts the previous entry,
doing the atomic operation on the global result.

There is also some unfortunate moving of code that is required to flush
these caches correctly during mark overflow handling.

CR:
https://bugs.openjdk.java.net/browse/JDK-8197850
Webrev:
http://cr.openjdk.java.net/~tschatzl/8197850/webrev/index.html
Testing:
hs-tier 1-5; the next change will add an assert that verifies that this
concurrently calculated value is correct at the end of rebuild, i.e.
the results will always verified.

Thanks,
  Thomas