RFR(XS): G1: Concurrent mark stuck in loop calling os::elapsedVTime()

[Jon Masamitsu]

On 05/05/2014 01:24 AM, Per Liden wrote:
> Hi Jon,
>
> On 05/01/2014 01:29 AM, Jon Masamitsu wrote:
>> Per,
>>
>> Are you saying that when the heap expands, "_heap_end" might not be
>> updated but
>> "_finger" will be updated for an allocation in the newly expanded part
>> of the heap?
>
> Yes, that's correct. The exact scenario when this happens tends to be 
> this:
>
> 1) Heap has N regions, where N is below max heap size so there's still 
> room for expansion.
> 2) An humongous allocation of two regions is done.
> 3) In this particular case, to satisfy the allocation the heap need to 
> be expanded by one region, and the humongous allocation ends up at 
> [N-1, N+1).
> 4) At this point _heap_end still points to N, but the heap size is 
> actually N+1.
Can that be fixed?

Jon

> 5) When CM claims the humongous region starting at N-1 the _finger 
> will be bumped to N+1, and _finger is now past _heap_end.
>
> /Per
>
>>
>> Jon
>>
>> On 4/30/2014 6:13 AM, Per Liden wrote:
>>> Hi,
>>>
>>> Here's another G1 concurrent mark fix I'd like to have reviewed.
>>>
>>> Summary: If the heap is expended when a concurrent mark is in progress
>>> there's a window where the global marking finger (_cm->_finger) points
>>> past the heap end (_cm->_heap_end). When this happens the marking
>>> threads will get stuck in a loop spinning, because
>>> _cm->out_of_regions() will still return false. out_of_regions() is
>>> currently implemented as "return _finger == _heap_end;".
>>>
>>> This patch fixes this problem by adjusting out_of_region() to instead
>>> be "return _finger >= _heap_end;". This is safe because objects in
>>> those new regions will be considered live anyway, because their TAMS
>>> will be equal to bottom.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040804
>>> Webrev: http://cr.openjdk.java.net/~pliden/8040804/webrev.0/
>>>
>>> /Per
>>
>