Cost of single-threaded nmethod hotness updates at each safepoint (in JDK 8) (original) (raw)

Vitaly Davidovich vitalyd at gmail.com
Fri Jul 31 22:10:51 UTC 2015

Yes, I misremembered thinking turning off tiered disabled sweeps at safepoints; sorry for the noise.

sent from my phone On Jul 31, 2015 6:04 PM, "Srinivas Ramakrishna" <ysr1729 at gmail.com> wrote:

Hi Bernd -- It doesn't seem coupled to GC; here's an example snapshot: sun.ci.codeCacheCapacity=13041664 sun.ci.codeCacheMaxCapacity=50331648 sun.ci.codeCacheMethodsReclaimedNum=4281 sun.ci.codeCacheSweepsTotalNum=409 sun.ci.codeCacheSweepsTotalTimeMillis=1541 sun.ci.codeCacheUsed=10864704 sun.gc.collector.0.invocations=6319 sun.gc.collector.1.invocations=6 BTW, to a question of Vitaly's on this thread earlier, this code executes irrespective of whether you are running tiered or not (the above is from tiered explictly off -- earlier ones were with tiered on --, yet note the excessive time in the stack walk as part of this code in JDK 8): [mark nmethods, 0.0171828 secs] On a similar note (and to Vladimir's earlier note of turning off code cache flushing) and with the understanding that there were lots of changes related to tiered compilation and code cache flushing between 7 ad 8, turning on Tiered in 7 leads to the occasional (rare) long safepoint for the stack walks, but else not. And finally the same issue must exist in 9 as well, albeit based on code inspection, not running with JDK 9 yet. Have a good weekend! -- ramki On Fri, Jul 31, 2015 at 2:44 PM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:

Am Fri, 31 Jul 2015 12:07:18 -0700 schrieb Srinivas Ramakrishna <ysr1729 at gmail.com>:

> sun.ci.codeCacheSweepsTotalNum=58 ... > Notice that the code cache usage is less that 35 MB, for the 240 MB > capacity, yet it seems we have had 58 sweeps already I would also be interested in what causes this. Is this caused by System.gc maybe? (we do see sweeps and decreasing code cache usage on systems where no pressure should exist). Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150731/3f5bf99a/attachment.html>

More information about the hotspot-compiler-dev mailing list