Fwd: Better default for ParallelGCThreads and ConcGCThreads by using number of physical cores and CPU mask.

Jon Masamitsu jon.masamitsu at oracle.com
Fri Nov 22 09:24:26 PST 2013

This is a contribution regarding the number of GC worker threads to
use.  Part of the change queries /proc on linux to get the number of
active cores on the platform.  The changes are in


Can someone familiar with this code take a look to see
if it is reasonable and done in a way that is consistent
with other /proc queries.


-------- Original Message --------
Subject: 	Better default for ParallelGCThreads and ConcGCThreads by 
using number of physical cores and CPU mask.
Date: 	Tue, 19 Nov 2013 15:35:22 -0800
From: 	Jungwoo Ha <jwha at google.com>
To: 	hotspot-gc-dev at openjdk.java.net


I am sending this webrev for the review.
(On behalf of Jon Masamitsu, it is upload here)

The feature is a new heuristics to calculate the default 
ParallelGCThreads and ConGCThreads.
In x86, hyperthreading is generally bad for GC because of the cache 
Hence, using all the hyper-threaded cores will slow down the overall GC 
Current hotspot reads the number of processors that the Linux reports,
which treats all hyper-threaded cores equally.
Second problem is that when cpu mask is set, not all the cores are 
available for the GC.

The patch improves the heuristics by evaluating the actual available 
physical cores
from the proc filesystem and the CPU mask, and use that as the basis for 
calculating the ParallelGCThreads and ConcGCThreads.

The improvements of GC pause time is significant. We evaluated on 
Nehalem, Westmere, Sandybridge as well as several AMD processors. We 
also evaluated on various CPU mask configuration and single/dual socket 
In almost all cases, there were speed up in GC pause time by 10~50%.

We primarily use CMS collector for the evaluation, but we also tested on 
other GCs as well.
Please take a look and let me know if this patch can be accepted.

Jungwoo Ha

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20131122/567146d7/attachment.html 

More information about the hotspot-runtime-dev mailing list