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