RFR (L) 8034246: remove CMS and ParNew adaptive size policy code

[Kirk Pepperdine]

Hi,

So my understanding correct (without digging into the code) is that CMS no longer uses any adaptive sizing?

In the past I’ve provided charts that demonstrated adaptive sizing shrank memory in response to lower object creation rates. All well and good but in these cases the lower object creation rates were a result of increased frequency and duration of collections which should have resulted in a larger heap! There are/were a number of other degenerative cases where top of heap aggressively tracked top of live set causing all kinds of grief so backing off of this implementation seems reasonable, especially if there is little chance of it being fixed.

Regards,
Kirk

On May 7, 2014, at 8:37 AM, Srinivas Ramakrishna <ysr1729 at gmail.com> wrote:

> 
> Looks good to me too, and good that we are able to remove code that hasn't been used and seems unlikely now, with G1 available, to have the resources to make it work well. Please make sure that this has also been approved by Jon.
> 
> Reviewed.
> -- Ramki
> 
> ysr1729
> 
>> On May 6, 2014, at 21:38, John Coomes <John.Coomes at oracle.com> wrote:
>> 
>> Mikael Gerdin (mikael.gerdin at oracle.com) wrote:
>>> John,
>>> 
>>>> On Monday 05 May 2014 09.14.40 John Coomes wrote:
>>>> I'd appreciate reviews of this change to delete unused adaptive size
>>>> policy code for cms and parnew.  It's big in terms of line count, but
>>>> most comes from the deletion of 6 files.
>>>> 
>>>> http://cr.openjdk.java.net/~jcoomes/8034246-rm-cms-asp/
>>> 
>>> Good to get rid of code that hasn't been working for a while.
>>> 
>>> In src/share/vm/memory/collectorPolicy.cpp the include statement:
>>> #include "gc_implementation/shared/adaptiveSizePolicy.hpp"
>>> is already present a few lines up.
>> 
>> Yes; fixed.
>> 
>>> CMSCollector::size_policy and ConcurrentMarkSweepGeneration::size_policy are 
>>> basically identical now, do you want to fix this now or leave this as just a 
>>> code removal change? (personally, I'm fine either way)
>> 
>> The ConcurrentMarkSweepGeneration one is no longer used, so I removed
>> it.  Updated webrev is at the same location.
>> 
>>> Consider the change reviewed nevertheless.
>> 
>> Thanks!
>> 
>> -John