The heap size difference among Parallel, CMS, and G1

[Thomas Schatzl]

Hi,

On Wed, 2017-12-20 at 15:47 +0800, Lijie Xu wrote:
> Hi All,
> 
> I'm testing the performance of Parallel, CMS, and G1. I found that
> their available heap sizes are different under the same -Xmx
> configuration.

  this is normal.

The different algorithms use different heap sizing heuristics. This is
both due to what the GCs allow (e.g. G1 allows very dynamic sizing of
generations while it is fixed for the others after startup) and work
(e.g. CMS may just need more space as it can not compact the old gen),
their target applications and other reasons.
Like some of the differences might just be because of timing in the
application, and there is a relatively large variation between runs. Or
nobody bothered to update these given a set of currently relevant
applications.

Since we usually do not change these heuristics in update releases,
they may reflect ideas from jdk8 or earlier (like March 2014). I
*think* maybe G1 got some re-tuning in the 8u40/60 (2015) timeframe.
But I am almost sure for the others heuristics were not updated for a
very long time (10 years, probably minimum).

Depending on your application they may or may not select the optimal
choices. Unless you can show on a large range of representative
applications that one or the other choice is better or worse, this is
not a bug :)

Since heap sizing has a huge impact on performance you might want to
make performance tests "out-of-the-box" (no settings at all) vs. (at
least) setting min and max heap to the same value to e.g. rule out
heap-sizing heuristics.

Be aware that some (popular) settings that make sense in some
collectors, may not do in others as they directly disable some
heuristics or just give completely non-representative results (like
e.g. fixing young gen size in G1)

Thanks,
  Thomas