跳到主要内容

JEP 284：新的 HotSpot 构建系统

QWen Max 中英对照

概述​

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

目标​

该项目的目标是用一个基于 build-infra 框架的全新且更加简化的系统来替换当前的构建系统。更具体地说：

  • 利用 build-infra 框架中现有的功能，以减少代码重复。
  • 简化 HotSpot 构建系统，以提供更易于维护的代码库，并降低未来改进的门槛。

非目标​

由于当前的 HotSpot 构建系统已经针对良好的性能进行了相当多的优化，因此我们预计此项更改不会带来特定的性能提升。

动机​

当前的 HotSpot 构建系统包含大量重复代码和冗余功能，这些内容最好由整体的 build-infra 框架来处理。信息的结构和流程难以跟踪，即使对于有经验的开发者来说也是如此。这导致了人们不愿意修复构建系统中的问题或添加新功能。

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

描述​

从高层次来看，构建 HotSpot 与其他构建 JDK 中的任何原生组件并没有太大不同。本质上，我们需要为 libjvm.so 调用 build-infra 函数 SetupNativeCompilation()。然而在实践中，HotSpot 的构建方式与 JDK 代码库中的原生库有所不同，因此需要进行一些适配工作。

一些技术差异的例子：

  • HotSpot 使用预编译头文件，这需要得到支持。
  • HotSpot 使用自己的一组编译器标志，这与产品其他部分使用的标志不同。
  • libjvm.so 可能会为不同的变体多次构建，例如 server 和 client。
  • HotSpot 使用多种可以启用或禁用的不同特性，例如 C1 和 JVMCI。
  • 出于历史原因，HotSpot 对平台和编译器使用不同的名称。

除了编译 libjvm.so 本地库之外，还有一些其他需要完成的预构建/后构建任务，例如：

  • 创建像 adlc 编译器这样的构建工具。
  • 使用 adlc 和 JVMTI 工具创建 gensrc。
  • Dtrace 支持需要预处理和后处理。
  • 需要构建额外的库，例如 libjsig.so。

测试​

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

原生构建产物永远无法实现 100% 的逐字节相等，因为技术差异会影响即使使用相同构建系统的重新构建。然而，比较脚本指出的任何剩余差异都应该被合理解释并证明在可接受范围内。（例如，此类变化可能是由于不同的构建输出目录导致的调试数据差异。）

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