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

[Bengt Rutisson]

Hi John,

Thanks for looking at this!

On 12/22/12 1:38 AM, John Coomes wrote:
> 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.

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