Re: RFR: 8253757: Add LLVM-based backend for hsdis

[Ludovic Henry]

On Fri, 18 Feb 2022 11:44:04 GMT, Magnus Ihse Bursie  wrote:

> Third time's a charm! After the two previous closed PRs for this issue, I 
> think this functionality is finally ready to enter mainline. :)
> 
> This code is at it's core the same as the previous PR. The main C++ hsdis 
> implementation is still the one @luhenry wrote, with some changes. As in the 
> previous PR, I extracted the LLVM-specific part into a separate file. In 
> addition to the last PR, I have also fixed a warning, and added a patch 
> inspired by @nick-arm for getting past instructions unknown to LLVM.
> 
> Thanks to the prototype written by @JornVernee (and his graciously providing 
> me with a working version of LLVM build for Windows), this PR now has full 
> support for LLVM on Windows (as well as Linux and macOS).
> 
> Finally, I have cleaned up the integration in autoconf and Hsdis.gmk, and 
> written a thorough guide in the README on how to build witth LLVM, on Windows 
> and on saner platforms. :)
> 
> I'm pretty sure this means that all comments and criticism in the previous PR 
> has been addressed.
> 
> Huge thanks to everyone who has helped me with getting this PR in place. I 
> have a hard time remember a feature that has been so tricky to get in place, 
> for something to seemingly simple...

Marked as reviewed by luhenry (Author).

Thanks again for pushing that forward! It's always good to have an alternative 
especially for porting to new platforms and architectures.

-

PR: https://git.openjdk.java.net/jdk/pull/7531

Re: RFR: 8253757: Add LLVM-based backend for hsdis

[Ludovic Henry]

On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie  wrote:

> This patch expands the newly added system for hsdis backends to include LLVM.
> 
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, 
> as published in the never integrated PR 
> https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out 
> the binutils-based part of it.)
> 
> Unfortunately I have not been able to make this work properly on Windows. 
> With some additional flags I made it compile without complaints, but it 
> caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I 
> tried to load the library. This is somewhat ironic, since the initial 
> implementation was created by Ludovic for the very purpose of using it on 
> Windows.
> 
> The lack of Windows support in this patch does not mean it is impossible to 
> get it to work, just that I need to co-operate with someone who has more 
> experience of compiling LLVM on Windows, and/or are more eager to get this 
> combination to work.

The value add of this LLVM-based hsdis is two-fold:
- It supports platforms that aren't supported by binutils (Windows-AArch64 for 
example)
- The license being more permissive would allow to build it as part of the 
OpenJDK build more easily (and even maybe ship it?)

LLVM has a strong track record of supporting new platforms (Windows-AArch64 and 
macOS-AArch64 for example, mostly because of investment from Microsoft and 
Apple respectively), and `hsdis` is a necessary tool for porting the OpenJDK to 
any new platform. Since the maintenance is fairly low (small codebase, small 
and knowledgable user base), I would be biased towards including it with 
appropriate warnings.

-

PR: https://git.openjdk.java.net/jdk/pull/5920

Re: RFR: 8253757: Add LLVM-based backend for hsdis

[Ludovic Henry]

On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie  wrote:

> This patch expands the newly added system for hsdis backends to include LLVM.
> 
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, 
> as published in the never integrated PR 
> https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out 
> the binutils-based part of it.)
> 
> Unfortunately I have not been able to make this work properly on Windows. 
> With some additional flags I made it compile without complaints, but it 
> caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I 
> tried to load the library. This is somewhat ironic, since the initial 
> implementation was created by Ludovic for the very purpose of using it on 
> Windows.
> 
> The lack of Windows support in this patch does not mean it is impossible to 
> get it to work, just that I need to co-operate with someone who has more 
> experience of compiling LLVM on Windows, and/or are more eager to get this 
> combination to work.

Marked as reviewed by luhenry (Author).

-

PR: https://git.openjdk.java.net/jdk/pull/5920

Re: RFR: 8253757: Add LLVM-based backend for hsdis

[Ludovic Henry]

On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie  wrote:

> This patch expands the newly added system for hsdis backends to include LLVM.
> 
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, 
> as published in the never integrated PR 
> https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out 
> the binutils-based part of it.)
> 
> Unfortunately I have not been able to make this work properly on Windows. 
> With some additional flags I made it compile without complaints, but it 
> caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I 
> tried to load the library. This is somewhat ironic, since the initial 
> implementation was created by Ludovic for the very purpose of using it on 
> Windows.
> 
> The lack of Windows support in this patch does not mean it is impossible to 
> get it to work, just that I need to co-operate with someone who has more 
> experience of compiling LLVM on Windows, and/or are more eager to get this 
> combination to work.

Very happy to see it landing :) Thank you!

I don't have access to a windows machine, and even less a Windows-AArch64 
machine. @lewurm would you be able to take a look?

-

PR: https://git.openjdk.java.net/jdk/pull/5920

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

[Ludovic Henry]

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and 
>> windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks 
>> JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with 
>> necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), 
>> required on macOS/AArch64 platform. It's implemented with 
>> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a 
>> thread, so W^X mode change relates to the java thread state change (for java 
>> threads). In most cases, JVM executes in write-only mode, except when 
>> calling a generated stub like SafeFetch, which requires a temporary switch 
>> to execute-only mode. The same execute-only mode is enabled when a java 
>> thread executes in java or native states. This approach of managing W^X mode 
>> turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>
>Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: 
> https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by luhenry (Author).

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253757: Add LLVM-based backend for hsdis

[Ludovic Henry]

On Mon, 21 Dec 2020 16:03:31 GMT, Magnus Ihse Bursie  wrote:

