JEP 248: Make G1 the Default Garbage Collector

[charlie hunt]

> 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.
> 
> Andrew.
> 

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.

thanks,

charlie