separate ParallelGCThreads ?

Srinivas Ramakrishna ysr1729 at
Thu Feb 9 16:52:49 UTC 2012

On Wed, Feb 8, 2012 at 6:30 PM, charlie hunt <charlie.hunt at>wrote:

>  Hi Ramki,
> Given that we (ideally) don't see ParallelOld GCs very frequently, we
> haven't really had a catalyst to push us to looking into having different
> settings for parallel scavenge versus parallel compaction threads.  In
> short, I think most folks are happy compaction is multi-threaded with
> parallel GC (i.e. shorter in duration). ;-)
yes, i totally understand :-)

> However, that doesn't mean that there may be some negative scaling of
> parallel old where it would otherwise be optimal for parallel scavenge.
> Have you seen something that suggests we should consider looking at this a
> bit more closely?  Or, was it Jon's changes that got you thinking about the
> possibility ?

I think that may be the case.... although the evidence is still fragmentary
and anecdotal,
and i haven't seen (or collected) real scaling data yet. Will let you know
once data is clearer.

thanks Charlie!
-- ramki

> thanks,
> charlie ...
> On 02/ 8/12 11:13 AM, Srinivas Ramakrishna wrote:
> Hmm... I suppose the lack of reaction must mean that there is no traction
> for Yet Another JVM Option ;-)
> Although it is arguable (theoretically at least) that the optimal level of
> parallelism for two different GC algorithms
> may not necessarily be identical. I wonder if the performance folks have
> noticed any negative
> scaling of parallel old at parallelism levels that would be otherwise
> optimal for parallel scavenge. Charlie or John?
> (I'll go see if Charlie's book says anything about that :-)
> -- ramki
> On Mon, Feb 6, 2012 at 11:01 AM, Srinivas Ramakrishna <ysr1729 at>wrote:
>> Hi all --
>> I am wondering if there may be any traction to using a different
>> "ParallelGCThreads" setting for old and young
>> phases of Parallel GC, somewhat analogous (although i understand the
>> analogy is too loose) to how there are separate
>> numbers of  (max) parallel threads for concurrent and stop-world phases
>> of CMS and G1. It's of course
>> almost trivial to implement as of now, but it introduces yet more
>> (user-settable) options, multiplying existing
>> confusion of the roles of many of these options.
>> In some sense, Jon's recent infrastructure work on eventually enabling
>> the jvm/gc to dynamically flex the # of GC threads
>> works in that direction in a more pleasant and ergonomic fashion, but I
>> was wondering whether, in the interim, we can have
>> a stop-gap where the users can explicitly set the values for (for
>> example) old and new collections via different parameters. I am
>> myself somewhat conflicted by this suggestion since it starts us down a
>> somewhat slippery slope of
>> that leads to an explosion of options, but at the same time, I'd like to
>> hear any thoughts, comments or
>> opinions on this suggestion.
>> thanks!
>> -- ramki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-gc-dev mailing list