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

[Per Liden]

Jon,

On 05/05/2014 07:29 PM, Jon Masamitsu wrote:
>
> 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?

In theory that could be done, but we would have to introduce locking or 
other means of synchronization between the mark threads and the mutator 
expanding the heap. But more importantly, when marking starts we want a 
snapshot of the heap and we shouldn't have to adjust CM's view of the 
heap size after that. There's currently a function to update the heap 
size called update_g1_committed(). This is called when the heap expands 
during a GC safepoint. However, as Bengt pointed out, that function is 
superfluous and should be removed (he created an RFE to do that, 
JDK-8042097).

/Per

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