1

A few weeks ago we faced higher use of CPU after some days running our apps in Wildfly. Looking at Thread Dump, we find out that C2 Compiler Thread was the suspect.

Analising the JVM memory pool we realized that, while using Wildfly with 28 applications deployed, the 250m default ReservedCodeCacheSize JVM parameter was not enough. So we set it to 380m. Ok. After 3 weeks, we had no more problems.

All good? Not yet. The system is up and running after 3 weeks for now.

But every time we deployed a new version of some application (undeploy the .war a deploy the new one) the use of CodeCace increases. In fact, after the undeploy the CodeCache does not descrease. And after the deploy of the new version, the CodeCache increase. The use of CodeCache only increases. That is, then at some point, after several hotdeploys the memory for the CodeCache will reach the ReservedCodeCacheSize and we'll need to restart the Wildfly.

I know that Wildfly has no control over the CodeCache, that is all managed by the JVM.

What I'm wondering is, are there any configurations that may be useful in order to stop the CodeCache from hitting the maximum size?

thanks!

ethanxyz_0
  • 713
  • 12
  • 37
  • 2
    What JVM options are used? Check if `-XX:NmethodSweepActivity=100` makes difference. This should cleanup old compiled methods more agressively. – apangin Nov 22 '17 at 21:50
  • @apangin I use the OpenJDK 8u131. Although I found a lot of Google hits about `-XX:NmethodSweepActivity` can't find any Oracle documentation about this JVM Option. – ethanxyz_0 Nov 23 '17 at 02:54
  • 1
    open source, grep for the parameter, blame, acquire [bug number](https://github.com/dmlloyd/openjdk/commit/875c48fd421156d63bf9f3a6fb2ab6edc4ef4bae#diff-2263ce4157ef18f10ef6116df5de5d33) from commit, dig up [mailing list message](http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-August/011431.html) corresponding to bug number. That's the nature of many XX options. – the8472 Nov 23 '17 at 20:36
  • @the8472 yeah I found the sources before (very well documented in the source files btw). But my concern whether the lack of official documentation of these XX options (not the documented ones) may be considered experimental or not recommended by Oracle? – ethanxyz_0 Nov 24 '17 at 06:53
  • They are not *experimental* (those are hidden behind `UnlockExperimentalVMOptions`), but XX options are basically internal tuning knobs that are subject to change and not part of a stable interface. But they are exposed for a reason, the JVM devs know that sometimes it is necessary to turn those knobs. If you pass an unrecognized option the JVM quits and complains loudly by default (although that can be changed too), so you'll have to test for that when rolling out new JVM versions, but they're generally safe to use if you understand what they do and their non-stable, vendor-specific nature. – the8472 Nov 24 '17 at 20:41

0 Answers0