JEP 248: Make G1 the Default Garbage Collector

[charlie hunt]

> On Jul 30, 2015, at 9:15 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> 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.

Not that I like to talk negatively of benchmarks, and I respect the SPEC organization … Let’s keep in mind SPECjvm is a throughput benchmark. It does not include latency or footprint metrics. It also has other weaknesses including (though not limited too); doesn’t run long enough, the workloads are rather trivial, can be tuned to the point where it can run with Parallel GC without experiencing a full GC. As an illustration, how many apps in the wild do you know run for 4 minutes and have rather predictable object allocation rates and predictable object lifetimes?

A performance regression in javac is worthy of worrying. It is an important part of the developer use case. As you are probably aware, one thing we should be careful about is reporting only percentages. For example, a 4 second versus 5 second javac compilation comparison warrants a 20% difference. In a developer use case, that 1 second difference in javac compilation may not be as noticeable or worrisome compared to an 8 minutes versus 10 minutes difference, (that too being a 20% difference).

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

One data point you can take a look at is from a J1 presentation that shows an application migration from Parallel GC to G1:
https://www.parleys.com/tutorial/garbage-first-garbage-collector-migration-expectations-advanced-tuning <https://www.parleys.com/tutorial/garbage-first-garbage-collector-migration-expectations-advanced-tuning>
* Start at about the 7:00 minute mark through about the 29 minute mark.
** Also note that this is about 18 - 24 months old, and many enhancements have gone into G1 since then.

I realize this is just one application. And, fwiw, it is a more complex application than SPECjvm. ;-)

In general what you find with G1 is in the face of fluctuating object allocation rates and object lifetimes, and applications that run for extended period of time, when taking into account throughput, latency and memory footprint, G1 tends to meet those goals better than Parallel GC.

hths,

charlie

> 
> Andrew.