跳到主要内容

JEP 284：新的 HotSpot 构建系统

概括​

使用 build-infra 框架重写 HotSpot 构建系统。

目标​

该项目的目标是用一种新的、更加简化的、基于构建基础架构的构建系统替换当前的构建系统。进一步来说：

  • 利用构建基础架构中的功能来最大限度地减少代码重复。
  • 简化HotSpot构建系统，提供更可维护的代码库，降低未来改进的门槛。

非目标​

我们预计此更改不会带来具体的性能改进，因为当前的 HotSpot 构建系统为了获得良好的性能而进行了大量调整。

动机​

当前的 HotSpot 构建系统包含大量重复代码和冗余功能，整体构建基础架构可以更好地处理这些代码和冗余功能。即使对于经验丰富的开发人员来说，信息的结构和流程也很难理解。这导致人们不愿修复问题并向构建系统添加新功能。

缺乏与构建基础设施的完全集成也阻碍了整个构建过程的进一步改进，这可能会在整个 JDK 构建过程中实现更多的性能提升。

描述​

从高层次上来说，构建 HotSpot 与在 JDK 中构建任何其他本机组件并没有真正的区别。本质上，我们需要调用SetupNativeCompilation()的build-infra 函数libjvm.so。在实践中，HotSpot 构建的演变与 JDK 存储库中的本机库不同，因此需要进行一些调整。

技术差异的一些示例：

  • HotSpot使用预编译头，需要支持。
  • HotSpot 使用自己的一组编译器标志，该标志与产品其余部分中使用的编译器标志不同。
  • libjvm.so可能会针对不同的变体（例如服务器和客户端）构建多次。
  • HotSpot 使用多种可以启用或禁用的不同功能，例如 C1 和 JVMCI。
  • 由于历史原因，HotSpot 对平台和编译器使用不同的名称。

除了编译libjvm.so本机库之外，还需要执行其他构建前/构建后的操作，例如：

  • 创建编译器等构建工具adlc。
  • gensrc使用adlcJVMTI 工具创建。
  • dtrace 支持需要预处理和后处理。
  • libjsig.so需要构建其他库等。

测试​

主要测试方法与JDK版本转换时相同，即使用脚本compare.sh。通过构建产品两次，一次使用旧的构建系统，一次使用新的构建系统，然后运行比较脚本，将指出生成的构建中的任何差异。

本机构建工件永远不会实现 100% 逐字节相等，因为技术差异甚至会影响使用相同构建系统的重建。然而，比较脚本指出的任何剩余差异都应予以考虑并解释为合理的。 （例如，此类更改可能是由于不同的构建输出目录而导致的调试数据差异。）

如果构建系统重新创建相同的二进制文件，理论上这应该足以进行测试。为了保障安全，在最终集成之前还将运行一组合适的正常产品测试。