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

[Per Liden]

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
>>