JEP 173: Remove Rarely-Used Combinations of Garbage Collectors

[Kirk Pepperdine]

Hi Peter,

I appreciate the desire to remove unneeded code from the JVM. I think you are right... in the cases where I did move customers to the serial collector 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.  That said, over the years, I've seen a number of strange or unexpected things when tuning apps out in the wild. Sometimes these things just go in the opposite direction you might have anticipated. For example, I'm surprised at the number iCMS logs I've received from a numerous sources. What isn't clear to me is how to confirm that my observation isn't an anomaly.

As for the expert system for the analysis of GC logs... I think to think that it's a fantasy. It is rare that a collector can be tuned on a single pass. That said, I've developed a number of heuristics that have been helpful in at least recognizing badly configured VMs. the heuristics in some cases will offer suggestions. However, tuning GC is a complex process with many variables and touching any part can completely destabilize any other part of the system you've tuned. 

-- Kirk

On 2012-12-06, at 10:40 PM, "Peter B. Kessler" <Peter.B.Kessler at Oracle.COM> wrote:

> 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