JEP 173: Remove Rarely-Used Combinations of Garbage Collectors

[Peter B. Kessler]

The trick is intuiting, from the command line tuning, what behavior they wanted.  Is it the footprint they need to keep, or the consistently short pause times, or the interval between young generation collections, the amount of fragmentation they experience in their old generations, etc.  All of the above, or are some of those accidental (maybe happy accidents, maybe not :-)?  What people want is the behavior they've tuned to, not any particular tuning of any particular collector.  That's why we'd like to get to "intent" flags: pause time goals, GC overhead, etc.  And collectors that will meet those goals.

			... peter

Azeem Jiva wrote:
> Kirk, and others --
>   The other option would be to remove less frequently used collectors 
> and convert the flags for those removed collectors to modified versions 
> of existing collectors.  So using iCMS in your commandline would give 
> you G1 (or whatever) instead, tuned as necessary to mimic iCMS as best 
> as possible.
>   I can see people arguing that it changes how the JVM runs, but there 
> are many under the cover changes that happen every week (new 
> optimizations, bugs fixed, etc) and except for people on this list and a 
> few interested parties nobody is aware of the change.  Same thing would 
> happen here.
>   Just a suggestion from someone that isn't a GC engineer :)
> 
> 
> On 12/06/2012 04:10 PM, Kirk Pepperdine wrote:
>> I could have just as easily tuned the parallel collector down to a 
>> single thread. So, getting rid of serial wouldn't be seen as a loss in 
>> my books.
>