RFR(S): 8149834: gc/shared/gcTimer.cpp:88 assert(_is_concurrent_phase_active) failed: A concurrent phase is not active

sangheon sangheon.kim at oracle.com
Fri Mar 4 20:26:51 UTC 2016


Hi Derek,

Thanks for looking at this!

Sangheon


On 03/04/2016 11:23 AM, Derek White wrote:
> Looks good to me!
>
>  - Derek
>
> On 3/3/16 2:41 AM, sangheon wrote:
>> Hi all,
>>
>> Could I have a couple of reviews for this quick fix?
>>
>> There is a race between VMThread and ConcurrentMarkThread for 
>> ConcurrentGCTimer.
>> At the end of abort, VMThread is trying to end concurrent timer and 
>> if ConcurrentMarkThread is trying to start or end concurrent phase, 
>> timer related asserts will be fired.
>> (Only ConcurrentMarkThread starts a concurrent phase)
>> We have 3 different cases but the root cause is same[1].
>>
>> This proposal is introducing 3 phases of started, not started and 
>> stopping for concurrent phase status.
>> And the status is updated by cmpxchg.
>>
>> However, I think more proper fix would be eliminating the race.
>> Currently G1CollectedHeap has ConcurrentGCTimer but it is mostly used 
>> from ConcurrentMarkThread.
>> So moving the timer and related routines to ConcurrentMark seems better.
>> I filed a new RFE for this[2].
>>
>> Many thanks to Jon, Bengt(base patch as well) and StefanK for the 
>> discussion.
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8151085
>> Webrev: http://cr.openjdk.java.net/~sangheki/8149834/webrev.00
>> Testing: JPRT, local test with adding some sleep at vm code.
>>
>> [1] Related bugs:
>> https://bugs.openjdk.java.net/browse/JDK-8145996
>> https://bugs.openjdk.java.net/browse/JDK-8150819
>>
>> [2] RFE for proper fix:
>> https://bugs.openjdk.java.net/browse/JDK-8151085
>>
>> Thanks,
>> Sangheon
>>
>>
>>
>>
>



More information about the hotspot-gc-dev mailing list