G1 feedback: frantic GC cycles

[Simone Bordet]

Hi,

On Thu, May 12, 2011 at 16:52, Tony Printezis <tony.printezis at oracle.com> wrote:
> On 5/4/2011 11:28 AM, Simone Bordet wrote:
>> Would it be possible that resizing of the young generation is way too
>> aggressive in G1 ?
>
> It might, if the behavior of the application is erratic. But what I was
> seeing in the log was way too aggressive. Also, we're currently looking at
> an issue that might be related. Can you also add +DisableExplicitGC just in
> case (this will make System.gc() noops).

It is already on.

>>> -XX:InitiatingHeapOccupancyPercent=60
>>
>> Tony, would you mind to explain this parameter ?
>
> It tells G1 to start a marking cycle when the heap is 60% full after a GC.

This is related to the full heap ?
E.g. if young size == old size, and old is 35% full of live objects,
does that mean that a concurrent GC starts when young is only 25% full
?

I am trying to compare this to CMSInitiatingOccupancyFraction, which -
if I am right - refers only to old generation occupation percentage.

I had the chance to run with -XX:-UseAdaptiveSizePolicy, although I
have not used the application as heavily as in previous days when I
reported the logs, and I have not experienced the frantic cycles
anymore.
I see very regular logs where the young GC starts when I have 512
blocks full and ends with 5-15 blocks full, for example:

{Heap before GC invocations=309 (full 48):
 garbage-first heap   total 1048576K, used 868128K
[0x00000000b0000000, 0x00000000f0000000, 0x00000000f0000000)
  region size 1024K, 512 young (524288K), 4 survivors (4096K)
 compacting perm gen  total 137216K, used 137168K [0x00000000f0000000,
0x00000000f8600000, 0x0000000100000000)
   the space 137216K,  99% used [0x00000000f0000000,
0x00000000f85f40b8, 0x00000000f85f4200, 0x00000000f8600000)
No shared spaces configured.
2011-05-12T16:53:26.011+0200: [GC pause (young), 0.11289800 secs]
...
Heap after GC invocations=310 (full 48):
 garbage-first heap   total 1048576K, used 348126K
[0x00000000b0000000, 0x00000000f0000000, 0x00000000f0000000)
  region size 1024K, 4 young (4096K), 4 survivors (4096K)
 compacting perm gen  total 137216K, used 137168K [0x00000000f0000000,
0x00000000f8600000, 0x0000000100000000)
   the space 137216K,  99% used [0x00000000f0000000,
0x00000000f85f40b8, 0x00000000f85f4200, 0x00000000f8600000)
No shared spaces configured.
}

and the next young GC again has 512 blocks full.
I'll confirm this when I have the chance to run the application more
heavily in the next days, but so far looks good.

Thanks !

Simon
-- 
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