G1 issue: falling over to Full GC

[Simone Bordet]

Hi,

On Fri, Nov 2, 2012 at 12:04 AM, Andreas Müller
<Andreas.Mueller at mgm-tp.com> wrote:
> No, I haven't tried that. I usually tuned the heap sizes first using ParallelGC (-XX:-UseAdaptiveSizePolicy) or ParNewGC and then kept them when I switched to CMS, because I had found that this gave me the most robust GC behavior. So far, I haven't been convinced that heap size automatism delivers the best results. Usually survivor spaces are too small and promotion rates too high when you use them. They are good for reasonable out-of-the-box behavior though.
> How come the heap size settings worked well in my good case?

My experience so far is that G1 works better when I don't specify
young gen sizes. I got weird behaviors when I tried (especially with
older G1 versions).
Also, G1 is different from other collectors in the way it treats
generations, so the logic that applies to the other collectors does
not necessary apply to G1.

>>No. In CMS the threshold was for the old generation, in G1 is for the whole heap. 80% is probably a bit too high.
> I suspected that. But when you use the default (45) and your live heap is 50% you will have the concurrent thread running all the time. Does this make sense?

Sure, and that's why you need to tune it and make it 60%, for example.
With 80% you may risk that a concurrent marking does not end in time
(this can be detected from the logs).

Will try to have a look at your logs tomorrow.

Simon
-- 
http://cometd.org
http://webtide.com
Developer advice, training, 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