Seeking answer to a GC pattern

[Jun Zhuang]

Hi Srinivas,

Thanks for your suggestion. I ran test with following parameters:

-server -XX:+UseCompressedOops -XX:+TieredCompilation -XX:ReservedCodeCacheSize=64m -XX:+UseCodeCacheFlushing -XX:+PrintTenuringDistribution -Xms2g -Xmx2g -XX:MaxPermSize=256m -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=6 -XX:-UseAdaptiveSizePolicy -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=2

But the -XX:MaxTenuringThreshold=2 setting does not seem to help anything. I am still seeing similar GC pattern as with the +AlwaysTenure, actually the young GC time is higher with MTT=2 (getting to 0.5 secs vs. 0.25 with AlwaysTenure).

Unless anyone else can provide another theory, I am convinced that nepotism is at play here. Changing the java startup parameters can only get me so far, dev will have to look at the code and see what can be done on the code level.

Thanks,
Jun

From: Srinivas Ramakrishna [mailto:ysr1729 at gmail.com]
Sent: Thursday, November 19, 2015 8:09 PM
To: Jun Zhuang <jun.zhuang at hobsons.com>
Cc: hotspot-gc-use at openjdk.java.net
Subject: Re: Seeking answer to a GC pattern

Use -XX:MaxTenuringThreshold=2 and you might see better behavior that +AlwaysTenure (which is almost always a very bad choice). That will at least reduce some of the nepotism issues from +AlwaysTenure that Thomas mentions. MTT > 2 is unlikely to help at your current frequency of minor collections since the mortality after age 1 is fairly low (from your tenuring distribution). Worth a quick test.

-- ramki

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20151120/974ec23d/attachment.html>