G1 Region size info

[Thomas Schatzl]

Hi Gopal,

On Wed, 2017-02-08 at 16:28 +0000, Gopal, Prasanna CWK wrote:
> Hi Thomas
> 
> Thanks for your reply. We have following G1 configuration at the
> moment 
> 
> 
[...]
> Apart from these parameters, can we try another parameter to make the
> evacuation more aggressive? 
> 

It premature to try to make the collection more aggressive if e.g.
there is not anything worth to reclaim anyway.

> 
> -XX:G1MixedGCLiveThresholdPercent=85   

You could increase that. Look at your "post-marking" output and see if
there would be a significant additional amount of space to be
reclaimed.

Be aware that evacuating e.g. 90% full regions might be slow (and you
will only ever get 10% back).

Another option would be decreasing G1HeapWastePercent (not sure what
the default is, but it is pretty low already iirc), which would more
thoroughly clean out the collection set.

Also being more aggressively evacuating may not help e.g. for problems
with humongous objects/region fragmentation.

If there is a lot of unusable memory at the end of humongous objects
(check the "post-marking" output) actually decreasing region size might
help.

Eg.
###   HUMS 0x000000079e000000-
0x00000007a0000000   33554432   33554432   33554432     501904008.8
###   HUMC 0x00000007a0000000-
0x00000007a2000000    2367536    2367536    2367536       2526909.9

indicates that that humongous object basically wastes 31M out of 64M,
which is really bad if there are more of those hanging around.

I do not see any good solution with g1 on 7u other than increasing the
heap if that large a region size is necessary. If these humongous
objects are short-lived (and do not have j.l.O. elements), then
upgrading to 8u/9 may help (i.e. if eager reclaim can clean out large
objects regularly and asap).

Btw, the log also indicates 4121M out of 6144M of live data (around
3800M after hypothetically cleaning out all of old gen). This amount of
live data may already beyond the comfort zone of most collectors. Only
Jdk9 improves a bit in these situations, but not sure if the changes
apply here.

Not sure if decreasing heap region size will help a lot either as the
heap is already relatively full.

> -XX:InitiatingHeapOccupancyPercent=60 ==> we have experimented with
> less values , it is just making the concurrent cycle without claiming
> any significant. 

Actually even 60% seems to much. If your average live set size is at
61% already like in the log, G1 already runs marking all the time.

> -XX:MaxGCPauseMillis=500
> 
> Our object allocation rate is very high, before increasing the memory
> can we try any other parameter which can make the evacuation more
> aggressive? Appreciate your help. Please do let me know, if you need
> any more information. 

Thanks,
  Thomas