JEP 391：macOS/AArch64移植

原文：https://openjdk.org/jeps/391
翻译：张欢

将JDK移植到macOS/AArch64。

非目标

• 实现所有可选组件（例如，编译器内在函数）不是目标，即使它们在其他AArch64端口中实现也是如此。
• 为macOS/AArch64以外的目标支持write-xor-execute（W^X）内存保护策略不是目标。

动机

Apple宣布了一项长期计划，将其Macintosh计算机系列从x64过渡到AArch64。因此，我们希望看到对JDK的macOS/AArch64端口的广泛需求。

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

描述

Linux（JEP 237）的AArch64端口已经存在，并且正在为 Windows（JEP 388）开发AArch64端口。我们希望通过使用条件编译来重用这些端口中现有的AArch64代码——这在JDK的端口中很常见——以适应低级约定的差异，例如应用程序二进制接口（ABI）和保留处理器寄存器集。

macOS/AArch64禁止内存段同时可执行和可写，这一策略称为write-xor-execute（W^X）。HotSpot VM定期创建和修改可执行代码，因此这个JEP将在HotSpot for 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的集成，而其他部分可以并行开发。