>> FWIW, I started working on a framework which would add support for 
>> selectable backends for hsdis. Unfortunately it was not as simple as I 
>> initially thought, so I had to put it on hold while directing my time to 
>> working on the winenv patch instead.
>> 
>> I believe the proper way forward is to get the "selectable hsdis backend" 
>> framework in place, and then retrofit this patch to add LLVM support in that 
>> framework. If this means that this PR should be closed, or kept open until 
>> this is done, I don't know.
>
> Nag nag bot...
> 
> I'm away for the holidays now, but I intend to pick up the work on the 
> selectable hsdis backend when I return. So while this exact code is unlikely 
> to be the one merged, it's good to have it open to allow me to double check 
> the solutions picked here.

@magicus that PR fell off my plate, but I'm happy to pick it up based on your 
"selectable hsdis backend" change.

-

PR: https://git.openjdk.java.net/jdk/pull/392

Integrated: 8254311: Incorrect statements in createWindowsDevkit2017.sh

[Ludovic Henry]

On Fri, 9 Oct 2020 15:39:18 GMT, Ludovic Henry  wrote:

> We made a typo in https://github.com/openjdk/jdk/pull/212 when updating 
> make/devkit/createWindowsDevkit2017.sh.

This pull request has now been integrated.

Changeset: 715e24af
Author:Ludovic Henry 
Committer: Tobias Hartmann 
URL:   https://git.openjdk.java.net/jdk/commit/715e24af
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8254311: Incorrect statements in createWindowsDevkit2017.sh

Reviewed-by: erikj, thartmann

-

PR: https://git.openjdk.java.net/jdk/pull/581

Re: RFR: 8254311: Incorrect statements in createWindowsDevkit2017.sh

[Ludovic Henry]

On Fri, 9 Oct 2020 16:09:27 GMT, Erik Joelsson  wrote:

>> We made a typo in https://github.com/openjdk/jdk/pull/212 when updating 
>> make/devkit/createWindowsDevkit2017.sh.
>
> Marked as reviewed by erikj (Reviewer).

@TobiHartmann as you reported https://bugs.openjdk.java.net/browse/JDK-8254311, 
could you please review and eventually
sponsor? Thank you!

-

PR: https://git.openjdk.java.net/jdk/pull/581

RFR: 8254311: Incorrect statements in createWindowsDevkit2017.sh

[Ludovic Henry]

8254311: Incorrect statements in createWindowsDevkit2017.sh

-

Commit messages:
 - 8254311: Incorrect statements in createWindowsDevkit2017.sh

Changes: https://git.openjdk.java.net/jdk/pull/581/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=581=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254311
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/581.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/581/head:pull/581

PR: https://git.openjdk.java.net/jdk/pull/581

Re: RFR: 8253757: Add LLVM-based backend for hsdis

[Ludovic Henry]

On Thu, 8 Oct 2020 18:07:59 GMT, Ludovic Henry  wrote:

