RFR (S): 8025441: G1: assert "assert(thread < _num_vtimes) failed: just checking" fails when G1ConcRefinementThreads > ParallelGCThreads

Bengt Rutisson bengt.rutisson at oracle.com
Fri Sep 27 04:10:13 UTC 2013


Hi Thomas,

Looks good.

Bengt

On 9/26/13 10:05 PM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following small change? It fixes the wrong
> use of ParallelGCThreads (i.e. the number of gc worker threads) when
> initializing the data structure that stores the remembered set summary
> information, that should use the number of refinement threads.
>
> The change in particular changes the following:
> - use the correct thread count value (number of concurrent refinement
> threads vs. parallel gc threads).
> - do not initialize the "initial" remembered set summary if
> G1SummarizeRSetStats is not set (this lead to the crash).
> - G1RemSetSummary::initialize() does not take a number of threads
> parameter any more. It has been the same in all invocations anyway, and
> it's always the same value too.
> - use ConcurrentG1Refine::thread_num(), the number of concurrent
> refinement threads, to size the cpu usage statistics array instead of
> G1RemSet::n_workers(), which is the number of GC workers.
> - jtreg test case that not only tests various combinations of
> G1ConcRefinementThreads and ParallelGCThreads, but also checks that the
> RS thread times output is there, and correct (number of entries).
>
> bugs.openjdk.java.net
> https://bugs.openjdk.java.net/browse/JDK-8025441
>
> Webrev
> http://cr.openjdk.java.net/~tschatzl/8025441/webrev/
>
> Testing
> JPRT, jtreg test case
>
> Thanks,
>    Thomas
>




More information about the hotspot-gc-dev mailing list