RFR(S): 8040803: G1: Concurrent mark hangs when mark stack overflows

[Erik Helin]

Looks good.

Thanks,
Erik

On 2014-05-09 09:39, Per Liden wrote:
> Thanks Bengt,
>
> Still need a second reviewer on this.
>
> /Per
>
> On 05/05/2014 06:11 PM, Bengt Rutisson wrote:
>>
>> Hi Per,
>>
>> Looks good.
>>
>> Bengt
>>
>>> 5 maj 2014 kl. 15:27 skrev Per Liden <per.liden at oracle.com>:
>>>
>>> Hi Bengt,
>>>
>>>> On 05/02/2014 10:33 AM, Bengt Rutisson wrote:
>>>>
>>>> Hi Per,
>>>>
>>>>> On 2014-04-30 15:04, Per Liden wrote:
>>>>> Hi,
>>>>>
>>>>> Could I please have a couple of reviews in this bug fix:
>>>>>
>>>>> Summary: G1's concurrent marking can potentially hang forever if the
>>>>> global mark stack overflows and immediately after that a Full GC
>>>>> happens, which tries to abort the marking. The reason is that there's
>>>>> a race between detecting the overflow situation and detecting the
>>>>> abort signal. Threads detecting the overflow situation first will go
>>>>> into the overflow protocol and wait on a barrier for all threads to
>>>>> reach this state. However, threads detecting the abort signal first
>>>>> will terminate and never participate in the barrier.
>>>>>
>>>>> This patch introduces an abort state and function on the
>>>>> WorkGangBarrierSync class, to unblock any threads waiting for the
>>>>> barrier to complete when the concurrent mark is aborted.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040803
>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8040803/webrev.0/
>>>>
>>>> The change looks good.
>>>
>>> Thanks for looking at the patch Bengt.
>>>
>>>>
>>>> One minor improvement would be to try to use an early exit in
>>>> ConcurrentMark::enter_first_sync_barrier() when the barrier fails.
>>>
>>> Here's an updated webrev with early exit:
>>>
>>> http://cr.openjdk.java.net/~pliden/8040803/webrev.1/
>>>
>>> /Per
>>>
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>>>
>>>>> /Per
>>>
>