>>> 1 question: binutils seems to support Windows AArch64. Did you try recently 
>>> binutils? If we can use binutils on Windows
>>> AArch64, you can fix makefile only.
>>> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/dlltool.c;h=ed016b97dc38cdb1b85d2f6df676b9c9750f0d41;hb=HEAD#l248
>> 
>> This is armv7, I don't see any support for armv8/AArch64 in `dlltool.c`.
>
> @magicus
> 
>> This is an interesting suggestion. There is a similar attempt at replacing 
>> binutils with capstone in
>> https://bugs.openjdk.java.net/browse/JDK-8188073, which unfortunately has 
>> not seen much progress due to lack of
>> resources; I don't know if you are aware of that? There is also a (extremely 
>> low priority) effort to rewrite the hsdis
>> makefile to be part of the normal build system, see e.g. 
>> https://bugs.openjdk.java.net/browse/JDK-8208495. Neither of
>> these should be any blocker for your change, but I think it might be good if 
>> you know about them.
> 
> I was not aware of the effort to use capstone to replace/complement binutils 
> in hsdis. I wonder how easy it is to port
> capstone to platforms in case it doesn't support them.
>> I have couple of concerns with your patch. One is the method in which LLVM 
>> is selected instead of binutils; afaict this
>> depends on having the LLVM variable set when executing the makefile. At the 
>> very least, this should be documented in
>> the README. I don't think any more complicated configuration is really 
>> necessary at this point. With full integration
>> with the build system, a more user-friendly way of selecting hsdis backend 
>> should be implemented, though.
> 
> I'll add documentation to the Makefile. And I agree, I would prefer not to 
> have to go through the whole build
> integration to integrate the support for LLVM.
>> Second, and I don't know if this is an artifact of git/github/the new skara 
>> tooling, but if you renamed hsdis.c to
>> hsdis.cpp, this relationship does not show up, not even in the generated 
>> webrevs. Instead they are considered a new + a
>> deleted file. This makes it hard to see what code changes you have done in 
>> that file.
> 
> That is Git not detecting enough similarities between the two files. I could 
> probably hack my way around and find a way
> to reduce the code diff if that's something you want.
>> And third; have you tested that your changes (both changing the main file 
>> from C to C++, and any code changes in it)
>> does not break the old binutils functionality? Afaic there are no test 
>> suites for exercising hsdis :-( so manual ad-hoc
>> testing is likely needed.
> 
> I've tested on Linux-x86_64 and Linux-AArch64 on top of Windows-AArch64 and 
> macOS-AArch64, and checked that both the
> binutils builds and works as previously and that the LLVM-based hsdis has an 
> equivalent output.

@navyxliu

> @luhenry I tried to build it with LLVM10.0.1
> on my x86_64, ubuntu, I ran into a small problem. here is how I build.
> $make ARCH=amd64 CC=/opt/llvm/bin/clang CXX=/opt/llvm/bin/clang++ 
> LLVM=/opt/llvm/
> 
> I can't meet this condition because Makefile defines LIBOS_linux.
> 
> #elif defined(LIBOS_Linux) && defined(LIBARCH_amd64)
> return "x86_64-pc-linux-gnu";
> 
> Actually, Makefile assigns OS to windows/linux/aix/macosx (all lower case)and 
> then
> CPPFLAGS += -DLIBOS_$(OS) -DLIBOS="$(OS)" -DLIBARCH_$(LIBARCH) 
> -DLIBARCH="$(LIBARCH)" -DLIB_EXT="$(LIB_EXT)"

Interestingly, I did it this way because on my machine `LIBOS_Linux` would get 
defined instead of `LIBOS_linux`. I
tried on WSL which might explain the difference. Could you please share more 
details on what environment you are using?

> In hsdis.cpp, native_target_triple needs to match whatever Makefile defined. 
> With that fix, I generate llvm version
> hsdis-amd64.so and it works flawlessly

I'm not sure I understand what you mean. Are you saying we should define the 
native target triple based on the
variables in the Makefile?

A difficulty I ran into is that there is not always a 1-to-1 mapping between 
the autoconf/gcc target triple and the
LLVM one. For example. you pass `x86_64-gnu-linux` to the OpenJDK's `configure` 
script, but the equivalent target
triple for LLVM is `x86_64-pc-linux-gnu`.

Since my plan isn't to use LLVM as the default for all platforms, and because 
there aren't that many combinations of
target OS/ARCH, I am taking the approach of hardcoding the combinations we care 
about in `hsdis.cpp`.

-

PR: https://git.openjdk.java.net/jdk/pull/392

Re: RFR: 8253757: Add LLVM-based backend for hsdis

[Ludovic Henry]

On Thu, 8 Oct 2020 12:30:13 GMT, Bernhard Urban-Forster  
wrote:

>> IMHO, it's great to have an alternative disassembler.  I personally had 
>> better experience using llvm MC when I decoded
>> aarch64 and AVX instructions than BFD.  Another argument is that LLVM 
>> toolchain is supposed to provide the premium
>> experience on non-gnu platforms such as FreeBSD.@luhenry  I tried to 
>> build it with LLVM10.0.1
>> on my x86_64, ubuntu, I ran into a small problem. here is how I build.
>> `$make ARCH=amd64 CC=/opt/llvm/bin/clang CXX=/opt/llvm/bin/clang++ 
>> LLVM=/opt/llvm/`
>> 
>> I can't meet this condition because Makefile defines LIBOS_linux.
>> #elif defined(LIBOS_Linux) && defined(LIBARCH_amd64)
>> return "x86_64-pc-linux-gnu";
>> 
>> Actually, Makefile assigns OS to windows/linux/aix/macosx (all lower 
>> case)and then
>> `CPPFLAGS+= -DLIBOS_$(OS) -DLIBOS="$(OS)" -DLIBARCH_$(LIBARCH) 
>> -DLIBARCH="$(LIBARCH)" -DLIB_EXT="$(LIB_EXT)"`
>> 
>> In hsdis.cpp, `native_target_triple` needs to match whatever Makefile 
>> defined.  With that fix, I generate llvm version
>> hsdis-amd64.so and it works flawlessly
>
>> 1 question: binutils seems to support Windows AArch64. Did you try recently 
>> binutils? If we can use binutils on Windows
>> AArch64, you can fix makefile only.
>> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/dlltool.c;h=ed016b97dc38cdb1b85d2f6df676b9c9750f0d41;hb=HEAD#l248
> 
> This is armv7, I don't see any support for armv8/AArch64 in `dlltool.c`.

@magicus

> This is an interesting suggestion. There is a similar attempt at replacing 
> binutils with capstone in
> https://bugs.openjdk.java.net/browse/JDK-8188073, which unfortunately has not 
> seen much progress due to lack of
> resources; I don't know if you are aware of that? There is also a (extremely 
> low priority) effort to rewrite the hsdis
> makefile to be part of the normal build system, see e.g. 
> https://bugs.openjdk.java.net/browse/JDK-8208495. Neither of
> these should be any blocker for your change, but I think it might be good if 
> you know about them.

I was not aware of the effort to use capstone to replace/complement binutils in 
hsdis. I wonder how easy it is to port
capstone to platforms in case it doesn't support them.

> I have couple of concerns with your patch. One is the method in which LLVM is 
> selected instead of binutils; afaict this
> depends on having the LLVM variable set when executing the makefile. At the 
> very least, this should be documented in
> the README. I don't think any more complicated configuration is really 
> necessary at this point. With full integration
> with the build system, a more user-friendly way of selecting hsdis backend 
> should be implemented, though.

I'll add documentation to the Makefile. And I agree, I would prefer not to have 
to go through the whole build
integration to integrate the support for LLVM.

> Second, and I don't know if this is an artifact of git/github/the new skara 
> tooling, but if you renamed hsdis.c to
> hsdis.cpp, this relationship does not show up, not even in the generated 
> webrevs. Instead they are considered a new + a
> deleted file. This makes it hard to see what code changes you have done in 
> that file.

That is Git not detecting enough similarities between the two files. I could 
probably hack my way around and find a way
to reduce the code diff if that's something you want.

