separate ParallelGCThreads ?

[Srinivas Ramakrishna]

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/20120208/f5d3bfbf/attachment.htm>