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

Bengt Rutisson bengt.rutisson at oracle.com
Thu Dec 20 23:26:46 UTC 2012


Hi Ramki,

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

Right. That is actually what I ended up doing. Running Ubuntu in a 
VirtualBox set up to use one CPU.

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

I did one set of test runs with SpecJBB2005 on the single CPU VirtualBox 
instance that I have. I got these scores:

17691  DefNew
17778  ParNew ParallelGCThreads=0
17770  ParNew ParallelGCThreads=1

I will do more runs and I'll also try it on a MT system as you 
suggested. But primarily the results look good.

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

Absolutely correct. We will keep the DefNew + SerialOld combo. We just 
want to cut down on the permutations that we need to test and support. 
So we aim to deprecate DefNew + CMS. But we will keep DefNew and still 
support and test it in combination with SerialOld.

Bengt

>
> -- ramki
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20121221/f90a0c37/attachment.htm>


More information about the hotspot-gc-dev mailing list