separate ParallelGCThreads ?

[Srinivas Ramakrishna]

On Wed, Feb 8, 2012 at 6:30 PM, charlie hunt <charlie.hunt at oracle.com>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 gmail.com>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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120209/71455e10/attachment.htm>