OpenJDK HotSpot或将在Java 9带来预先编译技术（AOT）

摘要：

OpenJDK HotSpot或将在Java 9初期版本引入预先编译技术（AOT）。InfoQ会持续关注2016年9月份提交的相关提案。

正文：

在“什么是即时编译（JIT）！？OpenJDK HotSpot VM剖析”这篇文章里，作者提到HotSpot执行引擎有一个即时（JIT）编译器。为了优化启动时间，分层编译先对代码进行解释，然后把它们快速移动到第1层，第2层和第3层，在这些层里使用客户端编译级别对它们进行编译（使用不同的剖析信息），最后把它们移动到服务端编译级别的层（更多信息可以参考上面的文章）。尽管有编译阶段的优化，HotSpot仍然会先解释执行字节码，然后才会使用即时编译。

今年9月，一个关于在HotSpot里添加预先编译（Ahead-of-Time，AOT）的提案被提交到JEP。AOT通过加载预编译的类来优化启动时间，避免了在解释模式或局部优化编译级别运行这些类。

AOT并非新出现的动态编译器技术。IBM的J9虚拟机就支持AOT，Excelsior JET和其它一些虚拟机也支持。AOT使用（共享）已经编译成本地代码的库让动态编译器达到更好的启动/预热效果。

跟JIT编译器类似，AOT编译也有分层和非分层两种模式，不同之处在于剖析信息和JIT再编译。那篇文章提到，在分层模式下，编译第2层会收集简单的剖析信息，AOT分层编译的代码也是如此。当AOT调用达到一定阈值，这些方法会在第3层被客户端编译器编译，这也为将在第4层发生的服务端再编译收集了全部剖析信息。

该提案由HotSpot团队负责人Valdimir Kozlov提交，里面提到了在第一个版本里只有java.base模块支持多层AOT，因为这个基本模块为众人所知，可以得到全面的内部测试。

AOT带来了一个叫作“jaotc”的工具，它在内部使用了Graal（用于生成代码）。Graal动态编译器集成了HotSpot虚拟机并且依赖JVM编译器接口（JVMCI），所以JDK（支持Graal或AOT）应该也支持JVMCI。Oracle technetwork网站上就有一些支持JVMCI的JDK版本。

根据提案的描述，jaotc工具支持以下这些标记：

--module <name> 要编译的模块
--output <file> 输出的文件名
--compile-commands <file> 写有编译命令的文件的名字
--compile-for-tiered 为分层编译生成剖析代码
--classpath <path> 指定可以从哪里找到用户类文件
--threads <number> 用于编译的线程数
--ignore-errors 忽略在类加载期间抛出的异常
--exit-on-error 在出现编译异常时退出
--info 在编译期间打印信息
--verbose 打印详细信息
--debug 打印调试信息
--help 打印使用帮助信息
--version 版本信息
-J <flag> Pass <flag> 直接传给运行时系统

产品级的JVM有如下标记：

+/-UseAOT                  - 使用AOT编译的文件
+/-PrintAOT                - 打印被使用的AOT类和方法
AOTLibrary=<file>          - 指定AOT库文件

一些非产品级或用于开发的标记对用户也是可用的：

PrintAOTStatistics      - 打印AOT统计信息
UseAOTStrictLoading     - 任何一个AOT库出现无效配置就退出虚拟机

提案同时提到，AOT的运行时事件日志将集成统一GC日志，并支持如下标签：

aotclassfingerprint
aotclassload
aotclassresolve

不列出风险或没有基本假定的提案是不完整的，AOT也不例外。AOT提案的风险标注如下：

预编译的代码可能不是最优的，所以会导致性能损失。性能测试结果表明，有些应用程序会从AOT编译的代码中获益，不过有些却出现明显的性能衰退。因为AOT特性是可选的，所以应用程序出现的性能衰退是可以避免的。如果用户发现应用程序启动变慢，或者达不到预期的性能峰值，那么可以重新构建一个不包含AOT库的JDK。

查看英文原文：Ahead-of-Time (AOT) Compilation May Come to OpenJDK HotSpot in Java 9