JEP 544：提前代码​​编译

JEP 544：提前代码编译所有者 John Rose 类型功能范围实现状态候选组件热点/编译器讨论 openjdk dot org 的 leyden dash dev 与 JEP 483 相关：提前类加载和链接 JEP 515：提前方法分析由 Alex Buckley、Dan Heidinga、Mark Reinhold、Vladimir 审核Kozlov 由 Vladimir Kozlov 认可 创建于 2024/06/30 04:47 更新于 2026/09/10 15:28 问题 8335368 摘要 通过在 HotSpot Java 虚拟机启动时立即提供应用程序的优化本机代码来缩短启动和预热时间。通过在训练运行中将应用程序代码编译为本机代码，并将本机代码存储在 AOT 缓存中以供后续生产运行使用来实现此目的。如果生产中的工作负载发生变化，则动态重新生成本机代码以持续达到峰值性能，从而提供提前 (AOT) 和即时 (JIT) 编译的最佳性能。目标 使应用程序能够更快地达到峰值性能。即使工作负载发生变化，应用程序也能维持峰值性能。不需要对应用程序、库或框架的代码进行任何更改。除了请求使用 AOT 缓存之外，不需要对 HotSpot 的配置进行任何更改。继续支持串行、并行、G1 和 ZGC 垃圾收集器。不要引入新的 AOT 工作流程，而是扩展现有的 AOT 缓存创建工作流程。确保从 AOT 编译的代码到 JIT 编译的代码的转换对于应用程序来说是不可见的。支持AArch64和x64处理器架构。非目标 提供纯 AOT 模式不是目标。应用程序将在同一运行中同时使用 AOT 编译的代码和 JIT 编译的代码，并根据需要在它们之间自动转换。支持交叉编译不是目标。在训练运行中编译的代码必须在后续生产运行中在相同的 CPU 架构上运行，并具有相同的功能集。支持HotSpot当前支持的所有CPU架构并不是目标。我们预计正常的移植活动最终会增加对所有主要架构的支持。动机 当 Java 应用程序由 HotSpot JVM 运行时，它会经历三个阶段：启动、预热、然后达到峰值性能。在启动期间，HotSpot 调用应用程序的 main 方法并按需加载、链接和初始化类。最初，它通过字节码解释器运行应用程序和 JDK 库代码，速度很慢。在解释器内部，HotSpot 通过对方法调用和循环迭代等事件进行计数来分析应用程序的行为。它使用配置文件数据来选择经常调用的方法或热点，并通过基本的 C1 编译器将其编译为本机代码。此本机代码仅进行了适度优化。在预热期间，应用程序会稳定其工作负载，并且类的加载、链接和初始化会逐渐减少。 HotSpot 继续在字节码解释器中以及通过 C1 插入的检测代码来分析应用程序。它收集更丰富的配置文件信息，不仅包括方法调用和循环迭代计数，还包括遇到的对象类型。随着配置文件数据随着时间的推移积累，它在统计上变得更加有用。最终，HotSpot 使用这些数据来选择最热门的方法，并通过高级 C2 编译器将其编译为本机代码。该本机代码不包含任何工具并且经过高度优化。分析应用程序和生成本机代码并不是免费的。字节码解释器不仅速度慢，而且经过检测的本机代码比未经检测的本机代码慢。将方法编译为本机代码需要 CPU 时间和内存，否则应用程序可能会使用这些时间，尽管 HotSpot 仅在配置文件数据表明这样做值得时才将方法编译为本机代码。然而，JIT 编译逐渐赶上应用程序的新兴热点，并且应用程序运行得更快。最终，所有热方法都被编译为完全优化的本机代码，并且编译器闲置。只要其热点不发生变化，应用程序就会保持这种最佳性能状态。然而，应用程序的热点可能会随着其工作负载的变化而变化。当这种情况发生时，HotSpot 可以通过根据需要丢弃先前生成的本机代码来动态地去优化，并通过为新的热门方法生成新的本机代码来重新优化。例如，如果应用程序最初收到两种类型的请求，则 HotSpot 会动态优化这两种请求类型的代码。如果应用程序开始接收第三种类型的请求，HotSpot 可以动态取消优化，然后重新优化所有三种类型请求的代码。实际上，应用程序可以通过另一个预热阶段，在应用程序的工作负载发生变化时保持性能。那么静态编译呢？静态补偿