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

[John Coomes]

Bengt Rutisson (bengt.rutisson at 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.

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