JEP 248: Make G1 the Default Garbage Collector

[Vitaly Davidovich]

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


In any space that cares about performance (and latency, in particular),
high allocation rates are always a red flag and/or non-starter,
irrespective if they make it out of nursery or not; those allocations being
short lived just dampens the blow somewhat, but doesn't make it "alright".
IMHO, the "allocations are cheap" mantra that's been perpetuated for many
years now has caused more harm than good.  If javac could be made quicker
by allocating less without hampering readability/maintainability, that
would be a nice win.


On Thu, Jul 30, 2015 at 2:56 PM, <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!
>
> - Mark
>