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">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>