Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled

JVM JIT 生成已编译的代码并将其存储在称为 CodeCache 的内存区域中。大多数平台上 CodeCache 的默认最大大小为 48M。如果任何应用程序需要编译大量方法导致大量编译代码，则此 CodeCache 可能已满。当它变满时，编译器被禁用以停止任何进一步的方法编译，并记录如下消息：

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
Code Cache  [0xffffffff77400000, 0xffffffff7a390000, 0xffffffff7a400000) total_blobs=11659 nmethods=10690 adapters=882 free_code_cache=909Kb largest_free_block=502656

当这种情况发生时，JVM 可能会调用此空间的清扫和刷新，以在 CodeCache 中腾出一些空间。有一个 JVM 选项UseCodeCacheFlushing可用于控制 Codeache 的刷新。启用此选项后，JVM 会调用紧急刷新，丢弃旧的一半已编译代码(nmethods)，以便在 CodeCache 中留出可用空间。此外，它会禁用编译器，直到可用空间超过配置的CodeCacheMinimumFreeSpace。CodeCacheMinimumFreeSpace选项的默认值为500K。

使用代码缓存刷新在 JDK6 中默认设置为 false，从 JDK7u4 开始默认启用。这实质上意味着在 jdk6 中，当 CodeCache 变满时，它不会被清扫和刷新，并禁用进一步的编译，而在 jdk7u+ 中，当 CodeCache 变满时会调用紧急刷新。默认情况下启用此选项会使一些与代码缓存刷新相关的问题在 jdk7u4+ 版本中可见。以下是 jdk7u4+ 中关于 CodeCache 刷新的两个已知问题：

1. 即使在紧急刷新后 CodeCache 占用率下降到几乎一半后，编译器也可能无法重新启动。
2. 紧急刷新可能会导致编译器线程的 CPU 使用率过高，从而导致整体性能下降。

这个性能问题，以及编译器没有重新启用的问题已经在 JDK8 中得到解决。要在 JDK7u4+ 中解决这些问题，我们可以使用ReservedCodeCacheSize选项增加代码缓存大小，方法是将其设置为大于编译代码占用空间的值，以便 CodeCache 永远不会变满。另一个解决方案是使用 -XX:- UseCodeCacheFlushing JVM 选项禁用 CodeCache Flushing 。

上述问题已在 JDK8 及其更新中得到修复。以下是在 jdk8 和 8u20 中修复的解决这些问题的错误列表：

* JDK-8006952：CodeCacheFlushing degenerates VM with过多的 codecache freelist 迭代(在 8 中修复)
* JDK-8012547：代码缓存刷新可能在没有完成内存回收的情况下卡住(8 中修复)
* JDK-8020151：PSR:PERF 填充代码缓存时性能大幅下降(8 中修复)
* JDK-8029091 计算错误代码缓存清除间隔(在 8u20 中固定)
* 8027593：从 hs25 b111 开始的受限代码缓存的性能下降(在 8 中修复)

JVM JIT generates compiled code and stores that in a memory area called CodeCache. The default maximum size of the CodeCache on most of the platforms is 48M. If any application needs to compile large number of methods resulting in huge amount of compiled code then this CodeCache may become full. When it becomes full, the compiler is disabled to stop any further compilations of methods, and a message like the following gets logged:

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
Code Cache [0xffffffff77400000, 0xffffffff7a390000, 0xffffffff7a400000) total_blobs=11659 nmethods=10690 adapters=882 free_code_cache=909Kb largest_free_block=502656

When this situation occurs, JVM may invoke sweeping and flushing of this space to make some room available in the CodeCache. There is a JVM option UseCodeCacheFlushing that can be used to control the flushing of the Codeache. With this option enabled JVM invokes an emergency flushing that discards older half of the compiled code(nmethods) to make space available in the CodeCache. In addition, it disables the compiler until the available free space becomes more than the configured CodeCacheMinimumFreeSpace. The default value of CodeCacheMinimumFreeSpace option is 500K.

UseCodeCacheFlushing is set to false by default in JDK6, and is enabled by default since JDK7u4. This essentially means that in jdk6 when the CodeCache becomes full, it is not swept and flushed and further compilations are disabled, and in jdk7u+, an emergency flushing is invoked when the CodeCache becomes full. Enabling this option by default made some issues related to the CodeCache flushing visible in jdk7u4+ releases. The following are two known problems in jdk7u4+ with respect to the CodeCache flushing:

1. The compiler may not get restarted even after the CodeCache occupancy drops down to almost half after the emergency flushing.
2. The emergency flushing may cause high CPU usage by the compiler threads leading to overall performance degradation.

This performance issue, and the problem of the compiler not getting re-enabled again has been addressed in JDK8. To workaround these in JDK7u4+, we can increase the code cache size using ReservedCodeCacheSize option by setting it to a value larger than the compiled-code footprint so that the CodeCache never becomes full. Another solution to this is to disable the CodeCache Flushing using -XX:-UseCodeCacheFlushing JVM option.

The above mentioned issues have been fixed in JDK8 and its updates. Here's the list of the bugs that have been fixed in jdk8 and 8u20 that address these problems:

* JDK-8006952: CodeCacheFlushing degenerates VM with excessive codecache freelist iteration (fixed in 8)
* JDK-8012547: Code cache flushing can get stuck without completing reclamation of memory (fixed in 8)
* JDK-8020151: PSR:PERF Large performance regressions when code cache is filled (fixed in 8)
* JDK-8029091 Bug in calculation of code cache sweeping interval (fixed in 8u20)
* 8027593: performance drop with constrained codecache starting with hs25 b111 (fixed in 8)