跳到主要内容

JEP 391: macOS/AArch64 移植

QWen Max 中英对照 JEP 391: macOS/AArch64 Port

总结​

将 JDK 移植到 macOS/AArch64。

非目标​

  • 即使其他 AArch64 移植版本实现了所有可选组件（例如，编译器内联函数），我们的目标并不是实现所有这些可选组件。
  • 对于 macOS/AArch64 以外的目标平台，支持写或执行（W^X）内存保护策略并不是我们的目标。

动机​

Apple 已宣布了一项长期计划，将其 Macintosh 电脑系列从 x64 过渡到 AArch64。因此，我们预计 macOS/AArch64 版本的 JDK 将会有广泛的需求。

虽然可以通过 macOS 内置的 Rosetta 2 转译器在基于 AArch64 的系统上运行 macOS/x64 版本的 JDK，但转译几乎肯定会带来显著的性能损失。

描述​

AArch64 的 Linux 移植已经存在（JEP 237），而 Windows 的 AArch64 移植工作正在进行中（JEP 388）。我们预计会通过条件编译来重用这些移植中现有的 AArch64 代码 —— 这在 JDK 的移植中是惯常做法 —— 以适应诸如应用二进制接口（ABI）和保留处理器寄存器集合等低级约定的差异。

macOS/AArch64 禁止内存段同时具有可执行和可写属性，这一策略被称为 write-xor-execute (W^X)。HotSpot 虚拟机经常创建并修改可执行代码，因此本 JEP 将在 HotSpot 中为 macOS/AArch64 实现 W^X 支持。

测试​

测试将包括但不限于与 TCK 的兼容性测试、使用 jtreg 进行回归测试以及使用应用程序进行验证。执行环境将包括 Apple 提供的开发平台以及消费者硬件（一旦可用）。

风险与假设​

  • 针对 macOS/AArch64 的变更可能会破坏现有的 Linux/AArch64、Windows/AArch64 和 macOS/x64 移植。通过广泛的预集成测试，这一风险将得以降低。

  • 我们预计能够以共享 AArch64 代码中相对较小的改动来实现新的 ABI 规范。macOS 特定代码的规模预计也会很小。

  • 我们预计 macOS/AArch64 和 Windows/AArch64 移植在某些方面会比较相似，从而允许部分代码在这两个移植版本之间共享，进一步减少 macOS 特定的 AArch64 代码量。

  • 我们假设新版本的 macOS 不会与过去的版本有实质性差异，因此针对新版本所需的代码改动量将会很小。

  • 我们预计支持 W^X 策略将得益于操作系统服务（例如 pthread_jit_write_protect_np 系统调用）。如果不可行，我们将开发替代方案。首个实现将以正确性为目标，但在一些不常见的情况下（如去优化）可能会带来性能损失。

依赖​

macOS/AArch64 端口和 Windows/AArch64 端口（JEP 388）可能会共享一些代码。此 JEP 的某些部分将依赖于 JEP 388 的集成，而其他部分可以并行开发。