<br><br><div class="gmail_quote">On Wed, Feb 8, 2012 at 6:30 PM, charlie hunt <span dir="ltr"><<a href="mailto:charlie.hunt@oracle.com">charlie.hunt@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi Ramki,<br>
<br>
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). ;-)<br>
<br></div></blockquote><div><br>yes, i totally understand :-)<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
However, that doesn't mean that there may be some negative scaling
of parallel old where it would otherwise be optimal for parallel
scavenge.<br>
<br>
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 ?<br></div></blockquote><div><br>I think that may be the case.... although the evidence is still fragmentary and anecdotal,<br>and i haven't seen (or collected) real scaling data yet. Will let you know once data is clearer.<br>
<br>thanks Charlie!<br>-- ramki<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
thanks,<br>
<br>
charlie ... <br><div><div class="h5">
<br>
On 02/ 8/12 11:13 AM, Srinivas Ramakrishna wrote:
<blockquote type="cite">Hmm... I suppose the lack of reaction must mean that
there is no traction for Yet Another JVM Option ;-)<br>
Although it is arguable (theoretically at least) that the optimal
level of parallelism for two different GC algorithms<br>
may not necessarily be identical. I wonder if the performance
folks have noticed any negative<br>
scaling of parallel old at parallelism levels that would be
otherwise optimal for parallel scavenge. Charlie or John?<br>
(I'll go see if Charlie's book says anything about that :-)<br>
<br>
-- ramki<br>
<br>
<div class="gmail_quote">On Mon, Feb 6, 2012 at 11:01 AM, Srinivas
Ramakrishna <span dir="ltr"><<a href="mailto:ysr1729@gmail.com" target="_blank">ysr1729@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
Hi all --<br>
<br>
I am wondering if there may be any traction to using a
different "ParallelGCThreads" setting for old and young<br>
phases of Parallel GC, somewhat analogous (although i
understand the analogy is too loose) to how there are separate<br>
numbers of (max) parallel threads for concurrent and
stop-world phases of CMS and G1. It's of course<br>
almost trivial to implement as of now, but it introduces yet
more (user-settable) options, multiplying existing<br>
confusion of the roles of many of these options.<br>
<br>
In some sense, Jon's recent infrastructure work on eventually
enabling the jvm/gc to dynamically flex the # of GC threads<br>
works in that direction in a more pleasant and ergonomic
fashion, but I was wondering whether, in the interim, we can
have<br>
a stop-gap where the users can explicitly set the values for
(for example) old and new collections via different
parameters. I am<br>
myself somewhat conflicted by this suggestion since it starts
us down a somewhat slippery slope of<br>
that leads to an explosion of options, but at the same time,
I'd like to hear any thoughts, comments or<br>
opinions on this suggestion.<br>
<br>
thanks!<br>
-- ramki<br>
</blockquote>
</div>
<br>
</blockquote>
<br>
<br>
</div></div></div>
</blockquote></div><br>