Request for Review (M) - 6858051: Create GC worker threads dynamically
jon.masamitsu at oracle.com
Thu Apr 28 22:40:57 UTC 2016
In order to reduce the dependency of WorkGang on AdaptiveSizePolicy,
removed AdaptiveSizePolicy::initial_number_of_workers() and duplicated
in GCTaskManager::initialize() and AbstractWorkGang::initialize_workers().
Moved AdaptiveSizePolicy::add_workers() to WorkerManager::add_workers() in
Removed guard DisableStartThread from add_workers() and always start the
Removed the bool return value from WorkerManager::add_workers (and let
that rippled down
to the callers).
Changed WorkerManager::add_workers() to return the number of created workers
(removed inout on parameters) and let the callers of
adjust their _active_workers to be consistent with the number of created
Changed number of workers created at initialization from 2 to 1.
Please let me know if I forgot anything.
On 04/26/2016 10:06 PM, Jon Masamitsu wrote:
> 6858051: Create GC worker threads dynamically
> This change creates a minimal number of GC workers at JVM initialization
> and then adds additional workers as they are needed. This has been
> made part of the
> UseDynamicNumberOfGCThreads feature. When a parallel task is about to
> be executed, the number of workers needed to execute the task is
> calculated (call
> that number N). If that number of workers already exist, then no
> additional workers
> are created. If fewer than N exists, then additional workers are
> created. Workers
> are not destroyed if not needed for the task.
> The UseParallelGC way of executing parallel tasks is different from
> the other
> collectors so it has a somewhat separate implementation.
> Testing: gc_test_suite with and without UseDynamicNumberOfGCThreads.
> Performance testing with the prototype did not show any regression with
> UseDynamicNumberOfGCThreads turned on. RBT testing for hotspot_gc
> is in progress.
More information about the hotspot-gc-dev