(original) (raw)

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@zusammenkunft.net> wrote:

Am Fri, 31 Jul 2015 12:07:18 -0700
schrieb Srinivas Ramakrishna <ysr1729@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