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

[Srinivas Ramakrishna]

Sorry for the delay in responding. The changes (this and the other bug id
for ParNew/1) all look good; thanks for verifying the performance numbers
as well!

thanks!
-- ramki

On Fri, Jan 4, 2013 at 2:23 AM, Bengt Rutisson <bengt.rutisson at oracle.com>wrote:

>
> 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/<http://cr.openjdk.java.net/%7Ebrutisso/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
>>>>>
>>>>>
>>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130104/54709642/attachment.htm>