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