JEP 173: Remove Rarely-Used Combinations of Garbage Collectors

[Peter B. Kessler]

I would never think of "slower" as the definition of "sub-optimal".  In the best of all possible worlds, we wouldn't remove a collector unless there was a replacement that was better in every way: at least pause time, throughput of the collector, overhead in the code of the mutators, heap space overhead requirements, etc.  To my example, if we find that even with only 1 worker the parallel collector is competitive with the serial collector, and strictly better with more than one worker, then to Bengt's point we shouldn't be spending engineering effort (including testing cycles, brain cells, etc.) on the serial collector.  I don't know how the collectors stack up in various scenarios.  I was asking that we drive the process with data, not just a desire to simplify the lives of the GC engineers, because, as you say, we have customers.  Part of the process should be identifying customers who are still using the serial collector and finding out why, and how any proposed alternati
ve works for them.  The JEP is part of that process.

It would be nice if we could tell people if their choice of options could be improved: in that sense, if their configuration is sub-optimal.  We had fantasies of doing that by expert-system analysis of GC logs, but that never happened.  So we do it by hand, which isn't always responsive, and doesn't scale.

			... peter

P.S. I'm no longer part of the HotSpot GC team so these are just my opinions.

Kirk Pepperdine wrote:
> On 2012-12-06, at 2:32 PM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
> 
>> Hi Peter,
>>
>> Thanks for your feedback!
>>
>> On 12/6/12 1:23 AM, Peter B. Kessler wrote:
>>> mark.reinhold at oracle.com wrote:
>>>> Posted: http://openjdk.java.net/jeps/173
>>>>
>>>> - Mark
>>> If the only use of SerialOld will be with ParallelScavenge + SerialOld, then maybe we should check what the performance hit (GC time, heap utilization, application throughput) is using ParallelScavenge + ParallelOld, possibly with ParallelOld throttled down to 1 worker thread.  (I understand that we can't remove the code for SerialOld because it backs CMS, but we could improve the user experience by not letting people choose sub-optimal configurations.)
> 
> I'd like to see a definition for sub-optimal. I would have to see the definition for slower be confused with "sub-optimal". Sometimes using "sub-optimal" configurations has been the way out of some sticky situations. In a few cases, "sub-optimal" was actually optimal for the application in question.
> 
> -- Kirk
>