Bug ID: JDK-8248496 JEP 388: Windows/AArch64 Port

Type: JEP
Component: hotspot
Sub-Component: runtime

Priority: P3
Status: Closed
Resolution: Delivered
Fix Versions: 16

Submitted: 2020-06-29
Updated: 2024-07-26
Resolved: 2021-01-29

Summary
-------

Port the JDK to Windows/AArch64.

Motivation
----------

With the release of new consumer and server-class AArch64 (ARM64) hardware, Windows/AArch64 has become an important platform due to end-user demand.

Description
-----------

We have ported the JDK to Windows/AArch64, by extending the work previously done for the Linux/AArch64 port [(JEP 237][linux-aarch64]).  This port includes the template interpreter, the C1 and C2 JIT compilers, and garbage collectors (serial, parallel, G1, Z and Shenandoah). It supports both the Windows 10 and Windows Server 2016 operating systems. 

The focus of this JEP is not the porting effort itself, which is mostly complete, but rather the integration of the port into the JDK main-line repository.

Currently, we have a little over a dozen changesets. We have kept the changes to the shared code to a minimum. Our changes extend the support of the AArch64 memory model to Windows, address some  MSVC issues, add LLP64 support to the AArch64 port, and perform CPU feature detection on Windows. We have also modified the build scripts to better support cross-compilation and the Windows toolchain.

The new platform code by itself is confined to 15 (+4) files and 1222 lines (+322).

Early-access binaries are available [here](https://github.com/microsoft/openjdk-aarch64).

Testing
-------

We have done thorough functional, performance, and regression testing on AArch64 test systems including Ampere eMAG1s, Marvell ThunderX2s (with SMT both on and off), and Surface Pro Xs. Our test suites include JTReg, JCStress, jmh-jdk-microbenchmarks, JFC applications and applets (demo/jfc), SPECJBB2005, SPECJBB2015, SPEC SERT, SPECJVM2008, DaCapo, and a few smaller benchmarks.
Two of the test matrices are documented in detail: [JTReg][jtreg] and
[SPECJBB2015][specjbb2015].

Apart from the AArch64 systems, we have also tested our patches on x64 systems (Intel Skylakes). Our test coverage includes Linux/AArch64, Windows/AArch64, Windows/x64, and, only for functional testing, Linux/x64.

We have a robust CI for functional tests and will continue running our patches through the CI as we make further changes.

Risks and Assumptions
---------------------

- We have made changes to shared code in the Linux/AArch64 backend to extend LP64 (64-bit long ints and pointers) to accommodate the [long-long ints and pointers (LLP64)][llp64]
 needed by the 64-bit Windows platform.

- We have also modified shared code on Windows, as mentioned above.

- We need to rework the usage of register x18, which on Windows/AArch64 is used for the Windows Thread Environment Block (TEB). We are working together with the Lead of the AArch64 Port project to find a graceful solution.


[msvc]: https://developercommunity.visualstudio.com/content/problem/1079221/arm64-bad-code-generation-around-signed-char-arith.html
[llp64]: https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
[jtreg]: https://github.com/microsoft/openjdk-aarch64/blob/master/JTRegtests.md
[specjbb2015]: https://github.com/microsoft/openjdk-aarch64/blob/master/SPECJBB2015-test-matrices.md
[linux-aarch64]: https://openjdk.java.net/jeps/237

here's the PR for implementation: https://github.com/openjdk/jdk/pull/212
02-10-2020
It's all good, Mark. Thanks for guiding us the right way. And thank you @Vladimir for helping us out. :)
24-09-2020
[~mbeckwit] Apologies for not noticing this earlier, but per the JEP 2.0 Process Proposal (https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html) only a Committer to the JDK Project can propose to target a JEP to a JDK release. [~kvn] has kindly agreed to take on ownership on your behalf, so if that’s okay with you then I’ll proceed with the targeting review.
24-09-2020
😂. Thanks Jesper. Done.
21-09-2020
When proposing to target you should also set the fix version to the JDK release to which you propose to target the JEP to. Five "to" in the same sentence, that can't be right...
20-09-2020
Thanks @Vladimir and @Mark. I will now propose to target the JEP.
20-09-2020
I endorsed this JEP.
20-09-2020
Please seek an endorsement from a Group or Area Lead (https://openjdk.java.net/projects/jdk/leads) before proposing to target this JEP.
17-09-2020
Thanks @Mark. Your changes look great. I have assigned it to you now. Thanks again.
09-07-2020
I’ve done a copy-editing pass to align the title and text of this JEP with previous port JEPs, generally streamline the text, and fix up some terminology. Please make any needed corrections, assign the issue to me, and then I’ll move it to Candidate.
09-07-2020
Thanks @Mark. Please let us know if we have covered your concerns.
07-07-2020
Thanks for submitting this! A few initial comments and questions: - Rather than require the reader to follow a link to see the overview of your functional, performance, and regression tests, consider summarizing them briefly in the JEP. Likewise for the list of AArch64 test systems. - Can you elaborate on what you mean by “LP64 vs. LLP64” and the changes to the linux-aarch64 code? - What is the “reworking around R18” about? Is that register 18? - If there are no alternatives, please just omit the Alternatives section.
06-07-2020
Thank you for the review Vladimir!
03-07-2020
I think JEP can be moved to Submitted state for OpenJDK Lead review.
02-07-2020
Good. I "reviewed" this JEP.
02-07-2020
Good questions Vladimir, thank you. 1. By now we have G1GC working (it was a MSVC bug; we will submit a temporary workaround). We aren't looking at ZGC and Shenandoah right now. We'll update the JEP accordingly. 2. ARM64 is only supported on Windows 10 and Windows Server 2016. 3. It only works via cross compilation as Microsoft tooling is x86/x86_64. It's a good point, we'll update `doc/building.md` accordingly.
02-07-2020
I read https://github.com/microsoft/openjdk-aarch64. There are few sentences I have questions about: 1. Do you plan to add support to all product GCs before final integration or it will only support Parallel and Serial GCs. It should be stated in JEP. 2. You need to list supported Windows Versions in this JEP. It seems you only support Windows 10 & Windows Server 2016. Is it true? 3. You need to list tools (C++ compiler and others) which can be used to build JDK. Does it support cross compilation? Thanks, Vladimir
02-07-2020
Thank you Vladimir.
02-07-2020
[~burban] Yes, it is okay to collect all RFEs into that. We usually call such umbrella RFE "Implementation of JEP: Windows AArch64 Support" and use its ID for final integration into JDK. The JEP is official main document which people read during JDK release which integrated it. As such it should not have words "proposal" in Summary. You don't need to talk about patches here or how it was implemented - it can be done in JDK-8248238. Think of Description section as final document when the feature is released. See http://openjdk.java.net/jeps/2 Look on other jeps: http://openjdk.java.net/jeps/0
02-07-2020
Thank you David, I re-used JDK-8248238 as "umbrella bug id", and linked the other more specific bugs to it. I hope that's fine.
02-07-2020
Usually a JEP is associated with one JBS issue that will be used as the single bug id under which the JEPs code changes will actually be integrated, once the JEP has been approved for a given release.
02-07-2020

Blocks :	JDK-8251280 - JEP 391: macOS/AArch64 Port
Relates :	JDK-8248238 - Implementation: JEP 388: Windows AArch64 Support