> And third; have you tested that your changes (both changing the main file 
> from C to C++, and any code changes in it)
> does not break the old binutils functionality? Afaic there are no test suites 
> for exercising hsdis :-( so manual ad-hoc
> testing is likely needed.

I've tested on Linux-x86_64 and Linux-AArch64 on top of Windows-AArch64 and 
macOS-AArch64, and checked that both the
binutils builds and works as previously and that the LLVM-based hsdis has an 
equivalent output.

-

PR: https://git.openjdk.java.net/jdk/pull/392

RE: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

[Ludovic Henry]

It’s me who made a mistake. This PR should be associated with JEP 388 as you 
are rightly pointing out.

From: Daniel D. Daugherty 
Sent: Thursday, October 1, 2020 3:05 PM
To: Ludovic Henry ; David Holmes 
; David Holmes ; Andrew 
Haley ; Chris Plummer ; 
Magnus Ihse Bursie ; build-dev@openjdk.java.net; 
core-libs-...@openjdk.java.net; hotspot-...@openjdk.java.net; 
serviceability-...@openjdk.java.net; shenandoah-...@openjdk.java.net; Monica 
Beckwith 
Subject: Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

So I'm confused... this PR is associated with this bug ID:


Issue

  *   
JDK-8248238<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248238=02%7C01%7Cluhenry%40microsoft.com%7Ce428223ea04a45c2d40308d866562328%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371867436454353=FV0tr%2FktSPQDxHkI1JMr7UCgW4ygPi8d4yKsGuPVUg8%3D=0>:
 Implementation of JEP: Windows AArch64 Support


and JDK-8248238 is associated with this JEP:


JDK-8248496<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248496=02%7C01%7Cluhenry%40microsoft.com%7Ce428223ea04a45c2d40308d866562328%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371867436454353=HAjFLX%2BtIaKz%2FFULuav%2BUXn6qTZb%2BkjiS4ijsWw7RQE%3D=0>
 JEP 388: Windows/AArch64 Port

Am I missing something here?

Dan

On 10/1/20 5:56 PM, Ludovic Henry wrote:

Hi David,



The JEP is not yet targeted so we have to wait for that formality. But once 
that happens I can sponsor for you.



Perfect, I didn't know about the need for the JEP to be targeted before the 
merge.



Also note that the PR references the wrong JEP so can you please edit the 
description to fix that.



I'll work with @Monica to update the PR's description to point to 
https://openjdk.java.net/jeps/391<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fjeps%2F391=02%7C01%7Cluhenry%40microsoft.com%7Ce428223ea04a45c2d40308d866562328%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371867436464348=Pj%2FNQvzEa8mrhvY75OFVBG7k623Mgnr56Xo3On%2BoQGo%3D=0>
 instead.



Thank you!

Ludovic

RE: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

[Ludovic Henry]

Hi David,

> The JEP is not yet targeted so we have to wait for that formality. But once 
> that happens I can sponsor for you.

Perfect, I didn't know about the need for the JEP to be targeted before the 
merge.

> Also note that the PR references the wrong JEP so can you please edit the 
> description to fix that.

I'll work with @Monica to update the PR's description to point to 
https://openjdk.java.net/jeps/391 instead.

Thank you!
Ludovic
 

RE: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

[Ludovic Henry]

Hi,

As we now have a whole bunch of reviews (thank you all!), we would need a 
sponsor to get it merged.

Thank you :) 

-

PR: https://github.com/openjdk/jdk/pull/212

RE: Preliminary review for new WINENV support

[Ludovic Henry]

Hi Magnus,

I want to follow up on this work of yours, as we've particular interest in it 
for the Windows-AArch64 port.

Let me know how I could assist you in this effort.

Thank you,

--
Ludovic

-Original Message-
From: build-dev  On Behalf Of Yasumasa Suenaga
Sent: Wednesday, July 8, 2020 9:47 PM
To: Derek Keeler ; Monica Beckwith 
; Magnus Ihse Bursie 
; build-dev 
Subject: Re: Preliminary review for new WINENV support

On 2020/07/09 12:12, Derek Keeler wrote:
> After applying Suenaga's patch, I see this error:
> 
> checking wsl distribution... 
> /home/dekeeler/dev/openjdk.net/sandbox/build/.configure-support/generated-configure.sh:
>  line 32952: -d: command not found
> 
> I'm running Debian 10 in my WSL2 instance and it does not include 
> `lsb_release` by default. Installed it with `sudo apt-get install 
> lsb-release`.

It's better if we add AC_CHECK_PROG for lsb_release for Windows (for just WSL?)


> The next trouble I ran into is that I only have Visual Studio 2019 installed. 
> I tried to make it work but lack the necessary experience to wrangle this 
> code. Will start again in the morning after installing VS2017.

FYI: I can run configure script with VS2019 community edition on Ubuntu 20.04 
on both WSL 1 and 2, however I could not complete building OpenJDK image on WSL 
2 due to I/O performance issue.


Thanks,

Yasumasa


