G1 eden resizing behaviour ?

[Simone Bordet]

Hi,

I observed the following behaviour in G1 and I would like some
feedback with respect to whether it is right/expected/known or not.

I have an application that allocates about 500-700 MiB/s, with a
promotion rate of about 5-7 MiB/s on a 32 GiB heap.
>From time to time, G1 performs a marking and then mixed GCs.

During the young GC (not mixed) that follows the end of the marking
phase, the eden is reduced to a very small size, for example:

2014-12-05T04:47:39.528-0800: 5054.135: [GC concurrent-cleanup-end,
0.0009276 secs]
2014-12-05T04:47:53.949-0800: 5068.556: [GC pause (G1 Evacuation Pause) (young)
   [Eden: 12.6G(12.6G)->0.0B(880.0M) Survivors: 768.0M->752.0M Heap:
26.8G(32.0G)->14.2G(32.0G)]
 [Times: user=3.79 sys=0.05, real=0.22 secs]

In the example above the Eden is shrunk from 12.6G to 880M.

G1 then keeps the eden small for the mixed GCs that follow.
After the mixed GCs have finished, young GCs are performed again,
which eventually re-grow the eden to a size similar to what was before
being shrunk.

In my case, in normal young GC regime, the young GCs happens more or
less every 15-20s, while during the mixed GC and for few young GCs
that follow they happen every about 2s.

Now, this behaviour can be explained by the fact that, in order to
make room for the old regions to be evacuated, and yet still stay
within the pause goal, less eden regions need to be taken into account
for the evacuation. Since the allocation rate does not change, less
eden regions cause more frequent GCs.

I am wondering whether this behaviour is right/expected/known, and
what effects it has on the pause time prediction logic (e.g. mixed GCs
times are not taken into account) as well as on the early promotion of
objects from eden.

I can provide GC logs and command line options if required.

Thanks !

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz