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

[Srinivas Ramakrishna]

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/2d27ac13/attachment.html>