JEP 391:macOS/AArch64端口



Port the JDK to macOS/AArch64.




  • It is not a goal to implement all optional components (e.g., compiler intrinsics), even if they are implemented in other AArch64 ports.
  • It is not a goal to support the write-xor-execute (W^X) memory-protection policy for targets other than macOS/AArch64.


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


Apple has announced a long-term plan to transition their line of Macintosh computers from x64 to AArch64. We therefore expect to see broad demand for a macOS/AArch64 port of the JDK.



Although it will be possible to run a macOS/x64 build of the JDK on AArch64-based systems via macOS's built-in Rosetta 2 translator, the translation will almost certainly introduce a significant performance penalty.

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


An AArch64 port already exists for Linux (JEP 237), and work is underway on an AArch64 port for Windows (JEP 388). We expect to reuse existing AArch64 code from these ports by employing conditional compilation — as is usual in ports of the JDK — to accommodate differences in low-level conventions such as the application binary interface (ABI) and the set of reserved processor registers.


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

macOS/AArch64 forbids memory segments from being executable and writeable at the same time, a policy known as write-xor-execute (W^X). The HotSpot VM routinely creates and modifies executable code, so this JEP will implement W^X support in HotSpot for macOS/AArch64.

macOS/AArch64禁止内存段同时可执行和可写,这一策略称为write-xor-execute(W^X)。HotSpot VM定期创建和修改可执行代码,因此这个JEP将在HotSpot for macOS/AArch64中实现W^X支持。


Testing will include, but not be limited to, compatibility testing with the TCK, regression testing with jtreg, and validation with applications. The execution environment will include development platforms available from Apple as well as consumer hardware, once it becomes available.


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

Risks and Assumptions

  • The changes for macOS/AArch64 risk breaking the existing Linux/AArch64, Windows/AArch64, and macOS/x64 ports. This risk will be reduced via extensive pre-integration testing.
  • We expect to be able to implement the new ABI convention with reasonably small changes in the shared AArch64 code. We expect the footprint of the macOS-specific code to be small.
  • We expect the macOS/AArch64 and Windows/AArch64 ports to be similar in some ways, allowing some code to be shared across these ports and further reducing the macOS-specific AArch64 code.
  • We assume that the new version of macOS will not differ substantially from past versions, so that the amount of code change required for the new version will be small.
  • We expect that supporting the W^X policy will be aided by operating-system services such as the pthread_jit_write_protect_np system call. If not, we will develop alternative approaches. The first implementation will target correctness with a possible performance penalty in uncommon cases, such as deoptimizations.


  • 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系统调用。如果没有,我们将开发替代方法。第一个实现将以正确性为目标,在不常见的情况下(例如去优化)可能会出现性能损失。


The macOS/AArch64 port and the Windows/AArch64 port (JEP 388) will likely share some code. Some parts of this JEP will depend upon the integration of JEP 388, while other parts can be developed in parallel.


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