JEP 248: Make G1 the Default Garbage Collector

[Thomas Schatzl]

Hi all,

On Thu, 2015-07-30 at 11:56 -0700, mark.reinhold at oracle.com wrote:
> 2015/7/30 11:04 -0700, charlie.hunt at oracle.com:
> > ...
> > 
> > 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:
+TraceExceptions).

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
https://bugs.openjdk.java.net/browse/JDK-8028337 .

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 https://bugs.openjdk.java.net/browse/JDK-8132937 to track this
issue.

Thanks,
  Thomas