JDK-8248500 : AArch64: Remove the r18 dependency on Windows AArch64
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: repo-aarch64-port
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: aarch64
  • Submitted: 2020-06-29
  • Updated: 2021-11-06
  • Resolved: 2020-09-28
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 Other
11.0.14Fixed repo-aarch64-portFixed
Related Reports
Relates :  
JDK-8248238 - Implementation: JEP 388: Windows AArch64 Support
Description
This register is used for TEB (Thread Environment Block, similar to Thread Local Storage) in the Windows ABI for AArch64.

Calling convention: https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#integer-registers
Comments
[~dholmes] good point, I agree. I changed the fix version accordingly.
05-11-2021
[~clanger] It is not right to mark this issue as fixed in JDK 16 b19 because this issue was never applied to mainline under the identity of this issue. The fact the same (we hope!) code went into JDK 16 b19 is immaterial to the Fix Version of this issue as it pertains to the commit that was done under this issue to the aarch64-port repo. The fix version of this issue should be repo-aarch64-port, the same as the "affects version".
05-11-2021
Thanks [~burban] for looking it up. This all makes perfect sense. I updated this bug and marked it as resolved in JDK16, b19 then - the same as JDK-8248238.
04-11-2021
I would not expect to see cherry-picked backports like this. This issue was only relevant to the in-progress work in the aarch64-port repo. That work was integrated en-masse when the port was upstreamed to mainline. If the entire port is being backported to 11u then it is that primary integration issue for the entire port that should be being back-ported. It makes no sense to me to backport an issue that only existed in isolation in a project repo.
04-11-2021
Resolved by https://hg.openjdk.java.net/aarch64-port/jdk-windows/rev/46e6be621aa9 and https://hg.openjdk.java.net/aarch64-port/jdk-windows/rev/22b54fb9323d edit (2021-11-04): Fixed a reference to a wrong commit.
04-11-2021
Thanks for your commments. David is right, this issue was originally part of the JEP issue that landed here: https://github.com/openjdk/jdk/commit/9604ee82690f89320614b37bfef4178abc869777 The situation since then has slightly changed: Another platform (macOS/AArch64) has showed up that partially depends on the Windows/AArch64 JEP. Specifically the r18 change that we are talking about here, so it makes sense to split it up, so that if the Windows/AArch64 backport JEP doesn't land for whatever reason into jdk11u, it wouldn't block a potential macOS/AArch64 backport. [~aph] requested the split here: https://github.com/openjdk/jdk11u-dev/pull/301#issuecomment-953098116
04-11-2021
[~burban], it's a bit weird that this item is marked resolved with fix version set to tbd. In your comment above, you also link to two changes in the aarch64-port mercurial repository. Could you please look up the change in the jdk/jdk repository which actually resolved this issue and link it here? And please set the fix version then accordingly. Thank you!
03-11-2021
Fix request Initially the AArch64 backend used r18 as an additional callee-saved register, as Linux doesn't use r18 as platform register (which is the actual intent according to the ABI). This backport fixes this wrong assumption, and thus enabling future backports to add support for other platforms that do use r18 as platform register to JDK11 (Windows and macOS). Reviewed by aph.
03-11-2021