JEP 248: Make G1 the Default Garbage Collector

[Andrew Dinn]

On 30/07/15 15:02, charlie hunt wrote:
> As an example, let’s contrast the two GC’s from a Java heap growth
> standpoint, Parallel GC will aggressively try to grow the Java heap
> to achieve throughput. G1 will grow the Java heap in reaction to
> meeting the pause time goal. In cases where the initial Java heap
> size differs from the max Java heap size, I have seen cases where
> Parallel GC will grow to the max Java heap size, yet G1 does not
> because G1 was able to meet the pause time goal without expanding to
> the max Java heap size.

I believe the ParallelGC behaviour is actually down to a bug in the GC
(one which Tony Printezis raised some time ago -- look for subject
containing "GCLocker blues" in the gc-dev archives from 27/06/2014
onwards). I believe the expansion arises from the fact that the GC keeps
calculating size targets on the assumption the heap is full even though
the GC has just run.

Anyway, whatever the cause I wrote a blog post about how to get round
this heap expansion behaviour in Parallel GC (it was very important for
us to be able to configure our OpenShift Java deployments to stick
within a certain footprint limit by default). The posts are available at


https://developerblog.redhat.com/2014/07/22/dude-wheres-my-paas-memory-tuning-javas-footprint-in-openshift-part-1/


https://developerblog.redhat.com/2014/07/22/dude-wheres-my-paas-memory-tuning-javas-footprint-in-openshift-part-2/

with the magic Parallel GC setting documented in part 2 as

  -XX:UseParallelGC \
  -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=40 \
  -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90

ParallelGC will actually respect the HeapFreeRatio settings (in this
case keep the excess pages trimmed to bewteen 20% and 40% of the live
heap) so long as you provide an over-generous time ratio setting (in
this case try to keep GC time down to 25% of mutation time!). The GC
doesn't ever actually risk hitting that time ratio target -- indeed in
my tests it was only a little bit over 1% (the default setting) even
with the very tight free limits of 20%-40%. Removing time ratio from the
calculation allowed the GC to apply the heap trimming heuristic correctly.

n.b. AdaptiveSizePolicyWeight is not that important -- it just says pay
more attention to recent GC stats (90%) over historic ones (10%).

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)