JEP 248: Make G1 the Default Garbage Collector

[Andrew Haley]

On 07/30/2015 03:02 PM, charlie hunt wrote:
> 
>> On Jul 30, 2015, at 3:59 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 05/06/15 10:48, Ben Evans wrote:
>>> I'm cautiously optimistic about the plan - but I would like a bit
>>> more of an idea of what quantitative data & experiences we would
>>> need to prove whether G1 was ready or not.
>>
>> Exactly.  Let's share the numbers.
> 
> Let’s also realize that there is more to performance than
> application throughput. There is also latency, memory footprint, and
> there are also those who monitor CPU usage and committed memory
> closely as a means (though not ideal) to predict additional system
> capacity.
> 
> I will also add, for those application executions that run with
> Parallel GC and never experience a full GC, they will almost all the
> time beat G1 on throughput (and probably latency too). We should
> keep in mind that G1’s design goals are a balance between
> throughput, latency and memory footprint.
> 
> As an example, let’s contrast the two GC’s from a Java heap growth
> standpoint, Parallel GC will aggressively try to grow the Java heap
> to achieve throughput. G1 will grow the Java heap in reaction to
> meeting the pause time goal. In cases where the initial Java heap
> size differs from the max Java heap size, I have seen cases where
> Parallel GC will grow to the max Java heap size, yet G1 does not
> because G1 was able to meet the pause time goal without expanding to
> the max Java heap size.

Thank you for your reply.

All of these things are important, I agree.  I'm perfectly happy that
we should trade some throughput for responsiveness.  My measurements
have showed that every SPECjvm benchmark is several percent slower,
and none are faster.  And the substantial performance regression in
javac worries me most of all.

John Rose said that some internal performance testing showed that G1
was meeting its goals and will be suitable to be the default
collector.  Maybe that's right, and we should accept a 4-5% decline in
overall performance in exchange for pause times.  But let's talk about
this in the context of some actual measurements.

Andrew.