Re: OpenJDK extension to AArch64 and Windows
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: OpenJDK extension to AArch64 and Windows
e. On the other hand, we try to follow the pattern of "create variable, call AC_SUBST" for our own sanity. Conceptually, the microsoft toolchain setup is almost equivalent to FLAGS_PRE_TOOLCHAIN. That is, the result should be that we have a set of "sysroot" (think "global") flags that should always be added. I have a patch in the works that changes this somewhat, and makes the dependencies clearer. * 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.) Ok. * 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? It is the default define used on Windows-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. Ok, sounds good. Keep it as it is then. * 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. I think you have found more or less exactly the right spots to inject the support for cross-compilation. I think I'd ended up with something similar if I was tasked with getting cross-compilation work on Windows. Maybe there's room for more generalisations, but it's a bit hard to say at this moment. I think things might clear up a bit more when I get the "unified winenv" patch in. It makes the sysroot cflag handling a bit more transparent. /Magnus 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,
Re: OpenJDK extension to AArch64 and Windows
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
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 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. /Magnus On 2020-06-24 23:33, Ludovic Henry wrote: 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 t
RE: OpenJDK extension to AArch64 and Windows
Hey Magnus, Thank you so much for adding build-dev. I have subscribed to it now. It will be great if Ludovic can work with you in solving questions/concerns. If most of them are build system related, please feel free to drop the other aliases (except the cc one ). I appreciate you working with / guiding us. -Monica -Original Message- From: Ludovic Henry Sent: Wednesday, June 24, 2020 4:34 PM To: Magnus Ihse Bursie ; 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 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%7CMonica.Bec > kwith%40microsoft.com%7C120c1eb9f5a7460546b608d818864aec%7C72f988bf86f > 141af91ab2d7cd011db47%7C1%7C0%7C637286312353215308sdata=nkoPhKNfc > GMjMoW8ZHlWFEunv72LJr8WbGYGAcjeVbs%3Dreserved=0 > Webrevs: > `Webrev P1`: > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.open > jdk.java.net%2F~burban%2Fwinarm64_p1_llp64%2Fdata=02%7C01%7CMonic > a.Beckwith%40microsoft.com%7C120c1eb9f5a7460546b608d818864aec%7C72f988 > bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286312353220284sdata=wWVm > AxaJ90jIoGd%2FFKn1ikVO17iFk9s6tDp9Eoaxemk%3Dreserved=0 & `Webrev > P2`: > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.open > jdk.java.net%2F~burban%2Fwinarm64_p2_new-target%2Fdata=02%7C01%7C > Monica.Beckwith%40microsoft.com%7C120c1eb9f5a7460546b608d818864aec%7C7 > 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286312353220284sdata > =3jvwY%2B9rZkpBZBbh7c%2FeKsigh5Y5L%2BbdnAVlCF0yFcA%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 driv
Re: OpenJDK extension to AArch64 and Windows
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
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://bugs.openjdk.java.net/browse/JDK-8248238 Webrevs: `Webrev P1`: http://cr.openjdk.java.net/~burban/winarm64_p1_llp64/ & `Webrev P2`: http://cr.openjdk.java.net/~burban/winarm64_p2_new-target/ 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://bugs.openjdk.java.net/browse/JDK-8247941 * Improvements in the shared cross-platform code on Windows (patch 4 aka P4 in our tests) - We will send out a separate patch soon. We welcome any feedback and comments from the community and are looking forward to working together. Regards, Monica [1] https://github.com/microsoft/openjdk-aarch64/blob/master/wkload-status-on-Win%2BArm64.md [2] https://github.com/microsoft/openjdk-aarch64/blob/master/JTRegtests.md [3] https://github.com/microsoft/openjdk-aarch64/blob/master/SPECJBB2015-test-matrices.md [4] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#integer-registers
