Help processing G1GC logs (visualization tools) - also, mysterious great performance after inexplicable full GC?

[Simone Bordet]

Hi,

On Tue, Oct 16, 2012 at 2:54 PM, Aaron Daubman <daubman at gmail.com> wrote:
> Greetings,
>
> I recently switched to trying G1GC for several webapps and am trying
> now to make sense of the GC behavior.
> I have a few hopefully not-too-newbie questions:
>
> 1) Is there any up-to-date documentation on tuning G1GC? (many
> articles about it seem to be pre-7u4 where there were apparently more
> experimental flags available for tuning). Also, is this currently the
> full set of flags available:
> http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html#G1Options

Perhaps most up to date information is from the JavaOne sessions just held.
See in particular:
https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=7236
https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=6583

> 4) In one webapp, the constant reason for frequent GCs is listed by
> VisualVM as "G1: humongous allocation attempt". However, searching to
> try and figure out what this means results in only a very few bug
> entries (e.g. 7018286) that do not explain at all what this means, or
> what the threshold for being declared 'humongous' is - were can I find
> out more about this reason for minor GC?

Humongous allocation means an allocation for a large object (a
"humongous object").
Normally these are large byte[], or objects that contain large byte[].

In G1, I believe that "humongous" is when the size is greater than
half a region, which by default are 1 MiB, but not 100% sure.

> 5) I think I am perhaps just missing something given the lack of
> capability of the current suite of tools, however this one really
> bothers/intrigues me.
> One webapp where I switched to G1GC does quite poorly (somewhat
> inexplicably) for 12 or so hours (in terms of response times). This
> app has a med/large (16G) heap size, and typically runs at 1/2 to 1/4
> heap utilization. On occasion, even though overall heap utilization is
> below 40%, there will occur a (I've only ever seen single) major GC,
> and, without explanation, the application runs with order-of-magnitude
> better performance after this (heap utilization remains about 40%
> after major GC... eden and old commit size go up a small amount,
> nothing else changes that I can see). What would cause this markedly
> better performance after a major GC, and how can I dig in to this
> better?
> (I am frustrated, since it seems I should be able to figure out what
> JVM flags to use that would cause performance to be always as good as
> it is after the mysterious full GC, but I haven't been able to figure
> anything out so far).

Please record logs with the flags suggested in the 2 presentations I
linked above.
In particular, I use:
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintAdaptiveSizePolicy

Once you have the log, attach it here, and hopefully someone will look at it.

Keep in mind that G1 is still "young" and while it will be the future,
today it may not be up to par with the other collectors.

Simon
-- 
http://cometd.org
http://webtide.com
Developer advice, services and support
from the Jetty & CometD experts.
----
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