G1 feedback: frantic GC cycles

[Simone Bordet]

Hi,

On Sat, Apr 30, 2011 at 11:44, Igor Veresov <igor.veresov at oracle.com> wrote:
> It does look like we've filled about 1M before the next collection happened,
> which is the default size of a region. PrintHeapAtGC should give more
> details on how many regions are there in each portion of the heap.

I was able to experience another event of frantic GC cycles, for which
I attach the new log.
Same JDK version, same OS, command line options now are (after Igor's
suggestion):

-Xms1024m
-Xmx1024m
-Xmn512m
-XX:MaxPermSize=256m
-ea
-verbose:gc
-XX:+PrintGCDetails
-XX:+PrintHeapAtGC
-XX:+DisableExplicitGC
-XX:+PrintGCDateStamps
-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
-XX:+TieredCompilation
-XX:+PrintCommandLineFlags
-XX:+AggressiveOpts
-XX:ReservedCodeCacheSize=256m

I had a JVM warning that the code cache size was too small, so I increased it.

This time the frantic cycles started at around 16:16:13 (line 11958)
and lasted until 16:17:28 (roughly 75 seconds, end of file) and during
that time there have been ~200 GC cycles.
After that, G1 seemed to take a breath, it stayed quiet for few
seconds (say 20), then started another frantic moment that I have not
reported in the attached log, then went normal again.
During those frantic moments the application is unusable, but then it
becomes usable again when the frantic moment stops.

I must say that I never saw these frantic moments early in the JVM
uptime, but only after some hours of usage of the application, not
sure if it's relevant (I am guessing it may, since the JVM is adaptive
and gathers stats on GC activity).

I am not sure how exactly to interpret the +PrintHeapAtGC output, but
it does show lines such as the one below after a young generation GC:

region size 1024K, 0 young (0K), 0 survivors (0K)

I know G1 is experimental, but if you can provide some early Rosetta
stone to decrypt the GC output, will just be great :)

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: g1_spin_2.log.gz
Type: application/x-gzip
Size: 101908 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20110504/43285e12/g1_spin_2.log.gz>