JEP 284: New HotSpot Build System | 新的 HotSpot 构建系统
摘要
使用 build-infra 框架重写 HotSpot 构建系统。
目标
该项目的目标是用基于 build-infra 框架的新的简化版构建系统替换当前的构建系统。具体来说：
- 利用 build-infra 框架中提供的功能，以最小化代码重复。
- 简化 HotSpot 构建系统，提供一个更易于维护的代码库，并降低未来改进的门槛。
非目标
我们不希望从这一变化中获得特定的性能改进，因为当前的 HotSpot 构建系统已经经过调优，性能良好。
动机
当前的 HotSpot 构建系统包含大量重复的代码和冗余的功能，这些功能最好由整体的 build-infra 框架来管理。即使对于经验丰富的开发人员来说，信息的结构和流程也很难理解。这导致了修复问题和向构建系统添加新特性的不愿意。
没有完全整合到 build-infra 中也阻碍了整体构建过程的进一步改进，这可能会在整体 JDK 构建过程中带来更多性能提升。
描述
从高层次上说，构建 HotSpot 实际上与构建 JDK 中的任何其他本地组件并无太大不同。实质上，我们需要调用 build-infra 函数 SetupNativeCompilation() 来为 libjvm.so 进行构建。实际上，HotSpot 构建与 JDK 存储库中的本地库有所不同，因此需要进行一些适应性调整。
一些技术差异的例子：
- HotSpot 使用预编译头文件，需要提供支持。
- HotSpot 使用自己的一套编译器标志，与产品中其余部分使用的标志不同。
libjvm.so可能会为不同的变体（例如服务器和客户端）构建多次。- HotSpot 使用几种可以启用或禁用的不同功能，例如 C1 和 JVMCI。
- 由于历史原因，HotSpot 使用不同的平台和编译器名称。
除了编译 libjvm.so 本地库之外，还有其他需要进行的预 / 后构建工作，例如：
- 创建像
adlc编译器这样的构建工具。 - 使用
adlc和 JVMTI 工具创建gensrc。 - Dtrace 支持需要进行预处理和后处理。
- 还需要构建额外的库，比如
libjsig.so。
测试
主要的测试方法将与 JDK 构建转换时相同，即使用 compare.sh 脚本。通过两次构建产品，一次使用旧的构建系统，一次使用新的构建系统，然后运行比较脚本，可以指出生成构建中的任何差异。
本地构建产物永远不会达到 100% 的字节完全相等，因为技术上的差异会影响即使使用相同的构建系统重新构建也会产生差异。然而，比较脚本指出的任何剩余差异应被解释并且在合理范围内加以说明。（例如，这样的更改可能是由于不同的构建输出目录导致的调试数据差异。）
如果构建系统可以重新创建相同的二进制文件，这从理论上讲就足够了。为保险起见，在最终集成之前，还将运行一套适当的常规产品测试。