+1 to all those observations.<br><br>Don't know how it affects sharing of code wrt "embedded" and other smaller footprint jvm's, if any, though....<br>I am sure that has been thought through at the right places, but good to keep in mind.<br>
<br>-- ramki<br><br><div class="gmail_quote">On Wed, Dec 5, 2012 at 4:23 PM, Peter B. Kessler <span dir="ltr"><<a href="mailto:Peter.B.Kessler@oracle.com" target="_blank">Peter.B.Kessler@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 class="im"><a href="mailto:mark.reinhold@oracle.com" target="_blank">mark.reinhold@oracle.com</a> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Posted: <a href="http://openjdk.java.net/jeps/173" target="_blank">http://openjdk.java.net/jeps/<u></u>173</a><br>
<br>
- Mark<br>
</blockquote>
<br></div>
If the only use of SerialOld will be with ParallelScavenge + SerialOld, then maybe we should check what the performance hit (GC time, heap utilization, application throughput) is using ParallelScavenge + ParallelOld, possibly with ParallelOld throttled down to 1 worker thread.  (I understand that we can't remove the code for SerialOld because it backs CMS, but we could improve the user experience by not letting people choose sub-optimal configurations.)  Similarly, if we could start weaning users off of DefNew we might eventually be able to remove the code for it.<br>

<br>
It would help the write-up if the *supported* configurations were listed.<span class="HOEnZb"><font color="#888888"><br>
<br>
                        ... peter<br>
</font></span></blockquote></div><br>