RFR(s): 8204094: assert(worker_i < _length) failed: Worker 15 is greater than max: 11 at ReferenceProcessorPhaseTimes
Kim Barrett
kim.barrett at oracle.com
Tue Jun 5 00:48:44 UTC 2018
> 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.
More information about the hotspot-gc-dev
mailing list