RFR (XS): 7045751 G1: +ExplicitGCInvokesConcurrent causes excessive single region evacuation pauses

[Y. Srinivas Ramakrishna]

Very good; thanks!

Reviewed.

-- ramki

On 6/13/2011 12:00 PM, John Cuthbertson wrote:
> Hi Ramki,
>
> Using code similar to CMS, the requesting thread is blocked until the # of full collections
> completed is incremented and the FullGCCount_lock is notified. This takes place at the very end of
> the marking cycle - after cleanup and and after clearing the next mark bitmap.
>
> JohnC
>
> On 06/13/11 11:15, Y. Srinivas Ramakrishna wrote:
>> Looks good. One question: we return when the marking cycle is
>> complete, or when the marking cycle _and_ the succeeding
>> concurrent clean-up is also complete?
>>
>> - ramki
>>
>> On 6/13/2011 10:16 AM, John Cuthbertson wrote:
>>> Hi Everyone,
>>>
>>> Can I have a couple of volunteers look of the small fix for this CR? The webrev can be found at:
>>> http://cr.openjdk.java.net/~johnc/7045751/webrev.0/
>>>
>>> The issue here was that if we had multiple threads executing a System.gc() (with
>>> +ExplicitGCInvokesConcurrent) we would have a thundering herd trying to start an initial mark
>>> evacuation pause. One thread would win, do the pause, and start the marking cycle, and block until
>>> the cycle complete. The next thread in would see that a marking cycle was in progress and do a
>>> regular evacuation pause. If none of the mutators (that were not trying to do a System.gc() call)
>>> did not manage to run, the collection set for this second pause would comprise of only the survivors
>>> from the first pause. The second thread would then block until the marking cycle was complete. And
>>> so on for the remaining threads requesting a System.gc().
>>>
>>> The solution is to skip the evacuation pause if we fail to force it to be an initial mark pause and
>>> just block (as normal) until the existing cycle completes.
>>>
>>> Tested with: GC test suite with and without ExplicitGCInvokesConcurrent.
>>>
>>> Thanks,
>>>
>>> JohnC
>>
>