Java 从 11.0.11 更新到 11.0.13 更改了 JVM 代码缓存行为，导致更多进程 CPU 使用率和奇怪的分析 nmethods 内存使用率

Question

我们使用 Java 11.0.11 和 -XX:ReservedCodeCacheSize=375m 运行一个复杂的集群应用程序，并 24/7 附加相同的负载配置文件，无需任何重新启动。

在我们将 AdoptOpenJDK jdk-11.0.11+9 更新为 Temurin jdk-11.0.13+8 后，两者都使用 -XX:ReservedCodeCacheSize=375m，在我们的应用程序中没有任何代码更改，只是更新 Java，我们注意到以下变化：

• 在具有 32 个 vCPU、256GB RAM 和 -Xms160G -Xmx160G 的AWS r5.8xlarge上运行时，进程 CPU 使用率从约 30% 增加到约 35%，这可能是由于 JVM Sweeper 线程活动较高造成的（见下文）
• 与 Java 11.0.11 一样，JVM CodeHeap“非分析 nmethods”（C2 优化代码）已填满（已用 = 176 MB，最大 = 184 MB），这是预期的，但
• JVM CodeHeap“分析的 nmethods”（C1 优化代码）在进程重新启动后不久就被填满（146 MB 已用内存，184 MB 最大内存），并且在仅仅 15 分钟后就减少到约 40 MB，并且从那时起一直保持在这个水平（ 24小时）

Java 11.0.13 + -XX:ReservedCodeCacheSize=375m，时区=UTC+1

与

Java 11.0.11 + -XX:ReservedCodeCacheSize=375m，时区=UTC+1

下一步是将 -XX:ReservedCodeCacheSize 增加到 512m，但大约 3 小时后，JVM CodeHeap“分析的 nmethods”（C1 优化代码）再次减少到大约 50 MB，甚至随着时间的推移进一步减少

Java 11.0.13 + -XX:ReservedCodeCacheSize=512m，时区=UTC+1

因此，我们决定将 -XX:ReservedCodeCacheSize 加倍到 1024m，并且在过去 7 天里，两个 CodeHeap 区域都保持稳定

• CodeHeap“非分析 nmethods”：405 MB 已用内存、405 MB 提交内存、508 MB 最大内存
• CodeHeap“分析的 nmethods”：258 MB 已用内存、258 MB 提交内存、508 MB 最大内存

Java 11.0.13 + -XX:ReservedCodeCacheSize=1024m 稳定运行一周，timezone=UTC+1

我们在不同节点以及一个节点上尝试了这些更改，结果始终是可重现的。

---

当 -XX:ReservedCodeCacheSize=375m 时，Linux perf 工具显示 Sweeper 线程的 CPU 使用率很高，在 1024m 时完全消失。

perf record -F 99 --output=perf-375m-uptime-21hours.data -ag -p <PID> sleep 60

+    4.82%     0.00%  Sweeper thread   libpthread-2.17.so                                                  [.] start_thread
+    4.82%     0.00%  Sweeper thread   libjvm.so                                                           [.] thread_native_entry
+    4.82%     0.00%  Sweeper thread   libjvm.so                                                           [.] Thread::call_run
+    4.82%     0.00%  Sweeper thread   libjvm.so                                                           [.] JavaThread::thread_main_inner
+    4.82%     0.00%  Sweeper thread   libjvm.so                                                           [.] NMethodSweeper::sweeper_loop
+    4.82%     0.00%  Sweeper thread   libjvm.so                                                           [.] NMethodSweeper::possibly_sweep
+    4.79%     0.03%  Sweeper thread   libjvm.so                                                           [.] NMethodSweeper::sweep_code_cache
+    4.24%     0.03%  Sweeper thread   libjvm.so                                                           [.] NMethodSweeper::process_compiled_method
+    4.05%     0.00%  C2 CompilerThre  libpthread-2.17.so                                                  [.] start_thread
+    4.05%     0.00%  C2 CompilerThre  libjvm.so                                                           [.] thread_native_entry
+    4.05%     0.00%  C2 CompilerThre  libjvm.so                                                           [.] Thread::call_run
+    4.05%     0.00%  C2 CompilerThre  libjvm.so                                                           [.] JavaThread::thread_main_inner
+    4.05%     0.00%  C2 CompilerThre  libjvm.so                                                           [.] CompileBroker::compiler_thread_loop
+    4.04%     0.00%  C2 CompilerThre  libjvm.so                                                           [.] CompileBroker::invoke_compiler_on_method
+    4.03%     0.00%  C2 CompilerThre  libjvm.so                                                           [.] C2Compiler::compile_method
+    4.03%     0.00%  C2 CompilerThre  libjvm.so                                                           [.] Compile::Compile
+    3.53%     0.68%  Sweeper thread   libjvm.so                                                           [.] CompiledMethod::cleanup_inline_caches_impl

