JEP 248: Make G1 the Default Garbage Collector

[Jungwoo Ha]

IIRC, javac is spent most of the time in JIT-ed code, and the performance
difference between G1 and Parallel should be the writebarrier cost. IIRC,
G1's write-barrier is >20% more expensive than the Parallel's.

On Thu, Jul 30, 2015 at 11:04 AM, charlie hunt <charlie.hunt at oracle.com>
wrote:

> Hi Andrew,
>
> Thanks for the response, you have some excellent points.
>
> On javac, my observation is that it tends to have a very high object
> allocation rate, and the object lifetimes are somewhat short.  And, I
> suppose if we think about what javac does, I suppose we can come to terms
> as to why that’s the case. I imagine if one put forth a concerted effort,
> javac could be improved (probably true for many apps too).  Performance of
> javac is certainly one we want to pay close attention due to its impact to
> the developer use case.
>
> I also like your comments on being prepared to answer / respond to
> observations that “J. Random Blogger” claims that Java just got slower.
> Completely agree with you!
>
> If / when we seen this kind of thing …  A quick and easy rebuttable could
> be, “But a quick and easy setting of -XX:+UseParallelGC on the command line
> and we expect your app’s performance to be as good as (or better) than the
> previous release” and perhaps we could also add that we expect the majority
> of folks who do not set a GC to have a positive out of the box experience
> with this change.
>
> In all fairness, it is may be worth mentioning too that it is possible
> that there are apps that do not set a specific GC today that may have a
> positive experience with G1 as the default. Though we likely will not hear
> many of those, not nearly as often as the negative experiences.
>
> Should also mention that it’s reasonable to expect the JDK 9 release notes
> will include the default GC has changed, (i.e when no GC is specified), and
> if the performance is not as expected / desired, to suggest enabling
> Parallel GC.
>
> thanks,
>
> charlie
>
>
> > On Jul 30, 2015, at 12:38 PM, Andrew Haley <aph at redhat.com> wrote:
> >
> > On 07/30/2015 04:03 PM, charlie hunt wrote:
> >>
> >> 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?
> >
> > I absolutely agree with you.
> >
> > Having said that, SPEC is not a simple benchmark, it's a bunch of
> > programs from a bunch of places, and they don't have much in common
> > beyond being self-contained and running for a few minutes.  I'm not
> > claiming that SPEC is the right thing to use to measure garbage
> > collection: I just want to make sure that when JDK9 comes out and
> > J. Random Blogger comes along with "Hey!  Java just got slower" we
> > have a good answer for them.  A good answer would be something along
> > the lines of "We know that, but G1 is in general better, and this is
> > why."
> >
> >> 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.
> >
> > Sure.  I suppose I was guessing that javac is typical of a of
> > Java application which parses lots of files, creates a lot of
> > hash tables and suchlike, and generates some output.  I was also
> > assuming that javac is well-written, which is very important when
> > considering a benchmark.  We surely don't want to optimize for
> > badly-written code which pointlessly allocates a ton of objects!
> >
> >> 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).
> >
> > OK, just for fun:
> >
> > java -XX:+UseParallelGC -jar dist/CompilerSpeed.jar 480 12
> > 12 threads, 480 seconds
> > Time: 481.35s, 13.38 compiles/s
> >
> > java -XX:+UseG1GC -jar dist/CompilerSpeed.jar 480 12
> > 12 threads, 480 seconds
> > Time: 481.00s, 11.49 compiles/s
> >
> > So, G1 takes 16% longer when run for 8 minutes, which is less
> > significant.
> >
> >> 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. ;-)
> >
> > This is excellent, thank you.  In particular, it is made clear quite
> > early on that the Parallel GC, if it is suitable for your application,
> > probably has the best lowest overheads of any of the GCs.  But
> > throughput and overhead not all we care about, of course.  They tend
> > to be all that benchmarks care about because they're the easiest
> > things to measure.  The collector which is the default has to be the
> > best over a variety of metrics.
> >
> >> 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.
> >
> > Okay, so we could perhaps say (to J.R. Blogger) that we are not
> > surprised to find some throughput degradation in Java applications,
> > but in general, over a balance of criteria, G1 is likely to be a
> > better default, especially for large and long-lived programs.
> >
> > And we need to prepare the ground when JDK9 is released for people who
> > will immediately measure it with their favourite benchmark.  At least
> > explain to them that they should use the same GC for the comparison.
> >
> > Andrew.
>
>


-- 
Jungwoo Ha | Java Platform Team | jwha at google.com