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

[Thomas Schatzl]

Hi Kim,

   first, sorry for the late reply.

On 10.03.20 22:27, Kim Barrett wrote:
>> 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).

- g1DirtyCardQueue.cpp:544: indentation of "fully_processed" parameter

- I suggest to undo that line break in the assert 547 - the resulting 
string is like 83 chars.

Looks good otherwise. I do not need a re-review for above tiny changes.

Thanks,
   Thomas