JEP 248: Make G1 the Default Garbage Collector

Thomas Schatzl thomas.schatzl at
Wed Aug 12 11:43:32 UTC 2015

Hi all,

On Thu, 2015-07-30 at 11:56 -0700, mark.reinhold at wrote:
> 2015/7/30 11:04 -0700, charlie.hunt at
> > ...
> > 
> > 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).
> If you mean to imply that high allocation rates and short lifetimes are,
> necessarily, signs of a poorly-written application then I'll have to
> disagree.  Sure, these things can be done to extremes, but I don't think
> javac does that and I'd hate to see it re-engineered to "improve" these
> particular metrics.  It might be better just to change javac's launcher
> to specify the Parallel GC, since this is most definitely an application
> for which pause times are irrelevant.
> >        Performance of javac is certainly one we want to pay close
> > attention due to its impact to the developer use case.
> No argument there!

Observations seem to point to that part of the problem is the high rate
of exceptions javac throws, around 60k exceptions per second (with -XX:

Not sure why javac needs to throw so many Exceptions, but it does not
seem to treat Exceptions as something exceptional... this is a known
performance issue with G1, see .

Parallel GC and others have special inlined code for this case, G1 does
not at this time. One workaround is to specify
-XX:-StackTraceInThrowable for now. At least it seems to improve G1
performance here in a few cursory runs.

The javac code may hit other special cases; it does not seem to be
really GC _pause_ related, as the same issue exists when running with
heap sizes that cause almost no GCs.

There is to track this


More information about the hotspot-dev mailing list