G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector]

[Jungwoo Ha]

On Thu, Jul 30, 2015 at 5:28 AM, Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:

> Hi Jungwoo,
>
>   just a few questions about your environment:
>
> On Thu, 2015-07-30 at 02:34 -0700, Jungwoo Ha wrote:
> > FYI, most of our users also can not use G1 because of the higher resource
> > usage.
> > That means more memory and more CPUs for GC.
> > We've seen GC CPUs grow by 3x when using G1.
>
> (Assuming you meant CPU usage here)
>

Yes. I meant GC CPU usages.


>
> Untuned or tuned G1? Vs. tuned or untuned CMS? On applications tuned for
> CMS?
>
>
Both tuned CMS and G1.


> Can you comment on the kind of applications (heap size, live set size,
> promotion rate, ...) etc?
>

Unfortunately, we don't have this data now.

> Though, we are able to change between Parallel and CMS without complaints.
> > Our users use shared machines, so any significant increase in CPU or
> memory
> > is not acceptable.
> > Rather tuning CMS to achieve latency goal is more feasible than using G1.
>
> What do you think, because there is more experience in tuning CMS in
> your company, or because it is inherently impossible to get close to
> CMS?
>

It is true that most of our engineers are more trained with CMS tuning.
However, I think there are inherent overhead for G1 to maintain RSet/CSet
and nepotism issues.
But, we haven't really measured how significant those costs are.


> > Also, just using CMS with default settings perform much better than G1.
>
> These applications, were they tuned for CMS (almost no objects escaping
> into old gen, very low fragmentation in old gen)?
>

We have variety of users from heavily tuned to zero tuned jobs.
Most of them when switching from Parallel to CMS has almost no complaints.
(Though we have modifications on CMS to make it safer which we love to send
it to you guys)


> What do you do in case of fragmention, or are long pauses (even with
> parallelization they tend to get long on larger heaps) acceptable in
> your case?
>

It is hard to say because there are so many different jobs.
One thing about fragmentation is that we have incremental compaction
implemented on remark phase.
But our users prefer to tune YG/OG size, and rely on parallel full GC for
the compaction rather than the increased remark time.

--Jungwoo