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

[Bengt Rutisson]

Thanks Ramki, John and Jesper for the reviews!

Pushing this now.

Bengt

On 12/22/12 6:08 AM, Bengt Rutisson wrote:
>
> 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
>>>>
>>>>
>