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

Per Liden per.liden at oracle.com
Mon May 5 08:24:38 UTC 2014


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




More information about the hotspot-gc-dev mailing list