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 刷新的两个已知问题:
- 即使在紧急刷新后 CodeCache 占用率下降到几乎一半后,编译器也可能无法重新启动。
- 紧急刷新可能会导致编译器线程的 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:
- The compiler may not get restarted even after the CodeCache occupancy drops down to almost half after the emergency flushing.
- 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)
相关文章
- 达摩院与国家气象中心共研AI算法,成功辅助预测广东省多地强对流天气
- 中国联通一季度净利润38.43亿元 同比增长21.4%
- 自动化是云原生应用程序安全的关键
- 充分发掘人工智能商业价值的十个关键角色
- AI到来,可能会给人类社会带来的影响
- 通过Hyper-V远程管理可在任何地方运行服务器
- 为什么要迁移到UCaaS?原因很多并且显而易见
- 欧洲人工智能法案即将出台,或影响全球科技监管
- 私有云并非万无一失 注意这些才能安心部署
- 千万数量级恶意地址拦截,TA究竟如何修炼成功?
- 人工智能只需进行脑部扫描即可预测你的政治意识形态
- CIO时代与工信部标准院合作推出信创体系认证培训
- 百年恒顺的数字化之路
- 阿里AI语音语义市场增速96%,远超传统语音厂商
- 锐捷极简光亮相高校信息化发展研讨会 聚焦智慧校园新基建
- 未来蓝牙市场稳步增长 蓝牙技术联盟持续发力
- 最大化使用托管数据中心的混合云方法
- SAP:携手合作伙伴,全面推动客户转型
- 锐捷网络:深耕生产网络应用场景,让工业互联网推进无忧
- 品质新生 创新再超越 锐捷网络发布智慧教室普教新品