因此，Java 11.0.13 和 -XX:ReservedCodeCacheSize=1024m 的 CPU 使用率与 Java 11.0.11 和 -XX:ReservedCodeCacheSize=375m 相同或稍好一些

---

在我们的调查过程中，没有打印任何有用的日志行，例如，我们期望看到类似“CodeCache 已满。编译器已被禁用”的内容。

jcmd <PID> VM.log what=codecache=info,sweep*=trace decorators=time,uptime,level,tags output=codecache-sweep.log

图中所有图表均使用UTC+1时区。日志文件中的所有时间戳均为 UTC+0。

颜色只是为了显示随时间的变化。

codecache-sweep-375m.log.0 有趣的开始时间的正则表达式：\[2021-11-22T10:2[5-9].+'profiled nmethods'- 每分钟大量扫描

codecache-sweep-512m.log.0 有趣的开始时间的正则表达式：\[2021-11-22T13:3[6-9].+'profiled nmethods- 每分钟仍然有很多扫描。

codecache-sweep-1024m.log 一切正常，没什么特别的，平均每天扫描 5 次

---

请注意，Java 11.0.12（发行说明）中对代码缓存/代码堆组件进行了很多更改：搜索CodeHeap

• JDK-8223444 改进 CodeHeap 可用空间管理
• JDK-8231460 较大空闲块的性能问题 (CodeHeap)
• ...

您能否帮助我们理解 CodeHeap 'profiled nmethods' 缩小到非常低的水平并且不再增加的原因和含义？

---

更新2021-12-28

使用 -XX:ReservedCodeCacheSize=375m 并jcmd <pid> Compiler.CodeHeap_Analytics aggregate每 5 秒重新运行 11.0.11 和 11.0.13，以便为 OpenJDK 团队收集更多数据。

包含日志和 CodeHeap_Analytics 数据的 zip

仍然可以重现更高的代码扫描器调用（使用 11.0.13）。

Java 11.0.11 2h uptime, sweeper invocations:
grep -F '[codecache,sweep,start]' codecache-sweep-11.0.11_375m.log* | wc -l
14.458

Java 11.0.13 2h uptime, sweeper invocations:
grep -F '[codecache,sweep,start]' codecache-sweep-11.0.13_375m.log* | wc -l
41.901

有关详细统计信息，请打开zip中的 jcmd_compiler_codeheap_analytics_aggregate 文件。

Answer 1

这是我在 OpenJDK 邮件列表上的评论的简短摘要。我最后一次评论是在 2022 年 1 月 3 日。

• 没有迹象表明观察到的行为是由错误引起的。
• 我看到的所有日志和痕迹都显示正常运行。
• 很可能 CodeHeap 大小（在 JVM 升级之前）已优化至最大值。
• JIT 代码生成中的一些微小变化，例如生成的代码大小稍大，已将 CodeHeap 管理推向了临界点的不利一面。
• 结果很明显：无法达到稳定状态。有永久性的代码扫描和重新编译。
• 随着时间的推移，分析方法的 CodeHeap 段会被耗尽，因为所有 nmehtod 都变得足够热，可以在最高优化级别进行编译。

补救措施？这听起来很愚蠢，但同时又很明显：增加 CodeCache 空间。由于使用足够大的 CodeCache 才能达到稳定状态，因此禁用分段代码缓存可能会有所帮助。