RFR: 8080106: Refactor setup of parallel GC threads
Jon Masamitsu
jon.masamitsu at oracle.com
Thu May 14 20:48:37 UTC 2015
Stefan,
I'll send mail for each of the CR's (so hold applause :-) until you
see the last one).
On 05/13/2015 06:17 AM, Stefan Karlsson wrote:
> Hi all,
>
> Please review these patches to unify the ways we specify the number of
> used worker threads. The main goal for these patches is to get rid of
> CollectedHeap::set_par_threads() and CollectedHeap::n_par_threads().
>
> The RFE has been split into multiple sub-tasks:
> 8080109: Use single-threaded code in
> Threads::possibly_parallel_oops_do when running with only one worker
> thread
> 8080110: Remove usage of CollectedHeap::n_par_threads() from root
> processing
> 8080111: Remove SubTaskDone::_n_threads
> 8080112: Replace and remove the last usages of
> CollectedHeap::n_par_threads()
> 8080113: Remove CollectedHeap::set_par_threads()
>
> See the description below for each individual patch:
>
> ---
> http://cr.openjdk.java.net/~stefank/8080109/webrev.00
> 8080109: Use single-threaded code in
> Threads::possibly_parallel_oops_do when running with only one worker
> thread
>
> Today, the root processing code differentiates between two types of
> single-threaded executions:
>
> 1) n_par_threads() == 0, used from Serial GC and other code paths that
> executes the root processing from the VM Thread.
> 2) n_par_threads() == 1, used from non-Serial GCs when the
> root_processing is executed by one GC worker thread.
>
> Today, the only code difference is that the latter will use cmpxchg to
> claim the threads in Threads::possibly_parallel_oops_do.
>
> I propose that we use the same code for both values of
> n_par_threads(), and only use the cmpxchg version if we are running
> with more than one worker thread.
>
> ---
Looks good. Reviewed.
Jon
More information about the hotspot-gc-dev
mailing list