RFR(s): 8204094: assert(worker_i < _length) failed: Worker 15 is greater than max: 11 at ReferenceProcessorPhaseTimes

[sangheon.kim at oracle.com]

Thank you for reviewing this, Kim.

Sangheon


On 6/4/18 5:48 PM, Kim Barrett wrote:
>> On May 30, 2018, at 10:19 PM, sangheon.kim at oracle.com wrote:
>>
>> Hi all,
>>
>> Can I have reviews for this patch that fixes assertion failure at ReferenceProcessorPhaseTimes?
>>
>> This failure only happens when ParallelRefProcEnabled option is set on CMS and Parallel GC.
>> The problem is that we are using more workers than we created a storage for workers.
>> When we create ReferenceProcessorPhaseTimes, we set how many workers will be monitored (i.e. prepare an array to save time information). And currently we are setting it with ReferenceProcessor queue size(ReferenceProcessor::_num_queues). But this is problematic because the queue size is continuously updated by ReferenceProcessor::set_active_mt_degree() with active workers every GC. And the queue size is decided later than ReferenceProcessorPhaseTimes is created. So if active workers repeats to increase/decrease, ReferenceProcessorPhaseTimes would have smaller than active workers.
>>
>> This patch is proposing to use maximum queue when create ReferenceProcessorPhaseTimes.
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8204094
>> Webrev: http://cr.openjdk.java.net/~sangheki/8204094/webrev.0
>> Testing: hs-tier1-5 with/without ParallelRefProcEnabled
>>
>> Thanks,
>> Sangheon
>> ------------------------
>> For example:
>> 1) Set 2 when create ReferenceProcessorPhaseTimes(xx, 2): ReferenceProcessor::num_queues() = 2, because previously we had only 2 active workers.
>> 2) Set 23 for ReferenceProcessor::set_active_mt_degree(23), current active workers are increased.
>> 3) Assertion failure as we are using more workers than set from #1.
> Looks good.
>