> -Derek
> 
> 
> From: build-dev  on behalf of Derek Keeler 
> 
> Sent: July 8, 2020 5:53 PM
> To: Monica Beckwith ; Magnus Ihse Bursie 
> ; build-dev 
> Subject: Re: Preliminary review for new WINENV support
> 
> This is fantastic!
> 
> I'm synching to this branch tonight and will start building it locally on my 
> WSL2 environment. I'll send questions/comments to this thread unless there is 
> a better place?
> 
> (Note: our internal email system may obfuscate the links below in future 
> replies, my apologies).
> 
> -Derek
> 
> 
> From: build-dev  on behalf of Monica 
> Beckwith 
> Sent: July 5, 2020 11:34 AM
> To: Magnus Ihse Bursie ; build-dev 
> 
> Subject: Re: Preliminary review for new WINENV support
> 
> Wow! Impressive work, @Magnus Ihse 
> Bursie . When working with 
> cross-compilation mods for aarch64-win port, I realized we needed to clean 
> up/better support the quirks around fixpath and also I was hoping to expand 
> the support to wsl2, etc. From what I am reading, you seem to have touched 
> all of these and more! I am mostly offline for the next two days, but will 
> start testing your changes when I am back online. Thank you for doing the 
> needful.
> 
> Monica
> 
> Get Outlook for Android
> 
> 
> From: build-dev  on behalf of Magnus Ihse 
> Bursie 
> Sent: Saturday, July 4, 2020 7:08:20 PM
> To: build-dev 
> Subject: Preliminary review for new WINENV support
> 
> I've been working for some time on a complete rewrite of how we handle the 
> pecularities of the Windows build environment. This new solution supports 
> Cygwin, Msys2, WSL1 and WSL2 (after a fashion, see below), what I have termed 
> different "winenvs".
> 
> One of the main design goals has been to minimize the difference for the 
> configure script and make files for the different winenvs, and leverage as 
> much shared code between them as possible. Another has been to try to collect 
> all the "trickiness" needed in as few places as possible, ideally just one, 
> instead of having it spread out all over the configure script. A third design 
> goal has been to prepare for cross-compilation for Windows from Linux, using 
> Wine.
> 
> It pretty soon turned out that I needed to get a better grip on how we detect 
> tools in configure, so a complete overhaul of this is included in the change. 
> Now we have more or less fully parted with the original autoconf functions, 
> which has long been too limited for us, and now finally has reached their end 
> of usefulness.
> 
> At this point, I have a prototype / preview that basically works, but has 
> some limitations.
> 
> I'd like to ask anyone interested in building OpenJDK on Windows to take the 
> patch for a spin. Especially if you have an esoteric or exotic setup!
> 
> Webrev: 
> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~ihse%2Fwinenv-preview-1%2Fwebrev.01%2Fdata=02%7C01%7Cluhenry%40microsoft.com%7C55d5bddc82f142c2312c08d823c33111%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637298668546029073sdata=k7tQ6%2BfwdrD8AGryNZdqAD%2Fk3Lnc%2B%2B75opEaWASISo0%3Dreserved=0
> 
> (If you prefer, you can check out the branch "ihse-winenv-branch" on 
> 

Re: OpenJDK extension to AArch64 and Windows

[Ludovic Henry]

VC/bin/x64
+cp $DEVKIT_ROOT/VC/redist/x64/$MSVCR_DLL $DEVKIT_ROOT/VC/bin/x64
+cp $DEVKIT_ROOT/VC/redist/arm64/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/arm64
+cp $DEVKIT_ROOT/VC/redist/arm64/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/arm64
 
 

 # Copy SDK files
@@ -152,8 +158,10 @@ mkdir -p $DEVKIT_ROOT/$SDK_VERSION/bin
 cp -r "$SDK_INSTALL_DIR/bin/$SDK_FULL_VERSION/x64" 
$DEVKIT_ROOT/$SDK_VERSION/bin/
 cp -r "$SDK_INSTALL_DIR/bin/$SDK_FULL_VERSION/x86" 
$DEVKIT_ROOT/$SDK_VERSION/bin/
 mkdir -p $DEVKIT_ROOT/$SDK_VERSION/lib
+cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/um/arm64" 
$DEVKIT_ROOT/$SDK_VERSION/lib/
 cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/um/x64" 
$DEVKIT_ROOT/$SDK_VERSION/lib/
 cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/um/x86" 
$DEVKIT_ROOT/$SDK_VERSION/lib/
+cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/ucrt/arm64" 
$DEVKIT_ROOT/$SDK_VERSION/lib/
 cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/ucrt/x64" 
$DEVKIT_ROOT/$SDK_VERSION/lib/
 cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/ucrt/x86" 
$DEVKIT_ROOT/$SDK_VERSION/lib/
 mkdir -p $DEVKIT_ROOT/$SDK_VERSION/Redist
@@ -188,6 +196,13 @@ echo-info 
"DEVKIT_MSVCR_DLL_x86_64=\"\$DEVKIT_ROOT/VC/redist/x64/$MSVCR_DLL\""
 echo-info "DEVKIT_MSVCP_DLL_x86_64=\"\$DEVKIT_ROOT/VC/redist/x64/$MSVCP_DLL\""
 echo-info 
"DEVKIT_UCRT_DLL_DIR_x86_64=\"\$DEVKIT_ROOT/10/Redist/ucrt/DLLs/x64\""
 echo-info ""
+echo-info 
"DEVKIT_TOOLCHAIN_PATH_aarch64=\"\$DEVKIT_ROOT/VC/bin/arm64:\$DEVKIT_ROOT/$SDK_VERSION/bin/x64:\$DEVKIT_ROOT/$SDK_VERSION/bin/x86\""
+echo-info 
"DEVKIT_VS_INCLUDE_aarch64=\"\$DEVKIT_ROOT/VC/include;\$DEVKIT_ROOT/VC/atlmfc/include;\$DEVKIT_ROOT/$SDK_VERSION/include/shared;\$DEVKIT_ROOT/$SDK_VERSION/include/ucrt;\$DEVKIT_ROOT/$SDK_VERSION/include/um;\$DEVKIT_ROOT/$SDK_VERSION/include/winrt\""
+echo-info 
"DEVKIT_VS_LIB_aarch64=\"\$DEVKIT_ROOT/VC/lib/arm64;\$DEVKIT_ROOT/VC/atlmfc/lib/arm64;\$DEVKIT_ROOT/$SDK_VERSION/lib/arm64\""
+echo-info 
"DEVKIT_MSVCR_DLL_aarch64=\"\$DEVKIT_ROOT/VC/redist/arm64/$MSVCR_DLL\""
+echo-info 
"DEVKIT_MSVCP_DLL_aarch64=\"\$DEVKIT_ROOT/VC/redist/arm64/$MSVCP_DLL\""
+echo-info 
"DEVKIT_UCRT_DLL_DIR_aarch64=\"\$DEVKIT_ROOT/10/Redist/ucrt/DLLs/arm64\""
+echo-info ""
 echo-info "DEVKIT_TOOLS_VERSION=\"$TOOLS_VERSION\""
 echo-info "DEVKIT_REDIST_VERSION=\"$REDIST_VERSION\""
 echo-info "DEVKIT_SDK_VERSION=\"$SDK_FULL_VERSION\""
diff --git a/make/devkit/createWindowsDevkit2019.sh 
b/make/devkit/createWindowsDevkit2019.sh
index 8a97f0c2a3b..a5c89f09faa 100644
--- a/make/devkit/createWindowsDevkit2019.sh
+++ b/make/devkit/createWindowsDevkit2019.sh
@@ -117,19 +117,23 @@ REDIST_SUBDIR="VC/Redist/MSVC/$REDIST_VERSION"
 echo "Copying VC..."
 rm -rf $DEVKIT_ROOT/VC
 mkdir -p $DEVKIT_ROOT/VC/bin
+cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" $DEVKIT_ROOT/VC/bin/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/x64" $DEVKIT_ROOT/VC/bin/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx86/x86" $DEVKIT_ROOT/VC/bin/
 mkdir -p $DEVKIT_ROOT/VC/lib
+cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/lib/arm64" $DEVKIT_ROOT/VC/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/lib/x64" $DEVKIT_ROOT/VC/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/lib/x86" $DEVKIT_ROOT/VC/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/include" $DEVKIT_ROOT/VC/
 mkdir -p $DEVKIT_ROOT/VC/atlmfc/lib
+cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/atlmfc/lib/arm64" 
$DEVKIT_ROOT/VC/atlmfc/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/atlmfc/lib/x64" $DEVKIT_ROOT/VC/atlmfc/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/atlmfc/lib/x86" $DEVKIT_ROOT/VC/atlmfc/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/atlmfc/include" $DEVKIT_ROOT/VC/atlmfc/
 mkdir -p $DEVKIT_ROOT/VC/Auxiliary
 cp -r "$VS_INSTALL_DIR/VC/Auxiliary/Build" $DEVKIT_ROOT/VC/Auxiliary/
 mkdir -p $DEVKIT_ROOT/VC/redist
+cp -r "$VS_INSTALL_DIR/$REDIST_SUBDIR/arm64" $DEVKIT_ROOT/VC/redist/
 cp -r "$VS_INSTALL_DIR/$REDIST_SUBDIR/x64" $DEVKIT_ROOT/VC/redist/
 cp -r "$VS_INSTALL_DIR/$REDIST_SUBDIR/x86" $DEVKIT_ROOT/VC/redist/
 
@@ -139,6 +143,8 @@ cp $DEVKIT_ROOT/VC/redist/x86/$MSVCR_DLL 
$DEVKIT_ROOT/VC/bin/x86
 cp $DEVKIT_ROOT/VC/redist/x86/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/x86
 cp $DEVKIT_ROOT/VC/redist/x64/$MSVCR_DLL $DEVKIT_ROOT/VC/bin/x64
 cp $DEVKIT_ROOT/VC/redist/x64/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/x64
+cp $DEVKIT_ROOT/VC/redist/arm64/$MSVCR_DLL $DEVKIT_ROOT/VC/bin/arm64
+cp $DEVKIT_ROOT/VC/redist/arm64/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/arm64
 
 
##

Re: Preliminary review for new WINENV support

[Ludovic Henry]

Hi,

I tried out your changes locally, and with Yasumasa's change and the following 
diff [1], I can confirm that this works on my setup (VS2019 devkit w/ Cygwin). 
I'll give a spin with WSL1 and WSL2, as well as VS2017.

[1] Diff to fix support for VS2019

--- a/make/autoconf/toolchain_microsoft.m4
+++ b/make/autoconf/toolchain_microsoft.m4
@@ -628,9 +606,9 @@ AC_DEFUN([TOOLCHAIN_SETUP_VS_RUNTIME_DLLS],
   fi

   AC_ARG_WITH(vcruntime-1-dll, [AS_HELP_STRING([--with-vcruntime-1-dll],
   [path to microsoft C++ runtime dll (vcruntime*_1.dll) (Windows x64 only) 
@<:@probed@:>@])])

-  if test "x$VCRUNTIME_1_NAME" != "x" && test "x$OPENJDK_TARGET_BITS" = x64; 
then
+  if test "x$VCRUNTIME_1_NAME" != "x" && test "x$OPENJDK_TARGET_CPU_BITS" = 
x64; then
 if test "x$with_vcruntime_1_dll" != x; then
   # If given explicitly by user, do not probe. If not present, fail 
directly.
   TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL($VCRUNTIME_1_NAME, 
[$with_vcruntime_1_dll],

I also want to propose integrating the bits to support cross-compilation with 
the microsoft toolchain as part of your change, even without adding the 
targetting for Windows-AArch64. The following diff [2] integrates such support 
for cross-compilation without adding Windows-AArch64:

[2] Diff to add support for cross-compilation

commit c23c78e33e57955d3f344383619592f34b84169b
Author: Ludovic Henry 
Date:   Tue Jul 7 11:35:41 2020 -0700

8248498: Add build system support for Windows AArch64 (Part 1)

This adds support for cross-compilation on Windows, without adding the
AArch64 specific bits.

https://bugs.openjdk.java.net/browse/JDK-8248498

diff --git a/make/autoconf/basic.m4 b/make/autoconf/basic.m4
index 7248163242d..60b4097cba9 100644
--- a/make/autoconf/basic.m4
+++ b/make/autoconf/basic.m4
@@ -111,6 +111,16 @@ AC_DEFUN([BASIC_EVAL_DEVKIT_VARIABLE],
   fi
 ])

+###
+# Evaluates platform specific overrides for build devkit variables.
+# $1: Name of variable
+AC_DEFUN([BASIC_EVAL_BUILD_DEVKIT_VARIABLE],
+[
+  if test "x[$]$1" = x; then
+eval $1="\${$1_${OPENJDK_BUILD_CPU}}"
+  fi
+])
+
 ###
 AC_DEFUN_ONCE([BASIC_SETUP_DEVKIT],
 [
diff --git a/make/autoconf/flags-ldflags.m4 b/make/autoconf/flags-ldflags.m4
index a2a52f98ef7..8af9a20b5e8 100644
--- a/make/autoconf/flags-ldflags.m4
+++ b/make/autoconf/flags-ldflags.m4
@@ -164,15 +164,14 @@ AC_DEFUN([FLAGS_SETUP_LDFLAGS_CPU_DEP],
 fi

   elif test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
-if test "x${OPENJDK_$1_CPU}" = "xx86"; then
-  $1_CPU_LDFLAGS="-safeseh"
-  # NOTE: Old build added -machine. Probably not needed.
-  $1_CPU_LDFLAGS_JVM_ONLY="-machine:I386"
+if test "x${OPENJDK_$1_CPU_BITS}" = "x32"; then
   $1_CPU_EXECUTABLE_LDFLAGS="-stack:327680"
-else
-  $1_CPU_LDFLAGS_JVM_ONLY="-machine:AMD64"
+elif test "x${OPENJDK_$1_CPU_BITS}" = "x64"; then
   $1_CPU_EXECUTABLE_LDFLAGS="-stack:1048576"
 fi
+if test "x${OPENJDK_$1_CPU}" = "xx86"; then
+  $1_CPU_LDFLAGS="-safeseh"
+fi
   fi

   # JVM_VARIANT_PATH depends on if this is build or target...
diff --git a/make/autoconf/flags.m4 b/make/autoconf/flags.m4
index 694d41052ba..8cbf306ab0c 100644
--- a/make/autoconf/flags.m4
+++ b/make/autoconf/flags.m4
@@ -204,32 +204,36 @@ AC_DEFUN_ONCE([FLAGS_SETUP_USER_SUPPLIED_FLAGS],
 # Param 1 - Optional prefix to all variables. (e.g BUILD_)
 AC_DEFUN([FLAGS_SETUP_SYSROOT_FLAGS],
 [
-  if test "x[$]$1SYSROOT" != "x"; then
-if test "x$TOOLCHAIN_TYPE" = xgcc; then
-  $1SYSROOT_CFLAGS="--sysroot=[$]$1SYSROOT"
-  $1SYSROOT_LDFLAGS="--sysroot=[$]$1SYSROOT"
-elif test "x$TOOLCHAIN_TYPE" = xclang; then
-  $1SYSROOT_CFLAGS="-isysroot [$]$1SYSROOT"
-  $1SYSROOT_LDFLAGS="-isysroot [$]$1SYSROOT"
-fi
-  fi
-
-  if test "x$OPENJDK_TARGET_OS" = xmacosx; then
-# We also need -iframework/System/Library/Frameworks
-$1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -iframework 
[$]$1SYSROOT/System/Library/Frameworks"
-$1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -iframework 
[$]$1SYSROOT/System/Library/Frameworks"
-# These always need to be set, or we can't find the frameworks embedded in 
JavaVM.framework
-# set this here so it doesn't have to be peppered throughout the forest
-$1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -F 
[$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
-$1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -F 
[$]$1SYSROOT/System/Library/Framework

Re: OpenJDK extension to AArch64 and Windows

[Ludovic Henry]

dows-compatible codebases to specify 
whether it's targetting a 64-bit platform or not. We need to define it to have 
Windows-specific code in the existing aarch64 code of the OpenJDK. It makes 
sense to define it for x64 as well as arm64, but I agree it's not a requirement.

> * In jib-profiles.js: I appreciate the effort, but this file is
> basically just for Oracle-internal usage. If and when we will add
> support for building on windows-aarch64, we can update the file to work
> properly with the JIB tool.

Ok.

> I am impressed that you manage to get cross-compilation working for
> Windows with that small amount of changes, though! If you had asked med
> beforehand, I'd have guessed that it would require more substantial
> changes. As you say, this is not something we have done before.

The meat of the change is in `toolchain.m4` with the support functions in 
`toolchain_windows.m4`. It is where I iterated the most to find the right 
encapsulation across the different components relying on it - and I've to say 
it wasn't straightforward to understand how all the pieces fit together. I'd be 
happy to work out with you a better way to do the foundational work of 
supporting cross-compilation with the Microsoft toolchain, just le me know how 
you'd like to proceed.

Thank you,

--
Ludovic


From: Magnus Ihse Bursie 
Sent: Monday, June 29, 2020 07:12
To: Ludovic Henry; Monica Beckwith; hotspot-runtime-...@openjdk.java.net; 
aarch64-port-...@openjdk.java.net; build-dev
Cc: openjdk-aarch64
Subject: Re: OpenJDK extension to AArch64 and Windows

I have now looked a bit more closely at the code. This is what I have
found so far that attracted my eye. Please note that this is not a
complete review. When you have a JEP and a test plan for how to verify
these changes and make sure you do not break existing platforms, you can
post a new RFR and I'll do a full review.

* In flags-cflags.m4: You don't have to set  $1_CFLAGS_CPU_JVM="", an
empty value is default for unspecified variables.

* In flags-ldflags.m4: The stack size seems dependent on CPU_BITS, not
the CPU arch. Please break out the -stack argument setting. Also, have
you verified if -machine is really needed? The comment says that it's
probably not; if it's just an old, unnecessary, precaution, we should
probably remove it instead, to simplify the logic.

* In platform.m4: These changes worries me. Neither of them were
necessary for the linux-aarch64 port. But now you are changing the
values for all aarch64 builds, not just windows-aarch64. Have you
discovered a bug for linux-aarch64? Otherwise, these changes looks like
they are going to break linux-aarch64. If you believe you need to modify
these legacy values (which we'd rather move away from), please see if
you have made changes elsewhere that can be resolved without resorting
to adding new identifiers to the legacy values.

* In basic.m4: Please move BASIC_EVAL_BUILD_DEVKIT_VARIABLE to be
positioned next to BASIC_EVAL_DEVKIT_VARIABLE.

* In toolchain_windows.m4:
  In TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL, if you know about the upcoming
changes to file, why don't you add both the old and the new pattern to
the test?

  In TOOLCHAIN_SETUP_MSVC_DLL, when it was just two instances, the code
duplication could be accepted, but with three instances you need to
generalize this and refactor out the changing platform part of the path
only to the if statement. This applies, with some variation, to all four
changed places.

  In the new TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS, you are doing
   AC_SUBST($1SYSROOT_CFLAGS)
   AC_SUBST($1SYSROOT_LDFLAGS)

However, that seems superfluous, since it is already done by
FLAGS_SETUP_SYSROOT_FLAGS in flags.m4. In fact, now that I checked this,
I spotted that we *already* do an unnecessary AC_SUBST in
FLAGS_POST_TOOLCHAIN for the build sysroot flags! :-o

* In GensrcMisc,gmk: You are changing this for all users of the
microsoft toolchain. I don't recall seeing any problems with this on
x64. What version of Visual Studio are you using? Is this a limitation
in the aarch64 version of CL.EXE, or does it apply to other platforms as
well? Finally, if we do need to keep it, please use "-" as prefix for
options (even though the microsoft tooling normally suggests the
non-standard "/" -- this can all too easily be confused with path names.)

* In GensrcAdlc.gmk: You are adding -D_WIN64=1 for all 64-bit platforms,
i.e. also for x64, which has apparently worked fine until now without
that define. What does the define do, and what is the rationale for not
only adding it on your platform?

* In jib-profiles.js: I appreciate the effort, but this file is
basically just for Oracle-internal usage. If and when we will add
support for building on windows-aarch64, we can update the file to work
properly with the JIB tool.

I am impressed that you manage to get cross-compilation working for
Windows with th

Re: OpenJDK extension to AArch64 and Windows

[Ludovic Henry]

Hi Magnus,

Happy to answer any question you have on the build system changes.

A lot of the changes were due to the build system not supporting 
cross-compilation well when targetting the microsoft toolchain (it just never 
really had to support it). We had to go through a few hoops to remove as many 
of our own quick hacks, initially there just to get things building - like 
hardcoding the target being windows-aarch64 for example.

Thank you for your review,

--
Ludovic


From: Magnus Ihse Bursie 
Sent: Wednesday, June 24, 2020 13:44
To: Monica Beckwith; hotspot-runtime-...@openjdk.java.net; 
aarch64-port-...@openjdk.java.net; build-dev
Cc: openjdk-aarch64
Subject: Re: OpenJDK extension to AArch64 and Windows

Hi Monica,

All build system changes must be sent to build-dev for review by the
build team, and you are doing quite a lot of build changes. (I'm cc:ing
build-dev now.)

I did a quick scan and found some changes that looked odd enough to draw
my attention.

I will need some time to fully understand what you are trying to
accomplish here, before I can give a full review.

/Magnus


On 2020-06-24 18:40, Monica Beckwith wrote:
> Hello OpenJDK community,
>
> As the project lead here @Microsoft, I am pleased to share that we have been 
> working towards a Windows addition to the OpenJDK AArch64 port. We are very 
> thankful to all that have contributed to the Linux+aarch64 and 
> Windows+x86-64. Both these codebases came to our rescue on numerous occasions.
>
> Support status: We have successfully ported C2 and can build the server 
> release (cross-compiled environment)
> Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC)
> Tests and benchmarks covered [1]: JTReg [2], JCStress, 
> jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, 
> SPEC JBB2005.
> Umbrella Bug ID: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248238data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002619088sdata=QXhd0zUDi2tqCLKiY%2F%2BKZzOzQNLirhq9WdxVAvogkqo%3Dreserved=0
> Webrevs:
> `Webrev P1`: 
> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fwinarm64_p1_llp64%2Fdata=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002619088sdata=I4NuehXTkw1U6pChqT7Po0e4m8CvPTgucp0BtMN%2FFGk%3Dreserved=0
>   &
> `Webrev P2`: 
> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fwinarm64_p2_new-target%2Fdata=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002619088sdata=UKxXrBjXUOM7Yw7qQ02TOujYnNp0W439FclIqoVs7mk%3Dreserved=0
>
> The first patch `Webrev P1` (patch 1 aka P1 in our tests) helps integrate 
> support for Windows (LLP64) on Linux + AArch64
> The second patch `Webrev P2` (patch 2 aka P2 in our tests) adds the 
> 'windows-aarch64' support in `os_cpu`. We also had to modify shared code, and 
> I am highlighting a few details here:
>   * In windows_x86 such as the `get_frame_at_stack_banging_point` in 
> `os_windows_x86.cpp`,
>   * In `os/windows os_windows.cpp` to make it aware of Windows + Arm64
>   * `os/windows` in `threadCritical_windows.cpp`,
>   * Windbg support
>   * `globalDefinitions_visCPP.hpp` in `share/utilities`
>   * We also added Vectored Exception Handling (VEH) to P2, as it is a 
> requirement on Windows + Arm64 (due to ABI specifications).
> Also, in `Webrev P2`, you will find that we have made some significant 
> changes to `cpu/aarch64` around register usage since on Windows + Arm64, 
> register R18 points to TEB [4]. We have discussed this with Andrew Haley and 
> Andrew Dinn, and they are helping us with a cleaner implementation of the 
> same. Their constant support and guidance have humbled me.
>
> I'd also like to recognize the great work done by Ludovic Henry (our resident 
> runtime expert) in driving the C2 support and by Bernhard Urban-Forster, (who 
> recently joined our team) in helping expand the coverage to G1 GC.
>
> As a part of this project, we have also worked on two additional patches:
>   * Expanding VEH on Windows to x86-64 (patch 3 aka P3 in our tests). 
> Details here: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8247941data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002629036sdata=cH8q0LmaYoV%2BZfiunRHJYTyHz3kfm2RpnC5phc9Th8c%3Dreserved=0
>   * Improvements in the shared cross-platform code on Windows (patch