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

[John Cuthbertson]

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
>