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

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 清扫线程活动引起的（见下文）
• JVM CodeHeap 'non-profiled nmethods'（C2 优化代码）已填满（使用=176 MB，最大=184 MB），与 Java 11.0.11 一样，这是预期的但是
• JVM CodeHeap 'profiled nmethods'（C1 优化代码）已填满（146 MB 已使用 memory，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 'profiled nmethods'（C1 优化代码）再次减少到 50 MB，甚至随着时间的推移进一步减少

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

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

• CodeHeap 'non-profiled nmethods'：405 MB 已使用 memory，405 MB 已提交 memory，508 MB 最大 ZCD69B4957F06CD818D1ZBF3D61980E29
• CodeHeap 'profiled nmethods'：已使用 258 MB memory，已提交 258 MB memory，最大 508 MB ZCD69B4957F06CD818D7ZBF3D61980E291

Java 11.0.13 + -XX:ReservedCodeCacheSize=1024m 稳定运行一周，时区=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 和 -7XX:ReservedCodeCacheSize=3 相同或略好

---

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

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

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

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

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

重新运行 11.0.11 和 11.0.13，使用 -XX:ReservedCodeCacheSize=375m 和jcmd <pid> Compiler.CodeHeap_Analytics aggregate一次，以便为 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 管理推到了临界点的不利方面。
• 结果很明显：不能达到稳定的 state。 有永久的代码扫描和重新编译。
• 分析方法的 CodeHeap 段会随着时间的推移而耗尽，因为所有 nmehtod 都变得足够热，可以在最高优化级别进行编译。

补救措施？ 这听起来既愚蠢又明显：增加 CodeCache 空间。 因为通过足够大的 CodeCache 可以达到稳定的 state，禁用分段代码缓存可能是有益的。