JDK-8248238 : Implementation: JEP 388: Windows AArch64 Support
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_10
  • CPU: aarch64
  • Submitted: 2020-06-24
  • Updated: 2021-12-16
  • Resolved: 2020-10-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 16
11.0.13Unresolved 16 b19Fixed
Related Reports
Blocks :  
JDK-8248656 - Add Windows AArch64 platform support code
Blocks :  
JDK-8248670 - Windows: Exception handling support on AArch64
Blocks :  
JDK-8248659 - AArch64: Extend CPU Feature detection
Relates :  
JDK-8278885 - Remove Windows ARM64 int8_t workaround in G1
Relates :  
JDK-8248496 - JEP 388: Windows/AArch64 Port
Relates :  
JDK-8248500 - AArch64: Remove the r18 dependency on Windows AArch64
Relates :  
JDK-8254252 - Generic arraycopy stub overwrites callee-save rdi register on 64-bit Windows
Description
This is the umbrella bug ID for the initial support of Windows AArch64.
Comments
Fix request (11u) Backporting this patch would allow JDK 11 to stay relevant while Arm64 machines become increasingly widespread. The current build method is not ideal, but minimizes the changes to other platforms, lowering the risks. We haven't seen regressions on other platforms. We've shared test results under the PR: https://github.com/openjdk/jdk11u-dev/pull/301 Reviewed by aph, adinn, ihse, vkempik, and lewurm.
23-11-2021
Changeset: 9604ee82 Author: Monica Beckwith <mbeckwit@openjdk.org> Committer: David Holmes <dholmes@openjdk.org> Date: 2020-10-05 03:21:39 +0000 URL: https://git.openjdk.java.net/jdk/commit/9604ee82
05-10-2020
Hi @Michael. Thanks for your comment. We have tested JLink and we know that it works. We are in the process of learning about WiX toolset's and Gluon's Arm64 roadmap. We will keep you posted. Thanks again.
21-07-2020
Have you already considered to extend/adapt/test the jpackage tool? In order to establish a new platform, you certainly need the ability to package applications for it. I just ask because I haven't seen it being mentioned anywhere. And what about JavaFX?
17-07-2020
Ah, makes sense. Sorry and thank you for your clarification. This works out really well for us. I appreciate your guidance, @David.
08-07-2020
Sorry there is some confusion remaining. This issue, JDK-8248238, is the issue that will be used to integrate the implementation of the JEP to the mainline repository. It's "Affects Version" should be 16 and its "Fix version" of "tbd" until the JEP is targeted. The issues that "block" this issue were described as things that would be initially fixed in the https://hg.openjdk.java.net/aarch64-port/jdk-windows/ repository. Those issues are the ones that should have repo-aarch64-port as their "Affects Version" and "Fix Version".
08-07-2020
The release value repo-aarch64-port has been created. Please set the affects and fix version to that for all issues you intend to push first to https://hg.openjdk.java.net/aarch64-port/jdk-windows/. Thanks.
07-07-2020
For anything that is to be pushed to aarch64-port/jdk-windows/ it is preferable to use a project specific "Affects Version" and "Fix Version" so they don't easily get confused with issues pushed to the mainline repos. Such a value needs to be requested - the process for which I am checking and will advise. Thanks.
04-07-2020
Thank you David. As you pointed out, we are planning to upstream many of the JBS issues as independent fixes; I removed those from this JBS issue. For the remaining ones (linked to this issue as "is blocked by"), I would like to keep them and integrate them into https://hg.openjdk.java.net/aarch64-port/jdk-windows/ once we have authorship for aarch64-port. Having them separated eases the process of reviewing a lot. Thanks, -Bernhard
03-07-2020
There is no need to have so many additional issues filed in relation to this port. You should have one JBS issue per changeset you intend to push. While some of the issues could be "fixed" independently of this port under the guise of "general cleanup", many/most are specific to the port and can't be pushed until the JEP is approved. At that point you really want one large complete changeset associated with one JBS issue - this one.
02-07-2020
The Aarch64 project description states: " It is hoped that this project will eventually be able to support operating systems other than GNU/Linux, and welcomes contributors with the necessary expertise." so it does seem like a suitable home - as long as the Project lead agrees of course.
25-06-2020
New ports require a lot of pre-work, typically starting as a project and then using a JEP to move the port into mainline.
25-06-2020
This isn't a new port as such, but an extension to an existing port to support an additional operating system. A JEP is needed, but I don't see any reason why it couldn't live under the existing AArch64 project.
25-06-2020
Mail thread in hotspot-runtime - https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040330.html
24-06-2020