RFR: 8139652: Mutator refinement processing should take the oldest dirty card buffer

[Kim Barrett]

> On Mar 3, 2020, at 9:32 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> Please review this change to the handling of completed buffers by mutator
> threads.  Previously it would conditionally process and potentially reuse the
> buffer, rather than enqueuing it.  Now, always enqueue the buffer and
> allocate a new one, and conditionally process the next (oldest) dirty buffer
> in the DCQS.  The benefit of this is that the buffers being processed by the
> mutator age for a while in the DCQS (just as is done by for concurrent
> refinement thread processing), so if the mutator is making repeated writes
> to the same or nearby locations, the associated card marking has more
> opportunaty to be filtered out.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8139652
> 
> Webrev:
> https://cr.openjdk.java.net/~kbarrett/8139652/open.00/
> 
> Testing
> mach5 tier1-5 along with changes for JDK-8239825 and JDK-8139652. 

The original webrev was based on JDK-8239825 and JDK-8240133.  The
push and backout of JDK-8240133 has made that webrev no longer apply
cleanly.  So here's a new, up to date (as of this morning) webrev:

https://cr.openjdk.java.net/~kbarrett/8139652/open.01/

Tested with mach5 tier1-5 along with change for JDK-8239825 (which
hasn't been pushed yet).

I forgot to mention previously that I've also done some performance
testing, which didn't find anything interesting from this change.
Compared each of before/after this change plus each of default
-XX:G1ConcRefinementThreads and that option = 0.