Sudden permanent increase in Minor (ParNew) GC time, that only a stop-the-world System.gc() alleviates

[Pas]

Hello,

Long story short, Minor GC times jump from ~30ms to more than a second (and
increase to about 5 seconds), and only an explicit paralell Full GC can
whack it out of this madness. Interestingly it looks like this bug/feature
manifests when a big ~100+ MB byte[] object gets allocated, thus triggering
a CMS initial-sweep. (The CMS runs fine though, but the young gen
collections take forever.)

http://pastebin.com/RcBkCEEE (of course, if someone's interested I here's
the full 50 MBs of the otherwise rather predictable log, 2.9MB compressed
http://zomg.hu/work/wtf-gc.log.xz )

We're running the stock Oracle 1.6.0_37 64bit JVM, on a 8 core new Xeon
E3-something with plenty of RAM for the heap, with the following options:

-Xmx5128M
(-Xms5128M, though the linked gclog is without this)
-XX:NewSize=300m
-XX:MaxNewSize=300m
-XX:PermSize=64m
-XX:MaxPermSize=192m

-XX:+UseParNewGC
-XX:ParallelGCThreads=2
-XX:MaxTenuringThreshold=4
-XX:SurvivorRatio=3

-XX:+UseConcMarkSweepGC
-XX:+UnlockDiagnosticVMOptions
-XX:+CMSScavengeBeforeRemark
-XX:CMSInitiatingOccupancyFraction=65

-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintTenuringDistribution
-XX:+PrintGCDateStamps
-XX:PrintFLSStatistics=1
-Xloggc:/logs/gc.log
-verbose:gc

Has anyone experienced similar issues?

Thanks for your time,
Pas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20130127/ff4a9a83/attachment.html