JEP 173: Remove Rarely-Used Combinations of Garbage Collectors
kirk at kodewerk.com
Thu Dec 6 13:02:30 PST 2012
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.
More information about the hotspot-gc-dev