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