什么是ReservedCodeCacheSize 和InitialCodeCacheSize？

发布于 2024-12-05 16:01:27 字数 327 浏览 3 评论 0原文

有人可以解释一下 JVM 选项 ReservedCodeCacheSize 和 InitialCodeCacheSize 是什么吗？具体来说我什么时候/为什么要改变它？我如何确定合适的尺寸？

这就是文档所说的：

-XX:ReservedCodeCacheSize=32m 保留代码缓存大小（以字节为单位）- 最大代码缓存大小。 [Solaris 64 位、amd64 和 -server x86：2048m；在 1.5.0_06 及更早版本中，Solaris 64 位和 and64：1024m。]

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

旧夏天 2024-12-12 16:01:27

ReservedCodeCacheSize（和InitialCodeCacheSize）是 Java Hotspot VM 的（即时）编译器的一个选项。基本上它设置了编译器代码缓存的最大大小。

缓存可能已满，这会导致如下警告：

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  [0x000000010958f000, 0x000000010c52f000, 0x000000010c58f000)
 total_blobs=15406 nmethods=14989 adapters=362 free_code_cache=835Kb largest_free_block=449792

如果随后出现 Java HotSpot(TM) 客户端 VM 警告：发生异常 java.lang.OutOfMemoryError 将信号 SIGINT 分派给处理程序，情况会更糟 - VM 可能需要被强制终止。

什么时候设置这个选项？

当 Hotspot 编译器无法减少 JVM 所需的内存时
（因此存在 JIT 编译器失败的风险），

通常您不会更改此值。我认为默认值非常平衡，因为此问题仅在极少数情况下发生（根据我的经验）。

ReservedCodeCacheSize (and InitialCodeCacheSize) is an option for the (just-in-time) compiler of the Java Hotspot VM. Basically it sets the maximum size for the compiler's code cache.

The cache can become full, which results in warnings like the following:

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  [0x000000010958f000, 0x000000010c52f000, 0x000000010c58f000)
 total_blobs=15406 nmethods=14989 adapters=362 free_code_cache=835Kb largest_free_block=449792

It's much worse when followed by Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated.

When to set this option?

when having Hotspot compiler failures
to reduce memory needed by the JVM (and hence risking JIT compiler failures)

Normally you'd not change this value. I think the default values are quite good balanced because this problems occur on very rare occasions only (in my experince).

回复收藏 0 原文

黑凤梨 2024-12-12 16:01:27

@jeha 回答了我想从这个问题中知道的所有内容，除了将参数设置为什么值之外。由于我没有编写正在部署的代码，因此我对其内存占用没有太多了解。

但是，您可以使用 jconsole 附加到正在运行的 java 进程，然后使用“内存”选项卡找出代码缓存大小。为了完整起见，步骤如下（Linux VM 环境，尽管我确信其他环境也类似）：

在您的计算机上启动 jconsole
找到正确的进程 ID 并将 jconsole 附加到它（这将需要一些时间）
导航到“ “内存”选项卡
从“图表：”下拉列表中，选择“内存池“代码缓存””
同样，屏幕刷新可能需要一些时间，然后您应该看到类似以下内容的内容：
如您所见，我的代码缓存使用了大约 49 MB。此时我仍然使用文档（和@jeha）所说的默认值 48 MB。这对我增加设置来说无疑是一个很大的动力！
本。
<小时>
默认情况下 1024 MB 可能有点过了，但默认情况下 48 MB 似乎还不够......

回复收藏 0 原文

白云不回头 2024-12-12 16:01:27

Indeed 工程团队提供了很好的学习经验，以及他们在迁移到 jdk 8 时遇到的挑战。

http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/

结论：Jdk 8 需要比 JDK 7 更多的代码缓存

JRE 8 的默认代码缓存大小约为 250MB，大约比 JRE 7 的默认 48MB 大五倍。我们的经验是，JRE 8 需要额外的代码缓存。到目前为止，我们已经将大约十个服务切换到 JRE 8，所有这些服务使用的代码缓存比以前多了大约四倍。

回复收藏 0 原文

无人问我粥可暖 2024-12-12 16:01:27

来自https://blogs.oracle.com/poonam/entry/why_do_i_get_message：

以下是 jdk7u4+ 中与 CodeCache 刷新相关的两个已知问题：
紧急刷新后，即使 CodeCache 占用率下降到接近一半，编译器也可能无法重新启动。
紧急刷新可能会导致编译器线程的 CPU 使用率过高，从而导致整体性能下降。
这个性能问题以及编译器无法再次重新启用的问题已在 JDK8 中得到解决。为了解决 JDK7u4+ 中的这些问题，我们可以使用 ReserveCodeCacheSize 选项来增加代码缓存大小，方法是将其设置为大于编译代码占用空间的值，以便 CodeCache 永远不会变满。另一个解决方案是使用 -XX:-UseCodeCacheFlushing JVM 选项禁用 CodeCache Flushing。
上述问题已在 JDK8 及其更新中得到修复。

因此，对于在 JDK 6（禁用代码刷新）和 7 上运行的系统，该信息可能值得一提。

回复收藏 0 原文

~没有更多了~