Request for review (S): 8003820: Deprecate untested and rarely used GC combinations

[Srinivas Ramakrishna]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20121220/2d3650c6/attachment.htm>