Sorry for the delay in responding. The changes (this and the other bug id for ParNew/1) all look good; thanks for verifying the performance numbers as well!<br><br>thanks!<br>-- ramki<br><br><div class="gmail_quote">On Fri, Jan 4, 2013 at 2:23 AM, Bengt Rutisson <span dir="ltr"><<a href="mailto:bengt.rutisson@oracle.com" target="_blank">bengt.rutisson@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Thanks Ramki, John and Jesper for the reviews!<br>
<br>
Pushing this now.<span class="HOEnZb"><font color="#888888"><br>
<br>
Bengt</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 12/22/12 6:08 AM, Bengt Rutisson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi John,<br>
<br>
Thanks for looking at this!<br>
<br>
On 12/22/12 1:38 AM, John Coomes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Bengt Rutisson (<a href="mailto:bengt.rutisson@oracle.com" target="_blank">bengt.rutisson@oracle.com</a>) wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Ramki,<br>
<br>
I made the change to pick ParNew by default also on single CPU systems.<br>
However, I think this change deserves a separate bug ID and changeset.<br>
So, I just sent out a new review request with just this change.<br>
<br>
Once that has been handled. I think the review request discussed in this<br>
email thread will look exactly as it is now.<br>
</blockquote>
Given the other change to keep ParNew enabled on 1-cpu systems, this<br>
looks good to me.<br>
<br>
You might want to append to the warning something along the lines of<br>
"and will likely be removed in a future release". We intend to remove<br>
this, so "deprecated" here is notably different from its use in the<br>
Java APIs, where nothing deprecated has ever been removed.<br>
</blockquote>
<br>
Good point. Updated webrev:<br>
<br>
<a href="http://cr.openjdk.java.net/%7Ebrutisso/8003820/webrev.01/" target="_blank">http://cr.openjdk.java.net/~<u></u>brutisso/8003820/webrev.01/</a><br>
<br>
Thanks,<br>
Bengt<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-John<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks again for looking at this!<br>
Bengt<br>
<br>
On 12/20/12 9:21 PM, Srinivas Ramakrishna wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What happens when you run CMS on a single-processor. I hope you<br>
don't see a deprecation warning.<br>
</blockquote>
Ooops. Good point. It took me a long while to find a machine with<br>
just one cpu that could actually run JDK8. But you are correct. We<br>
will print a warning in that case.<br>
<br>
<br>
Remember that virtualized platforms or LDOMS or Zones may partition a<br>
large box into small 1-cpu slices (although may be not 1-core).<br>
<br>
On Solaris, you can easily test your code by means of psradm to turn<br>
off all but one virtual cpu.<br>
<br>
<br>
I think the fix is to not pick DefNew by default for single<br>
processor machines. I'll see if I can get any performance data for<br>
that.<br>
<br>
<br>
I'd test that on a regular MP with ParNew=1 vs DefNew, as well as<br>
separately with psrset and pbind (although my guess is that<br>
the latter two would be indistinguishable from each other). As I<br>
recall, scaling was near linear at those small numbers for ParNew,<br>
and the breakeven point was at 2, so my guess based on very old data<br>
from the fogs of time is that we'd see a fairly sizable pause<br>
time and overhead hit on a single cpu.<br>
<br>
Stepping back for a moment, is supporting embedded environments<br>
perhaps from the same parent code base an issue, so DefNew &<br>
Serial is going to be part of the code base for a while, anyway?<br>
<br>
I understand though that saving on testing resources by pruning down<br>
supported combinations is one important motivation, in which case<br>
DefNew+CMS gets deprecated (and switches to Parnew/1+CMS on 1-cpu<br>
configs), but DefNew continues to be part of the code base,<br>
and so DefNew code gets used (and tested) at least in part to the<br>
extent that ParNew uses at least some functionality defined in DefNew.<br>
<br>
-- ramki<br>
<br>
<br>
</blockquote></blockquote></blockquote>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br>