RFR: 8162929: Enqueuing dirty cards into a single DCQS during GC does not scale

[Kim Barrett]

Please review this refactoring of G1DirtyCardQueue[Set], splitting
into two sets of classes that each better support the purpose they are
used for.  The existing G1DirtyCardQueue[Set] is (and remains) the
mechanism for communicating between the logging post-write barrier and
the remset, via refinement (both concurrent and STW).  The new
G1RedirtyCardsQueue[Set] are used during collections to collect and en
masse dump old remset information back into that cycle for later
reconsideration.

There is a G1RedirtyCardsQueueSet associated with the collector
object, replacing the second (non-refinement related)
G1DirtyCardQueueSet.  During certain collection phases we now allocate
G1RedirtyCardsQueue objects local to worker threads, with the
collected buffers sent to that new qset.  Because the collection and
processing of those buffers happen in distinct non-overlapping phases,
we can easily use a lock-free stack as the qset's completed buffer
list.  We don't even need to track the number of buffers.

This splitting allowed a little bit of immediate simplification of
G1DirtyCardQueueSet.  It will also make it easier to make future
improvements in that area.

Although the CR describes a performance problem, it seems that other
improvements in the intervening 3 years have substantially reduced the
described problems.  (In particular, substantially fewer cards go
through this process.)  On various performance tests this change has
not shown significant improvements, though also no regressions.  It
might be that with some workloads and with enough worker threads this
change could still have significant performance benefit though.  But
the main point of making this change now is the resultant code
simplification.

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

Webrev:
http://cr.openjdk.java.net/~kbarrett/8162929/open.00/

Testing:
mach5 tier1-5
aurora perf tests for G1
locally BigRamTester