On Mon, 11 May 2026 16:21:25 GMT, Luigi Montoya <[email protected]> wrote:
>> As of the end of last year, Github Actions now supports Windows ARM64 >> runners. Also, we fixed all issues that would cause Windows ARM64 GHA tests >> to fail. >> >> This change includes: >> - Change Github Actions to natively build Windows ARM64. >> - Enable Github Actions testing for Windows ARM64. >> >> I also confirmed that the new `windows-11-arm` pool uses Visual Studio >> Enterprise 2022. For more information see >> [Windows11-Arm64-Readme](https://github.com/actions/runner-images/blob/main/images/windows/Windows11-Arm64-Readme.md#visual-studio-enterprise-2022) >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Luigi Montoya has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains one commit: > > Enable GHA testing for Windows ARM64 (#1) > > * Enable GHA testing for Windows ARM64 > > * Update Boot JDK to be JDK26 I have a few code comments, and a few generic ones. MSVC situation is already messy, and we had to downgrade to Visual Studio 2022 recently. This change assumes that `windows-2022` and `windows-11-arm` runners have matched VS versions. This would be a problem going forward: we would not be able to easily and selectively upgrade VS for either x64 or ARM64 in isolation. I think really comes down to MSVC paths in `build-windows.yml`, think how to split arch paths a bit better? Generically, we try to keep the GHA testing tight resource-wise to avoid overburdening GHA infrastructure. Adding more tests must be weighted against the cost of running these tests on every PR. For Linux AArch64 I could see how it clears the bar, as a significant chunk of real world is running on it. Same for MacOS AArch64. For Windows ARM64, I just don't have an intuitive feel. Then again, if you Microsoft folks are fine with spending more GHA public runners compute on OpenJDK testing, maybe it is not a problem. .github/actions/get-msys2/action.yml line 37: > 35: steps: > 36: - name: 'Install MSYS2 on x86.x64' > 37: id: msys2 Want to call this one `msys2-x64`? .github/actions/get-msys2/action.yml line 58: > 56: - name: 'Set MSYS2 path' > 57: run: | > 58: if ('${{ inputs.architecture }}' -eq 'ARM64') { Might be a bit cleaner if you split this in separate steps for `x64` and `arm64`. Then we would not be as dependent on `pwsh` syntax for string checks. .github/actions/get-msys2/action.yml line 66: > 64: > 65: # Remove the default config.site file provided by MSYS2 to ensure > config.guess accurately detects the host system. > 66: - name: 'Remove default config.site' So you have to do this, because the change also drops `--extra-conf-options` earlier? .github/workflows/build-windows.yml line 114: > 112: run: | > 113: set +e > 114: if [ "${{ inputs.architecture }}" = "ARM64" ]; then `-eq`, or am I missing something? .github/workflows/build-windows.yml line 131: > 129: run: | > 130: # Run Visual Studio Installer > 131: '/c/Program Files (x86)/Microsoft Visual > Studio/Installer/vs_installer.exe' \ Is MSVC still in `Program Files (x86)` on Windows ARM64 runners? ------------- PR Review: https://git.openjdk.org/jdk/pull/31102#pullrequestreview-4335980292 PR Review Comment: https://git.openjdk.org/jdk/pull/31102#discussion_r3280356671 PR Review Comment: https://git.openjdk.org/jdk/pull/31102#discussion_r3280364120 PR Review Comment: https://git.openjdk.org/jdk/pull/31102#discussion_r3280424275 PR Review Comment: https://git.openjdk.org/jdk/pull/31102#discussion_r3280413169 PR Review Comment: https://git.openjdk.org/jdk/pull/31102#discussion_r3280433846
