From vkempik at azul.com Sat Aug 1 07:24:57 2020 From: vkempik at azul.com (Vladimir Kempik) Date: Sat, 1 Aug 2020 07:24:57 +0000 Subject: RFR: 8250876: Build system preparation to macos on aarch64 Message-ID: Hello Please review this change for JDK-8250876 This changeset adds support for macos/aarch64 into build system. It will allow to crosscompile for macos/aarch64 using intel mac as well. This changeset does NOT address some arm specific issues in the macos related code, we plan to do that in s separate commit. An example of configure to cross-compile for macos/arm64: --with-boot-jdk=/path/to/java/ --with-build-jdk=/path/to/same/java/as/compiled --disable-warnings-as-errors --with-jvm-variants=zero --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch arm64' --with-extra-ldflags='-arch arm64 -F/Path/To/Folder/Containing/JNF_framework/' ?with-extra-cxxflags='-arch arm64? JNF.framework is missing arm64 part as of next macos release, but Apple has opensourced it. Fix to adlc were needed due to it using symbols from stdc++ and not linking to it, so it fails when doing make images. The webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.00/ The bug: https://bugs.openjdk.java.net/browse/JDK-8250876 Testing: jdk/submit. Thanks, Vladimir. From david.holmes at oracle.com Mon Aug 3 03:51:06 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Aug 2020 13:51:06 +1000 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: References: Message-ID: <5b33b051-5232-9776-78d4-69773781cf52@oracle.com> Hi Vladimir, On 1/08/2020 5:24 pm, Vladimir Kempik wrote: > Hello > > Please review this change for JDK-8250876 > > This changeset adds support for macos/aarch64 into build system. macOS/Aarch64 is not yet an accepted platform for the OpenJDK. Adding such a platform requires a JEP as is being done for the Windows/Aarch64 port. Thanks, David ----- > It will allow to crosscompile for macos/aarch64 using intel mac as well. > > This changeset does NOT address some arm specific issues in the macos related code, we plan to do that in s separate commit. > > An example of configure to cross-compile for macos/arm64: > > --with-boot-jdk=/path/to/java/ --with-build-jdk=/path/to/same/java/as/compiled --disable-warnings-as-errors --with-jvm-variants=zero --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch arm64' --with-extra-ldflags='-arch arm64 -F/Path/To/Folder/Containing/JNF_framework/' ?with-extra-cxxflags='-arch arm64? > > JNF.framework is missing arm64 part as of next macos release, but Apple has opensourced it. > > Fix to adlc were needed due to it using symbols from stdc++ and not linking to it, so it fails when doing make images. > > The webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.00/ > The bug: https://bugs.openjdk.java.net/browse/JDK-8250876 > > Testing: jdk/submit. > > Thanks, Vladimir. > From erik.joelsson at oracle.com Mon Aug 3 12:42:44 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 3 Aug 2020 05:42:44 -0700 Subject: JDK 16 RFR of build changes for JDK-8071961: Add javac lint warning when a default constructor is created In-Reply-To: <87717076-1eb8-a757-6be3-72ed71829e10@oracle.com> References: <87717076-1eb8-a757-6be3-72ed71829e10@oracle.com> Message-ID: <2da5896f-e3f9-fa56-e6c3-6045e160145f@oracle.com> Looks good. /Erik On 2020-07-31 14:18, Joe Darcy wrote: > Hello, > > FYI, a new javac lint warning is in the works and out for review on > compiler-dev: > > ??? JDK-8071961: Add javac lint warning when a default constructor is > created > https://mail.openjdk.java.net/pipermail/compiler-dev/2020-July/014782.html > > > The warning notes where a formal API class exposes a default > constructor, that is, an implicit constructor generated by the > compiler (see JLS 8.8.9 for details > https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.8.9). > > The JDK modules are generally compiled under "-Xlint:all -Werror". > Therefore, if a new lint warning is added *without* first clearing > those conditions, the build will break. Many modules have already been > cleared (JDK-8250212); others are still in progress (JDK-8250639). > > Please review the make system portions of JDK-8071961 that disable the > warning on modules where the new warning still has some occurrences: > > ??? http://cr.openjdk.java.net/~darcy/8071961.7/ > > Patch for the relevant file below. Depending on the relative timing of > fixing the warning locations and the javac changes being ready, some > of the module changes in the make file might be removed. > > Thanks, > > -Joe > > --- old/make/CompileJavaModules.gmk??? 2020-07-31 14:04:28.285167000 > -0700 > +++ new/make/CompileJavaModules.gmk??? 2020-07-31 14:04:27.657167000 > -0700 > @@ -76,6 +76,7 @@ > > ?################################################################################ > > > +java.desktop_DISABLED_WARNINGS += default-ctor > ?java.desktop_DOCLINT += -Xdoclint:all/protected,-reference \ > ???? '-Xdoclint/package:java.*,javax.*' > ?java.desktop_COPY += .gif .png .wav .txt .xml .css .pf > @@ -298,6 +299,10 @@ > > ?################################################################################ > > > +jdk.accessibility_DISABLED_WARNINGS += default-ctor > + > +################################################################################ > > + > ?jdk.charsets_COPY += .dat > > ?################################################################################ > > @@ -347,10 +352,19 @@ > > ?################################################################################ > > > +jdk.jartool_DISABLED_WARNINGS += default-ctor > ?jdk.jartool_JAVAC_FLAGS += -XDstringConcat=inline > > ?################################################################################ > > > +jdk.httpserver_DISABLED_WARNINGS += default-ctor > + > +################################################################################ > > + > +jdk.unsupported.desktop_DISABLED_WARNINGS += default-ctor > + > +################################################################################ > > + > ?# No SCTP implementation on Mac OS X or AIX. These classes should be > excluded. > ?SCTP_IMPL_CLASSES = \ > $(TOPDIR)/src/jdk.sctp/unix/classes/sun/nio/ch/sctp/AssociationChange.java > \ > From erik.joelsson at oracle.com Mon Aug 3 12:57:45 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 3 Aug 2020 05:57:45 -0700 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: References: Message-ID: Hello Vladimir, These changes look innocent enough to me. They aren't actually adding macosx-aarch64 support, they are just removing two minor (and more likely OS version related) hurdles from the build. You still have to provide the actual configuration on the configure command line as is shown in your example. Before we can call build system support, we would need configure to automatically setup those flags and add a separate parameter for the JNF framework. So, given that, I don't think this change warrants a JEP in itself. My only complaint is that you revert jib-profiles.js. That file is only used internally at Oracle. If/when we need it to support macosx-aarch64, we will provide those changes. I must say I'm happy to see you managed to get a working build configuration with just this though! /Erik On 2020-08-01 00:24, Vladimir Kempik wrote: > Hello > > Please review this change for JDK-8250876 > > This changeset adds support for macos/aarch64 into build system. > It will allow to crosscompile for macos/aarch64 using intel mac as well. > > This changeset does NOT address some arm specific issues in the macos related code, we plan to do that in s separate commit. > > An example of configure to cross-compile for macos/arm64: > > --with-boot-jdk=/path/to/java/ --with-build-jdk=/path/to/same/java/as/compiled --disable-warnings-as-errors --with-jvm-variants=zero --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch arm64' --with-extra-ldflags='-arch arm64 -F/Path/To/Folder/Containing/JNF_framework/' ?with-extra-cxxflags='-arch arm64? > > JNF.framework is missing arm64 part as of next macos release, but Apple has opensourced it. > > Fix to adlc were needed due to it using symbols from stdc++ and not linking to it, so it fails when doing make images. > > The webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.00/ > The bug: https://bugs.openjdk.java.net/browse/JDK-8250876 > > Testing: jdk/submit. > > Thanks, Vladimir. From david.holmes at oracle.com Mon Aug 3 22:46:32 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 Aug 2020 08:46:32 +1000 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: References: Message-ID: <2c0de319-aeb2-2c4d-2633-ddd612579165@oracle.com> On 3/08/2020 10:57 pm, Erik Joelsson wrote: > Hello Vladimir, > > These changes look innocent enough to me. They aren't actually adding > macosx-aarch64 support, they are just removing two minor (and more > likely OS version related) hurdles from the build. You still have to > provide the actual configuration on the configure command line as is > shown in your example. Before we can call build system support, we would > need configure to automatically setup those flags and add a separate > parameter for the JNF framework. So, given that, I don't think this > change warrants a JEP in itself. Of course this change doesn't warrant a JEP in itself :) My point is that until we have a JEP for the platform that is being targeted then we shouldn't be making changes to provide support for that platform. That said I didn't actually look at the changes but focused on the larger stated aim, so apologies for that. The actual changes here are small and not obviously related to supporting macOS-Aarch64. But I'm unclear on this change as it affects all macOS builds: 42 else ifeq ($(call isBuildOs, macosx), true) 43 ADLC_LDFLAGS := -lc++ if this was fixing a bug as indicated, why do we not see this bug in regular builds? Thanks, David ----- > My only complaint is that you revert jib-profiles.js. That file is only > used internally at Oracle. If/when we need it to support macosx-aarch64, > we will provide those changes. > > I must say I'm happy to see you managed to get a working build > configuration with just this though! > > /Erik > > On 2020-08-01 00:24, Vladimir Kempik wrote: >> Hello >> >> Please review this change for JDK-8250876 >> >> This changeset adds support for macos/aarch64 into build system. >> It will allow to crosscompile for macos/aarch64 using intel mac as well. >> >> This changeset does NOT address some arm specific issues in the macos >> related code, we plan to do that in s separate commit. >> >> An example of configure to cross-compile for macos/arm64: >> >> --with-boot-jdk=/path/to/java/ >> --with-build-jdk=/path/to/same/java/as/compiled >> --disable-warnings-as-errors --with-jvm-variants=zero >> --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch >> arm64' --with-extra-ldflags='-arch arm64 >> -F/Path/To/Folder/Containing/JNF_framework/' >> ?with-extra-cxxflags='-arch arm64? >> >> JNF.framework is missing arm64 part as of next macos release, but >> Apple has opensourced it. >> >> Fix to adlc were needed due to it using symbols from stdc++ and not >> linking to it, so it fails when doing make images. >> >> The webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.00/ >> The bug: https://bugs.openjdk.java.net/browse/JDK-8250876 >> >> Testing: jdk/submit. >> >> Thanks, Vladimir. From galder at redhat.com Tue Aug 4 08:40:45 2020 From: galder at redhat.com (Galder Zamarreno) Date: Tue, 4 Aug 2020 10:40:45 +0200 Subject: RFR: JDK-8248158 Configure fails with autoconf not found even though it's installed In-Reply-To: References: <5b25d03a-675f-072a-5772-2e2b03739484@oracle.com> <7ba7f5cd-abd2-3331-e836-97e769a8189d@redhat.com> Message-ID: Hi all, Could someone have a look at my updated webrev below? Thanks Galder On Fri, Jul 10, 2020 at 6:48 PM Galder Zamarreno wrote: > Hi again, > > I've got a new webrev for this: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/02/webrev/ > > It further expands `type -p` to replace `command -v` uses. It also > replaces $WHICH usages and removes the check for `which` as well. > > I tried Simon's suggestions, but getting that right complicated the patch. > > Galder > > > On Tue, Jul 7, 2020 at 4:31 PM Galder Zamarreno wrote: > >> >> >> On Mon, Jul 6, 2020 at 10:50 PM Simon Tooke wrote: >> >>> (Disclaimer: I am not a reviewer, so this is an opinion, not a review) >>> >>> I have tested this on Windows and it built without issue, although the >>> submit repo should be the final gate. I'd also like to add my void to >>> simply redefining 'WHICH' as it leads to less changes in the source >>> code, which would make life easier should this be backported to 11u >>> and/or 8u. >> >> >> So, you would just switch the UTIL_REQUIRE_PROGS call for WHICH to be >> `type ...` instead? >> >> >>> >>> -Simon >>> >>> On 2020-07-02 4:22 a.m., Galder Zamarreno wrote: >>> > On Thu, Jul 2, 2020 at 12:37 AM Magnus Ihse Bursie < >>> > magnus.ihse.bursie at oracle.com> wrote: >>> > >>> >> >>> >> On 2020-07-01 12:05, Galder Zamarreno wrote: >>> >>> Using `which` to check whether commands exist can result in confusing >>> >>> errors when `which` itself is not installed in the system. This is >>> the >>> >> case >>> >>> with `autoconf`, where if `autoconf` is present but `which` isn't, >>> the >>> >>> build system says that `autoconf` is missing, when in reality it is >>> >> `which` >>> >>> which is missing. The fix switches autoconf uses of `which` for >>> `type -p` >>> >>> instead, which is a Bash built-in command. >>> >>> >>> >>> I've tested the fix with a fedora docker container that had >>> `autoconf` >>> >>> installed but `which`. When using `type -p` it correctly detects >>> >> `autoconf` >>> >>> installed and eventually fails saying that `which` is not installed, >>> >> which >>> >>> is the expected behaviour. >>> >>> >>> >>> `which` is still in use in make/autoconf/util_windows.m4. A possible >>> >> future >>> >>> improvement would be to see if `which` use there could be replaced as >>> >> well. >>> >>> Eventually, when no `which` uses remain, the presence check for >>> `which` >>> >>> could be removed. >>> >> I agree that we should replace "which" with "type -p" everywhere. The >>> >> best way to do this is probably to replace the value of $WHICH with >>> >> "type -p". It's a bash built-in, so we can count on its presence. If >>> you >>> >> want to fix that as part of this bug, I'm ok with it, otherwise we >>> >> should open a new bug to track this. I think there is also one or two >>> >> instances of "command" recently added as (better, but not as good as >>> >> "type -p") replacements for which. >>> >> >>> > I discovered one place in util.m4 where command was being used. >>> > >>> > There are other places outside of make/ where command is used but I >>> feel >>> > those are a bit out of scope here. >>> > >>> > My main objective is that from a configure perspective, we'd try to >>> reduce >>> > the number of dependencies needed to build things. >>> > >>> > I'll send an updated webrev shortly. >>> > >>> > >>> >> /Magnus >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248158 >>> >>> WebRev: >>> >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/ >>> >>> Galder >>> >> >>> >>> From erik.joelsson at oracle.com Tue Aug 4 12:38:46 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Aug 2020 05:38:46 -0700 Subject: RFR: JDK-8248158 Configure fails with autoconf not found even though it's installed In-Reply-To: References: <5b25d03a-675f-072a-5772-2e2b03739484@oracle.com> <7ba7f5cd-abd2-3331-e836-97e769a8189d@redhat.com> Message-ID: I think this looks ok. Have you tested it on Windows? /Erik On 2020-08-04 01:40, Galder Zamarreno wrote: > Hi all, > > Could someone have a look at my updated webrev below? > > Thanks > > Galder > > > On Fri, Jul 10, 2020 at 6:48 PM Galder Zamarreno wrote: > >> Hi again, >> >> I've got a new webrev for this: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/02/webrev/ >> >> It further expands `type -p` to replace `command -v` uses. It also >> replaces $WHICH usages and removes the check for `which` as well. >> >> I tried Simon's suggestions, but getting that right complicated the patch. >> >> Galder >> >> >> On Tue, Jul 7, 2020 at 4:31 PM Galder Zamarreno wrote: >> >>> >>> On Mon, Jul 6, 2020 at 10:50 PM Simon Tooke wrote: >>> >>>> (Disclaimer: I am not a reviewer, so this is an opinion, not a review) >>>> >>>> I have tested this on Windows and it built without issue, although the >>>> submit repo should be the final gate. I'd also like to add my void to >>>> simply redefining 'WHICH' as it leads to less changes in the source >>>> code, which would make life easier should this be backported to 11u >>>> and/or 8u. >>> >>> So, you would just switch the UTIL_REQUIRE_PROGS call for WHICH to be >>> `type ...` instead? >>> >>> >>>> -Simon >>>> >>>> On 2020-07-02 4:22 a.m., Galder Zamarreno wrote: >>>>> On Thu, Jul 2, 2020 at 12:37 AM Magnus Ihse Bursie < >>>>> magnus.ihse.bursie at oracle.com> wrote: >>>>> >>>>>> On 2020-07-01 12:05, Galder Zamarreno wrote: >>>>>>> Using `which` to check whether commands exist can result in confusing >>>>>>> errors when `which` itself is not installed in the system. This is >>>> the >>>>>> case >>>>>>> with `autoconf`, where if `autoconf` is present but `which` isn't, >>>> the >>>>>>> build system says that `autoconf` is missing, when in reality it is >>>>>> `which` >>>>>>> which is missing. The fix switches autoconf uses of `which` for >>>> `type -p` >>>>>>> instead, which is a Bash built-in command. >>>>>>> >>>>>>> I've tested the fix with a fedora docker container that had >>>> `autoconf` >>>>>>> installed but `which`. When using `type -p` it correctly detects >>>>>> `autoconf` >>>>>>> installed and eventually fails saying that `which` is not installed, >>>>>> which >>>>>>> is the expected behaviour. >>>>>>> >>>>>>> `which` is still in use in make/autoconf/util_windows.m4. A possible >>>>>> future >>>>>>> improvement would be to see if `which` use there could be replaced as >>>>>> well. >>>>>>> Eventually, when no `which` uses remain, the presence check for >>>> `which` >>>>>>> could be removed. >>>>>> I agree that we should replace "which" with "type -p" everywhere. The >>>>>> best way to do this is probably to replace the value of $WHICH with >>>>>> "type -p". It's a bash built-in, so we can count on its presence. If >>>> you >>>>>> want to fix that as part of this bug, I'm ok with it, otherwise we >>>>>> should open a new bug to track this. I think there is also one or two >>>>>> instances of "command" recently added as (better, but not as good as >>>>>> "type -p") replacements for which. >>>>>> >>>>> I discovered one place in util.m4 where command was being used. >>>>> >>>>> There are other places outside of make/ where command is used but I >>>> feel >>>>> those are a bit out of scope here. >>>>> >>>>> My main objective is that from a configure perspective, we'd try to >>>> reduce >>>>> the number of dependencies needed to build things. >>>>> >>>>> I'll send an updated webrev shortly. >>>>> >>>>> >>>>>> /Magnus >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248158 >>>>>>> WebRev: >>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/ >>>>>>> Galder >>>> From galder at redhat.com Tue Aug 4 13:25:56 2020 From: galder at redhat.com (Galder Zamarreno) Date: Tue, 4 Aug 2020 15:25:56 +0200 Subject: RFR: JDK-8248158 Configure fails with autoconf not found even though it's installed In-Reply-To: References: <5b25d03a-675f-072a-5772-2e2b03739484@oracle.com> <7ba7f5cd-abd2-3331-e836-97e769a8189d@redhat.com> Message-ID: Hi Erik, I've been in contact with Simon (cc) who has been testing the patch on Windows and he said it all looked good. @Simon Tooke , do you need to verify again? Galder On Tue, Aug 4, 2020 at 2:40 PM Erik Joelsson wrote: > I think this looks ok. Have you tested it on Windows? > > /Erik > > On 2020-08-04 01:40, Galder Zamarreno wrote: > > Hi all, > > > > Could someone have a look at my updated webrev below? > > > > Thanks > > > > Galder > > > > > > On Fri, Jul 10, 2020 at 6:48 PM Galder Zamarreno > wrote: > > > >> Hi again, > >> > >> I've got a new webrev for this: > >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/02/webrev/ > >> > >> It further expands `type -p` to replace `command -v` uses. It also > >> replaces $WHICH usages and removes the check for `which` as well. > >> > >> I tried Simon's suggestions, but getting that right complicated the > patch. > >> > >> Galder > >> > >> > >> On Tue, Jul 7, 2020 at 4:31 PM Galder Zamarreno > wrote: > >> > >>> > >>> On Mon, Jul 6, 2020 at 10:50 PM Simon Tooke wrote: > >>> > >>>> (Disclaimer: I am not a reviewer, so this is an opinion, not a review) > >>>> > >>>> I have tested this on Windows and it built without issue, although the > >>>> submit repo should be the final gate. I'd also like to add my void to > >>>> simply redefining 'WHICH' as it leads to less changes in the source > >>>> code, which would make life easier should this be backported to 11u > >>>> and/or 8u. > >>> > >>> So, you would just switch the UTIL_REQUIRE_PROGS call for WHICH to be > >>> `type ...` instead? > >>> > >>> > >>>> -Simon > >>>> > >>>> On 2020-07-02 4:22 a.m., Galder Zamarreno wrote: > >>>>> On Thu, Jul 2, 2020 at 12:37 AM Magnus Ihse Bursie < > >>>>> magnus.ihse.bursie at oracle.com> wrote: > >>>>> > >>>>>> On 2020-07-01 12:05, Galder Zamarreno wrote: > >>>>>>> Using `which` to check whether commands exist can result in > confusing > >>>>>>> errors when `which` itself is not installed in the system. This is > >>>> the > >>>>>> case > >>>>>>> with `autoconf`, where if `autoconf` is present but `which` isn't, > >>>> the > >>>>>>> build system says that `autoconf` is missing, when in reality it is > >>>>>> `which` > >>>>>>> which is missing. The fix switches autoconf uses of `which` for > >>>> `type -p` > >>>>>>> instead, which is a Bash built-in command. > >>>>>>> > >>>>>>> I've tested the fix with a fedora docker container that had > >>>> `autoconf` > >>>>>>> installed but `which`. When using `type -p` it correctly detects > >>>>>> `autoconf` > >>>>>>> installed and eventually fails saying that `which` is not > installed, > >>>>>> which > >>>>>>> is the expected behaviour. > >>>>>>> > >>>>>>> `which` is still in use in make/autoconf/util_windows.m4. A > possible > >>>>>> future > >>>>>>> improvement would be to see if `which` use there could be replaced > as > >>>>>> well. > >>>>>>> Eventually, when no `which` uses remain, the presence check for > >>>> `which` > >>>>>>> could be removed. > >>>>>> I agree that we should replace "which" with "type -p" everywhere. > The > >>>>>> best way to do this is probably to replace the value of $WHICH with > >>>>>> "type -p". It's a bash built-in, so we can count on its presence. If > >>>> you > >>>>>> want to fix that as part of this bug, I'm ok with it, otherwise we > >>>>>> should open a new bug to track this. I think there is also one or > two > >>>>>> instances of "command" recently added as (better, but not as good as > >>>>>> "type -p") replacements for which. > >>>>>> > >>>>> I discovered one place in util.m4 where command was being used. > >>>>> > >>>>> There are other places outside of make/ where command is used but I > >>>> feel > >>>>> those are a bit out of scope here. > >>>>> > >>>>> My main objective is that from a configure perspective, we'd try to > >>>> reduce > >>>>> the number of dependencies needed to build things. > >>>>> > >>>>> I'll send an updated webrev shortly. > >>>>> > >>>>> > >>>>>> /Magnus > >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248158 > >>>>>>> WebRev: > >>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/ > >>>>>>> Galder > >>>> > > From beurba at microsoft.com Tue Aug 4 14:02:56 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Tue, 4 Aug 2020 14:02:56 +0000 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: <2c0de319-aeb2-2c4d-2633-ddd612579165@oracle.com> References: , <2c0de319-aeb2-2c4d-2633-ddd612579165@oracle.com> Message-ID: Good observation David, the change in adlc is just fixing a symptom. The difference to a regular macOS build is that technically, despite running on the same machine, it's actually cross compiling due to Rosetta being the --build=x86_64 system. Being a cross-compile, we therefore hit this case: https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921 And thus infers `/usr/bin/CC` for CXX. I guess cross compiling hasn't been a thing on macOS yet. I tried the following and it passes the adlc build: --- a/make/autoconf/toolchain.m4 +++ b/make/autoconf/toolchain.m4 @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], # find the build compilers in the tools dir, if needed. UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc]) UTIL_FIXUP_EXECUTABLE(BUILD_CC) - UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++]) + UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++]) UTIL_FIXUP_EXECUTABLE(BUILD_CXX) UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm) UTIL_FIXUP_EXECUTABLE(BUILD_NM) Although I'm not sure about its cleanliness :-) -Bernhard ________________________________________ From: build-dev on behalf of David Holmes Sent: Tuesday, August 4, 2020 00:46 To: Erik Joelsson; Vladimir Kempik; build-dev Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64 On 3/08/2020 10:57 pm, Erik Joelsson wrote: > Hello Vladimir, > > These changes look innocent enough to me. They aren't actually adding > macosx-aarch64 support, they are just removing two minor (and more > likely OS version related) hurdles from the build. You still have to > provide the actual configuration on the configure command line as is > shown in your example. Before we can call build system support, we would > need configure to automatically setup those flags and add a separate > parameter for the JNF framework. So, given that, I don't think this > change warrants a JEP in itself. Of course this change doesn't warrant a JEP in itself :) My point is that until we have a JEP for the platform that is being targeted then we shouldn't be making changes to provide support for that platform. That said I didn't actually look at the changes but focused on the larger stated aim, so apologies for that. The actual changes here are small and not obviously related to supporting macOS-Aarch64. But I'm unclear on this change as it affects all macOS builds: 42 else ifeq ($(call isBuildOs, macosx), true) 43 ADLC_LDFLAGS := -lc++ if this was fixing a bug as indicated, why do we not see this bug in regular builds? Thanks, David ----- > My only complaint is that you revert jib-profiles.js. That file is only > used internally at Oracle. If/when we need it to support macosx-aarch64, > we will provide those changes. > > I must say I'm happy to see you managed to get a working build > configuration with just this though! > > /Erik > > On 2020-08-01 00:24, Vladimir Kempik wrote: >> Hello >> >> Please review this change for JDK-8250876 >> >> This changeset adds support for macos/aarch64 into build system. >> It will allow to crosscompile for macos/aarch64 using intel mac as well. >> >> This changeset does NOT address some arm specific issues in the macos >> related code, we plan to do that in s separate commit. >> >> An example of configure to cross-compile for macos/arm64: >> >> --with-boot-jdk=/path/to/java/ >> --with-build-jdk=/path/to/same/java/as/compiled >> --disable-warnings-as-errors --with-jvm-variants=zero >> --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch >> arm64' --with-extra-ldflags='-arch arm64 >> -F/Path/To/Folder/Containing/JNF_framework/' >> ?with-extra-cxxflags='-arch arm64? >> >> JNF.framework is missing arm64 part as of next macos release, but >> Apple has opensourced it. >> >> Fix to adlc were needed due to it using symbols from stdc++ and not >> linking to it, so it fails when doing make images. >> >> The webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~vkempik%2F8250876%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=HpXJmHXbuawTdExWESK9ssesYTuPTj7N6inXjaHfVaM%3D&reserved=0 >> The bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=9z2Nw8d0pa5huxUKOYorMOVy6SBo7o%2FhDT1EmgOhxQ8%3D&reserved=0 >> >> Testing: jdk/submit. >> >> Thanks, Vladimir. From erik.joelsson at oracle.com Tue Aug 4 14:09:05 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Aug 2020 07:09:05 -0700 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: References: <2c0de319-aeb2-2c4d-2633-ddd612579165@oracle.com> Message-ID: That's a good find! You are correct in that we haven't cross compiled in any direction involving Macosx before. The preferred patch would be a bit more elaborate than that. Ideally we need better control over the toolchain type of the BUILD_* compiler settings. For now, I think just forcing clang/clang++ if BUILD_OS is macosx is good enough. /Erik On 2020-08-04 07:02, Bernhard Urban-Forster wrote: > Good observation David, the change in adlc is just fixing a symptom. The difference to a regular macOS build is that technically, despite running on the same machine, it's actually cross compiling due to Rosetta being the --build=x86_64 system. > > Being a cross-compile, we therefore hit this case: > https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921 > > And thus infers `/usr/bin/CC` for CXX. > > I guess cross compiling hasn't been a thing on macOS yet. I tried the following and it passes the adlc build: > > --- a/make/autoconf/toolchain.m4 > +++ b/make/autoconf/toolchain.m4 > @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], > # find the build compilers in the tools dir, if needed. > UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc]) > UTIL_FIXUP_EXECUTABLE(BUILD_CC) > - UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++]) > + UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++]) > UTIL_FIXUP_EXECUTABLE(BUILD_CXX) > UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm) > UTIL_FIXUP_EXECUTABLE(BUILD_NM) > > Although I'm not sure about its cleanliness :-) > > -Bernhard > > ________________________________________ > From: build-dev on behalf of David Holmes > Sent: Tuesday, August 4, 2020 00:46 > To: Erik Joelsson; Vladimir Kempik; build-dev > Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov > Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64 > > On 3/08/2020 10:57 pm, Erik Joelsson wrote: >> Hello Vladimir, >> >> These changes look innocent enough to me. They aren't actually adding >> macosx-aarch64 support, they are just removing two minor (and more >> likely OS version related) hurdles from the build. You still have to >> provide the actual configuration on the configure command line as is >> shown in your example. Before we can call build system support, we would >> need configure to automatically setup those flags and add a separate >> parameter for the JNF framework. So, given that, I don't think this >> change warrants a JEP in itself. > Of course this change doesn't warrant a JEP in itself :) My point is > that until we have a JEP for the platform that is being targeted then we > shouldn't be making changes to provide support for that platform. > > That said I didn't actually look at the changes but focused on the > larger stated aim, so apologies for that. > > The actual changes here are small and not obviously related to > supporting macOS-Aarch64. But I'm unclear on this change as it affects > all macOS builds: > > 42 else ifeq ($(call isBuildOs, macosx), true) > 43 ADLC_LDFLAGS := -lc++ > > if this was fixing a bug as indicated, why do we not see this bug in > regular builds? > > Thanks, > David > ----- > > >> My only complaint is that you revert jib-profiles.js. That file is only >> used internally at Oracle. If/when we need it to support macosx-aarch64, >> we will provide those changes. >> >> I must say I'm happy to see you managed to get a working build >> configuration with just this though! >> >> /Erik >> >> On 2020-08-01 00:24, Vladimir Kempik wrote: >>> Hello >>> >>> Please review this change for JDK-8250876 >>> >>> This changeset adds support for macos/aarch64 into build system. >>> It will allow to crosscompile for macos/aarch64 using intel mac as well. >>> >>> This changeset does NOT address some arm specific issues in the macos >>> related code, we plan to do that in s separate commit. >>> >>> An example of configure to cross-compile for macos/arm64: >>> >>> --with-boot-jdk=/path/to/java/ >>> --with-build-jdk=/path/to/same/java/as/compiled >>> --disable-warnings-as-errors --with-jvm-variants=zero >>> --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch >>> arm64' --with-extra-ldflags='-arch arm64 >>> -F/Path/To/Folder/Containing/JNF_framework/' >>> ?with-extra-cxxflags='-arch arm64? >>> >>> JNF.framework is missing arm64 part as of next macos release, but >>> Apple has opensourced it. >>> >>> Fix to adlc were needed due to it using symbols from stdc++ and not >>> linking to it, so it fails when doing make images. >>> >>> The webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~vkempik%2F8250876%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=HpXJmHXbuawTdExWESK9ssesYTuPTj7N6inXjaHfVaM%3D&reserved=0 >>> The bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=9z2Nw8d0pa5huxUKOYorMOVy6SBo7o%2FhDT1EmgOhxQ8%3D&reserved=0 >>> >>> Testing: jdk/submit. >>> >>> Thanks, Vladimir. From erik.joelsson at oracle.com Tue Aug 4 14:53:01 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Aug 2020 07:53:01 -0700 Subject: RFR: JDK-8248158 Configure fails with autoconf not found even though it's installed In-Reply-To: References: <5b25d03a-675f-072a-5772-2e2b03739484@oracle.com> <7ba7f5cd-abd2-3331-e836-97e769a8189d@redhat.com> Message-ID: I ran this patch through our internal system (corresponds to the submit repo), so it's working for us at least. /Erik On 2020-08-04 06:25, Galder Zamarreno wrote: > Hi Erik, > > I've been in contact with Simon (cc) who has been testing the patch on > Windows and he said it all looked good. > > @Simon Tooke , do you need to verify again? > > Galder > > > On Tue, Aug 4, 2020 at 2:40 PM Erik Joelsson > wrote: > > I think this looks ok. Have you tested it on Windows? > > /Erik > > On 2020-08-04 01:40, Galder Zamarreno wrote: > > Hi all, > > > > Could someone have a look at my updated webrev below? > > > > Thanks > > > > Galder > > > > > > On Fri, Jul 10, 2020 at 6:48 PM Galder Zamarreno > > wrote: > > > >> Hi again, > >> > >> I've got a new webrev for this: > >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/02/webrev/ > >> > >> It further expands `type -p` to replace `command -v` uses. It also > >> replaces $WHICH usages and removes the check for `which` as well. > >> > >> I tried Simon's suggestions, but getting that right complicated > the patch. > >> > >> Galder > >> > >> > >> On Tue, Jul 7, 2020 at 4:31 PM Galder Zamarreno > > wrote: > >> > >>> > >>> On Mon, Jul 6, 2020 at 10:50 PM Simon Tooke > wrote: > >>> > >>>> (Disclaimer: I am not a reviewer, so this is an opinion, not > a review) > >>>> > >>>> I have tested this on Windows and it built without issue, > although the > >>>> submit repo should be the final gate.? I'd also like to add > my void to > >>>> simply redefining 'WHICH' as it leads to less changes in the > source > >>>> code, which would make life easier should this be backported > to 11u > >>>> and/or 8u. > >>> > >>> So, you would just switch the UTIL_REQUIRE_PROGS call for > WHICH to be > >>> `type ...` instead? > >>> > >>> > >>>> -Simon > >>>> > >>>> On 2020-07-02 4:22 a.m., Galder Zamarreno wrote: > >>>>> On Thu, Jul 2, 2020 at 12:37 AM Magnus Ihse Bursie < > >>>>> magnus.ihse.bursie at oracle.com > > wrote: > >>>>> > >>>>>> On 2020-07-01 12:05, Galder Zamarreno wrote: > >>>>>>> Using `which` to check whether commands exist can result > in confusing > >>>>>>> errors when `which` itself is not installed in the system. > This is > >>>> the > >>>>>> case > >>>>>>> with `autoconf`, where if `autoconf` is present but > `which` isn't, > >>>> the > >>>>>>> build system says that `autoconf` is missing, when in > reality it is > >>>>>> `which` > >>>>>>> which is missing. The fix switches autoconf uses of > `which` for > >>>> `type -p` > >>>>>>> instead, which is a Bash built-in command. > >>>>>>> > >>>>>>> I've tested the fix with a fedora docker container that had > >>>> `autoconf` > >>>>>>> installed but `which`. When using `type -p` it correctly > detects > >>>>>> `autoconf` > >>>>>>> installed and eventually fails saying that `which` is not > installed, > >>>>>> which > >>>>>>> is the expected behaviour. > >>>>>>> > >>>>>>> `which` is still in use in make/autoconf/util_windows.m4. > A possible > >>>>>> future > >>>>>>> improvement would be to see if `which` use there could be > replaced as > >>>>>> well. > >>>>>>> Eventually, when no `which` uses remain, the presence > check for > >>>> `which` > >>>>>>> could be removed. > >>>>>> I agree that we should replace "which" with "type -p" > everywhere. The > >>>>>> best way to do this is probably to replace the value of > $WHICH with > >>>>>> "type -p". It's a bash built-in, so we can count on its > presence. If > >>>> you > >>>>>> want to fix that as part of this bug, I'm ok with it, > otherwise we > >>>>>> should open a new bug to track this. I think there is also > one or two > >>>>>> instances of "command" recently added as (better, but not > as good as > >>>>>> "type -p") replacements for which. > >>>>>> > >>>>> I discovered one place in util.m4 where command was being used. > >>>>> > >>>>> There are other places outside of make/ where command is > used but I > >>>> feel > >>>>> those are a bit out of scope here. > >>>>> > >>>>> My main objective is that from a configure perspective, we'd > try to > >>>> reduce > >>>>> the number of dependencies needed to build things. > >>>>> > >>>>> I'll send an updated webrev shortly. > >>>>> > >>>>> > >>>>>> /Magnus > >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248158 > >>>>>>> WebRev: > >>>>>> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/ > >>>>>>> Galder > >>>> > From david.holmes at oracle.com Tue Aug 4 23:46:59 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Aug 2020 09:46:59 +1000 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: References: <2c0de319-aeb2-2c4d-2633-ddd612579165@oracle.com> Message-ID: <981c03cc-fcd1-9c8f-6301-dea7ee2d959f@oracle.com> Thanks Bernhard. General cross-compilation improvement are a good thing. Cheers, David ----- On 5/08/2020 12:02 am, Bernhard Urban-Forster wrote: > Good observation David, the change in adlc is just fixing a symptom. The difference to a regular macOS build is that technically, despite running on the same machine, it's actually cross compiling due to Rosetta being the --build=x86_64 system. > > Being a cross-compile, we therefore hit this case: > https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921 > > And thus infers `/usr/bin/CC` for CXX. > > I guess cross compiling hasn't been a thing on macOS yet. I tried the following and it passes the adlc build: > > --- a/make/autoconf/toolchain.m4 > +++ b/make/autoconf/toolchain.m4 > @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], > # find the build compilers in the tools dir, if needed. > UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc]) > UTIL_FIXUP_EXECUTABLE(BUILD_CC) > - UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++]) > + UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++]) > UTIL_FIXUP_EXECUTABLE(BUILD_CXX) > UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm) > UTIL_FIXUP_EXECUTABLE(BUILD_NM) > > Although I'm not sure about its cleanliness :-) > > -Bernhard > > ________________________________________ > From: build-dev on behalf of David Holmes > Sent: Tuesday, August 4, 2020 00:46 > To: Erik Joelsson; Vladimir Kempik; build-dev > Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov > Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64 > > On 3/08/2020 10:57 pm, Erik Joelsson wrote: >> Hello Vladimir, >> >> These changes look innocent enough to me. They aren't actually adding >> macosx-aarch64 support, they are just removing two minor (and more >> likely OS version related) hurdles from the build. You still have to >> provide the actual configuration on the configure command line as is >> shown in your example. Before we can call build system support, we would >> need configure to automatically setup those flags and add a separate >> parameter for the JNF framework. So, given that, I don't think this >> change warrants a JEP in itself. > > Of course this change doesn't warrant a JEP in itself :) My point is > that until we have a JEP for the platform that is being targeted then we > shouldn't be making changes to provide support for that platform. > > That said I didn't actually look at the changes but focused on the > larger stated aim, so apologies for that. > > The actual changes here are small and not obviously related to > supporting macOS-Aarch64. But I'm unclear on this change as it affects > all macOS builds: > > 42 else ifeq ($(call isBuildOs, macosx), true) > 43 ADLC_LDFLAGS := -lc++ > > if this was fixing a bug as indicated, why do we not see this bug in > regular builds? > > Thanks, > David > ----- > > >> My only complaint is that you revert jib-profiles.js. That file is only >> used internally at Oracle. If/when we need it to support macosx-aarch64, >> we will provide those changes. >> >> I must say I'm happy to see you managed to get a working build >> configuration with just this though! >> >> /Erik >> >> On 2020-08-01 00:24, Vladimir Kempik wrote: >>> Hello >>> >>> Please review this change for JDK-8250876 >>> >>> This changeset adds support for macos/aarch64 into build system. >>> It will allow to crosscompile for macos/aarch64 using intel mac as well. >>> >>> This changeset does NOT address some arm specific issues in the macos >>> related code, we plan to do that in s separate commit. >>> >>> An example of configure to cross-compile for macos/arm64: >>> >>> --with-boot-jdk=/path/to/java/ >>> --with-build-jdk=/path/to/same/java/as/compiled >>> --disable-warnings-as-errors --with-jvm-variants=zero >>> --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch >>> arm64' --with-extra-ldflags='-arch arm64 >>> -F/Path/To/Folder/Containing/JNF_framework/' >>> ?with-extra-cxxflags='-arch arm64? >>> >>> JNF.framework is missing arm64 part as of next macos release, but >>> Apple has opensourced it. >>> >>> Fix to adlc were needed due to it using symbols from stdc++ and not >>> linking to it, so it fails when doing make images. >>> >>> The webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~vkempik%2F8250876%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=HpXJmHXbuawTdExWESK9ssesYTuPTj7N6inXjaHfVaM%3D&reserved=0 >>> The bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=9z2Nw8d0pa5huxUKOYorMOVy6SBo7o%2FhDT1EmgOhxQ8%3D&reserved=0 >>> >>> Testing: jdk/submit. >>> >>> Thanks, Vladimir. From suenaga at oss.nttdata.com Wed Aug 5 09:36:43 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 5 Aug 2020 18:36:43 +0900 Subject: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> Message-ID: CC'ing build-dev On 2020/08/05 18:30, Yasumasa Suenaga wrote: > Hi Matthias, > (CC'ed build-dev due to makefile change) > > I uploaded new webrev. Could you review it? > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/ > > On 2020/08/05 16:26, Baesken, Matthias wrote: >> Hello, >> >>>> I also checked the? hserr on another Hyper-V guest and still get the expected " HyperV virtualization detected"?? (which is good ? ). >>>> >>>> >>>> However on a host, I would still prefer to get some output (probably different than the guest output now) . >>> >>> What message do you expect? How about "Hyper-V role detected" ? >> >> Thats okay with me? (I think some people here say "Hyper-V host" so that might be an idea as well). > > I said "Hyper-V host" in previous mails, but it is not strictly correct. In Hyper-V, it should be "root partision". However it's a little difficult to understand, so I choose "role" in this place. > > >>>> Regarding the usage of >>>> >>>> #pragma comment(lib, "wbemuuid.lib") >>>> >>>> This seem to add an additional lib dependency ,? should some people from build/deploy? area comment on this maybe ? >>>> (not saying it is a very bad thing ) > > I modified libraries.m4. > wbemuuid.lib is needed for WMI call. > > > Thanks, > > Yasumasa > > >>> We add wbemuuid.lib to make/autoconf/libraries.m4 . >>> I will change it in next webrev, and I will CCing to build-dev on next turn. >> >> >> Let's see what they have to say. >> >> Best regards, Matthias >> >> From erik.joelsson at oracle.com Wed Aug 5 12:30:35 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 5 Aug 2020 05:30:35 -0700 Subject: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> Message-ID: <58a6ddb7-2aa0-595b-e999-2e4277f9e7c5@oracle.com> Build change is ok. /Erik On 2020-08-05 02:36, Yasumasa Suenaga wrote: > CC'ing build-dev > > On 2020/08/05 18:30, Yasumasa Suenaga wrote: >> Hi Matthias, >> (CC'ed build-dev due to makefile change) >> >> I uploaded new webrev. Could you review it? >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/ >> >> On 2020/08/05 16:26, Baesken, Matthias wrote: >>> Hello, >>> >>>>> I also checked the? hserr on another Hyper-V guest and still get >>>>> the expected " HyperV virtualization detected"?? (which is good ? ). >>>>> >>>>> >>>>> However on a host, I would still prefer to get some output >>>>> (probably different than the guest output now) . >>>> >>>> What message do you expect? How about "Hyper-V role detected" ? >>> >>> Thats okay with me? (I think some people here say "Hyper-V host" so >>> that might be an idea as well). >> >> I said "Hyper-V host" in previous mails, but it is not strictly >> correct. In Hyper-V, it should be "root partision". However it's a >> little difficult to understand, so I choose "role" in this place. >> >> >>>>> Regarding the usage of >>>>> >>>>> #pragma comment(lib, "wbemuuid.lib") >>>>> >>>>> This seem to add an additional lib dependency ,? should some >>>>> people from build/deploy? area comment on this maybe ? >>>>> (not saying it is a very bad thing ) >> >> I modified libraries.m4. >> wbemuuid.lib is needed for WMI call. >> >> >> Thanks, >> >> Yasumasa >> >> >>>> We add wbemuuid.lib to make/autoconf/libraries.m4 . >>>> I will change it in next webrev, and I will CCing to build-dev on >>>> next turn. >>> >>> >>> Let's see what they have to say. >>> >>> Best regards, Matthias >>> >>> From suenaga at oss.nttdata.com Thu Aug 6 00:09:35 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 6 Aug 2020 09:09:35 +0900 Subject: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: <58a6ddb7-2aa0-595b-e999-2e4277f9e7c5@oracle.com> References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <58a6ddb7-2aa0-595b-e999-2e4277f9e7c5@oracle.com> Message-ID: <488d9fdc-60cd-732b-b5fc-185cb0846868@oss.nttdata.com> Thanks Erik! Yasumasa On 2020/08/05 21:30, Erik Joelsson wrote: > Build change is ok. > > /Erik > > On 2020-08-05 02:36, Yasumasa Suenaga wrote: >> CC'ing build-dev >> >> On 2020/08/05 18:30, Yasumasa Suenaga wrote: >>> Hi Matthias, >>> (CC'ed build-dev due to makefile change) >>> >>> I uploaded new webrev. Could you review it? >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/ >>> >>> On 2020/08/05 16:26, Baesken, Matthias wrote: >>>> Hello, >>>> >>>>>> I also checked the? hserr on another Hyper-V guest and still get the expected " HyperV virtualization detected"?? (which is good ? ). >>>>>> >>>>>> >>>>>> However on a host, I would still prefer to get some output (probably different than the guest output now) . >>>>> >>>>> What message do you expect? How about "Hyper-V role detected" ? >>>> >>>> Thats okay with me? (I think some people here say "Hyper-V host" so that might be an idea as well). >>> >>> I said "Hyper-V host" in previous mails, but it is not strictly correct. In Hyper-V, it should be "root partision". However it's a little difficult to understand, so I choose "role" in this place. >>> >>> >>>>>> Regarding the usage of >>>>>> >>>>>> #pragma comment(lib, "wbemuuid.lib") >>>>>> >>>>>> This seem to add an additional lib dependency ,? should some people from build/deploy? area comment on this maybe ? >>>>>> (not saying it is a very bad thing ) >>> >>> I modified libraries.m4. >>> wbemuuid.lib is needed for WMI call. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>>> We add wbemuuid.lib to make/autoconf/libraries.m4 . >>>>> I will change it in next webrev, and I will CCing to build-dev on next turn. >>>> >>>> >>>> Let's see what they have to say. >>>> >>>> Best regards, Matthias >>>> >>>> From galder at redhat.com Thu Aug 6 14:28:29 2020 From: galder at redhat.com (Galder Zamarreno) Date: Thu, 6 Aug 2020 16:28:29 +0200 Subject: RFR: JDK-8251193 bin/idea.sh generating wrong source folders for JVMCI modules Message-ID: Hi, `bin/idea.sh` is not generating the right source folders for jdk.internal.vm.ci and jdk.internal.vm.compiler modules. These modules have different directory structures to the rest and so should be handled exceptionally so that the IDE has the right source folder definitions. The fix takes these two modules, inspects all the subdirectories within each module root and generates a source folder definition for each. As example, for jdk.internal.vm.ci, there should be a source folder for: * src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.aarch64/src * src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src * ... I've tested this in the patch on IDEA 2020.2. Bug: https://bugs.openjdk.java.net/browse/JDK-8251193 WebRev: http://cr.openjdk.java.net/~sgehwolf/webrevs/galder/JDK-8251193/01/webrev/ Galder From maurizio.cimadamore at oracle.com Thu Aug 6 15:01:54 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 6 Aug 2020 16:01:54 +0100 Subject: RFR: JDK-8251193 bin/idea.sh generating wrong source folders for JVMCI modules In-Reply-To: References: Message-ID: The basic fix looks good, I'm wondering, however, if we would only want to enable sources which match the current configuration? E.g. not add the sources for aarch64 if building on linux? But if we build all these modules regardless, then it's ok to add them all. Maurizio On 06/08/2020 15:28, Galder Zamarreno wrote: > Hi, > > `bin/idea.sh` is not generating the right source folders for > jdk.internal.vm.ci and jdk.internal.vm.compiler modules. > > These modules have different directory structures to the rest and so should > be handled exceptionally so that the IDE has the right source folder > definitions. > > The fix takes these two modules, inspects all the subdirectories within > each module root and generates a source folder definition for each. As > example, for jdk.internal.vm.ci, there should be a source folder for: > > * src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.aarch64/src > * src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src > * ... > > I've tested this in the patch on IDEA 2020.2. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251193 > WebRev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/galder/JDK-8251193/01/webrev/ > > Galder From sgehwolf at redhat.com Thu Aug 6 15:35:45 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 06 Aug 2020 17:35:45 +0200 Subject: RFR: JDK-8251193 bin/idea.sh generating wrong source folders for JVMCI modules In-Reply-To: References: Message-ID: Hi, On Thu, 2020-08-06 at 16:01 +0100, Maurizio Cimadamore wrote: > The basic fix looks good, I'm wondering, however, if we would only want > to enable sources which match the current configuration? E.g. not add > the sources for aarch64 if building on linux? But if we build all these > modules regardless, then it's ok to add them all. Looks like on an x86_64 Linux build aarch64 classes get compiled into the module(s) as well: $ find build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci | grep aarch64 build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/aarch64 build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/aarch64/AArch64$Flag.class build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/aarch64/AArch64Kind$1.class build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/aarch64/AArch64.class build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/aarch64/AArch64$CPUFeature.class build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/aarch64/AArch64$1.class build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/aarch64/AArch64Kind.class build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/hotspot/aarch64 build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/hotspot/aarch64/AArch64HotSpotRegisterConfig.class build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/hotspot/aarch64/AArch64HotSpotRegisterConfig$1.class build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/hotspot/aarch64/AArch64HotSpotVMConfig.class build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/hotspot/aarch64/AArch64HotSpotJVMCIBackendFactory.class Thanks, Severin > Maurizio > > On 06/08/2020 15:28, Galder Zamarreno wrote: > > Hi, > > > > `bin/idea.sh` is not generating the right source folders for > > jdk.internal.vm.ci and jdk.internal.vm.compiler modules. > > > > These modules have different directory structures to the rest and so should > > be handled exceptionally so that the IDE has the right source folder > > definitions. > > > > The fix takes these two modules, inspects all the subdirectories within > > each module root and generates a source folder definition for each. As > > example, for jdk.internal.vm.ci, there should be a source folder for: > > > > * src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.aarch64/src > > * src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src > > * ... > > > > I've tested this in the patch on IDEA 2020.2. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251193 > > WebRev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/galder/JDK-8251193/01/webrev/ > > > > Galder From adinn at redhat.com Fri Aug 7 09:38:15 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 7 Aug 2020 10:38:15 +0100 Subject: RFR: JDK-8251193 bin/idea.sh generating wrong source folders for JVMCI modules In-Reply-To: References: Message-ID: On 06/08/2020 16:35, Severin Gehwolf wrote: > On Thu, 2020-08-06 at 16:01 +0100, Maurizio Cimadamore wrote: >> The basic fix looks good, I'm wondering, however, if we would only want >> to enable sources which match the current configuration? E.g. not add >> the sources for aarch64 if building on linux? But if we build all these >> modules regardless, then it's ok to add them all. > > Looks like on an x86_64 Linux build aarch64 classes get compiled into > the module(s) as well: > > $ find build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci | grep aarch64 > build/linux-x86_64-server-release/jdk/modules/jdk.internal.vm.ci/jdk/vm/ci/aarch64 . . . Well, those classes could perhaps be stripped from (or just not installed in) the module set but this is about sources. Idea really needs to know where the AArch64 sources are even when running on x86_64 (and vice versa). Dev work on shared + x86_64-specific code can also require making compatible changes to AArch64-specific classes. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From mikael.vidstedt at oracle.com Fri Aug 7 21:11:17 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 7 Aug 2020 14:11:17 -0700 Subject: RFR(XS): 8251316: Sanity check the JDK under test before running tests Message-ID: Please review this small change which adds a sanity check run of the JDK under test before running jtreg tests. JBS: https://bugs.openjdk.java.net/browse/JDK-8251316 webrev: https://cr.openjdk.java.net/~mikael/webrevs/8251316/webrev.00/open/webrev * Background (from JBS) If the JDK under test is severely broken, if for example it crashes on startup, jtreg will typically just report "Error: cannot determine version for JDK: /path/to/bin/java" without any additional information. To make it faster to diagnose the problem it would be useful to do some sanity checking of the JDK before invoking jtreg. * Testing I verified locally that a crashing VM does produce the expected output both on the console and in the sanity.log log file Running tier1 now for good luck. Cheers, Mikael From erik.joelsson at oracle.com Fri Aug 7 21:18:22 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 7 Aug 2020 14:18:22 -0700 Subject: RFR(XS): 8251316: Sanity check the JDK under test before running tests In-Reply-To: References: Message-ID: Looks good. /Erik On 2020-08-07 14:11, Mikael Vidstedt wrote: > Please review this small change which adds a sanity check run of the JDK under test before running jtreg tests. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8251316 > webrev: https://cr.openjdk.java.net/~mikael/webrevs/8251316/webrev.00/open/webrev > > * Background (from JBS) > > If the JDK under test is severely broken, if for example it crashes on startup, jtreg will typically just report "Error: cannot determine version for JDK: /path/to/bin/java" without any additional information. To make it faster to diagnose the problem it would be useful to do some sanity checking of the JDK before invoking jtreg. > > * Testing > > I verified locally that a crashing VM does produce the expected output both on the console and in the sanity.log log file > Running tier1 now for good luck. > > Cheers, > Mikael > From david.holmes at oracle.com Sat Aug 8 12:25:11 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 8 Aug 2020 22:25:11 +1000 Subject: RFR(XS): 8251316: Sanity check the JDK under test before running tests In-Reply-To: References: Message-ID: <66a3ae65-e646-c824-6db1-21276d0d6d8d@oracle.com> Seems reasonable - at least until jtreg is fixed. Where does the hs_err file from a crashing VM end up? Thanks, David On 8/08/2020 7:11 am, Mikael Vidstedt wrote: > > Please review this small change which adds a sanity check run of the JDK under test before running jtreg tests. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8251316 > webrev: https://cr.openjdk.java.net/~mikael/webrevs/8251316/webrev.00/open/webrev > > * Background (from JBS) > > If the JDK under test is severely broken, if for example it crashes on startup, jtreg will typically just report "Error: cannot determine version for JDK: /path/to/bin/java" without any additional information. To make it faster to diagnose the problem it would be useful to do some sanity checking of the JDK before invoking jtreg. > > * Testing > > I verified locally that a crashing VM does produce the expected output both on the console and in the sanity.log log file > Running tier1 now for good luck. > > Cheers, > Mikael > From magnus.ihse.bursie at oracle.com Mon Aug 10 09:18:22 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Aug 2020 11:18:22 +0200 Subject: RFR(XS): 8251316: Sanity check the JDK under test before running tests In-Reply-To: <66a3ae65-e646-c824-6db1-21276d0d6d8d@oracle.com> References: <66a3ae65-e646-c824-6db1-21276d0d6d8d@oracle.com> Message-ID: <8b295926-2227-df7a-0c60-5efc74263110@oracle.com> On 2020-08-08 14:25, David Holmes wrote: > Seems reasonable - at least until jtreg is fixed. I agree; when jtreg is fixed we should revert this, since it's writing output that's not strictly needed, something I've been trying hard to fight. But until then: looks good. /Magnus > > Where does the hs_err file from a crashing VM end up? > > Thanks, > David > > On 8/08/2020 7:11 am, Mikael Vidstedt wrote: >> >> Please review this small change which adds a sanity check run of the >> JDK under test before running jtreg tests. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8251316 >> >> webrev: >> https://cr.openjdk.java.net/~mikael/webrevs/8251316/webrev.00/open/webrev >> >> >> >> * Background (from JBS) >> >> If the JDK under test is severely broken, if for example it crashes >> on startup, jtreg will typically just report "Error: cannot determine >> version for JDK: /path/to/bin/java" without any additional >> information. To make it faster to diagnose the problem it would be >> useful to do some sanity checking of the JDK before invoking jtreg. >> >> * Testing >> >> I verified locally that a crashing VM does produce the expected >> output both on the console and in the sanity.log log file >> Running tier1 now for good luck. >> >> Cheers, >> Mikael >> From magnus.ihse.bursie at oracle.com Mon Aug 10 09:52:19 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Aug 2020 11:52:19 +0200 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: References: <2c0de319-aeb2-2c4d-2633-ddd612579165@oracle.com> Message-ID: So, basically, what this patch is about is not so much "preparation for aarch64" as "allow cross-compile on macos"?? If I understand you correctly, maybe you should rename the bug? /Magnus On 2020-08-04 16:09, Erik Joelsson wrote: > That's a good find! You are correct in that we haven't cross compiled > in any direction involving Macosx before. > > The preferred patch would be a bit more elaborate than that. Ideally > we need better control over the toolchain type of the BUILD_* compiler > settings. For now, I think just forcing clang/clang++ if BUILD_OS is > macosx is good enough. > > /Erik > > On 2020-08-04 07:02, Bernhard Urban-Forster wrote: >> Good observation David, the change in adlc is just fixing a symptom. >> The difference to a regular macOS build is that technically, despite >> running on the same machine, it's actually cross compiling due to >> Rosetta being the --build=x86_64 system. >> >> Being a cross-compile, we therefore hit this case: >> https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921 >> >> >> And thus infers `/usr/bin/CC` for CXX. >> >> I guess cross compiling hasn't been a thing on macOS yet. I tried the >> following and it passes the adlc build: >> >> --- a/make/autoconf/toolchain.m4 >> +++ b/make/autoconf/toolchain.m4 >> @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], >> ????? # find the build compilers in the tools dir, if needed. >> ????? UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc]) >> ????? UTIL_FIXUP_EXECUTABLE(BUILD_CC) >> -??? UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++]) >> +??? UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++]) >> ????? UTIL_FIXUP_EXECUTABLE(BUILD_CXX) >> ????? UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm) >> ????? UTIL_FIXUP_EXECUTABLE(BUILD_NM) >> >> Although I'm not sure about its cleanliness :-) >> >> -Bernhard >> >> ________________________________________ >> From: build-dev on behalf of David >> Holmes >> Sent: Tuesday, August 4, 2020 00:46 >> To: Erik Joelsson; Vladimir Kempik; build-dev >> Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov >> Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64 >> >> On 3/08/2020 10:57 pm, Erik Joelsson wrote: >>> Hello Vladimir, >>> >>> These changes look innocent enough to me. They aren't actually adding >>> macosx-aarch64 support, they are just removing two minor (and more >>> likely OS version related) hurdles from the build. You still have to >>> provide the actual configuration on the configure command line as is >>> shown in your example. Before we can call build system support, we >>> would >>> need configure to automatically setup those flags and add a separate >>> parameter for the JNF framework. So, given that, I don't think this >>> change warrants a JEP in itself. >> Of course this change doesn't warrant a JEP in itself :) My point is >> that until we have a JEP for the platform that is being targeted then we >> shouldn't be making changes to provide support for that platform. >> >> That said I didn't actually look at the changes but focused on the >> larger stated aim, so apologies for that. >> >> The actual changes here are small and not obviously related to >> supporting macOS-Aarch64. But I'm unclear on this change as it affects >> all macOS builds: >> >> ??? 42?? else ifeq ($(call isBuildOs, macosx), true) >> ??? 43???? ADLC_LDFLAGS := -lc++ >> >> if this was fixing a bug as indicated, why do we not see this bug in >> regular builds? >> >> Thanks, >> David >> ----- >> >> >>> My only complaint is that you revert jib-profiles.js. That file is only >>> used internally at Oracle. If/when we need it to support >>> macosx-aarch64, >>> we will provide those changes. >>> >>> I must say I'm happy to see you managed to get a working build >>> configuration with just this though! >>> >>> /Erik >>> >>> On 2020-08-01 00:24, Vladimir Kempik wrote: >>>> Hello >>>> >>>> Please review this change for JDK-8250876 >>>> >>>> This changeset adds support for macos/aarch64 into build system. >>>> It will allow to crosscompile for macos/aarch64 using intel mac as >>>> well. >>>> >>>> This changeset does NOT address some arm specific issues in the macos >>>> related code, we plan to do that in s separate commit. >>>> >>>> An example of configure to cross-compile for macos/arm64: >>>> >>>> --with-boot-jdk=/path/to/java/ >>>> --with-build-jdk=/path/to/same/java/as/compiled >>>> --disable-warnings-as-errors --with-jvm-variants=zero >>>> --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch >>>> arm64' --with-extra-ldflags='-arch arm64 >>>> -F/Path/To/Folder/Containing/JNF_framework/' >>>> ?with-extra-cxxflags='-arch arm64? >>>> >>>> JNF.framework is missing arm64 part as of next macos release, but >>>> Apple has opensourced it. >>>> >>>> Fix to adlc were needed due to it using symbols from stdc++ and not >>>> linking to it, so it fails when doing make images. >>>> >>>> The webrev: >>>> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~vkempik%2F8250876%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=HpXJmHXbuawTdExWESK9ssesYTuPTj7N6inXjaHfVaM%3D&reserved=0 >>>> The bug: >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=9z2Nw8d0pa5huxUKOYorMOVy6SBo7o%2FhDT1EmgOhxQ8%3D&reserved=0 >>>> >>>> Testing: jdk/submit. >>>> >>>> Thanks, Vladimir. From vkempik at azul.com Mon Aug 10 10:47:00 2020 From: vkempik at azul.com (Vladimir Kempik) Date: Mon, 10 Aug 2020 10:47:00 +0000 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: References: <2c0de319-aeb2-2c4d-2633-ddd612579165@oracle.com> Message-ID: <826FC20B-2EF3-4412-AF88-1CC6CE993919@azul.com> Hello Renamed the bug to "Fix issues with cross-compile on macos" Please check updated webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/ Adlc is fine with cross-compiling now. Regards, Vladimir > 10 ???. 2020 ?., ? 12:52, Magnus Ihse Bursie ???????(?): > > So, basically, what this patch is about is not so much "preparation for aarch64" as "allow cross-compile on macos"? If I understand you correctly, maybe you should rename the bug? > > /Magnus > > On 2020-08-04 16:09, Erik Joelsson wrote: >> That's a good find! You are correct in that we haven't cross compiled in any direction involving Macosx before. >> >> The preferred patch would be a bit more elaborate than that. Ideally we need better control over the toolchain type of the BUILD_* compiler settings. For now, I think just forcing clang/clang++ if BUILD_OS is macosx is good enough. >> >> /Erik >> >> On 2020-08-04 07:02, Bernhard Urban-Forster wrote: >>> Good observation David, the change in adlc is just fixing a symptom. The difference to a regular macOS build is that technically, despite running on the same machine, it's actually cross compiling due to Rosetta being the --build=x86_64 system. >>> >>> Being a cross-compile, we therefore hit this case: >>> https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921 >>> >>> And thus infers `/usr/bin/CC` for CXX. >>> >>> I guess cross compiling hasn't been a thing on macOS yet. I tried the following and it passes the adlc build: >>> >>> --- a/make/autoconf/toolchain.m4 >>> +++ b/make/autoconf/toolchain.m4 >>> @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], >>> # find the build compilers in the tools dir, if needed. >>> UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc]) >>> UTIL_FIXUP_EXECUTABLE(BUILD_CC) >>> - UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++]) >>> + UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++]) >>> UTIL_FIXUP_EXECUTABLE(BUILD_CXX) >>> UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm) >>> UTIL_FIXUP_EXECUTABLE(BUILD_NM) >>> >>> Although I'm not sure about its cleanliness :-) >>> >>> -Bernhard >>> >>> ________________________________________ >>> From: build-dev on behalf of David Holmes >>> Sent: Tuesday, August 4, 2020 00:46 >>> To: Erik Joelsson; Vladimir Kempik; build-dev >>> Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov >>> Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64 >>> >>> On 3/08/2020 10:57 pm, Erik Joelsson wrote: >>>> Hello Vladimir, >>>> >>>> These changes look innocent enough to me. They aren't actually adding >>>> macosx-aarch64 support, they are just removing two minor (and more >>>> likely OS version related) hurdles from the build. You still have to >>>> provide the actual configuration on the configure command line as is >>>> shown in your example. Before we can call build system support, we would >>>> need configure to automatically setup those flags and add a separate >>>> parameter for the JNF framework. So, given that, I don't think this >>>> change warrants a JEP in itself. >>> Of course this change doesn't warrant a JEP in itself :) My point is >>> that until we have a JEP for the platform that is being targeted then we >>> shouldn't be making changes to provide support for that platform. >>> >>> That said I didn't actually look at the changes but focused on the >>> larger stated aim, so apologies for that. >>> >>> The actual changes here are small and not obviously related to >>> supporting macOS-Aarch64. But I'm unclear on this change as it affects >>> all macOS builds: >>> >>> 42 else ifeq ($(call isBuildOs, macosx), true) >>> 43 ADLC_LDFLAGS := -lc++ >>> >>> if this was fixing a bug as indicated, why do we not see this bug in >>> regular builds? >>> >>> Thanks, >>> David >>> ----- >>> >>> >>>> My only complaint is that you revert jib-profiles.js. That file is only >>>> used internally at Oracle. If/when we need it to support macosx-aarch64, >>>> we will provide those changes. >>>> >>>> I must say I'm happy to see you managed to get a working build >>>> configuration with just this though! >>>> >>>> /Erik >>>> >>>> On 2020-08-01 00:24, Vladimir Kempik wrote: >>>>> Hello >>>>> >>>>> Please review this change for JDK-8250876 >>>>> >>>>> This changeset adds support for macos/aarch64 into build system. >>>>> It will allow to crosscompile for macos/aarch64 using intel mac as well. >>>>> >>>>> This changeset does NOT address some arm specific issues in the macos >>>>> related code, we plan to do that in s separate commit. >>>>> >>>>> An example of configure to cross-compile for macos/arm64: >>>>> >>>>> --with-boot-jdk=/path/to/java/ >>>>> --with-build-jdk=/path/to/same/java/as/compiled >>>>> --disable-warnings-as-errors --with-jvm-variants=zero >>>>> --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch >>>>> arm64' --with-extra-ldflags='-arch arm64 >>>>> -F/Path/To/Folder/Containing/JNF_framework/' >>>>> ?with-extra-cxxflags='-arch arm64? >>>>> >>>>> JNF.framework is missing arm64 part as of next macos release, but >>>>> Apple has opensourced it. >>>>> >>>>> Fix to adlc were needed due to it using symbols from stdc++ and not >>>>> linking to it, so it fails when doing make images. >>>>> >>>>> The webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~vkempik%2F8250876%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=HpXJmHXbuawTdExWESK9ssesYTuPTj7N6inXjaHfVaM%3D&reserved=0 >>>>> The bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=9z2Nw8d0pa5huxUKOYorMOVy6SBo7o%2FhDT1EmgOhxQ8%3D&reserved=0 >>>>> >>>>> Testing: jdk/submit. >>>>> >>>>> Thanks, Vladimir. From erik.joelsson at oracle.com Mon Aug 10 13:11:24 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Aug 2020 06:11:24 -0700 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: <826FC20B-2EF3-4412-AF88-1CC6CE993919@azul.com> References: <2c0de319-aeb2-2c4d-2633-ddd612579165@oracle.com> <826FC20B-2EF3-4412-AF88-1CC6CE993919@azul.com> Message-ID: <5dc294b2-2968-b9ee-a227-68517cb2f0b8@oracle.com> On 2020-08-10 03:47, Vladimir Kempik wrote: > Hello > > Renamed the bug to "Fix issues with cross-compile on macos" > > Please check updated webrev: > http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/ > > Adlc is fine with cross-compiling now. > While not strictly needed for ADLC, I would like to see BUILD_CC getting the same treatment here for consistency. /Erik > Regards, Vladimir >> 10 ???. 2020 ?., ? 12:52, Magnus Ihse Bursie >> > > ???????(?): >> >> So, basically, what this patch is about is not so much "preparation >> for aarch64" as "allow cross-compile on macos"?? If I understand you >> correctly, maybe you should rename the bug? >> >> /Magnus >> >> On 2020-08-04 16:09, Erik Joelsson wrote: >>> That's a good find! You are correct in that we haven't cross >>> compiled in any direction involving Macosx before. >>> >>> The preferred patch would be a bit more elaborate than that. Ideally >>> we need better control over the toolchain type of the BUILD_* >>> compiler settings. For now, I think just forcing clang/clang++ if >>> BUILD_OS is macosx is good enough. >>> >>> /Erik >>> >>> On 2020-08-04 07:02, Bernhard Urban-Forster wrote: >>>> Good observation David, the change in adlc is just fixing a >>>> symptom. The difference to a regular macOS build is that >>>> technically, despite running on the same machine, it's actually >>>> cross compiling due to Rosetta being the --build=x86_64 system. >>>> >>>> Being a cross-compile, we therefore hit this case: >>>> https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921 >>>> >>>> >>>> And thus infers `/usr/bin/CC` for CXX. >>>> >>>> I guess cross compiling hasn't been a thing on macOS yet. I tried >>>> the following and it passes the adlc build: >>>> >>>> --- a/make/autoconf/toolchain.m4 >>>> +++ b/make/autoconf/toolchain.m4 >>>> @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], >>>> ????? # find the build compilers in the tools dir, if needed. >>>> ????? UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc]) >>>> ????? UTIL_FIXUP_EXECUTABLE(BUILD_CC) >>>> -??? UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++]) >>>> +??? UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++]) >>>> ????? UTIL_FIXUP_EXECUTABLE(BUILD_CXX) >>>> ????? UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm) >>>> ????? UTIL_FIXUP_EXECUTABLE(BUILD_NM) >>>> >>>> Although I'm not sure about its cleanliness :-) >>>> >>>> -Bernhard >>>> >>>> ________________________________________ >>>> From: build-dev >>> > on behalf of David Holmes >>>> > >>>> Sent: Tuesday, August 4, 2020 00:46 >>>> To: Erik Joelsson; Vladimir Kempik; build-dev >>>> Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov >>>> Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64 >>>> >>>> On 3/08/2020 10:57 pm, Erik Joelsson wrote: >>>>> Hello Vladimir, >>>>> >>>>> These changes look innocent enough to me. They aren't actually adding >>>>> macosx-aarch64 support, they are just removing two minor (and more >>>>> likely OS version related) hurdles from the build. You still have to >>>>> provide the actual configuration on the configure command line as is >>>>> shown in your example. Before we can call build system support, we >>>>> would >>>>> need configure to automatically setup those flags and add a separate >>>>> parameter for the JNF framework. So, given that, I don't think this >>>>> change warrants a JEP in itself. >>>> Of course this change doesn't warrant a JEP in itself :) My point is >>>> that until we have a JEP for the platform that is being targeted >>>> then we >>>> shouldn't be making changes to provide support for that platform. >>>> >>>> That said I didn't actually look at the changes but focused on the >>>> larger stated aim, so apologies for that. >>>> >>>> The actual changes here are small and not obviously related to >>>> supporting macOS-Aarch64. But I'm unclear on this change as it affects >>>> all macOS builds: >>>> >>>> ??? 42?? else ifeq ($(call isBuildOs, macosx), true) >>>> ??? 43???? ADLC_LDFLAGS := -lc++ >>>> >>>> if this was fixing a bug as indicated, why do we not see this bug in >>>> regular builds? >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>>> My only complaint is that you revert jib-profiles.js. That file is >>>>> only >>>>> used internally at Oracle. If/when we need it to support >>>>> macosx-aarch64, >>>>> we will provide those changes. >>>>> >>>>> I must say I'm happy to see you managed to get a working build >>>>> configuration with just this though! >>>>> >>>>> /Erik >>>>> >>>>> On 2020-08-01 00:24, Vladimir Kempik wrote: >>>>>> Hello >>>>>> >>>>>> Please review this change for JDK-8250876 >>>>>> >>>>>> This changeset adds support for macos/aarch64 into build system. >>>>>> It will allow to crosscompile for macos/aarch64 using intel mac >>>>>> as well. >>>>>> >>>>>> This changeset does NOT address some arm specific issues in the macos >>>>>> related code, we plan to do that in s separate commit. >>>>>> >>>>>> An example of configure to cross-compile for macos/arm64: >>>>>> >>>>>> --with-boot-jdk=/path/to/java/ >>>>>> --with-build-jdk=/path/to/same/java/as/compiled >>>>>> --disable-warnings-as-errors --with-jvm-variants=zero >>>>>> --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch >>>>>> arm64' --with-extra-ldflags='-arch arm64 >>>>>> -F/Path/To/Folder/Containing/JNF_framework/' >>>>>> ?with-extra-cxxflags='-arch arm64? >>>>>> >>>>>> JNF.framework is missing arm64 part as of next macos release, but >>>>>> Apple has opensourced it. >>>>>> >>>>>> Fix to adlc were needed due to it using symbols from stdc++ and not >>>>>> linking to it, so it fails when doing make images. >>>>>> >>>>>> The webrev: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~vkempik%2F8250876%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=HpXJmHXbuawTdExWESK9ssesYTuPTj7N6inXjaHfVaM%3D&reserved=0 >>>>>> The bug: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=9z2Nw8d0pa5huxUKOYorMOVy6SBo7o%2FhDT1EmgOhxQ8%3D&reserved=0 >>>>>> >>>>>> Testing: jdk/submit. >>>>>> >>>>>> Thanks, Vladimir. > From vkempik at azul.com Mon Aug 10 13:16:00 2020 From: vkempik at azul.com (Vladimir Kempik) Date: Mon, 10 Aug 2020 13:16:00 +0000 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: <5dc294b2-2968-b9ee-a227-68517cb2f0b8@oracle.com> References: <2c0de319-aeb2-2c4d-2633-ddd612579165@oracle.com> <826FC20B-2EF3-4412-AF88-1CC6CE993919@azul.com> <5dc294b2-2968-b9ee-a227-68517cb2f0b8@oracle.com> Message-ID: <45F59C7C-C597-436A-BF4B-19DC664FED34@azul.com> Hello Erik It?s not clear to me, what exactly you want to change in BUILD_CC, add clang to list for macos ? Thanks, Vladimir > 10 ???. 2020 ?., ? 16:11, Erik Joelsson ???????(?): > > On 2020-08-10 03:47, Vladimir Kempik wrote: >> Hello >> >> Renamed the bug to "Fix issues with cross-compile on macos" >> >> Please check updated webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/ >> >> Adlc is fine with cross-compiling now. >> > While not strictly needed for ADLC, I would like to see BUILD_CC getting the same treatment here for consistency. > > /Erik > >> Regards, Vladimir >>> 10 ???. 2020 ?., ? 12:52, Magnus Ihse Bursie > ???????(?): >>> >>> So, basically, what this patch is about is not so much "preparation for aarch64" as "allow cross-compile on macos"? If I understand you correctly, maybe you should rename the bug? >>> >>> /Magnus >>> >>> On 2020-08-04 16:09, Erik Joelsson wrote: >>>> That's a good find! You are correct in that we haven't cross compiled in any direction involving Macosx before. >>>> >>>> The preferred patch would be a bit more elaborate than that. Ideally we need better control over the toolchain type of the BUILD_* compiler settings. For now, I think just forcing clang/clang++ if BUILD_OS is macosx is good enough. >>>> >>>> /Erik >>>> >>>> On 2020-08-04 07:02, Bernhard Urban-Forster wrote: >>>>> Good observation David, the change in adlc is just fixing a symptom. The difference to a regular macOS build is that technically, despite running on the same machine, it's actually cross compiling due to Rosetta being the --build=x86_64 system. >>>>> >>>>> Being a cross-compile, we therefore hit this case: >>>>> https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921 >>>>> >>>>> And thus infers `/usr/bin/CC` for CXX. >>>>> >>>>> I guess cross compiling hasn't been a thing on macOS yet. I tried the following and it passes the adlc build: >>>>> >>>>> --- a/make/autoconf/toolchain.m4 >>>>> +++ b/make/autoconf/toolchain.m4 >>>>> @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], >>>>> # find the build compilers in the tools dir, if needed. >>>>> UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc]) >>>>> UTIL_FIXUP_EXECUTABLE(BUILD_CC) >>>>> - UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++]) >>>>> + UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++]) >>>>> UTIL_FIXUP_EXECUTABLE(BUILD_CXX) >>>>> UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm) >>>>> UTIL_FIXUP_EXECUTABLE(BUILD_NM) >>>>> >>>>> Although I'm not sure about its cleanliness :-) >>>>> >>>>> -Bernhard >>>>> >>>>> ________________________________________ >>>>> From: build-dev > on behalf of David Holmes > >>>>> Sent: Tuesday, August 4, 2020 00:46 >>>>> To: Erik Joelsson; Vladimir Kempik; build-dev >>>>> Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov >>>>> Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64 >>>>> >>>>> On 3/08/2020 10:57 pm, Erik Joelsson wrote: >>>>>> Hello Vladimir, >>>>>> >>>>>> These changes look innocent enough to me. They aren't actually adding >>>>>> macosx-aarch64 support, they are just removing two minor (and more >>>>>> likely OS version related) hurdles from the build. You still have to >>>>>> provide the actual configuration on the configure command line as is >>>>>> shown in your example. Before we can call build system support, we would >>>>>> need configure to automatically setup those flags and add a separate >>>>>> parameter for the JNF framework. So, given that, I don't think this >>>>>> change warrants a JEP in itself. >>>>> Of course this change doesn't warrant a JEP in itself :) My point is >>>>> that until we have a JEP for the platform that is being targeted then we >>>>> shouldn't be making changes to provide support for that platform. >>>>> >>>>> That said I didn't actually look at the changes but focused on the >>>>> larger stated aim, so apologies for that. >>>>> >>>>> The actual changes here are small and not obviously related to >>>>> supporting macOS-Aarch64. But I'm unclear on this change as it affects >>>>> all macOS builds: >>>>> >>>>> 42 else ifeq ($(call isBuildOs, macosx), true) >>>>> 43 ADLC_LDFLAGS := -lc++ >>>>> >>>>> if this was fixing a bug as indicated, why do we not see this bug in >>>>> regular builds? >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> My only complaint is that you revert jib-profiles.js. That file is only >>>>>> used internally at Oracle. If/when we need it to support macosx-aarch64, >>>>>> we will provide those changes. >>>>>> >>>>>> I must say I'm happy to see you managed to get a working build >>>>>> configuration with just this though! >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2020-08-01 00:24, Vladimir Kempik wrote: >>>>>>> Hello >>>>>>> >>>>>>> Please review this change for JDK-8250876 >>>>>>> >>>>>>> This changeset adds support for macos/aarch64 into build system. >>>>>>> It will allow to crosscompile for macos/aarch64 using intel mac as well. >>>>>>> >>>>>>> This changeset does NOT address some arm specific issues in the macos >>>>>>> related code, we plan to do that in s separate commit. >>>>>>> >>>>>>> An example of configure to cross-compile for macos/arm64: >>>>>>> >>>>>>> --with-boot-jdk=/path/to/java/ >>>>>>> --with-build-jdk=/path/to/same/java/as/compiled >>>>>>> --disable-warnings-as-errors --with-jvm-variants=zero >>>>>>> --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch >>>>>>> arm64' --with-extra-ldflags='-arch arm64 >>>>>>> -F/Path/To/Folder/Containing/JNF_framework/' >>>>>>> ?with-extra-cxxflags='-arch arm64? >>>>>>> >>>>>>> JNF.framework is missing arm64 part as of next macos release, but >>>>>>> Apple has opensourced it. >>>>>>> >>>>>>> Fix to adlc were needed due to it using symbols from stdc++ and not >>>>>>> linking to it, so it fails when doing make images. >>>>>>> >>>>>>> The webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~vkempik%2F8250876%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=HpXJmHXbuawTdExWESK9ssesYTuPTj7N6inXjaHfVaM%3D&reserved=0 >>>>>>> The bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=9z2Nw8d0pa5huxUKOYorMOVy6SBo7o%2FhDT1EmgOhxQ8%3D&reserved=0 >>>>>>> >>>>>>> Testing: jdk/submit. >>>>>>> >>>>>>> Thanks, Vladimir. >> From erik.joelsson at oracle.com Mon Aug 10 13:52:09 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Aug 2020 06:52:09 -0700 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: <45F59C7C-C597-436A-BF4B-19DC664FED34@azul.com> References: <2c0de319-aeb2-2c4d-2633-ddd612579165@oracle.com> <826FC20B-2EF3-4412-AF88-1CC6CE993919@azul.com> <5dc294b2-2968-b9ee-a227-68517cb2f0b8@oracle.com> <45F59C7C-C597-436A-BF4B-19DC664FED34@azul.com> Message-ID: <23616c11-d527-6a46-6ef2-8d6522eb261b@oracle.com> Yes, exactly. /Erik On 2020-08-10 06:16, Vladimir Kempik wrote: > Hello Erik > It?s not clear to me, what exactly you want to change in BUILD_CC, add > clang to list for macos ? > > Thanks, Vladimir > >> 10 ???. 2020 ?., ? 16:11, Erik Joelsson > > ???????(?): >> >> On 2020-08-10 03:47, Vladimir Kempik wrote: >>> Hello >>> >>> Renamed the bug to "Fix issues with cross-compile on macos" >>> >>> Please check updated webrev: >>> http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/ >>> >>> Adlc is fine with cross-compiling now. >>> >> While not strictly needed for ADLC, I would like to see BUILD_CC >> getting the same treatment here for consistency. >> >> /Erik >> >>> Regards, Vladimir >>>> 10 ???. 2020 ?., ? 12:52, Magnus Ihse Bursie >>>> >>> > ???????(?): >>>> >>>> So, basically, what this patch is about is not so much "preparation >>>> for aarch64" as "allow cross-compile on macos"?? If I understand >>>> you correctly, maybe you should rename the bug? >>>> >>>> /Magnus >>>> >>>> On 2020-08-04 16:09, Erik Joelsson wrote: >>>>> That's a good find! You are correct in that we haven't cross >>>>> compiled in any direction involving Macosx before. >>>>> >>>>> The preferred patch would be a bit more elaborate than that. >>>>> Ideally we need better control over the toolchain type of the >>>>> BUILD_* compiler settings. For now, I think just forcing >>>>> clang/clang++ if BUILD_OS is macosx is good enough. >>>>> >>>>> /Erik >>>>> >>>>> On 2020-08-04 07:02, Bernhard Urban-Forster wrote: >>>>>> Good observation David, the change in adlc is just fixing a >>>>>> symptom. The difference to a regular macOS build is that >>>>>> technically, despite running on the same machine, it's actually >>>>>> cross compiling due to Rosetta being the --build=x86_64 system. >>>>>> >>>>>> Being a cross-compile, we therefore hit this case: >>>>>> https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921 >>>>>> >>>>>> >>>>>> And thus infers `/usr/bin/CC` for CXX. >>>>>> >>>>>> I guess cross compiling hasn't been a thing on macOS yet. I tried >>>>>> the following and it passes the adlc build: >>>>>> >>>>>> --- a/make/autoconf/toolchain.m4 >>>>>> +++ b/make/autoconf/toolchain.m4 >>>>>> @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], >>>>>> ????? # find the build compilers in the tools dir, if needed. >>>>>> ????? UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc]) >>>>>> UTIL_FIXUP_EXECUTABLE(BUILD_CC) >>>>>> -??? UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++]) >>>>>> +??? UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++]) >>>>>> UTIL_FIXUP_EXECUTABLE(BUILD_CXX) >>>>>> ????? UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm) >>>>>> UTIL_FIXUP_EXECUTABLE(BUILD_NM) >>>>>> >>>>>> Although I'm not sure about its cleanliness :-) >>>>>> >>>>>> -Bernhard >>>>>> >>>>>> ________________________________________ >>>>>> From: build-dev >>>>> > on behalf of David >>>>>> Holmes > >>>>>> Sent: Tuesday, August 4, 2020 00:46 >>>>>> To: Erik Joelsson; Vladimir Kempik; build-dev >>>>>> Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov >>>>>> Subject: Re: RFR: 8250876: Build system preparation to macos on >>>>>> aarch64 >>>>>> >>>>>> On 3/08/2020 10:57 pm, Erik Joelsson wrote: >>>>>>> Hello Vladimir, >>>>>>> >>>>>>> These changes look innocent enough to me. They aren't actually >>>>>>> adding >>>>>>> macosx-aarch64 support, they are just removing two minor (and more >>>>>>> likely OS version related) hurdles from the build. You still have to >>>>>>> provide the actual configuration on the configure command line as is >>>>>>> shown in your example. Before we can call build system support, >>>>>>> we would >>>>>>> need configure to automatically setup those flags and add a separate >>>>>>> parameter for the JNF framework. So, given that, I don't think this >>>>>>> change warrants a JEP in itself. >>>>>> Of course this change doesn't warrant a JEP in itself :) My point is >>>>>> that until we have a JEP for the platform that is being targeted >>>>>> then we >>>>>> shouldn't be making changes to provide support for that platform. >>>>>> >>>>>> That said I didn't actually look at the changes but focused on the >>>>>> larger stated aim, so apologies for that. >>>>>> >>>>>> The actual changes here are small and not obviously related to >>>>>> supporting macOS-Aarch64. But I'm unclear on this change as it >>>>>> affects >>>>>> all macOS builds: >>>>>> >>>>>> ??? 42?? else ifeq ($(call isBuildOs, macosx), true) >>>>>> ??? 43???? ADLC_LDFLAGS := -lc++ >>>>>> >>>>>> if this was fixing a bug as indicated, why do we not see this bug in >>>>>> regular builds? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> My only complaint is that you revert jib-profiles.js. That file >>>>>>> is only >>>>>>> used internally at Oracle. If/when we need it to support >>>>>>> macosx-aarch64, >>>>>>> we will provide those changes. >>>>>>> >>>>>>> I must say I'm happy to see you managed to get a working build >>>>>>> configuration with just this though! >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2020-08-01 00:24, Vladimir Kempik wrote: >>>>>>>> Hello >>>>>>>> >>>>>>>> Please review this change for JDK-8250876 >>>>>>>> >>>>>>>> This changeset adds support for macos/aarch64 into build system. >>>>>>>> It will allow to crosscompile for macos/aarch64 using intel mac >>>>>>>> as well. >>>>>>>> >>>>>>>> This changeset does NOT address some arm specific issues in the >>>>>>>> macos >>>>>>>> related code, we plan to do that in s separate commit. >>>>>>>> >>>>>>>> An example of configure to cross-compile for macos/arm64: >>>>>>>> >>>>>>>> --with-boot-jdk=/path/to/java/ >>>>>>>> --with-build-jdk=/path/to/same/java/as/compiled >>>>>>>> --disable-warnings-as-errors --with-jvm-variants=zero >>>>>>>> --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch >>>>>>>> arm64' --with-extra-ldflags='-arch arm64 >>>>>>>> -F/Path/To/Folder/Containing/JNF_framework/' >>>>>>>> ?with-extra-cxxflags='-arch arm64? >>>>>>>> >>>>>>>> JNF.framework is missing arm64 part as of next macos release, but >>>>>>>> Apple has opensourced it. >>>>>>>> >>>>>>>> Fix to adlc were needed due to it using symbols from stdc++ and not >>>>>>>> linking to it, so it fails when doing make images. >>>>>>>> >>>>>>>> The webrev: >>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~vkempik%2F8250876%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=HpXJmHXbuawTdExWESK9ssesYTuPTj7N6inXjaHfVaM%3D&reserved=0 >>>>>>>> The bug: >>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=9z2Nw8d0pa5huxUKOYorMOVy6SBo7o%2FhDT1EmgOhxQ8%3D&reserved=0 >>>>>>>> >>>>>>>> Testing: jdk/submit. >>>>>>>> >>>>>>>> Thanks, Vladimir. >>> > From vkempik at azul.com Mon Aug 10 14:14:16 2020 From: vkempik at azul.com (Vladimir Kempik) Date: Mon, 10 Aug 2020 14:14:16 +0000 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: <5dc294b2-2968-b9ee-a227-68517cb2f0b8@oracle.com> References: <2c0de319-aeb2-2c4d-2633-ddd612579165@oracle.com> <826FC20B-2EF3-4412-AF88-1CC6CE993919@azul.com> <5dc294b2-2968-b9ee-a227-68517cb2f0b8@oracle.com> Message-ID: <9E2F389A-40A7-4FF9-BA27-42E35850DBCB@azul.com> Hello Please check the updated webrev - http://cr.openjdk.java.net/~vkempik/8250876/webrev.02/ Thanks, Vladimir > 10 ???. 2020 ?., ? 16:11, Erik Joelsson ???????(?): > > On 2020-08-10 03:47, Vladimir Kempik wrote: >> Hello >> >> Renamed the bug to "Fix issues with cross-compile on macos" >> >> Please check updated webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/ >> >> Adlc is fine with cross-compiling now. >> > While not strictly needed for ADLC, I would like to see BUILD_CC getting the same treatment here for consistency. > > /Erik > >> Regards, Vladimir >>> 10 ???. 2020 ?., ? 12:52, Magnus Ihse Bursie ???????(?): >>> >>> So, basically, what this patch is about is not so much "preparation for aarch64" as "allow cross-compile on macos"? If I understand you correctly, maybe you should rename the bug? >>> >>> /Magnus >>> >>> On 2020-08-04 16:09, Erik Joelsson wrote: >>>> That's a good find! You are correct in that we haven't cross compiled in any direction involving Macosx before. >>>> >>>> The preferred patch would be a bit more elaborate than that. Ideally we need better control over the toolchain type of the BUILD_* compiler settings. For now, I think just forcing clang/clang++ if BUILD_OS is macosx is good enough. >>>> >>>> /Erik >>>> >>>> On 2020-08-04 07:02, Bernhard Urban-Forster wrote: >>>>> Good observation David, the change in adlc is just fixing a symptom. The difference to a regular macOS build is that technically, despite running on the same machine, it's actually cross compiling due to Rosetta being the --build=x86_64 system. >>>>> >>>>> Being a cross-compile, we therefore hit this case: >>>>> https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921 >>>>> >>>>> And thus infers `/usr/bin/CC` for CXX. >>>>> >>>>> I guess cross compiling hasn't been a thing on macOS yet. I tried the following and it passes the adlc build: >>>>> >>>>> --- a/make/autoconf/toolchain.m4 >>>>> +++ b/make/autoconf/toolchain.m4 >>>>> @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], >>>>> # find the build compilers in the tools dir, if needed. >>>>> UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc]) >>>>> UTIL_FIXUP_EXECUTABLE(BUILD_CC) >>>>> - UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++]) >>>>> + UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++]) >>>>> UTIL_FIXUP_EXECUTABLE(BUILD_CXX) >>>>> UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm) >>>>> UTIL_FIXUP_EXECUTABLE(BUILD_NM) >>>>> >>>>> Although I'm not sure about its cleanliness :-) >>>>> >>>>> -Bernhard >>>>> >>>>> ________________________________________ >>>>> From: build-dev on behalf of David Holmes >>>>> Sent: Tuesday, August 4, 2020 00:46 >>>>> To: Erik Joelsson; Vladimir Kempik; build-dev >>>>> Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov >>>>> Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64 >>>>> >>>>> On 3/08/2020 10:57 pm, Erik Joelsson wrote: >>>>>> Hello Vladimir, >>>>>> >>>>>> These changes look innocent enough to me. They aren't actually adding >>>>>> macosx-aarch64 support, they are just removing two minor (and more >>>>>> likely OS version related) hurdles from the build. You still have to >>>>>> provide the actual configuration on the configure command line as is >>>>>> shown in your example. Before we can call build system support, we would >>>>>> need configure to automatically setup those flags and add a separate >>>>>> parameter for the JNF framework. So, given that, I don't think this >>>>>> change warrants a JEP in itself. >>>>> Of course this change doesn't warrant a JEP in itself :) My point is >>>>> that until we have a JEP for the platform that is being targeted then we >>>>> shouldn't be making changes to provide support for that platform. >>>>> >>>>> That said I didn't actually look at the changes but focused on the >>>>> larger stated aim, so apologies for that. >>>>> >>>>> The actual changes here are small and not obviously related to >>>>> supporting macOS-Aarch64. But I'm unclear on this change as it affects >>>>> all macOS builds: >>>>> >>>>> 42 else ifeq ($(call isBuildOs, macosx), true) >>>>> 43 ADLC_LDFLAGS := -lc++ >>>>> >>>>> if this was fixing a bug as indicated, why do we not see this bug in >>>>> regular builds? >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> My only complaint is that you revert jib-profiles.js. That file is only >>>>>> used internally at Oracle. If/when we need it to support macosx-aarch64, >>>>>> we will provide those changes. >>>>>> >>>>>> I must say I'm happy to see you managed to get a working build >>>>>> configuration with just this though! >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2020-08-01 00:24, Vladimir Kempik wrote: >>>>>>> Hello >>>>>>> >>>>>>> Please review this change for JDK-8250876 >>>>>>> >>>>>>> This changeset adds support for macos/aarch64 into build system. >>>>>>> It will allow to crosscompile for macos/aarch64 using intel mac as well. >>>>>>> >>>>>>> This changeset does NOT address some arm specific issues in the macos >>>>>>> related code, we plan to do that in s separate commit. >>>>>>> >>>>>>> An example of configure to cross-compile for macos/arm64: >>>>>>> >>>>>>> --with-boot-jdk=/path/to/java/ >>>>>>> --with-build-jdk=/path/to/same/java/as/compiled >>>>>>> --disable-warnings-as-errors --with-jvm-variants=zero >>>>>>> --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch >>>>>>> arm64' --with-extra-ldflags='-arch arm64 >>>>>>> -F/Path/To/Folder/Containing/JNF_framework/' >>>>>>> ?with-extra-cxxflags='-arch arm64? >>>>>>> >>>>>>> JNF.framework is missing arm64 part as of next macos release, but >>>>>>> Apple has opensourced it. >>>>>>> >>>>>>> Fix to adlc were needed due to it using symbols from stdc++ and not >>>>>>> linking to it, so it fails when doing make images. >>>>>>> >>>>>>> The webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~vkempik%2F8250876%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=HpXJmHXbuawTdExWESK9ssesYTuPTj7N6inXjaHfVaM%3D&reserved=0 >>>>>>> The bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=9z2Nw8d0pa5huxUKOYorMOVy6SBo7o%2FhDT1EmgOhxQ8%3D&reserved=0 >>>>>>> >>>>>>> Testing: jdk/submit. >>>>>>> >>>>>>> Thanks, Vladimir. >> From erik.joelsson at oracle.com Mon Aug 10 18:19:05 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Aug 2020 11:19:05 -0700 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: <9E2F389A-40A7-4FF9-BA27-42E35850DBCB@azul.com> References: <2c0de319-aeb2-2c4d-2633-ddd612579165@oracle.com> <826FC20B-2EF3-4412-AF88-1CC6CE993919@azul.com> <5dc294b2-2968-b9ee-a227-68517cb2f0b8@oracle.com> <9E2F389A-40A7-4FF9-BA27-42E35850DBCB@azul.com> Message-ID: <4f7a8bd8-df4e-c227-2ff2-ca55568e6e8e@oracle.com> Looks good. /Erik On 2020-08-10 07:14, Vladimir Kempik wrote: > Hello > Please check the updated webrev - http://cr.openjdk.java.net/~vkempik/8250876/webrev.02/ > Thanks, Vladimir > >> 10 ???. 2020 ?., ? 16:11, Erik Joelsson ???????(?): >> >> On 2020-08-10 03:47, Vladimir Kempik wrote: >>> Hello >>> >>> Renamed the bug to "Fix issues with cross-compile on macos" >>> >>> Please check updated webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/ >>> >>> Adlc is fine with cross-compiling now. >>> >> While not strictly needed for ADLC, I would like to see BUILD_CC getting the same treatment here for consistency. >> >> /Erik >> >>> Regards, Vladimir >>>> 10 ???. 2020 ?., ? 12:52, Magnus Ihse Bursie ???????(?): >>>> >>>> So, basically, what this patch is about is not so much "preparation for aarch64" as "allow cross-compile on macos"? If I understand you correctly, maybe you should rename the bug? >>>> >>>> /Magnus >>>> >>>> On 2020-08-04 16:09, Erik Joelsson wrote: >>>>> That's a good find! You are correct in that we haven't cross compiled in any direction involving Macosx before. >>>>> >>>>> The preferred patch would be a bit more elaborate than that. Ideally we need better control over the toolchain type of the BUILD_* compiler settings. For now, I think just forcing clang/clang++ if BUILD_OS is macosx is good enough. >>>>> >>>>> /Erik >>>>> >>>>> On 2020-08-04 07:02, Bernhard Urban-Forster wrote: >>>>>> Good observation David, the change in adlc is just fixing a symptom. The difference to a regular macOS build is that technically, despite running on the same machine, it's actually cross compiling due to Rosetta being the --build=x86_64 system. >>>>>> >>>>>> Being a cross-compile, we therefore hit this case: >>>>>> https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921 >>>>>> >>>>>> And thus infers `/usr/bin/CC` for CXX. >>>>>> >>>>>> I guess cross compiling hasn't been a thing on macOS yet. I tried the following and it passes the adlc build: >>>>>> >>>>>> --- a/make/autoconf/toolchain.m4 >>>>>> +++ b/make/autoconf/toolchain.m4 >>>>>> @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], >>>>>> # find the build compilers in the tools dir, if needed. >>>>>> UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc]) >>>>>> UTIL_FIXUP_EXECUTABLE(BUILD_CC) >>>>>> - UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++]) >>>>>> + UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++]) >>>>>> UTIL_FIXUP_EXECUTABLE(BUILD_CXX) >>>>>> UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm) >>>>>> UTIL_FIXUP_EXECUTABLE(BUILD_NM) >>>>>> >>>>>> Although I'm not sure about its cleanliness :-) >>>>>> >>>>>> -Bernhard >>>>>> >>>>>> ________________________________________ >>>>>> From: build-dev on behalf of David Holmes >>>>>> Sent: Tuesday, August 4, 2020 00:46 >>>>>> To: Erik Joelsson; Vladimir Kempik; build-dev >>>>>> Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov >>>>>> Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64 >>>>>> >>>>>> On 3/08/2020 10:57 pm, Erik Joelsson wrote: >>>>>>> Hello Vladimir, >>>>>>> >>>>>>> These changes look innocent enough to me. They aren't actually adding >>>>>>> macosx-aarch64 support, they are just removing two minor (and more >>>>>>> likely OS version related) hurdles from the build. You still have to >>>>>>> provide the actual configuration on the configure command line as is >>>>>>> shown in your example. Before we can call build system support, we would >>>>>>> need configure to automatically setup those flags and add a separate >>>>>>> parameter for the JNF framework. So, given that, I don't think this >>>>>>> change warrants a JEP in itself. >>>>>> Of course this change doesn't warrant a JEP in itself :) My point is >>>>>> that until we have a JEP for the platform that is being targeted then we >>>>>> shouldn't be making changes to provide support for that platform. >>>>>> >>>>>> That said I didn't actually look at the changes but focused on the >>>>>> larger stated aim, so apologies for that. >>>>>> >>>>>> The actual changes here are small and not obviously related to >>>>>> supporting macOS-Aarch64. But I'm unclear on this change as it affects >>>>>> all macOS builds: >>>>>> >>>>>> 42 else ifeq ($(call isBuildOs, macosx), true) >>>>>> 43 ADLC_LDFLAGS := -lc++ >>>>>> >>>>>> if this was fixing a bug as indicated, why do we not see this bug in >>>>>> regular builds? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> My only complaint is that you revert jib-profiles.js. That file is only >>>>>>> used internally at Oracle. If/when we need it to support macosx-aarch64, >>>>>>> we will provide those changes. >>>>>>> >>>>>>> I must say I'm happy to see you managed to get a working build >>>>>>> configuration with just this though! >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2020-08-01 00:24, Vladimir Kempik wrote: >>>>>>>> Hello >>>>>>>> >>>>>>>> Please review this change for JDK-8250876 >>>>>>>> >>>>>>>> This changeset adds support for macos/aarch64 into build system. >>>>>>>> It will allow to crosscompile for macos/aarch64 using intel mac as well. >>>>>>>> >>>>>>>> This changeset does NOT address some arm specific issues in the macos >>>>>>>> related code, we plan to do that in s separate commit. >>>>>>>> >>>>>>>> An example of configure to cross-compile for macos/arm64: >>>>>>>> >>>>>>>> --with-boot-jdk=/path/to/java/ >>>>>>>> --with-build-jdk=/path/to/same/java/as/compiled >>>>>>>> --disable-warnings-as-errors --with-jvm-variants=zero >>>>>>>> --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch >>>>>>>> arm64' --with-extra-ldflags='-arch arm64 >>>>>>>> -F/Path/To/Folder/Containing/JNF_framework/' >>>>>>>> ?with-extra-cxxflags='-arch arm64? >>>>>>>> >>>>>>>> JNF.framework is missing arm64 part as of next macos release, but >>>>>>>> Apple has opensourced it. >>>>>>>> >>>>>>>> Fix to adlc were needed due to it using symbols from stdc++ and not >>>>>>>> linking to it, so it fails when doing make images. >>>>>>>> >>>>>>>> The webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~vkempik%2F8250876%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=HpXJmHXbuawTdExWESK9ssesYTuPTj7N6inXjaHfVaM%3D&reserved=0 >>>>>>>> The bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cbeurba%40microsoft.com%7C0c8d58d5eb9144e8717f08d837ff3736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320916565796801&sdata=9z2Nw8d0pa5huxUKOYorMOVy6SBo7o%2FhDT1EmgOhxQ8%3D&reserved=0 >>>>>>>> >>>>>>>> Testing: jdk/submit. >>>>>>>> >>>>>>>> Thanks, Vladimir. From magnus.ihse.bursie at oracle.com Tue Aug 11 09:38:05 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Aug 2020 11:38:05 +0200 Subject: [OpenJDK 2D-Dev] 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager In-Reply-To: <5F31B27E.9040902@oracle.com> References: <5F31B27E.9040902@oracle.com> Message-ID: On 2020-08-10 22:47, Philip Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8251367 > webrev: http://cr.openjdk.java.net/~prr/8251367/ > > When using something other than the java launcher (ie the jpackage > launcher) > harfbuzz.dll is not found by windows dll loading. > So we need to load it explicitly else the Java class that loads > fontmanager,dll > will fail to initialize. > > At the same time, I'd like to fix a very minor inconsequential pair of > typoes > that exclude from the build files by the wrong directory pathname. Phil, Is the exclude still needed, if the build worked fine without it..? /Magnus > > -phil. From magnus.ihse.bursie at oracle.com Tue Aug 11 12:43:28 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Aug 2020 14:43:28 +0200 Subject: RFR: JDK-8251399 JDK-8248701 had incorrect indentation Message-ID: <3b24c889-7a30-b4b8-77fc-14a897fe7e07@oracle.com> The fix for JDK-8248701 did not start with a tab, despite being part of a recipe. While this is technically not required for continuted lines, we have as a code rule that all recipe lines should start with a tab. Webrev (and inline patches for that matter) sucks at showing this properly. Check the patch file if you want to verify that spaces are replaced with a tab. :-) Bug: https://bugs.openjdk.java.net/browse/JDK-8251399 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8251399-fix-whitespace-in-Modules/webrev.01 /Magnus From erik.joelsson at oracle.com Tue Aug 11 13:02:48 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 11 Aug 2020 06:02:48 -0700 Subject: RFR: JDK-8251399 JDK-8248701 had incorrect indentation In-Reply-To: <3b24c889-7a30-b4b8-77fc-14a897fe7e07@oracle.com> References: <3b24c889-7a30-b4b8-77fc-14a897fe7e07@oracle.com> Message-ID: <204fd7d6-a18f-d741-f118-364f7c435647@oracle.com> Looks good. /Erik On 2020-08-11 05:43, Magnus Ihse Bursie wrote: > The fix for JDK-8248701 did not start with a tab, despite being part > of a recipe. While this is technically not required for continuted > lines, we have as a code rule that all recipe lines should start with > a tab. > > Webrev (and inline patches for that matter) sucks at showing this > properly. Check the patch file if you want to verify that spaces are > replaced with a tab. :-) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251399 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8251399-fix-whitespace-in-Modules/webrev.01 > > /Magnus From philip.race at oracle.com Tue Aug 11 14:58:39 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 11 Aug 2020 07:58:39 -0700 Subject: [OpenJDK 2D-Dev] 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager In-Reply-To: References: <5F31B27E.9040902@oracle.com> Message-ID: <5F32B21F.1090005@oracle.com> One isn't strictly required, but the code in the file isn't used. The other (hb-coretext.cc) needs to be excluded on other platforms besides macOS. I think the build must actually strip the directory part and just look for the filename part, else the build should have failed with the wrong path. -phil. On 8/11/20, 2:38 AM, Magnus Ihse Bursie wrote: > > > On 2020-08-10 22:47, Philip Race wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8251367 >> webrev: http://cr.openjdk.java.net/~prr/8251367/ >> >> When using something other than the java launcher (ie the jpackage >> launcher) >> harfbuzz.dll is not found by windows dll loading. >> So we need to load it explicitly else the Java class that loads >> fontmanager,dll >> will fail to initialize. >> >> At the same time, I'd like to fix a very minor inconsequential pair >> of typoes >> that exclude from the build files by the wrong directory pathname. > Phil, > > Is the exclude still needed, if the build worked fine without it..? > > /Magnus >> >> -phil. > From suenaga at oss.nttdata.com Wed Aug 12 00:44:33 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 12 Aug 2020 09:44:33 +0900 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> Message-ID: <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> PING: Could you review this change? JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/ Build change has been reviewed by Erik. Thanks, Yasumasa On 2020/08/05 18:30, Yasumasa Suenaga wrote: > Hi Matthias, > (CC'ed build-dev due to makefile change) > > I uploaded new webrev. Could you review it? > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/ > > On 2020/08/05 16:26, Baesken, Matthias wrote: >> Hello, >> >>>> I also checked the? hserr on another Hyper-V guest and still get the expected " HyperV virtualization detected"?? (which is good ? ). >>>> >>>> >>>> However on a host, I would still prefer to get some output (probably different than the guest output now) . >>> >>> What message do you expect? How about "Hyper-V role detected" ? >> >> Thats okay with me? (I think some people here say "Hyper-V host" so that might be an idea as well). > > I said "Hyper-V host" in previous mails, but it is not strictly correct. In Hyper-V, it should be "root partision". However it's a little difficult to understand, so I choose "role" in this place. > > >>>> Regarding the usage of >>>> >>>> #pragma comment(lib, "wbemuuid.lib") >>>> >>>> This seem to add an additional lib dependency ,? should some people from build/deploy? area comment on this maybe ? >>>> (not saying it is a very bad thing ) > > I modified libraries.m4. > wbemuuid.lib is needed for WMI call. > > > Thanks, > > Yasumasa > > >>> We add wbemuuid.lib to make/autoconf/libraries.m4 . >>> I will change it in next webrev, and I will CCing to build-dev on next turn. >> >> >> Let's see what they have to say. >> >> Best regards, Matthias >> >> From matthias.baesken at sap.com Wed Aug 12 10:51:49 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 12 Aug 2020 10:51:49 +0000 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> Message-ID: Hi Yasumasa , I'm more or less fine with the change . But still not fully convinced that removing the iteration is a good thing . http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/cpu/x86/vm_version_x86.cpp.frames.html 1827 for (base = 0x40000000; base < 0x40010000; base += 0x100) { 1828 check_virt_cpuid(base, registers); I think just checking "0x40000000" should work in most cases but if I remember correctly sometimes it was not enough . See also some references about Xen/KVM : https://lists.linuxfoundation.org/pipermail/virtualization/2012-May/019974.html "If compat mode for another h/v is enabled then those leaves will appear at 0x40000000 and Xen's will be bumped up, so a fully Xen aware set of drivers (or detection routine, etc) should check at 0x100 intervals until 0x40010000 " and https://lore.kernel.org/patchwork/patch/394371/ And not so happy about the WMI usage (called in early JVM startup) : http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp.frames.html bool VM_Version::is_in_VM() { ... } ... } But if noone else complains about it, I guess it's okay . Best regards, Matthias >PING: Could you review this change? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/ > >Build change has been reviewed by Erik. > From david.holmes at oracle.com Wed Aug 12 12:12:23 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Aug 2020 22:12:23 +1000 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> Message-ID: <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> On 12/08/2020 8:51 pm, Baesken, Matthias wrote: > Hi Yasumasa , I'm more or less fine with the change . > But still not fully convinced that removing the iteration is a good thing . > > http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/cpu/x86/vm_version_x86.cpp.frames.html > > 1827 for (base = 0x40000000; base < 0x40010000; base += 0x100) { > 1828 check_virt_cpuid(base, registers); > > I think just checking "0x40000000" should work in most cases but if I remember correctly sometimes it was not enough . > See also some references about Xen/KVM : > > https://lists.linuxfoundation.org/pipermail/virtualization/2012-May/019974.html > > "If compat mode for another h/v is enabled then those leaves will appear > at 0x40000000 and Xen's will be bumped up, so a fully Xen aware set of > drivers (or detection routine, etc) should check at 0x100 intervals > until 0x40010000 " > > and > > https://lore.kernel.org/patchwork/patch/394371/ > > > > And not so happy about the WMI usage (called in early JVM startup) : > > http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp.frames.html > > bool VM_Version::is_in_VM() { ... } > ... > } > > But if noone else complains about it, I guess it's okay . I haven't reviewed this because I don't understand any of the code. But all that extra stuff during VM initialization doesn't look good to me. We do not want to pay a startup penalty just because we want a more accurate hypervisor listing in an error report! Can we not determine this only if needed? (Granted doing all this stuff during crash reporting may also be an issue.) David ----- > > Best regards, Matthias > > >> PING: Could you review this change? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 >> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/ >> >> Build change has been reviewed by Erik. >> > From suenaga at oss.nttdata.com Wed Aug 12 12:56:08 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 12 Aug 2020 21:56:08 +0900 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> Message-ID: <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> Hi Matthias, David, On 2020/08/12 21:12, David Holmes wrote: > On 12/08/2020 8:51 pm, Baesken, Matthias wrote: >> Hi Yasumasa ,? I'm more or less fine with the change . >> But still not fully convinced? that removing? the iteration is a good thing . >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/cpu/x86/vm_version_x86.cpp.frames.html >> >> 1827?? for (base = 0x40000000; base < 0x40010000; base += 0x100) { >> 1828???? check_virt_cpuid(base, registers); >> >> I think just checking? "0x40000000" should work in most cases but if I remember correctly sometimes it was not enough . >> See also? some references about Xen/KVM : >> >> https://lists.linuxfoundation.org/pipermail/virtualization/2012-May/019974.html >> >> "If compat mode for another h/v is enabled then those leaves will appear >> at 0x40000000 and Xen's will be bumped up, so a fully Xen aware set of >> drivers (or detection routine, etc) should check at 0x100 intervals >> until 0x40010000 " >> >> and >> >> https://lore.kernel.org/patchwork/patch/394371/ I understand that if the process runs on Xen on other hypervisor (e.g. KVM), information for Xen would be set between 0x40000100 and 0x40010000. Ok, I will not remove the loop in new webrev, and will add comment about it. >> And not so happy about the WMI? usage (called in early JVM startup) : >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp.frames.html >> >> bool VM_Version::is_in_VM() { ... } >> ? ... >> } >> >> ? But if noone else complains about it, I guess it's okay . > > I haven't reviewed this because I don't understand any of the code. But all that extra stuff during VM initialization doesn't look good to me. We do not want to pay a startup penalty just because we want a more accurate hypervisor listing in an error report! > > Can we not determine this only if needed? (Granted doing all this stuff during crash reporting may also be an issue.) This value would be used in hs_err and VM.info dcmd, so we can determine it when it is needed. However the change would be bigger, and it is not the original scope. Can we fix them at the same time? Thanks, Yasumasa > David > ----- > >> >> Best regards, Matthias >> >> >>> PING: Could you review this change? >>> >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 >>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/ >>> >>> Build change has been reviewed by Erik. >>> >> From david.holmes at oracle.com Wed Aug 12 13:04:41 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Aug 2020 23:04:41 +1000 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> Message-ID: Hi Yasumasa, On 12/08/2020 10:56 pm, Yasumasa Suenaga wrote: > Hi Matthias, David, > > On 2020/08/12 21:12, David Holmes wrote: >> On 12/08/2020 8:51 pm, Baesken, Matthias wrote: >>> Hi Yasumasa ,? I'm more or less fine with the change . >>> But still not fully convinced? that removing? the iteration is a good >>> thing . >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/cpu/x86/vm_version_x86.cpp.frames.html >>> >>> >>> 1827?? for (base = 0x40000000; base < 0x40010000; base += 0x100) { >>> 1828???? check_virt_cpuid(base, registers); >>> >>> I think just checking? "0x40000000" should work in most cases but if >>> I remember correctly sometimes it was not enough . >>> See also? some references about Xen/KVM : >>> >>> https://lists.linuxfoundation.org/pipermail/virtualization/2012-May/019974.html >>> >>> >>> "If compat mode for another h/v is enabled then those leaves will appear >>> at 0x40000000 and Xen's will be bumped up, so a fully Xen aware set of >>> drivers (or detection routine, etc) should check at 0x100 intervals >>> until 0x40010000 " >>> >>> and >>> >>> https://lore.kernel.org/patchwork/patch/394371/ > > I understand that if the process runs on Xen on other hypervisor (e.g. > KVM), information for Xen would be set between 0x40000100 and 0x40010000. > Ok, I will not remove the loop in new webrev, and will add comment about > it. > > >>> And not so happy about the WMI? usage (called in early JVM startup) : >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp.frames.html >>> >>> >>> bool VM_Version::is_in_VM() { ... } >>> ? ... >>> } >>> >>> ? But if noone else complains about it, I guess it's okay . >> >> I haven't reviewed this because I don't understand any of the code. >> But all that extra stuff during VM initialization doesn't look good to >> me. We do not want to pay a startup penalty just because we want a >> more accurate hypervisor listing in an error report! >> >> Can we not determine this only if needed? (Granted doing all this >> stuff during crash reporting may also be an issue.) > > This value would be used in hs_err and VM.info dcmd, so we can determine > it when it is needed. > However the change would be bigger, and it is not the original scope. > Can we fix them at the same time? Are you able to run startup benchmarks to see if there is any regression? David ----- > > Thanks, > > Yasumasa > > >> David >> ----- >> >>> >>> Best regards, Matthias >>> >>> >>>> PING: Could you review this change? >>>> >>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 >>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/ >>>> >>>> Build change has been reviewed by Erik. >>>> >>> From martin.doerr at sap.com Wed Aug 12 13:40:09 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 Aug 2020 13:40:09 +0000 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> Message-ID: Hi David, thanks for your good questions. I had also started to look at it and had similar thoughts. If we want to reduce overhead, inline assembler / intrisics will be better than creating a stub in the code cache. I think the existing inline assembler implementation for linux should also work on 32 bit linux. Maybe also on BSD (not sure). And on Windows, there's a __cpuid intrinsic available. (I have never tried it.) These implementations have no significant overhead. Maybe we can use them instead? Unfortunately, I'm not familiar with the code in vm_version_windows_x86.cpp, either. And I don't know if it's always fine to 0x40000000 as input to CPUID. Seems like Intel doesn't support that in the real instruction (returns all zero). I this value caught by all virtualization environments? Maybe we can find a little more precise name than "is_in_VM" because I usually think about the Java Thread state "_thread_in_vm". Nevertheless, I appreciate improvements in virtualization detection. Sometimes, problems or crashes are related to the virtualization layer, so having precise information is helpful. Best regards, Martin > -----Original Message----- > From: David Holmes > Sent: Mittwoch, 12. August 2020 15:05 > To: Yasumasa Suenaga ; Baesken, Matthias > ; hotspot-runtime-dev at openjdk.java.net; > build-dev at openjdk.java.net > Cc: Doerr, Martin > Subject: Re: PING: RFR: 8250598: Hyper-V is detected in spite of running on > host OS > > Hi Yasumasa, > > On 12/08/2020 10:56 pm, Yasumasa Suenaga wrote: > > Hi Matthias, David, > > > > On 2020/08/12 21:12, David Holmes wrote: > >> On 12/08/2020 8:51 pm, Baesken, Matthias wrote: > >>> Hi Yasumasa ,? I'm more or less fine with the change . > >>> But still not fully convinced? that removing? the iteration is a good > >>> thing . > >>> > >>> http://cr.openjdk.java.net/~ysuenaga/JDK- > 8250598/webrev.01/src/hotspot/cpu/x86/vm_version_x86.cpp.frames.html > >>> > >>> > >>> 1827?? for (base = 0x40000000; base < 0x40010000; base += 0x100) { > >>> 1828???? check_virt_cpuid(base, registers); > >>> > >>> I think just checking? "0x40000000" should work in most cases but if > >>> I remember correctly sometimes it was not enough . > >>> See also? some references about Xen/KVM : > >>> > >>> https://lists.linuxfoundation.org/pipermail/virtualization/2012- > May/019974.html > >>> > >>> > >>> "If compat mode for another h/v is enabled then those leaves will > appear > >>> at 0x40000000 and Xen's will be bumped up, so a fully Xen aware set of > >>> drivers (or detection routine, etc) should check at 0x100 intervals > >>> until 0x40010000 " > >>> > >>> and > >>> > >>> https://lore.kernel.org/patchwork/patch/394371/ > > > > I understand that if the process runs on Xen on other hypervisor (e.g. > > KVM), information for Xen would be set between 0x40000100 and > 0x40010000. > > Ok, I will not remove the loop in new webrev, and will add comment about > > it. > > > > > >>> And not so happy about the WMI? usage (called in early JVM startup) : > >>> > >>> http://cr.openjdk.java.net/~ysuenaga/JDK- > 8250598/webrev.01/src/hotspot/os_cpu/windows_x86/vm_version_windo > ws_x86.cpp.frames.html > >>> > >>> > >>> bool VM_Version::is_in_VM() { ... } > >>> ? ... > >>> } > >>> > >>> ? But if noone else complains about it, I guess it's okay . > >> > >> I haven't reviewed this because I don't understand any of the code. > >> But all that extra stuff during VM initialization doesn't look good to > >> me. We do not want to pay a startup penalty just because we want a > >> more accurate hypervisor listing in an error report! > >> > >> Can we not determine this only if needed? (Granted doing all this > >> stuff during crash reporting may also be an issue.) > > > > This value would be used in hs_err and VM.info dcmd, so we can > determine > > it when it is needed. > > However the change would be bigger, and it is not the original scope. > > Can we fix them at the same time? > > Are you able to run startup benchmarks to see if there is any regression? > > David > ----- > > > > > Thanks, > > > > Yasumasa > > > > > >> David > >> ----- > >> > >>> > >>> Best regards, Matthias > >>> > >>> > >>>> PING: Could you review this change? > >>>> > >>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 > >>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK- > 8250598/webrev.01/ > >>>> > >>>> Build change has been reviewed by Erik. > >>>> > >>> From matthias.baesken at sap.com Wed Aug 12 14:45:22 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 12 Aug 2020 14:45:22 +0000 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> Message-ID: > And on Windows, there's a __cpuid intrinsic available. (I have never tried it.) Hi Martin, we use this intrinsic in "our" JVM so yes it works . > Nevertheless, I appreciate improvements in virtualization detection. Sometimes, problems or crashes are related to the virtualization layer, so having precise information is helpful. Our support colleagues often use that info . Best regards, Matthias From matthias.baesken at sap.com Wed Aug 12 15:05:35 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 12 Aug 2020 15:05:35 +0000 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> Message-ID: >I understand that if the process runs on Xen on other hypervisor (e.g. KVM), information for Xen would be set between 0x40000100 and 0x40010000. >Ok, I will not remove the loop in new webrev, and will add comment about it. Hi Yasumasa , thanks ! Regarding the WMI overhead , if you could get some more info on this it would be better to judge if it is perfectly okay or concerning . (I remember that I looked into it a couple of years ago , but decided not to use it in early VM startup ; but have to confess this was just based on a "gut feeling", No micro benchmarks ) Best regards, Matthias From suenaga at oss.nttdata.com Thu Aug 13 01:12:29 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 13 Aug 2020 10:12:29 +0900 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> Message-ID: Hi Matthias, David, I measured startup benchmarks with `Measure-Command {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe --version}` on PowerShell. * PC: Ryzen 3 3300X, 16GB memory * OS: Windows 10 x64 (May 2020 Update) * Java: jdk/jdk revision 60537 (Compiled by VS 2019 (16.7.0)) * without patch TotalMilliseconds : 70.2124 TotalMilliseconds : 64.4465 TotalMilliseconds : 59.0854 TotalMilliseconds : 68.0255 TotalMilliseconds : 72.6467 average : 66.8833 * with webrev.01 TotalMilliseconds : 81.7185 TotalMilliseconds : 68.539 TotalMilliseconds : 85.7226 TotalMilliseconds : 72.6584 TotalMilliseconds : 75.6091 average : 76.84952 Overhead of WMI seems to be +10ms in this case. Yasumasa On 2020/08/13 0:05, Baesken, Matthias wrote: >> I understand that if the process runs on Xen on other hypervisor (e.g. KVM), information for Xen would be set between 0x40000100 and 0x40010000. >> Ok, I will not remove the loop in new webrev, and will add comment about it. > > Hi Yasumasa , thanks ! > > Regarding the WMI overhead , if you could get some more info on this it would be better to judge if it is perfectly okay or concerning . > > (I remember that I looked into it a couple of years ago , but decided not to use it in early VM startup ; but have to confess this was just based on a "gut feeling", > No micro benchmarks ) > > Best regards, Matthias > > From david.holmes at oracle.com Thu Aug 13 02:54:57 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Aug 2020 12:54:57 +1000 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> Message-ID: <97d20ede-53ba-86f8-674b-4ec7e244b12c@oracle.com> On 13/08/2020 11:12 am, Yasumasa Suenaga wrote: > Hi Matthias, David, > > I measured startup benchmarks with `Measure-Command > {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe > --version}` on PowerShell. > > * PC: Ryzen 3 3300X, 16GB memory > * OS: Windows 10 x64 (May 2020 Update) > * Java: jdk/jdk revision 60537 > ??? (Compiled by VS 2019 (16.7.0)) > > * without patch > TotalMilliseconds : 70.2124 > TotalMilliseconds : 64.4465 > TotalMilliseconds : 59.0854 > TotalMilliseconds : 68.0255 > TotalMilliseconds : 72.6467 > average : 66.8833 > > * with webrev.01 > TotalMilliseconds : 81.7185 > TotalMilliseconds : 68.539 > TotalMilliseconds : 85.7226 > TotalMilliseconds : 72.6584 > TotalMilliseconds : 75.6091 > average : 76.84952 > > Overhead of WMI seems to be +10ms in this case. Which is nearly 15%! Sorry but I just know Claes will be very unhappy if this were to go in as-is. David ----- > > Yasumasa > > > On 2020/08/13 0:05, Baesken, Matthias wrote: >>> I understand that if the process runs on Xen on other hypervisor >>> (e.g. KVM), information for Xen would be set between 0x40000100 and >>> 0x40010000. >>> Ok, I will not remove the loop in new webrev, and will add comment >>> about it. >> >> Hi Yasumasa? , thanks ! >> >> Regarding the WMI overhead , if you could? get some more info on this >> it would be better to judge if it is perfectly okay or? concerning . >> >> (I remember that I looked into it a couple of years ago , but decided >> not to use it in early VM startup ;? but have to confess this was just >> based on a "gut feeling", >> ? No micro benchmarks? ) >> >> Best regards, Matthias >> >> From suenaga at oss.nttdata.com Thu Aug 13 04:15:16 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 13 Aug 2020 13:15:16 +0900 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: <97d20ede-53ba-86f8-674b-4ec7e244b12c@oracle.com> References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> <97d20ede-53ba-86f8-674b-4ec7e244b12c@oracle.com> Message-ID: On 2020/08/13 11:54, David Holmes wrote: > On 13/08/2020 11:12 am, Yasumasa Suenaga wrote: >> Hi Matthias, David, >> >> I measured startup benchmarks with `Measure-Command {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe --version}` on PowerShell. >> >> * PC: Ryzen 3 3300X, 16GB memory >> * OS: Windows 10 x64 (May 2020 Update) >> * Java: jdk/jdk revision 60537 >> ???? (Compiled by VS 2019 (16.7.0)) >> >> * without patch >> TotalMilliseconds : 70.2124 >> TotalMilliseconds : 64.4465 >> TotalMilliseconds : 59.0854 >> TotalMilliseconds : 68.0255 >> TotalMilliseconds : 72.6467 >> average : 66.8833 >> >> * with webrev.01 >> TotalMilliseconds : 81.7185 >> TotalMilliseconds : 68.539 >> TotalMilliseconds : 85.7226 >> TotalMilliseconds : 72.6584 >> TotalMilliseconds : 75.6091 >> average : 76.84952 >> >> Overhead of WMI seems to be +10ms in this case. > > Which is nearly 15%! Sorry but I just know Claes will be very unhappy if this were to go in as-is. Should we make the change to determine just before it is needed (e.g. VM.info or hs_err log) at first? It is out of scope of this change, so I want to work as another issue if it is needed. Yasumasa > David > ----- > >> >> Yasumasa >> >> >> On 2020/08/13 0:05, Baesken, Matthias wrote: >>>> I understand that if the process runs on Xen on other hypervisor (e.g. KVM), information for Xen would be set between 0x40000100 and 0x40010000. >>>> Ok, I will not remove the loop in new webrev, and will add comment about it. >>> >>> Hi Yasumasa? , thanks ! >>> >>> Regarding the WMI overhead , if you could? get some more info on this it would be better to judge if it is perfectly okay or? concerning . >>> >>> (I remember that I looked into it a couple of years ago , but decided not to use it in early VM startup ;? but have to confess this was just based on a "gut feeling", >>> ? No micro benchmarks? ) >>> >>> Best regards, Matthias >>> >>> From david.holmes at oracle.com Thu Aug 13 06:20:09 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Aug 2020 16:20:09 +1000 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> <97d20ede-53ba-86f8-674b-4ec7e244b12c@oracle.com> Message-ID: <88d9af48-025e-9ae2-47f8-8e5e6cef3685@oracle.com> On 13/08/2020 2:15 pm, Yasumasa Suenaga wrote: > On 2020/08/13 11:54, David Holmes wrote: >> On 13/08/2020 11:12 am, Yasumasa Suenaga wrote: >>> Hi Matthias, David, >>> >>> I measured startup benchmarks with `Measure-Command >>> {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe >>> --version}` on PowerShell. >>> >>> * PC: Ryzen 3 3300X, 16GB memory >>> * OS: Windows 10 x64 (May 2020 Update) >>> * Java: jdk/jdk revision 60537 >>> ???? (Compiled by VS 2019 (16.7.0)) >>> >>> * without patch >>> TotalMilliseconds : 70.2124 >>> TotalMilliseconds : 64.4465 >>> TotalMilliseconds : 59.0854 >>> TotalMilliseconds : 68.0255 >>> TotalMilliseconds : 72.6467 >>> average : 66.8833 >>> >>> * with webrev.01 >>> TotalMilliseconds : 81.7185 >>> TotalMilliseconds : 68.539 >>> TotalMilliseconds : 85.7226 >>> TotalMilliseconds : 72.6584 >>> TotalMilliseconds : 75.6091 >>> average : 76.84952 >>> >>> Overhead of WMI seems to be +10ms in this case. >> >> Which is nearly 15%! Sorry but I just know Claes will be very unhappy >> if this were to go in as-is. > > Should we make the change to determine just before it is needed (e.g. > VM.info or hs_err log) at first? > It is out of scope of this change, so I want to work as another issue if > it is needed. Okay use another issue to do deferred initialization of detailed version info that may not be used. I'm not sure exactly what that covers. Concurrent initialization may be an issue to consider. Thanks, David P.S I have a long weekend coming up. > > Yasumasa > > >> David >> ----- >> >>> >>> Yasumasa >>> >>> >>> On 2020/08/13 0:05, Baesken, Matthias wrote: >>>>> I understand that if the process runs on Xen on other hypervisor >>>>> (e.g. KVM), information for Xen would be set between 0x40000100 and >>>>> 0x40010000. >>>>> Ok, I will not remove the loop in new webrev, and will add comment >>>>> about it. >>>> >>>> Hi Yasumasa? , thanks ! >>>> >>>> Regarding the WMI overhead , if you could? get some more info on >>>> this it would be better to judge if it is perfectly okay or >>>> concerning . >>>> >>>> (I remember that I looked into it a couple of years ago , but >>>> decided not to use it in early VM startup ;? but have to confess >>>> this was just based on a "gut feeling", >>>> ? No micro benchmarks? ) >>>> >>>> Best regards, Matthias >>>> >>>> From matthias.baesken at sap.com Thu Aug 13 06:52:28 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 13 Aug 2020 06:52:28 +0000 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <05f4a122-6b17-37f9-5ee4-228704308a6f@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> <97d20ede-53ba-86f8-674b-4ec7e244b12c@oracle.com> Message-ID: > >Should we make the change to determine just before it is needed (e.g. VM.info or hs_err log) at first? >It is out of scope of this change, so I want to work as another issue if it is needed. > Hi , I think we better do not call into WMI , when writing an hs_err file . Best regards, Matthias -----Original Message----- From: Yasumasa Suenaga Sent: Donnerstag, 13. August 2020 06:15 To: David Holmes ; Baesken, Matthias ; hotspot-runtime-dev at openjdk.java.net; build-dev at openjdk.java.net Cc: Doerr, Martin Subject: Re: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS On 2020/08/13 11:54, David Holmes wrote: > On 13/08/2020 11:12 am, Yasumasa Suenaga wrote: >> Hi Matthias, David, >> >> I measured startup benchmarks with `Measure-Command {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe --version}` on PowerShell. >> >> * PC: Ryzen 3 3300X, 16GB memory >> * OS: Windows 10 x64 (May 2020 Update) >> * Java: jdk/jdk revision 60537 >> ???? (Compiled by VS 2019 (16.7.0)) >> >> * without patch >> TotalMilliseconds : 70.2124 >> TotalMilliseconds : 64.4465 >> TotalMilliseconds : 59.0854 >> TotalMilliseconds : 68.0255 >> TotalMilliseconds : 72.6467 >> average : 66.8833 >> >> * with webrev.01 >> TotalMilliseconds : 81.7185 >> TotalMilliseconds : 68.539 >> TotalMilliseconds : 85.7226 >> TotalMilliseconds : 72.6584 >> TotalMilliseconds : 75.6091 >> average : 76.84952 >> >> Overhead of WMI seems to be +10ms in this case. > > Which is nearly 15%! Sorry but I just know Claes will be very unhappy if this were to go in as-is. Should we make the change to determine just before it is needed (e.g. VM.info or hs_err log) at first? It is out of scope of this change, so I want to work as another issue if it is needed. Yasumasa > David > ----- > >> >> Yasumasa >> >> >> On 2020/08/13 0:05, Baesken, Matthias wrote: >>>> I understand that if the process runs on Xen on other hypervisor (e.g. KVM), information for Xen would be set between 0x40000100 and 0x40010000. >>>> Ok, I will not remove the loop in new webrev, and will add comment about it. >>> >>> Hi Yasumasa? , thanks ! >>> >>> Regarding the WMI overhead , if you could? get some more info on this it would be better to judge if it is perfectly okay or? concerning . >>> >>> (I remember that I looked into it a couple of years ago , but decided not to use it in early VM startup ;? but have to confess this was just based on a "gut feeling", >>> ? No micro benchmarks? ) >>> >>> Best regards, Matthias >>> >>> From kim.barrett at oracle.com Thu Aug 13 07:15:11 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 13 Aug 2020 03:15:11 -0400 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: References: Message-ID: <870CF292-4100-442B-94D6-18133DC7E4DE@oracle.com> > On Aug 1, 2020, at 3:24 AM, Vladimir Kempik wrote: > > Hello > > Please review this change for JDK-8250876 > > This changeset adds support for macos/aarch64 into build system. > It will allow to crosscompile for macos/aarch64 using intel mac as well. > > This changeset does NOT address some arm specific issues in the macos related code, we plan to do that in s separate commit. > > An example of configure to cross-compile for macos/arm64: > > --with-boot-jdk=/path/to/java/ --with-build-jdk=/path/to/same/java/as/compiled --disable-warnings-as-errors --with-jvm-variants=zero --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch arm64' --with-extra-ldflags='-arch arm64 -F/Path/To/Folder/Containing/JNF_framework/' ?with-extra-cxxflags='-arch arm64? > > JNF.framework is missing arm64 part as of next macos release, but Apple has opensourced it. > > Fix to adlc were needed due to it using symbols from stdc++ and not linking to it, so it fails when doing make images. > > The webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.00/ > The bug: https://bugs.openjdk.java.net/browse/JDK-8250876 > > Testing: jdk/submit. > > Thanks, Vladimir. Coming late to the party, as I see this has already been pushed. But one thing caught my eye. ------------------------------------------------------------------------------ 42 else ifeq ($(call isBuildOs, macosx), true) 43 ADLC_LDFLAGS := -lc++ I'm surprised this is needed. I expected the C++ toolchain to implicitly include that, the way g++ does. If something like this really is needed, then it seems like it should be ADLC_LIBS that should be modified, rather than ADLC_LDFLAGS. Though I noticed there are currently no assignments to ADLC_LIBS. I'm similarly surprised by this pre-existing bit in CoreLibraries.gmk: $(eval $(call SetupJdkLibrary, BUILD_LIBJIMAGE, \ ... LIBS_unix := -ljvm -ldl $(LIBCXX), \ LIBS_macosx := -lc++, \ And that suggests a better place for all this (assuming its needed at all) is in lib-std.m4, setting LIBCXX for macosx and using it where needed. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Thu Aug 13 07:19:58 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 13 Aug 2020 03:19:58 -0400 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: <870CF292-4100-442B-94D6-18133DC7E4DE@oracle.com> References: <870CF292-4100-442B-94D6-18133DC7E4DE@oracle.com> Message-ID: <5AB651DB-6217-4D33-A1CD-6E3B1D0E31A2@oracle.com> > On Aug 13, 2020, at 3:15 AM, Kim Barrett wrote: > >> On Aug 1, 2020, at 3:24 AM, Vladimir Kempik wrote: >> >> Hello >> >> Please review this change for JDK-8250876 >> >> This changeset adds support for macos/aarch64 into build system. >> It will allow to crosscompile for macos/aarch64 using intel mac as well. >> >> This changeset does NOT address some arm specific issues in the macos related code, we plan to do that in s separate commit. >> >> An example of configure to cross-compile for macos/arm64: >> >> --with-boot-jdk=/path/to/java/ --with-build-jdk=/path/to/same/java/as/compiled --disable-warnings-as-errors --with-jvm-variants=zero --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch arm64' --with-extra-ldflags='-arch arm64 -F/Path/To/Folder/Containing/JNF_framework/' ?with-extra-cxxflags='-arch arm64? >> >> JNF.framework is missing arm64 part as of next macos release, but Apple has opensourced it. >> >> Fix to adlc were needed due to it using symbols from stdc++ and not linking to it, so it fails when doing make images. >> >> The webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.00/ >> The bug: https://bugs.openjdk.java.net/browse/JDK-8250876 >> >> Testing: jdk/submit. >> >> Thanks, Vladimir. > > Coming late to the party, as I see this has already been pushed. But > one thing caught my eye. I should have read further ahead in the thread. Looks like this got dealt with in a different way that seems much better. > > ------------------------------------------------------------------------------ > 42 else ifeq ($(call isBuildOs, macosx), true) > 43 ADLC_LDFLAGS := -lc++ > > I'm surprised this is needed. I expected the C++ toolchain to > implicitly include that, the way g++ does. > > If something like this really is needed, then it seems like it should > be ADLC_LIBS that should be modified, rather than ADLC_LDFLAGS. > Though I noticed there are currently no assignments to ADLC_LIBS. > > I'm similarly surprised by this pre-existing bit in CoreLibraries.gmk: > > $(eval $(call SetupJdkLibrary, BUILD_LIBJIMAGE, \ > ... > LIBS_unix := -ljvm -ldl $(LIBCXX), \ > LIBS_macosx := -lc++, \ > > And that suggests a better place for all this (assuming its needed at > all) is in lib-std.m4, setting LIBCXX for macosx and using it where > needed. > > ------------------------------------------------------------------------------ From suenaga at oss.nttdata.com Thu Aug 13 07:39:46 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 13 Aug 2020 16:39:46 +0900 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <247113e2-ca18-85c2-4743-e73ddd7dca14@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> <97d20ede-53ba-86f8-674b-4ec7e244b12c@oracle.com> Message-ID: Hi Matthias, David, On 2020/08/13 15:52, Baesken, Matthias wrote: > >> >> Should we make the change to determine just before it is needed (e.g. VM.info or hs_err log) at first? >> It is out of scope of this change, so I want to work as another issue if it is needed. >> > > Hi , > I think we better do not call into WMI , when writing an hs_err file . I found out from Hypervisor Top Level Functional Specification [1] section 2.4.8. That says CPUID leaf 0x40000007 is available to the root partition only. I changed VM_Version::is_in_VM() as below, and it works fine. (I use __cpuid intrinsic in here because this code would be compiled by cl.exe only.) ``` #include #define EAX 0 #define EBX 1 #define ECX 2 #define EDX 3 bool VM_Version::is_in_VM() { int regs[4]; __cpuid(regs, 0x40000007); // CPUID leaf 0x40000007 is available to the root partition only. return (regs[EAX] == 0x0) && (regs[EBX] == 0x0) && (regs[ECX] == 0x0) && (regs[EDX] == 0x0); } ``` Also startup performance is better than WMI call. TotalMilliseconds : 66.7863 TotalMilliseconds : 56.8123 TotalMilliseconds : 57.0015 TotalMilliseconds : 62.4755 TotalMilliseconds : 67.7632 average : 62.16776 If you are ok this change, I will update webrev, and will send review request. (new webrev will include both loop for CPUID leaf and renaming is_in_VM) Thanks, Yasumasa [1] https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/master/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v6.0b.pdf > Best regards, Matthias > > > > -----Original Message----- > From: Yasumasa Suenaga > Sent: Donnerstag, 13. August 2020 06:15 > To: David Holmes ; Baesken, Matthias ; hotspot-runtime-dev at openjdk.java.net; build-dev at openjdk.java.net > Cc: Doerr, Martin > Subject: Re: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS > > On 2020/08/13 11:54, David Holmes wrote: >> On 13/08/2020 11:12 am, Yasumasa Suenaga wrote: >>> Hi Matthias, David, >>> >>> I measured startup benchmarks with `Measure-Command {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe --version}` on PowerShell. >>> >>> * PC: Ryzen 3 3300X, 16GB memory >>> * OS: Windows 10 x64 (May 2020 Update) >>> * Java: jdk/jdk revision 60537 >>> ???? (Compiled by VS 2019 (16.7.0)) >>> >>> * without patch >>> TotalMilliseconds : 70.2124 >>> TotalMilliseconds : 64.4465 >>> TotalMilliseconds : 59.0854 >>> TotalMilliseconds : 68.0255 >>> TotalMilliseconds : 72.6467 >>> average : 66.8833 >>> >>> * with webrev.01 >>> TotalMilliseconds : 81.7185 >>> TotalMilliseconds : 68.539 >>> TotalMilliseconds : 85.7226 >>> TotalMilliseconds : 72.6584 >>> TotalMilliseconds : 75.6091 >>> average : 76.84952 >>> >>> Overhead of WMI seems to be +10ms in this case. >> >> Which is nearly 15%! Sorry but I just know Claes will be very unhappy if this were to go in as-is. > > Should we make the change to determine just before it is needed (e.g. VM.info or hs_err log) at first? > It is out of scope of this change, so I want to work as another issue if it is needed. > > > Yasumasa > > >> David >> ----- >> >>> >>> Yasumasa >>> >>> >>> On 2020/08/13 0:05, Baesken, Matthias wrote: >>>>> I understand that if the process runs on Xen on other hypervisor (e.g. KVM), information for Xen would be set between 0x40000100 and 0x40010000. >>>>> Ok, I will not remove the loop in new webrev, and will add comment about it. >>>> >>>> Hi Yasumasa? , thanks ! >>>> >>>> Regarding the WMI overhead , if you could? get some more info on this it would be better to judge if it is perfectly okay or? concerning . >>>> >>>> (I remember that I looked into it a couple of years ago , but decided not to use it in early VM startup ;? but have to confess this was just based on a "gut feeling", >>>> ? No micro benchmarks? ) >>>> >>>> Best regards, Matthias >>>> >>>> From magnus.ihse.bursie at oracle.com Thu Aug 13 10:38:34 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Aug 2020 12:38:34 +0200 Subject: RFR: JDK-8251516 VSCode IDE configuration specifies c++03 Message-ID: <9ad1254c-4948-c774-9524-ae31043903c9@oracle.com> From the bug report: make/ide/vscode/hotspot/indexers/cpptools-settings.txt: ?"C_Cpp.default.cppStandard": "c++03", make/ide/vscode/hotspot/indexers/rtags-settings.txt: ?"C_Cpp.default.cppStandard": "c++03", make/ide/vscode/hotspot/indexers/ccls-settings.txt: ?"C_Cpp.default.cppStandard": "c++03", make/ide/vscode/hotspot/indexers/clangd-settings.txt: ?"C_Cpp.default.cppStandard": "c++03", Those should probably be c++14 now. Bug: https://bugs.openjdk.java.net/browse/JDK-8251516 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8251516-fix-vscode-ide-gen-for-c++14/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Thu Aug 13 10:54:12 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Aug 2020 12:54:12 +0200 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: <870CF292-4100-442B-94D6-18133DC7E4DE@oracle.com> References: <870CF292-4100-442B-94D6-18133DC7E4DE@oracle.com> Message-ID: <4af641c6-8607-f3b1-08b2-53ace5c87200@oracle.com> On 2020-08-13 09:15, Kim Barrett wrote: >> On Aug 1, 2020, at 3:24 AM, Vladimir Kempik wrote: >> >> Hello >> >> Please review this change for JDK-8250876 >> >> This changeset adds support for macos/aarch64 into build system. >> It will allow to crosscompile for macos/aarch64 using intel mac as well. >> >> This changeset does NOT address some arm specific issues in the macos related code, we plan to do that in s separate commit. >> >> An example of configure to cross-compile for macos/arm64: >> >> --with-boot-jdk=/path/to/java/ --with-build-jdk=/path/to/same/java/as/compiled --disable-warnings-as-errors --with-jvm-variants=zero --openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch arm64' --with-extra-ldflags='-arch arm64 -F/Path/To/Folder/Containing/JNF_framework/' ?with-extra-cxxflags='-arch arm64? >> >> JNF.framework is missing arm64 part as of next macos release, but Apple has opensourced it. >> >> Fix to adlc were needed due to it using symbols from stdc++ and not linking to it, so it fails when doing make images. >> >> The webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.00/ >> The bug: https://bugs.openjdk.java.net/browse/JDK-8250876 >> >> Testing: jdk/submit. >> >> Thanks, Vladimir. > Coming late to the party, as I see this has already been pushed. But > one thing caught my eye. > > ------------------------------------------------------------------------------ > 42 else ifeq ($(call isBuildOs, macosx), true) > 43 ADLC_LDFLAGS := -lc++ > > I'm surprised this is needed. I expected the C++ toolchain to > implicitly include that, the way g++ does. > > If something like this really is needed, then it seems like it should > be ADLC_LIBS that should be modified, rather than ADLC_LDFLAGS. > Though I noticed there are currently no assignments to ADLC_LIBS. > > I'm similarly surprised by this pre-existing bit in CoreLibraries.gmk: > > $(eval $(call SetupJdkLibrary, BUILD_LIBJIMAGE, \ > ... > LIBS_unix := -ljvm -ldl $(LIBCXX), \ > LIBS_macosx := -lc++, \ > > And that suggests a better place for all this (assuming its needed at > all) is in lib-std.m4, setting LIBCXX for macosx and using it where > needed. Yes, that looks weird. Probably some left-over from the initial integration of libjimage. I can build fine locally without it; I'm just verifying that it also works in the CI. Thank you for noticing this! /Magnus > > ------------------------------------------------------------------------------ > From kim.barrett at oracle.com Thu Aug 13 10:59:04 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 13 Aug 2020 06:59:04 -0400 Subject: RFR: 8250876: Build system preparation to macos on aarch64 In-Reply-To: <4af641c6-8607-f3b1-08b2-53ace5c87200@oracle.com> References: <870CF292-4100-442B-94D6-18133DC7E4DE@oracle.com> <4af641c6-8607-f3b1-08b2-53ace5c87200@oracle.com> Message-ID: > On Aug 13, 2020, at 6:54 AM, Magnus Ihse Bursie wrote: > > On 2020-08-13 09:15, Kim Barrett wrote: >> I'm similarly surprised by this pre-existing bit in CoreLibraries.gmk: >> >> $(eval $(call SetupJdkLibrary, BUILD_LIBJIMAGE, \ >> ... >> LIBS_unix := -ljvm -ldl $(LIBCXX), \ >> LIBS_macosx := -lc++, \ >> >> And that suggests a better place for all this (assuming its needed at >> all) is in lib-std.m4, setting LIBCXX for macosx and using it where >> needed. > Yes, that looks weird. Probably some left-over from the initial integration of libjimage. I can build fine locally without it; I'm just verifying that it also works in the CI. Thank you for noticing this! I just filed https://bugs.openjdk.java.net/browse/JDK-8251533 for that. From david.holmes at oracle.com Thu Aug 13 11:39:49 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Aug 2020 21:39:49 +1000 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> <97d20ede-53ba-86f8-674b-4ec7e244b12c@oracle.com> Message-ID: <08584797-0841-945e-ec6d-7050a12326b4@oracle.com> On 13/08/2020 5:39 pm, Yasumasa Suenaga wrote: > Hi Matthias, David, > > On 2020/08/13 15:52, Baesken, Matthias wrote: >> >>> >>> Should we make the change to determine just before it is needed (e.g. >>> VM.info or hs_err log) at first? >>> It is out of scope of this change, so I want to work as another issue >>> if it is needed. >>> >> >> Hi , >> I think we better do not call into WMI , when? writing an hs_err file?? . > > I found out from Hypervisor Top Level Functional Specification [1] > section 2.4.8. > That says CPUID leaf 0x40000007 is available to the root partition only. > > I changed VM_Version::is_in_VM() as below, and it works fine. > (I use __cpuid intrinsic in here because this code would be compiled by > cl.exe only.) > > ``` > #include > > #define EAX 0 > #define EBX 1 > #define ECX 2 > #define EDX 3 > > bool VM_Version::is_in_VM() { > ? int regs[4]; > ? __cpuid(regs, 0x40000007); > > ? // CPUID leaf 0x40000007 is available to the root partition only. > ? return (regs[EAX] == 0x0) && (regs[EBX] == 0x0) && (regs[ECX] == 0x0) > && (regs[EDX] == 0x0); > } > ``` > > Also startup performance is better than WMI call. > > TotalMilliseconds : 66.7863 > TotalMilliseconds : 56.8123 > TotalMilliseconds : 57.0015 > TotalMilliseconds : 62.4755 > TotalMilliseconds : 67.7632 > average : 62.16776 > > If you are ok this change, I will update webrev, and will send review > request. > (new webrev will include both loop for CPUID leaf and renaming is_in_VM) If it works and addresses the startup hit then I'm fine with it - but still can't actually review the code. Thanks, David > > Thanks, > > Yasumasa > > > [1] > https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/master/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v6.0b.pdf > > > >> Best regards, Matthias >> >> >> >> -----Original Message----- >> From: Yasumasa Suenaga >> Sent: Donnerstag, 13. August 2020 06:15 >> To: David Holmes ; Baesken, Matthias >> ; hotspot-runtime-dev at openjdk.java.net; >> build-dev at openjdk.java.net >> Cc: Doerr, Martin >> Subject: Re: PING: RFR: 8250598: Hyper-V is detected in spite of >> running on host OS >> >> On 2020/08/13 11:54, David Holmes wrote: >>> On 13/08/2020 11:12 am, Yasumasa Suenaga wrote: >>>> Hi Matthias, David, >>>> >>>> I measured startup benchmarks with `Measure-Command >>>> {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe >>>> --version}` on PowerShell. >>>> >>>> * PC: Ryzen 3 3300X, 16GB memory >>>> * OS: Windows 10 x64 (May 2020 Update) >>>> * Java: jdk/jdk revision 60537 >>>> ????? (Compiled by VS 2019 (16.7.0)) >>>> >>>> * without patch >>>> TotalMilliseconds : 70.2124 >>>> TotalMilliseconds : 64.4465 >>>> TotalMilliseconds : 59.0854 >>>> TotalMilliseconds : 68.0255 >>>> TotalMilliseconds : 72.6467 >>>> average : 66.8833 >>>> >>>> * with webrev.01 >>>> TotalMilliseconds : 81.7185 >>>> TotalMilliseconds : 68.539 >>>> TotalMilliseconds : 85.7226 >>>> TotalMilliseconds : 72.6584 >>>> TotalMilliseconds : 75.6091 >>>> average : 76.84952 >>>> >>>> Overhead of WMI seems to be +10ms in this case. >>> >>> Which is nearly 15%! Sorry but I just know Claes will be very unhappy >>> if this were to go in as-is. >> >> Should we make the change to determine just before it is needed (e.g. >> VM.info or hs_err log) at first? >> It is out of scope of this change, so I want to work as another issue >> if it is needed. >> >> >> Yasumasa >> >> >>> David >>> ----- >>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/08/13 0:05, Baesken, Matthias wrote: >>>>>> I understand that if the process runs on Xen on other hypervisor >>>>>> (e.g. KVM), information for Xen would be set between 0x40000100 >>>>>> and 0x40010000. >>>>>> Ok, I will not remove the loop in new webrev, and will add comment >>>>>> about it. >>>>> >>>>> Hi Yasumasa? , thanks ! >>>>> >>>>> Regarding the WMI overhead , if you could? get some more info on >>>>> this it would be better to judge if it is perfectly okay or >>>>> concerning . >>>>> >>>>> (I remember that I looked into it a couple of years ago , but >>>>> decided not to use it in early VM startup ;? but have to confess >>>>> this was just based on a "gut feeling", >>>>> ?? No micro benchmarks? ) >>>>> >>>>> Best regards, Matthias >>>>> >>>>> From magnus.ihse.bursie at oracle.com Thu Aug 13 12:00:52 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Aug 2020 14:00:52 +0200 Subject: RFR: JDK-8251533 MacOS build of libjimage explicitly adds C++ standard library Message-ID: <50d3d24e-fc1a-ca38-b710-0e300f7525db@oracle.com> From the bug report: In CoreLibraries.gmk we have $(eval $(call SetupJdkLibrary, BUILD_LIBJIMAGE, \ ... ???LIBS_unix := -ljvm -ldl $(LIBCXX), \ ???LIBS_macosx := -lc++, \ I think the LIBS_macosx line should not be needed. Other similar places don't seem to do that. If it were necessary to explicitly add the C++ standard library to the link command, that would be better done by setting up LIBCXX. Bug: https://bugs.openjdk.java.net/browse/JDK-8251533 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8251533-libjimage-links-with-lc++/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Aug 13 13:20:20 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Aug 2020 06:20:20 -0700 Subject: RFR: JDK-8251516 VSCode IDE configuration specifies c++03 In-Reply-To: <9ad1254c-4948-c774-9524-ae31043903c9@oracle.com> References: <9ad1254c-4948-c774-9524-ae31043903c9@oracle.com> Message-ID: <3d00bb45-6dc5-d43d-27a2-b677d8e7e732@oracle.com> Looks good. /Erik On 2020-08-13 03:38, Magnus Ihse Bursie wrote: > From the bug report: > > make/ide/vscode/hotspot/indexers/cpptools-settings.txt: > ?"C_Cpp.default.cppStandard": "c++03", > make/ide/vscode/hotspot/indexers/rtags-settings.txt: > ?"C_Cpp.default.cppStandard": "c++03", > make/ide/vscode/hotspot/indexers/ccls-settings.txt: > ?"C_Cpp.default.cppStandard": "c++03", > make/ide/vscode/hotspot/indexers/clangd-settings.txt: > ?"C_Cpp.default.cppStandard": "c++03", > > Those should probably be c++14 now. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251516 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8251516-fix-vscode-ide-gen-for-c++14/webrev.01 > > /Magnus From erik.joelsson at oracle.com Thu Aug 13 13:22:52 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Aug 2020 06:22:52 -0700 Subject: RFR: JDK-8251533 MacOS build of libjimage explicitly adds C++ standard library In-Reply-To: <50d3d24e-fc1a-ca38-b710-0e300f7525db@oracle.com> References: <50d3d24e-fc1a-ca38-b710-0e300f7525db@oracle.com> Message-ID: <6e57aa53-c08c-7c96-1142-1a49c4716772@oracle.com> Looks good. In the ADLC case, it seemed to be needed when linking with gcc instead of clang. /Erik On 2020-08-13 05:00, Magnus Ihse Bursie wrote: > From the bug report: > > In CoreLibraries.gmk we have > > $(eval $(call SetupJdkLibrary, BUILD_LIBJIMAGE, \ > ... > ???LIBS_unix := -ljvm -ldl $(LIBCXX), \ > ???LIBS_macosx := -lc++, \ > > I think the LIBS_macosx line should not be needed. Other similar > places don't seem to do that. If it were necessary to explicitly add > the C++ standard library to the link command, that would be better > done by setting up LIBCXX. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251533 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8251533-libjimage-links-with-lc++/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Thu Aug 13 15:26:42 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Aug 2020 17:26:42 +0200 Subject: RFR: JDK-8251541 "no symbols" printed when building hotspot Message-ID: <036d51ba-6a1c-88cc-b8c0-3f97dbc3350b@oracle.com> Recently a lot of "no symbols" is shown when building hotspot, at least on macOS. This comes from the new/delete operator check which uses nm. I have checked the source of these problems. Several files are now empty due to refactoring and the use of (incidentally) file-wide #ifdefs. So we just need to handle the fact that nm can write "no symbols" to stderr. I also refactored the operator checking to use ExecuteWithLog, which would have helped me track down this issue, had it been there from the beginning. :) I have verified that this solves the bug. I have also for testing introduced a incorrect use of "new" and verified that this still trigger. Bug: https://bugs.openjdk.java.net/browse/JDK-8251541 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8251541-stop-printing-no-symbol/webrev.01 /Magnus From joe.darcy at oracle.com Thu Aug 13 17:40:09 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 13 Aug 2020 10:40:09 -0700 Subject: JDK 16 RFR of JDK-8251549: Update docs on building for Git Message-ID: <8466e28c-065e-7dc3-c862-27ed48762d59@oracle.com> Hello, Ahead of the JDK switching to Git, please review the updates to the build docs: ??? JDK-8251549: Update docs on building for Git ??? http://cr.openjdk.java.net/~darcy/8251549.0/ This would be pushed shortly *after* the transition to Git. Once the changes to md are agree to, I'll regenerate the companion html file. Thanks, -Joe From suenaga at oss.nttdata.com Fri Aug 14 02:36:26 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 14 Aug 2020 11:36:26 +0900 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: <08584797-0841-945e-ec6d-7050a12326b4@oracle.com> References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> <97d20ede-53ba-86f8-674b-4ec7e244b12c@oracle.com> <08584797-0841-945e-ec6d-7050a12326b4@oracle.com> Message-ID: <0facc9ee-eb47-a40c-4064-75d648b48eab@oss.nttdata.com> Hi David, Matthias, Martin, I uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.02/ It generates runtime stub for hypervisor detection, and it can distinguish between Hyper-V host (root partition) and guest. And also it works on 32bit platforms. I measured startup performance (java --version) with Measure-Command on PowerShell, this change is faster than current implementation. TotalMilliseconds : 57.8196 TotalMilliseconds : 66.8379 TotalMilliseconds : 64.7693 TotalMilliseconds : 55.6546 TotalMilliseconds : 63.848 average : 61.78588 This change has passed tests on submit repo (mach5-one-ysuenaga-JDK-8250598-20200814-0119-13424118), and also it works fine on following environments: - Hyper-V host (Windows 10 x64) - Hyper-V guest (Windows 10 x64) - Hyper-V guest (Linux x64) - Hyper-V guest (32bit JDK on Linux x64) Thanks, Yasumasa On 2020/08/13 20:39, David Holmes wrote: > On 13/08/2020 5:39 pm, Yasumasa Suenaga wrote: >> Hi Matthias, David, >> >> On 2020/08/13 15:52, Baesken, Matthias wrote: >>> >>>> >>>> Should we make the change to determine just before it is needed (e.g. VM.info or hs_err log) at first? >>>> It is out of scope of this change, so I want to work as another issue if it is needed. >>>> >>> >>> Hi , >>> I think we better do not call into WMI , when? writing an hs_err file?? . >> >> I found out from Hypervisor Top Level Functional Specification [1] section 2.4.8. >> That says CPUID leaf 0x40000007 is available to the root partition only. >> >> I changed VM_Version::is_in_VM() as below, and it works fine. >> (I use __cpuid intrinsic in here because this code would be compiled by cl.exe only.) >> >> ``` >> #include >> >> #define EAX 0 >> #define EBX 1 >> #define ECX 2 >> #define EDX 3 >> >> bool VM_Version::is_in_VM() { >> ?? int regs[4]; >> ?? __cpuid(regs, 0x40000007); >> >> ?? // CPUID leaf 0x40000007 is available to the root partition only. >> ?? return (regs[EAX] == 0x0) && (regs[EBX] == 0x0) && (regs[ECX] == 0x0) && (regs[EDX] == 0x0); >> } >> ``` >> >> Also startup performance is better than WMI call. >> >> TotalMilliseconds : 66.7863 >> TotalMilliseconds : 56.8123 >> TotalMilliseconds : 57.0015 >> TotalMilliseconds : 62.4755 >> TotalMilliseconds : 67.7632 >> average : 62.16776 >> >> If you are ok this change, I will update webrev, and will send review request. >> (new webrev will include both loop for CPUID leaf and renaming is_in_VM) > > If it works and addresses the startup hit then I'm fine with it - but still can't actually review the code. > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> [1] https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/master/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v6.0b.pdf >> >> >>> Best regards, Matthias >>> >>> >>> >>> -----Original Message----- >>> From: Yasumasa Suenaga >>> Sent: Donnerstag, 13. August 2020 06:15 >>> To: David Holmes ; Baesken, Matthias ; hotspot-runtime-dev at openjdk.java.net; build-dev at openjdk.java.net >>> Cc: Doerr, Martin >>> Subject: Re: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS >>> >>> On 2020/08/13 11:54, David Holmes wrote: >>>> On 13/08/2020 11:12 am, Yasumasa Suenaga wrote: >>>>> Hi Matthias, David, >>>>> >>>>> I measured startup benchmarks with `Measure-Command {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe --version}` on PowerShell. >>>>> >>>>> * PC: Ryzen 3 3300X, 16GB memory >>>>> * OS: Windows 10 x64 (May 2020 Update) >>>>> * Java: jdk/jdk revision 60537 >>>>> ????? (Compiled by VS 2019 (16.7.0)) >>>>> >>>>> * without patch >>>>> TotalMilliseconds : 70.2124 >>>>> TotalMilliseconds : 64.4465 >>>>> TotalMilliseconds : 59.0854 >>>>> TotalMilliseconds : 68.0255 >>>>> TotalMilliseconds : 72.6467 >>>>> average : 66.8833 >>>>> >>>>> * with webrev.01 >>>>> TotalMilliseconds : 81.7185 >>>>> TotalMilliseconds : 68.539 >>>>> TotalMilliseconds : 85.7226 >>>>> TotalMilliseconds : 72.6584 >>>>> TotalMilliseconds : 75.6091 >>>>> average : 76.84952 >>>>> >>>>> Overhead of WMI seems to be +10ms in this case. >>>> >>>> Which is nearly 15%! Sorry but I just know Claes will be very unhappy if this were to go in as-is. >>> >>> Should we make the change to determine just before it is needed (e.g. VM.info or hs_err log) at first? >>> It is out of scope of this change, so I want to work as another issue if it is needed. >>> >>> >>> Yasumasa >>> >>> >>>> David >>>> ----- >>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2020/08/13 0:05, Baesken, Matthias wrote: >>>>>>> I understand that if the process runs on Xen on other hypervisor (e.g. KVM), information for Xen would be set between 0x40000100 and 0x40010000. >>>>>>> Ok, I will not remove the loop in new webrev, and will add comment about it. >>>>>> >>>>>> Hi Yasumasa? , thanks ! >>>>>> >>>>>> Regarding the WMI overhead , if you could? get some more info on this it would be better to judge if it is perfectly okay or concerning . >>>>>> >>>>>> (I remember that I looked into it a couple of years ago , but decided not to use it in early VM startup ;? but have to confess this was just based on a "gut feeling", >>>>>> ?? No micro benchmarks? ) >>>>>> >>>>>> Best regards, Matthias >>>>>> >>>>>> From magnus.ihse.bursie at oracle.com Fri Aug 14 09:19:35 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Aug 2020 11:19:35 +0200 Subject: JDK 16 RFR of JDK-8251549: Update docs on building for Git In-Reply-To: <8466e28c-065e-7dc3-c862-27ed48762d59@oracle.com> References: <8466e28c-065e-7dc3-c862-27ed48762d59@oracle.com> Message-ID: <874787e3-3443-d5a9-b711-9dbb04602e1b@oracle.com> On 2020-08-13 19:40, Joe Darcy wrote: > Hello, > > Ahead of the JDK switching to Git, please review the updates to the > build docs: > > ??? JDK-8251549: Update docs on building for Git > ??? http://cr.openjdk.java.net/~darcy/8251549.0/ > > This would be pushed shortly *after* the transition to Git. > > Once the changes to md are agree to, I'll regenerate the companion > html file. My main question here is your recommendation to use https://gitforwindows.org. Have you verified that this works in all circumstances? The reason we had the entire paragraph was that this was certainly not true for mercurial -- if you used a version of hg that did not know about mercurial metadata, weird things started happen after a while. I think it was stuff like permissions being set and copied incorrectly, etc. Sometimes paths got messed up, like if you used symlinks etc. Unfortunately, I don't remember all details, but it tended to be a handful of edge cases with hard-to-debug failures each year. So my gut reaction here is that we should keep this recommendation: use "git" from cygwin, instead of using a stand-alone version. And if you have tested this thoroughly and show that gitforwindows seem to work, we do not keep those instructions in the list of special considerations for Windows at all. /Magnus > > Thanks, > > -Joe > From magnus.ihse.bursie at oracle.com Fri Aug 14 10:14:08 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Aug 2020 12:14:08 +0200 Subject: JDK 16 RFR of JDK-8251549: Update docs on building for Git In-Reply-To: <8466e28c-065e-7dc3-c862-27ed48762d59@oracle.com> References: <8466e28c-065e-7dc3-c862-27ed48762d59@oracle.com> Message-ID: On 2020-08-13 19:40, Joe Darcy wrote: > Hello, > > Ahead of the JDK switching to Git, please review the updates to the > build docs: > > ??? JDK-8251549: Update docs on building for Git > ??? http://cr.openjdk.java.net/~darcy/8251549.0/ Also (more a stylistic thing): +??? `git clone https://git.openjdk.java.net/jdk/` Why not drop the trailing /? One less character to type, and you need not worry readers if it's strictly needed or not. /Magnus > > This would be pushed shortly *after* the transition to Git. > > Once the changes to md are agree to, I'll regenerate the companion > html file. > > Thanks, > > -Joe > From erik.joelsson at oracle.com Fri Aug 14 12:49:03 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Aug 2020 05:49:03 -0700 Subject: RFR: JDK-8251541 "no symbols" printed when building hotspot In-Reply-To: <036d51ba-6a1c-88cc-b8c0-3f97dbc3350b@oracle.com> References: <036d51ba-6a1c-88cc-b8c0-3f97dbc3350b@oracle.com> Message-ID: <45f53ffc-999a-21cc-607e-e555d5af6918@oracle.com> On 2020-08-13 08:26, Magnus Ihse Bursie wrote: > Recently a lot of "no symbols" is shown when building hotspot, at > least on macOS. > > This comes from the new/delete operator check which uses nm. > > I have checked the source of these problems. Several files are now > empty due to refactoring and the use of (incidentally) file-wide > #ifdefs. So we just need to handle the fact that nm can write "no > symbols" to stderr. > > I also refactored the operator checking to use ExecuteWithLog, which > would have helped me track down this issue, had it been there from the > beginning. :) > I'm not sure how ExecuteWithLog helps. In your version of this recipe, both stdout and stderr are piped together into the greps and then stored in $1.op_check, which happens to be the same file ExecuteWithLog is piping output to, so there are two sets of pipes to this file. To me this looks like any output on stderr is will just get filtered out and the pipes ExecuteWithLog adds will never do anything. /Erik > I have verified that this solves the bug. I have also for testing > introduced a incorrect use of "new" and verified that this still trigger. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251541 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8251541-stop-printing-no-symbol/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Fri Aug 14 13:21:33 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Aug 2020 15:21:33 +0200 Subject: RFR: JDK-8251541 "no symbols" printed when building hotspot In-Reply-To: <45f53ffc-999a-21cc-607e-e555d5af6918@oracle.com> References: <036d51ba-6a1c-88cc-b8c0-3f97dbc3350b@oracle.com> <45f53ffc-999a-21cc-607e-e555d5af6918@oracle.com> Message-ID: <05e7035e-813b-9e45-cc7f-7514b30fc593@oracle.com> On 2020-08-14 14:49, Erik Joelsson wrote: > On 2020-08-13 08:26, Magnus Ihse Bursie wrote: >> Recently a lot of "no symbols" is shown when building hotspot, at >> least on macOS. >> >> This comes from the new/delete operator check which uses nm. >> >> I have checked the source of these problems. Several files are now >> empty due to refactoring and the use of (incidentally) file-wide >> #ifdefs. So we just need to handle the fact that nm can write "no >> symbols" to stderr. >> >> I also refactored the operator checking to use ExecuteWithLog, which >> would have helped me track down this issue, had it been there from >> the beginning. :) >> > I'm not sure how ExecuteWithLog helps. In your version of this recipe, > both stdout and stderr are piped together into the greps and then > stored in $1.op_check, which happens to be the same file > ExecuteWithLog is piping output to, so there are two sets of pipes to > this file. To me this looks like any output on stderr is will just get > filtered out and the pipes ExecuteWithLog adds will never do anything. Good point.? I insist though that, had we had ExecuteWithLog, the error message to stderr would have been easier for me to track, when we didn't pipe stderr. :-) However, ExecuteWithLog does other things than logging the output. It also stored the command line for easy reproducability. My intention is to long-term convert all external execution to using ExecuteWithLog (or some form thereof). So if you don't mind, I'd still like to keep it. /Magnus > > /Erik > >> I have verified that this solves the bug. I have also for testing >> introduced a incorrect use of "new" and verified that this still >> trigger. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8251541 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8251541-stop-printing-no-symbol/webrev.01 >> >> /Magnus From erik.joelsson at oracle.com Fri Aug 14 13:35:34 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Aug 2020 06:35:34 -0700 Subject: RFR: JDK-8251541 "no symbols" printed when building hotspot In-Reply-To: <05e7035e-813b-9e45-cc7f-7514b30fc593@oracle.com> References: <036d51ba-6a1c-88cc-b8c0-3f97dbc3350b@oracle.com> <45f53ffc-999a-21cc-607e-e555d5af6918@oracle.com> <05e7035e-813b-9e45-cc7f-7514b30fc593@oracle.com> Message-ID: <4c5dc9de-fc88-1122-afb3-9d017c94b613@oracle.com> Ok by me. /Erik On 2020-08-14 06:21, Magnus Ihse Bursie wrote: > On 2020-08-14 14:49, Erik Joelsson wrote: >> On 2020-08-13 08:26, Magnus Ihse Bursie wrote: >>> Recently a lot of "no symbols" is shown when building hotspot, at >>> least on macOS. >>> >>> This comes from the new/delete operator check which uses nm. >>> >>> I have checked the source of these problems. Several files are now >>> empty due to refactoring and the use of (incidentally) file-wide >>> #ifdefs. So we just need to handle the fact that nm can write "no >>> symbols" to stderr. >>> >>> I also refactored the operator checking to use ExecuteWithLog, which >>> would have helped me track down this issue, had it been there from >>> the beginning. :) >>> >> I'm not sure how ExecuteWithLog helps. In your version of this >> recipe, both stdout and stderr are piped together into the greps and >> then stored in $1.op_check, which happens to be the same file >> ExecuteWithLog is piping output to, so there are two sets of pipes to >> this file. To me this looks like any output on stderr is will just >> get filtered out and the pipes ExecuteWithLog adds will never do >> anything. > Good point.? I insist though that, had we had ExecuteWithLog, the > error message to stderr would have been easier for me to track, when > we didn't pipe stderr. :-) > > However, ExecuteWithLog does other things than logging the output. It > also stored the command line for easy reproducability. My intention is > to long-term convert all external execution to using ExecuteWithLog > (or some form thereof). > > So if you don't mind, I'd still like to keep it. > > /Magnus > > >> >> /Erik >> >>> I have verified that this solves the bug. I have also for testing >>> introduced a incorrect use of "new" and verified that this still >>> trigger. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8251541 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8251541-stop-printing-no-symbol/webrev.01 >>> >>> /Magnus > From david.holmes at oracle.com Tue Aug 18 01:42:45 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Aug 2020 11:42:45 +1000 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: <0facc9ee-eb47-a40c-4064-75d648b48eab@oss.nttdata.com> References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <37c30cea-c4f7-f329-c8dd-4e719cad608e@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> <97d20ede-53ba-86f8-674b-4ec7e244b12c@oracle.com> <08584797-0841-945e-ec6d-7050a12326b4@oracle.com> <0facc9ee-eb47-a40c-4064-75d648b48eab@oss.nttdata.com> Message-ID: <145b716c-54ee-b32a-d008-a4ca3e7359db@oracle.com> Hi Yasumasa, On 14/08/2020 12:36 pm, Yasumasa Suenaga wrote: > Hi David, Matthias, Martin, > > I uploaded new webrev. Could you review again? > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.02/ > > It generates runtime stub for hypervisor detection, and it can > distinguish between Hyper-V host (root partition) and guest. And also it > works on 32bit platforms. > > I measured startup performance (java --version) with Measure-Command on > PowerShell, this change is faster than current implementation. > > TotalMilliseconds : 57.8196 > TotalMilliseconds : 66.8379 > TotalMilliseconds : 64.7693 > TotalMilliseconds : 55.6546 > TotalMilliseconds : 63.848 > average : 61.78588 This seems good to me, but again I can't review the details. My main concern is how you are testing this across a range of virtualized hosts? But if it fixes your Hyper-V issue and doesn't break anything else then I am fine with it. I will leave the technical review to Martin and Matthias. FYI I'm heading out on a weeks vacation after today so won't be able to follow up further. Thanks, David > This change has passed tests on submit repo > (mach5-one-ysuenaga-JDK-8250598-20200814-0119-13424118), and also it > works fine on following environments: > > ? - Hyper-V host (Windows 10 x64) > ? - Hyper-V guest (Windows 10 x64) > ? - Hyper-V guest (Linux x64) > ? - Hyper-V guest (32bit JDK on Linux x64) > > > Thanks, > > Yasumasa > > > On 2020/08/13 20:39, David Holmes wrote: >> On 13/08/2020 5:39 pm, Yasumasa Suenaga wrote: >>> Hi Matthias, David, >>> >>> On 2020/08/13 15:52, Baesken, Matthias wrote: >>>> >>>>> >>>>> Should we make the change to determine just before it is needed >>>>> (e.g. VM.info or hs_err log) at first? >>>>> It is out of scope of this change, so I want to work as another >>>>> issue if it is needed. >>>>> >>>> >>>> Hi , >>>> I think we better do not call into WMI , when? writing an hs_err >>>> file?? . >>> >>> I found out from Hypervisor Top Level Functional Specification [1] >>> section 2.4.8. >>> That says CPUID leaf 0x40000007 is available to the root partition only. >>> >>> I changed VM_Version::is_in_VM() as below, and it works fine. >>> (I use __cpuid intrinsic in here because this code would be compiled >>> by cl.exe only.) >>> >>> ``` >>> #include >>> >>> #define EAX 0 >>> #define EBX 1 >>> #define ECX 2 >>> #define EDX 3 >>> >>> bool VM_Version::is_in_VM() { >>> ?? int regs[4]; >>> ?? __cpuid(regs, 0x40000007); >>> >>> ?? // CPUID leaf 0x40000007 is available to the root partition only. >>> ?? return (regs[EAX] == 0x0) && (regs[EBX] == 0x0) && (regs[ECX] == >>> 0x0) && (regs[EDX] == 0x0); >>> } >>> ``` >>> >>> Also startup performance is better than WMI call. >>> >>> TotalMilliseconds : 66.7863 >>> TotalMilliseconds : 56.8123 >>> TotalMilliseconds : 57.0015 >>> TotalMilliseconds : 62.4755 >>> TotalMilliseconds : 67.7632 >>> average : 62.16776 >>> >>> If you are ok this change, I will update webrev, and will send review >>> request. >>> (new webrev will include both loop for CPUID leaf and renaming is_in_VM) >> >> If it works and addresses the startup hit then I'm fine with it - but >> still can't actually review the code. >> >> Thanks, >> David >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/master/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v6.0b.pdf >>> >>> >>> >>>> Best regards, Matthias >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Yasumasa Suenaga >>>> Sent: Donnerstag, 13. August 2020 06:15 >>>> To: David Holmes ; Baesken, Matthias >>>> ; hotspot-runtime-dev at openjdk.java.net; >>>> build-dev at openjdk.java.net >>>> Cc: Doerr, Martin >>>> Subject: Re: PING: RFR: 8250598: Hyper-V is detected in spite of >>>> running on host OS >>>> >>>> On 2020/08/13 11:54, David Holmes wrote: >>>>> On 13/08/2020 11:12 am, Yasumasa Suenaga wrote: >>>>>> Hi Matthias, David, >>>>>> >>>>>> I measured startup benchmarks with `Measure-Command >>>>>> {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe >>>>>> --version}` on PowerShell. >>>>>> >>>>>> * PC: Ryzen 3 3300X, 16GB memory >>>>>> * OS: Windows 10 x64 (May 2020 Update) >>>>>> * Java: jdk/jdk revision 60537 >>>>>> ????? (Compiled by VS 2019 (16.7.0)) >>>>>> >>>>>> * without patch >>>>>> TotalMilliseconds : 70.2124 >>>>>> TotalMilliseconds : 64.4465 >>>>>> TotalMilliseconds : 59.0854 >>>>>> TotalMilliseconds : 68.0255 >>>>>> TotalMilliseconds : 72.6467 >>>>>> average : 66.8833 >>>>>> >>>>>> * with webrev.01 >>>>>> TotalMilliseconds : 81.7185 >>>>>> TotalMilliseconds : 68.539 >>>>>> TotalMilliseconds : 85.7226 >>>>>> TotalMilliseconds : 72.6584 >>>>>> TotalMilliseconds : 75.6091 >>>>>> average : 76.84952 >>>>>> >>>>>> Overhead of WMI seems to be +10ms in this case. >>>>> >>>>> Which is nearly 15%! Sorry but I just know Claes will be very >>>>> unhappy if this were to go in as-is. >>>> >>>> Should we make the change to determine just before it is needed >>>> (e.g. VM.info or hs_err log) at first? >>>> It is out of scope of this change, so I want to work as another >>>> issue if it is needed. >>>> >>>> >>>> Yasumasa >>>> >>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2020/08/13 0:05, Baesken, Matthias wrote: >>>>>>>> I understand that if the process runs on Xen on other hypervisor >>>>>>>> (e.g. KVM), information for Xen would be set between 0x40000100 >>>>>>>> and 0x40010000. >>>>>>>> Ok, I will not remove the loop in new webrev, and will add >>>>>>>> comment about it. >>>>>>> >>>>>>> Hi Yasumasa? , thanks ! >>>>>>> >>>>>>> Regarding the WMI overhead , if you could? get some more info on >>>>>>> this it would be better to judge if it is perfectly okay or >>>>>>> concerning . >>>>>>> >>>>>>> (I remember that I looked into it a couple of years ago , but >>>>>>> decided not to use it in early VM startup ;? but have to confess >>>>>>> this was just based on a "gut feeling", >>>>>>> ?? No micro benchmarks? ) >>>>>>> >>>>>>> Best regards, Matthias >>>>>>> >>>>>>> From suenaga at oss.nttdata.com Tue Aug 18 03:02:47 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 18 Aug 2020 12:02:47 +0900 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: <145b716c-54ee-b32a-d008-a4ca3e7359db@oracle.com> References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> <97d20ede-53ba-86f8-674b-4ec7e244b12c@oracle.com> <08584797-0841-945e-ec6d-7050a12326b4@oracle.com> <0facc9ee-eb47-a40c-4064-75d648b48eab@oss.nttdata.com> <145b716c-54ee-b32a-d008-a4ca3e7359db@oracle.com> Message-ID: On 2020/08/18 10:42, David Holmes wrote: > Hi Yasumasa, > > On 14/08/2020 12:36 pm, Yasumasa Suenaga wrote: >> Hi David, Matthias, Martin, >> >> I uploaded new webrev. Could you review again? >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.02/ >> >> It generates runtime stub for hypervisor detection, and it can distinguish between Hyper-V host (root partition) and guest. And also it works on 32bit platforms. >> >> I measured startup performance (java --version) with Measure-Command on PowerShell, this change is faster than current implementation. >> >> TotalMilliseconds : 57.8196 >> TotalMilliseconds : 66.8379 >> TotalMilliseconds : 64.7693 >> TotalMilliseconds : 55.6546 >> TotalMilliseconds : 63.848 >> average : 61.78588 > > This seems good to me, but again I can't review the details. My main concern is how you are testing this across a range of virtualized hosts? But if it fixes your Hyper-V issue and doesn't break anything else then I am fine with it. Thanks David! I don't have any other virtualized hosts excepting Hyper-V, so I cannot test any more. However detection logic is equivalent from current implementation, so I believe it does not break anything else if it works fine on Hyper-V. And also Matthias has queued this change to internal tests in SAP. I guess he will share the result next week. > I will leave the technical review to Martin and Matthias. > > FYI I'm heading out on a weeks vacation after today so won't be able to follow up further. Have a nice vacation! Thanks, Yasumasa > Thanks, > David > >> This change has passed tests on submit repo (mach5-one-ysuenaga-JDK-8250598-20200814-0119-13424118), and also it works fine on following environments: >> >> ?? - Hyper-V host (Windows 10 x64) >> ?? - Hyper-V guest (Windows 10 x64) >> ?? - Hyper-V guest (Linux x64) >> ?? - Hyper-V guest (32bit JDK on Linux x64) >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/08/13 20:39, David Holmes wrote: >>> On 13/08/2020 5:39 pm, Yasumasa Suenaga wrote: >>>> Hi Matthias, David, >>>> >>>> On 2020/08/13 15:52, Baesken, Matthias wrote: >>>>> >>>>>> >>>>>> Should we make the change to determine just before it is needed (e.g. VM.info or hs_err log) at first? >>>>>> It is out of scope of this change, so I want to work as another issue if it is needed. >>>>>> >>>>> >>>>> Hi , >>>>> I think we better do not call into WMI , when? writing an hs_err file?? . >>>> >>>> I found out from Hypervisor Top Level Functional Specification [1] section 2.4.8. >>>> That says CPUID leaf 0x40000007 is available to the root partition only. >>>> >>>> I changed VM_Version::is_in_VM() as below, and it works fine. >>>> (I use __cpuid intrinsic in here because this code would be compiled by cl.exe only.) >>>> >>>> ``` >>>> #include >>>> >>>> #define EAX 0 >>>> #define EBX 1 >>>> #define ECX 2 >>>> #define EDX 3 >>>> >>>> bool VM_Version::is_in_VM() { >>>> ?? int regs[4]; >>>> ?? __cpuid(regs, 0x40000007); >>>> >>>> ?? // CPUID leaf 0x40000007 is available to the root partition only. >>>> ?? return (regs[EAX] == 0x0) && (regs[EBX] == 0x0) && (regs[ECX] == 0x0) && (regs[EDX] == 0x0); >>>> } >>>> ``` >>>> >>>> Also startup performance is better than WMI call. >>>> >>>> TotalMilliseconds : 66.7863 >>>> TotalMilliseconds : 56.8123 >>>> TotalMilliseconds : 57.0015 >>>> TotalMilliseconds : 62.4755 >>>> TotalMilliseconds : 67.7632 >>>> average : 62.16776 >>>> >>>> If you are ok this change, I will update webrev, and will send review request. >>>> (new webrev will include both loop for CPUID leaf and renaming is_in_VM) >>> >>> If it works and addresses the startup hit then I'm fine with it - but still can't actually review the code. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/master/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v6.0b.pdf >>>> >>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Yasumasa Suenaga >>>>> Sent: Donnerstag, 13. August 2020 06:15 >>>>> To: David Holmes ; Baesken, Matthias ; hotspot-runtime-dev at openjdk.java.net; build-dev at openjdk.java.net >>>>> Cc: Doerr, Martin >>>>> Subject: Re: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS >>>>> >>>>> On 2020/08/13 11:54, David Holmes wrote: >>>>>> On 13/08/2020 11:12 am, Yasumasa Suenaga wrote: >>>>>>> Hi Matthias, David, >>>>>>> >>>>>>> I measured startup benchmarks with `Measure-Command {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe --version}` on PowerShell. >>>>>>> >>>>>>> * PC: Ryzen 3 3300X, 16GB memory >>>>>>> * OS: Windows 10 x64 (May 2020 Update) >>>>>>> * Java: jdk/jdk revision 60537 >>>>>>> ????? (Compiled by VS 2019 (16.7.0)) >>>>>>> >>>>>>> * without patch >>>>>>> TotalMilliseconds : 70.2124 >>>>>>> TotalMilliseconds : 64.4465 >>>>>>> TotalMilliseconds : 59.0854 >>>>>>> TotalMilliseconds : 68.0255 >>>>>>> TotalMilliseconds : 72.6467 >>>>>>> average : 66.8833 >>>>>>> >>>>>>> * with webrev.01 >>>>>>> TotalMilliseconds : 81.7185 >>>>>>> TotalMilliseconds : 68.539 >>>>>>> TotalMilliseconds : 85.7226 >>>>>>> TotalMilliseconds : 72.6584 >>>>>>> TotalMilliseconds : 75.6091 >>>>>>> average : 76.84952 >>>>>>> >>>>>>> Overhead of WMI seems to be +10ms in this case. >>>>>> >>>>>> Which is nearly 15%! Sorry but I just know Claes will be very unhappy if this were to go in as-is. >>>>> >>>>> Should we make the change to determine just before it is needed (e.g. VM.info or hs_err log) at first? >>>>> It is out of scope of this change, so I want to work as another issue if it is needed. >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2020/08/13 0:05, Baesken, Matthias wrote: >>>>>>>>> I understand that if the process runs on Xen on other hypervisor (e.g. KVM), information for Xen would be set between 0x40000100 and 0x40010000. >>>>>>>>> Ok, I will not remove the loop in new webrev, and will add comment about it. >>>>>>>> >>>>>>>> Hi Yasumasa? , thanks ! >>>>>>>> >>>>>>>> Regarding the WMI overhead , if you could? get some more info on this it would be better to judge if it is perfectly okay or concerning . >>>>>>>> >>>>>>>> (I remember that I looked into it a couple of years ago , but decided not to use it in early VM startup ;? but have to confess this was just based on a "gut feeling", >>>>>>>> ?? No micro benchmarks? ) >>>>>>>> >>>>>>>> Best regards, Matthias >>>>>>>> >>>>>>>> From martin.doerr at sap.com Tue Aug 18 14:39:20 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 18 Aug 2020 14:39:20 +0000 Subject: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <3a1a5ff7-308d-c003-fc34-14b276ecaf43@oss.nttdata.com> <3ff5ac95-7664-cf03-9c25-05f47a2509a8@oss.nttdata.com> <416db93b-6d12-266f-9210-5f92a4840e6c@oracle.com> <0f535934-731b-0989-3bfa-51c332902399@oss.nttdata.com> <97d20ede-53ba-86f8-674b-4ec7e244b12c@oracle.com> <08584797-0841-945e-ec6d-7050a12326b4@oracle.com> <0facc9ee-eb47-a40c-4064-75d648b48eab@oss.nttdata.com> <145b716c-54ee-b32a-d008-a4ca3e7359db@oracle.com> Message-ID: Hi Yasumasa, thanks a lot for measuring and improving the overhead. This version looks much better. I still wonder what the reason was for using a stub. There was probably a reason, but I don't remember. Hopefully, Matthias can find time for another review when he's back next week. Thanks and best regards, Martin > -----Original Message----- > From: Yasumasa Suenaga > Sent: Dienstag, 18. August 2020 05:03 > To: David Holmes ; Baesken, Matthias > ; hotspot-runtime-dev at openjdk.java.net; > build-dev at openjdk.java.net; Doerr, Martin > Subject: Re: PING: RFR: 8250598: Hyper-V is detected in spite of running on > host OS > > On 2020/08/18 10:42, David Holmes wrote: > > Hi Yasumasa, > > > > On 14/08/2020 12:36 pm, Yasumasa Suenaga wrote: > >> Hi David, Matthias, Martin, > >> > >> I uploaded new webrev. Could you review again? > >> > >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.02/ > >> > >> It generates runtime stub for hypervisor detection, and it can distinguish > between Hyper-V host (root partition) and guest. And also it works on 32bit > platforms. > >> > >> I measured startup performance (java --version) with Measure-Command > on PowerShell, this change is faster than current implementation. > >> > >> TotalMilliseconds : 57.8196 > >> TotalMilliseconds : 66.8379 > >> TotalMilliseconds : 64.7693 > >> TotalMilliseconds : 55.6546 > >> TotalMilliseconds : 63.848 > >> average : 61.78588 > > > > This seems good to me, but again I can't review the details. My main > concern is how you are testing this across a range of virtualized hosts? But if it > fixes your Hyper-V issue and doesn't break anything else then I am fine with > it. > > Thanks David! > > I don't have any other virtualized hosts excepting Hyper-V, so I cannot test > any more. > However detection logic is equivalent from current implementation, so I > believe it does not break anything else if it works fine on Hyper-V. > > And also Matthias has queued this change to internal tests in SAP. I guess he > will share the result next week. > > > > I will leave the technical review to Martin and Matthias. > > > > FYI I'm heading out on a weeks vacation after today so won't be able to > follow up further. > > Have a nice vacation! > > > Thanks, > > Yasumasa > > > > Thanks, > > David > > > >> This change has passed tests on submit repo (mach5-one-ysuenaga-JDK- > 8250598-20200814-0119-13424118), and also it works fine on following > environments: > >> > >> ?? - Hyper-V host (Windows 10 x64) > >> ?? - Hyper-V guest (Windows 10 x64) > >> ?? - Hyper-V guest (Linux x64) > >> ?? - Hyper-V guest (32bit JDK on Linux x64) > >> > >> > >> Thanks, > >> > >> Yasumasa > >> > >> > >> On 2020/08/13 20:39, David Holmes wrote: > >>> On 13/08/2020 5:39 pm, Yasumasa Suenaga wrote: > >>>> Hi Matthias, David, > >>>> > >>>> On 2020/08/13 15:52, Baesken, Matthias wrote: > >>>>> > >>>>>> > >>>>>> Should we make the change to determine just before it is needed > (e.g. VM.info or hs_err log) at first? > >>>>>> It is out of scope of this change, so I want to work as another issue if > it is needed. > >>>>>> > >>>>> > >>>>> Hi , > >>>>> I think we better do not call into WMI , when? writing an hs_err file?? . > >>>> > >>>> I found out from Hypervisor Top Level Functional Specification [1] > section 2.4.8. > >>>> That says CPUID leaf 0x40000007 is available to the root partition only. > >>>> > >>>> I changed VM_Version::is_in_VM() as below, and it works fine. > >>>> (I use __cpuid intrinsic in here because this code would be compiled by > cl.exe only.) > >>>> > >>>> ``` > >>>> #include > >>>> > >>>> #define EAX 0 > >>>> #define EBX 1 > >>>> #define ECX 2 > >>>> #define EDX 3 > >>>> > >>>> bool VM_Version::is_in_VM() { > >>>> ?? int regs[4]; > >>>> ?? __cpuid(regs, 0x40000007); > >>>> > >>>> ?? // CPUID leaf 0x40000007 is available to the root partition only. > >>>> ?? return (regs[EAX] == 0x0) && (regs[EBX] == 0x0) && (regs[ECX] == > 0x0) && (regs[EDX] == 0x0); > >>>> } > >>>> ``` > >>>> > >>>> Also startup performance is better than WMI call. > >>>> > >>>> TotalMilliseconds : 66.7863 > >>>> TotalMilliseconds : 56.8123 > >>>> TotalMilliseconds : 57.0015 > >>>> TotalMilliseconds : 62.4755 > >>>> TotalMilliseconds : 67.7632 > >>>> average : 62.16776 > >>>> > >>>> If you are ok this change, I will update webrev, and will send review > request. > >>>> (new webrev will include both loop for CPUID leaf and renaming > is_in_VM) > >>> > >>> If it works and addresses the startup hit then I'm fine with it - but still > can't actually review the code. > >>> > >>> Thanks, > >>> David > >>> > >>>> > >>>> Thanks, > >>>> > >>>> Yasumasa > >>>> > >>>> > >>>> [1] https://github.com/MicrosoftDocs/Virtualization- > Documentation/raw/master/tlfs/Hypervisor%20Top%20Level%20Functional > %20Specification%20v6.0b.pdf > >>>> > >>>> > >>>>> Best regards, Matthias > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Yasumasa Suenaga > >>>>> Sent: Donnerstag, 13. August 2020 06:15 > >>>>> To: David Holmes ; Baesken, Matthias > ; hotspot-runtime-dev at openjdk.java.net; > build-dev at openjdk.java.net > >>>>> Cc: Doerr, Martin > >>>>> Subject: Re: PING: RFR: 8250598: Hyper-V is detected in spite of > running on host OS > >>>>> > >>>>> On 2020/08/13 11:54, David Holmes wrote: > >>>>>> On 13/08/2020 11:12 am, Yasumasa Suenaga wrote: > >>>>>>> Hi Matthias, David, > >>>>>>> > >>>>>>> I measured startup benchmarks with `Measure-Command > {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -- > version}` on PowerShell. > >>>>>>> > >>>>>>> * PC: Ryzen 3 3300X, 16GB memory > >>>>>>> * OS: Windows 10 x64 (May 2020 Update) > >>>>>>> * Java: jdk/jdk revision 60537 > >>>>>>> ????? (Compiled by VS 2019 (16.7.0)) > >>>>>>> > >>>>>>> * without patch > >>>>>>> TotalMilliseconds : 70.2124 > >>>>>>> TotalMilliseconds : 64.4465 > >>>>>>> TotalMilliseconds : 59.0854 > >>>>>>> TotalMilliseconds : 68.0255 > >>>>>>> TotalMilliseconds : 72.6467 > >>>>>>> average : 66.8833 > >>>>>>> > >>>>>>> * with webrev.01 > >>>>>>> TotalMilliseconds : 81.7185 > >>>>>>> TotalMilliseconds : 68.539 > >>>>>>> TotalMilliseconds : 85.7226 > >>>>>>> TotalMilliseconds : 72.6584 > >>>>>>> TotalMilliseconds : 75.6091 > >>>>>>> average : 76.84952 > >>>>>>> > >>>>>>> Overhead of WMI seems to be +10ms in this case. > >>>>>> > >>>>>> Which is nearly 15%! Sorry but I just know Claes will be very unhappy > if this were to go in as-is. > >>>>> > >>>>> Should we make the change to determine just before it is needed > (e.g. VM.info or hs_err log) at first? > >>>>> It is out of scope of this change, so I want to work as another issue if it > is needed. > >>>>> > >>>>> > >>>>> Yasumasa > >>>>> > >>>>> > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>>> > >>>>>>> Yasumasa > >>>>>>> > >>>>>>> > >>>>>>> On 2020/08/13 0:05, Baesken, Matthias wrote: > >>>>>>>>> I understand that if the process runs on Xen on other hypervisor > (e.g. KVM), information for Xen would be set between 0x40000100 and > 0x40010000. > >>>>>>>>> Ok, I will not remove the loop in new webrev, and will add > comment about it. > >>>>>>>> > >>>>>>>> Hi Yasumasa? , thanks ! > >>>>>>>> > >>>>>>>> Regarding the WMI overhead , if you could? get some more info > on this it would be better to judge if it is perfectly okay or concerning . > >>>>>>>> > >>>>>>>> (I remember that I looked into it a couple of years ago , but > decided not to use it in early VM startup ;? but have to confess this was just > based on a "gut feeling", > >>>>>>>> ?? No micro benchmarks? ) > >>>>>>>> > >>>>>>>> Best regards, Matthias > >>>>>>>> > >>>>>>>> From ningsheng.jian at arm.com Wed Aug 19 09:53:45 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 19 Aug 2020 17:53:45 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Message-ID: Hi Andrew, I have updated the patch based on the review comments. Would you mind taking another look? Thanks! Full: http://cr.openjdk.java.net/~njian/8231441/webrev.04/ Incremental: http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ Also add build-dev, as there's a makefile change. And the split parts: 1) SVE feature detection: http://cr.openjdk.java.net/~njian/8231441/webrev.04-feature 2) c2 register allocation: http://cr.openjdk.java.net/~njian/8231441/webrev.04-ra 3) SVE c2 backend: http://cr.openjdk.java.net/~njian/8231441/webrev.04-c2 Bug: https://bugs.openjdk.java.net/browse/JDK-8231441 CSR: https://bugs.openjdk.java.net/browse/JDK-8248742 JTreg tests are still running, and so far no new failure found. Thanks, Ningsheng On 8/17/20 5:16 PM, Andrew Dinn wrote: > Hi Pengfei, > > On 17/08/2020 07:00, Ningsheng Jian wrote: >> Thanks a lot for the review! Sorry for the late reply, as I was on >> vacation last week. And thanks to Pengfei and Joshua for helping >> clarifying some details in the patch. > > Yes, they did a very good job of answering most of the pending questions. > >>> I also eyeballed /some/ of the generated code to check that it looked >>> ok. I'd really like to be able to do that systematically for a >>> comprehensive test suite that exercised every rule but I only had the >>> machine for a few days. This really ought to be done as a follow-up to >>> ensure that all the rules are working as expected. >> >> Yes, we would expect Pengfei's OptoAssembly check patch can get merged >> in future. > > I'm fine with that as a follow-up patch if you raise a JIRA for it. > >>> I am not clear why you are choosing to re-init ptrue after certain JVM >>> runtime calls (e.g. when Z calls into the runtime) and not others e.g. >>> when we call a JVM_ENTRY. Could you explain the rationale you have >>> followed here? >> >> We do the re-init at any possible return points to c2 code, not in any >> runtime c++ functions, which will reduce the re-init calls. >> >> Actually I found those entries by some hack of jvm. In the hacky code >> below we use gcc option -finstrument-functions to build hotspot. With >> this option, each C/C++ function entry/exit will call the instrument >> functions we defined. In instrument functions, we clobber p7 (or other >> reg for test) register, and in c2 function return we verify that p7 (or >> other reg) has been reinitialized. >> >> http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch > > Nice work. It's very good to have that documented. I'm willing to accept > i) that this has found all current cases and ii) that the verify will > catch any cases that might get introduced by future changes (e.g. the > callout introduced by ZGC that you mention below). As the above mot say > there is a slim chance this might have missed some cases but I think it > is pretty unlikely. > > >>> Specific Comments (register allocator webrev): >>> >>> >>> aarch64.ad:97-100 >>> >>> Why have you added a reg_def for R8 and R9 here and also to alloc_class >>> chunk0 at lines 544-545? They aren't used by C2 so why define them? >>> >> >> I think Pengfei has helped to explain that. I will either add clear >> comments or rename the register name as you suggested. > > Ok, good. > >> As Joshua clarified, we are also working on predicate scalable reg, >> which is not in this patch. Thanks for the suggestion, I will try to >> refactor this a bit. > > Ok, I'll wait for an updated patch. Are you planning to include the > scalable predicate reg code as part of this patch? I think that would be > better as it would help to clarify the need to distinguish vector regs > as a subset of scalable regs. > >>> zBarrierSetAssembler_aarch64.cpp:434 >>> >>> Can you explain why we need to check p7 here and not do so in other >>> places where we call into the JVM? I'm not saying this is wrong. I just >>> want to know how you decided where re-init of p7 was needed. >>> >> >> Actually I found this by my hack patch above while running jtreg tests. >> The stub slowpath here can be a c++ function. > > Yes, good catch. > >>> superword.cpp:97 >>> >>> Does this mean that is someone sets the maximum vector size to a >>> non-power of two, such as 384, all superword operations will be >>> bypassed? Including those which can be done using NEON vectors? >>> >> >> Current SLP vectorizer only supports power-of-2 vector size. We are >> trying to work out a new vectorizer to support all SVE vector sizes, so >> we would expect a size like 384 could go to that path. I tried current >> patch on a 512-bit SVE hardware which does not support 384-bit: >> >> $ java -XX:MaxVectorSize=16 -version # (32 and 64 are the same) >> openjdk version "16-internal" 2021-03-16 >> >> $ java -XX:MaxVectorSize=48 -version >> OpenJDK 64-Bit Server VM warning: Current system only supports max SVE >> vector length 32. Set MaxVectorSize to 32 >> >> (Fallbacks to 32 and issue a warning, as the prctl() call returns 32 >> instead of unsupported 48: >> https://www.kernel.org/doc/Documentation/arm64/sve.txt) >> >> Do you think we need to exit vm instead of warning and fallbacking to 32 >> here? > > Yes, I think a vm exit would probably be a better choice. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From magnus.ihse.bursie at oracle.com Wed Aug 19 10:05:01 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Aug 2020 12:05:01 +0200 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Message-ID: <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> On 2020-08-19 11:53, Ningsheng Jian wrote: > Hi Andrew, > > I have updated the patch based on the review comments. Would you mind > taking another look? Thanks! > > Full: > http://cr.openjdk.java.net/~njian/8231441/webrev.04/ Build changes look good. Thank you for remembering to cc build-dev! This is maybe not relevant, but I was surprised to find src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, and b) the name implies that it is a test, even though that it resides in src. Is this really proper? /Magnus > > Incremental: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ > > Also add build-dev, as there's a makefile change. > > And the split parts: > > 1) SVE feature detection: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-feature > > 2) c2 register allocation: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-ra > > 3) SVE c2 backend: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-c2 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231441 > CSR: https://bugs.openjdk.java.net/browse/JDK-8248742 > > JTreg tests are still running, and so far no new failure found. > > Thanks, > Ningsheng > > On 8/17/20 5:16 PM, Andrew Dinn wrote: >> Hi Pengfei, >> >> On 17/08/2020 07:00, Ningsheng Jian wrote: >>> Thanks a lot for the review! Sorry for the late reply, as I was on >>> vacation last week. And thanks to Pengfei and Joshua for helping >>> clarifying some details in the patch. >> >> Yes, they did a very good job of answering most of the pending >> questions. >> >>>> I also eyeballed /some/ of the generated code to check that it looked >>>> ok. I'd really like to be able to do that systematically for a >>>> comprehensive test suite that exercised every rule but I only had the >>>> machine for a few days. This really ought to be done as a follow-up to >>>> ensure that all the rules are working as expected. >>> >>> Yes, we would expect Pengfei's OptoAssembly check patch can get merged >>> in future. >> >> I'm fine with that as a follow-up patch if you raise a JIRA for it. >> >>>> I am not clear why you are choosing to re-init ptrue after certain JVM >>>> runtime calls (e.g. when Z calls into the runtime) and not others e.g. >>>> when we call a JVM_ENTRY. Could you explain the rationale you have >>>> followed here? >>> >>> We do the re-init at any possible return points to c2 code, not in any >>> runtime c++ functions, which will reduce the re-init calls. >>> >>> Actually I found those entries by some hack of jvm. In the hacky code >>> below we use gcc option -finstrument-functions to build hotspot. With >>> this option, each C/C++ function entry/exit will call the instrument >>> functions we defined. In instrument functions, we clobber p7 (or other >>> reg for test) register, and in c2 function return we verify that p7 (or >>> other reg) has been reinitialized. >>> >>> http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch >>> >> >> Nice work. It's very good to have that documented. I'm willing to accept >> i) that this has found all current cases and ii) that the verify will >> catch any cases that might get introduced by future changes (e.g. the >> callout introduced by ZGC that you mention below). As the above mot say >> there is a slim chance this might have missed some cases but I think it >> is pretty unlikely. >> >> >>>> Specific Comments (register allocator webrev): >>>> >>>> >>>> aarch64.ad:97-100 >>>> >>>> Why have you added a reg_def for R8 and R9 here and also to >>>> alloc_class >>>> chunk0 at lines 544-545? They aren't used by C2 so why define them? >>>> >>> >>> I think Pengfei has helped to explain that. I will either add clear >>> comments or rename the register name as you suggested. >> >> Ok, good. >> >>> As Joshua clarified, we are also working on predicate scalable reg, >>> which is not in this patch. Thanks for the suggestion, I will try to >>> refactor this a bit. >> >> Ok, I'll wait for an updated patch. Are you planning to include the >> scalable predicate reg code as part of this patch? I think that would be >> better as it would help to clarify the need to distinguish vector regs >> as a subset of scalable regs. >> >>>> zBarrierSetAssembler_aarch64.cpp:434 >>>> >>>> Can you explain why we need to check p7 here and not do so in other >>>> places where we call into the JVM? I'm not saying this is wrong. I >>>> just >>>> want to know how you decided where re-init of p7 was needed. >>>> >>> >>> Actually I found this by my hack patch above while running jtreg tests. >>> The stub slowpath here can be a c++ function. >> >> Yes, good catch. >> >>>> superword.cpp:97 >>>> >>>> Does this mean that is someone sets the maximum vector size to a >>>> non-power of two, such as 384, all superword operations will be >>>> bypassed? Including those which can be done using NEON vectors? >>>> >>> >>> Current SLP vectorizer only supports power-of-2 vector size. We are >>> trying to work out a new vectorizer to support all SVE vector sizes, so >>> we would expect a size like 384 could go to that path. I tried current >>> patch on a 512-bit SVE hardware which does not support 384-bit: >>> >>> $ java -XX:MaxVectorSize=16 -version # (32 and 64 are the same) >>> openjdk version "16-internal" 2021-03-16 >>> >>> $ java -XX:MaxVectorSize=48 -version >>> OpenJDK 64-Bit Server VM warning: Current system only supports max SVE >>> vector length 32. Set MaxVectorSize to 32 >>> >>> (Fallbacks to 32 and issue a warning, as the prctl() call returns 32 >>> instead of unsupported 48: >>> https://www.kernel.org/doc/Documentation/arm64/sve.txt) >>> >>> Do you think we need to exit vm instead of warning and fallbacking >>> to 32 >>> here? >> >> Yes, I think a vm exit would probably be a better choice. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Red Hat Distinguished Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill >> > From ningsheng.jian at arm.com Wed Aug 19 10:40:49 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 19 Aug 2020 18:40:49 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> Message-ID: <4ec335ca-0a88-3b98-f6e4-fe7a0453ae7b@arm.com> Hi Magnus, Thanks for the review! On 8/19/20 6:05 PM, Magnus Ihse Bursie wrote: > On 2020-08-19 11:53, Ningsheng Jian wrote: >> Hi Andrew, >> >> I have updated the patch based on the review comments. Would you mind >> taking another look? Thanks! >> >> Full: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04/ > Build changes look good. Thank you for remembering to cc build-dev! > > This is maybe not relevant, but I was surprised to find > src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, > and b) the name implies that it is a test, even though that it resides > in src. Is this really proper? This handy script is used to (manually) generate some code in assembler_aarch64.cpp. The generated code is for assembler smoke test, so it named that. It's helpful to make sure the assembler emits correct binary code, but I am not sure whether a python code in the project is proper or not. Thanks, Ningsheng > > /Magnus >> >> Incremental: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ >> >> Also add build-dev, as there's a makefile change. >> >> And the split parts: >> >> 1) SVE feature detection: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04-feature >> >> 2) c2 register allocation: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04-ra >> >> 3) SVE c2 backend: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04-c2 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231441 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8248742 >> >> JTreg tests are still running, and so far no new failure found. >> >> Thanks, >> Ningsheng >> >> On 8/17/20 5:16 PM, Andrew Dinn wrote: >>> Hi Pengfei, >>> >>> On 17/08/2020 07:00, Ningsheng Jian wrote: >>>> Thanks a lot for the review! Sorry for the late reply, as I was on >>>> vacation last week. And thanks to Pengfei and Joshua for helping >>>> clarifying some details in the patch. >>> >>> Yes, they did a very good job of answering most of the pending >>> questions. >>> >>>>> I also eyeballed /some/ of the generated code to check that it looked >>>>> ok. I'd really like to be able to do that systematically for a >>>>> comprehensive test suite that exercised every rule but I only had the >>>>> machine for a few days. This really ought to be done as a follow-up to >>>>> ensure that all the rules are working as expected. >>>> >>>> Yes, we would expect Pengfei's OptoAssembly check patch can get merged >>>> in future. >>> >>> I'm fine with that as a follow-up patch if you raise a JIRA for it. >>> >>>>> I am not clear why you are choosing to re-init ptrue after certain JVM >>>>> runtime calls (e.g. when Z calls into the runtime) and not others e.g. >>>>> when we call a JVM_ENTRY. Could you explain the rationale you have >>>>> followed here? >>>> >>>> We do the re-init at any possible return points to c2 code, not in any >>>> runtime c++ functions, which will reduce the re-init calls. >>>> >>>> Actually I found those entries by some hack of jvm. In the hacky code >>>> below we use gcc option -finstrument-functions to build hotspot. With >>>> this option, each C/C++ function entry/exit will call the instrument >>>> functions we defined. In instrument functions, we clobber p7 (or other >>>> reg for test) register, and in c2 function return we verify that p7 (or >>>> other reg) has been reinitialized. >>>> >>>> http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch >>>> >>> >>> Nice work. It's very good to have that documented. I'm willing to accept >>> i) that this has found all current cases and ii) that the verify will >>> catch any cases that might get introduced by future changes (e.g. the >>> callout introduced by ZGC that you mention below). As the above mot say >>> there is a slim chance this might have missed some cases but I think it >>> is pretty unlikely. >>> >>> >>>>> Specific Comments (register allocator webrev): >>>>> >>>>> >>>>> aarch64.ad:97-100 >>>>> >>>>> Why have you added a reg_def for R8 and R9 here and also to >>>>> alloc_class >>>>> chunk0 at lines 544-545? They aren't used by C2 so why define them? >>>>> >>>> >>>> I think Pengfei has helped to explain that. I will either add clear >>>> comments or rename the register name as you suggested. >>> >>> Ok, good. >>> >>>> As Joshua clarified, we are also working on predicate scalable reg, >>>> which is not in this patch. Thanks for the suggestion, I will try to >>>> refactor this a bit. >>> >>> Ok, I'll wait for an updated patch. Are you planning to include the >>> scalable predicate reg code as part of this patch? I think that would be >>> better as it would help to clarify the need to distinguish vector regs >>> as a subset of scalable regs. >>> >>>>> zBarrierSetAssembler_aarch64.cpp:434 >>>>> >>>>> Can you explain why we need to check p7 here and not do so in other >>>>> places where we call into the JVM? I'm not saying this is wrong. I >>>>> just >>>>> want to know how you decided where re-init of p7 was needed. >>>>> >>>> >>>> Actually I found this by my hack patch above while running jtreg tests. >>>> The stub slowpath here can be a c++ function. >>> >>> Yes, good catch. >>> >>>>> superword.cpp:97 >>>>> >>>>> Does this mean that is someone sets the maximum vector size to a >>>>> non-power of two, such as 384, all superword operations will be >>>>> bypassed? Including those which can be done using NEON vectors? >>>>> >>>> >>>> Current SLP vectorizer only supports power-of-2 vector size. We are >>>> trying to work out a new vectorizer to support all SVE vector sizes, so >>>> we would expect a size like 384 could go to that path. I tried current >>>> patch on a 512-bit SVE hardware which does not support 384-bit: >>>> >>>> $ java -XX:MaxVectorSize=16 -version # (32 and 64 are the same) >>>> openjdk version "16-internal" 2021-03-16 >>>> >>>> $ java -XX:MaxVectorSize=48 -version >>>> OpenJDK 64-Bit Server VM warning: Current system only supports max SVE >>>> vector length 32. Set MaxVectorSize to 32 >>>> >>>> (Fallbacks to 32 and issue a warning, as the prctl() call returns 32 >>>> instead of unsupported 48: >>>> https://www.kernel.org/doc/Documentation/arm64/sve.txt) >>>> >>>> Do you think we need to exit vm instead of warning and fallbacking >>>> to 32 >>>> here? >>> >>> Yes, I think a vm exit would probably be a better choice. >>> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> Red Hat Distinguished Engineer >>> Red Hat UK Ltd >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill >>> >> > From aph at redhat.com Wed Aug 19 11:10:10 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Aug 2020 12:10:10 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> Message-ID: On 19/08/2020 11:05, Magnus Ihse Bursie wrote: > This is maybe not relevant, but I was surprised to find > src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, > and b) the name implies that it is a test, even though that it resides > in src. Is this really proper? I have no idea whether it's really proper, but it allows us to check that instructions are encoded correctly by cross-checking with the system's assembler. There might well be a more hygienic way to do that, but I don't want to be without it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Wed Aug 19 13:01:44 2020 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 19 Aug 2020 14:01:44 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Message-ID: <47a0b915-291d-7bee-c298-a85d57b1c3a7@redhat.com> Hi Ningsheng, On 19/08/2020 10:53, Ningsheng Jian wrote: > I have updated the patch based on the review comments. Would you mind > taking another look? Thanks! > > Full: > http://cr.openjdk.java.net/~njian/8231441/webrev.04/ > > Incremental: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ That looks ok. A few suggested tweaks: aarch64.ad:168 I think the following comment explains more clearly what is going on: // For SVE vector registers, we simply extend vector register size to 8 // 'logical' slots. This is nominally 256 bits but it actually covers // all possible 'physical' SVE vector register lengths from 128 ~ 2048 bits. // The 'physical' SVE vector register length is detected during startup // so the register allocator is able to identify the correct number of // bytes needed for an SVE spill/unspill. // Note that a vector register with 4 slots, denotes a 128-bit NEON // register allowing it to be distinguished from the // corresponding SVE vector register when the SVE vector length // is 128 bits. postaloc.cpp:312 & 322 311 if (lrgs(val_idx).is_scalable()) { 312 assert(val->ideal_reg() == Op_VecA, "scalable vector register"); . . . 321 if (lrgs(val_idx).is_scalable()) { 322 assert(val->ideal_reg() == Op_VecA, "scalable vector register"); You don't strictly need the asserts here as this is already asserted in the call to is_scalable(). > JTreg tests are still running, and so far no new failure found. Ok, well assuming they pass I am happy with this latest patch modulo the tweaks above. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From ningsheng.jian at arm.com Thu Aug 20 02:27:08 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Thu, 20 Aug 2020 10:27:08 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <47a0b915-291d-7bee-c298-a85d57b1c3a7@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <47a0b915-291d-7bee-c298-a85d57b1c3a7@redhat.com> Message-ID: <01299e5a-8786-bd78-83f4-5e7f900f96da@arm.com> Hi Andrew, On 8/19/20 9:01 PM, Andrew Dinn wrote: > Hi Ningsheng, > > On 19/08/2020 10:53, Ningsheng Jian wrote: >> I have updated the patch based on the review comments. Would you mind >> taking another look? Thanks! >> >> Full: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04/ >> >> Incremental: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ > > That looks ok. A few suggested tweaks: > Thanks! > aarch64.ad:168 > > I think the following comment explains more clearly what is going on: > > // For SVE vector registers, we simply extend vector register size to 8 > // 'logical' slots. This is nominally 256 bits but it actually covers > // all possible 'physical' SVE vector register lengths from 128 ~ 2048 bits. > // The 'physical' SVE vector register length is detected during startup > // so the register allocator is able to identify the correct number of > // bytes needed for an SVE spill/unspill. > // Note that a vector register with 4 slots, denotes a 128-bit NEON > // register allowing it to be distinguished from the > // corresponding SVE vector register when the SVE vector length > // is 128 bits. > This looks better than mine. Thanks! :-) > postaloc.cpp:312 & 322 > > 311 if (lrgs(val_idx).is_scalable()) { > 312 assert(val->ideal_reg() == Op_VecA, "scalable vector register"); > > . . . > > 321 if (lrgs(val_idx).is_scalable()) { > 322 assert(val->ideal_reg() == Op_VecA, "scalable vector register"); > > You don't strictly need the asserts here as this is already asserted in > the call to is_scalable(). > The assertion in LRG::is_scalable() is different, while this is an assertion for ideal_reg of a given node. > >> JTreg tests are still running, and so far no new failure found. > Ok, well assuming they pass I am happy with this latest patch modulo the > tweaks above. > Will report back once the tests on real hardware passed. Thanks, Ningsheng From nick.gasson at arm.com Thu Aug 20 04:48:30 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 20 Aug 2020 12:48:30 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> Message-ID: <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> On 08/19/20 19:10 pm, Andrew Haley wrote: > On 19/08/2020 11:05, Magnus Ihse Bursie wrote: >> This is maybe not relevant, but I was surprised to find >> src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, >> and b) the name implies that it is a test, even though that it resides >> in src. Is this really proper? > > I have no idea whether it's really proper, but it allows us to check > that instructions are encoded correctly by cross-checking with the > system's assembler. There might well be a more hygienic way to do > that, but I don't want to be without it. It is perhaps a bit strange to have the test code under src/ and embedded in the assembler implementation. How about we move it under test/ using the existing gtest framework for native code tests? That runs in tier1 and also for release builds. I tried this just now and it's easy to do. -- Thanks, Nick From adinn at redhat.com Thu Aug 20 08:34:45 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 20 Aug 2020 09:34:45 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <01299e5a-8786-bd78-83f4-5e7f900f96da@arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <47a0b915-291d-7bee-c298-a85d57b1c3a7@redhat.com> <01299e5a-8786-bd78-83f4-5e7f900f96da@arm.com> Message-ID: Hi Ningsheng, >> postaloc.cpp:312 & 322 >> >> 311???? if (lrgs(val_idx).is_scalable()) { >> 312?????? assert(val->ideal_reg() == Op_VecA, "scalable vector >> register"); >> >> ???????? . . . >> >> 321?????? if (lrgs(val_idx).is_scalable()) { >> 322???????? assert(val->ideal_reg() == Op_VecA, "scalable vector >> register"); >> >> You don't strictly need the asserts here as this is already asserted in >> the call to is_scalable(). > > The assertion in LRG::is_scalable() is different, while this is an > assertion for ideal_reg of a given node. Yes, my apologies for misreading that. These assertions should be retained. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Thu Aug 20 08:50:32 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Aug 2020 09:50:32 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <01299e5a-8786-bd78-83f4-5e7f900f96da@arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <47a0b915-291d-7bee-c298-a85d57b1c3a7@redhat.com> <01299e5a-8786-bd78-83f4-5e7f900f96da@arm.com> Message-ID: <7a12ad31-9196-c724-16c9-9994b096974c@redhat.com> On 20/08/2020 03:27, Ningsheng Jian wrote: > // Note that a vector register with 4 slots, denotes a 128-bit NEON Lose the comma. :-) Never known to miss a trivial point, -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Thu Aug 20 08:48:07 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 20 Aug 2020 09:48:07 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> On 20/08/2020 05:48, Nick Gasson wrote: > On 08/19/20 19:10 pm, Andrew Haley wrote: >> On 19/08/2020 11:05, Magnus Ihse Bursie wrote: >>> This is maybe not relevant, but I was surprised to find >>> src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, >>> and b) the name implies that it is a test, even though that it resides >>> in src. Is this really proper? >> >> I have no idea whether it's really proper, but it allows us to check >> that instructions are encoded correctly by cross-checking with the >> system's assembler. There might well be a more hygienic way to do >> that, but I don't want to be without it. > > It is perhaps a bit strange to have the test code under src/ and > embedded in the assembler implementation. How about we move it under > test/ using the existing gtest framework for native code tests? That > runs in tier1 and also for release builds. I tried this just now and > it's easy to do. I'm not sure that would be an improvement. This python code is used to generate C code run as part of JVM startup in a debug JVM build i.e. code that is linked into the JVM itself. So, the code it generates is really the same as the debug code embedded in the JVM. It doesn't really bear any relation to the code in the test tree. If the generator code were to go anywhere else it would perhaps make most sense to put it in the make tree. I'm not sure that is required though or even appropriate. There is already a precedent for keeping generator code in the source tree and, when it is specific to a given arch, keeping it next to the related source. The adlc generator code sits in the shared source tree. The m4 file used to generate parts of aarch64.ad is in the aarch64 source tree. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Thu Aug 20 08:53:52 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Aug 2020 09:53:52 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <6fea2144-b416-cad3-8c99-068a82490256@redhat.com> On 20/08/2020 05:48, Nick Gasson wrote: > On 08/19/20 19:10 pm, Andrew Haley wrote: >> On 19/08/2020 11:05, Magnus Ihse Bursie wrote: >>> This is maybe not relevant, but I was surprised to find >>> src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, >>> and b) the name implies that it is a test, even though that it resides >>> in src. Is this really proper? >> >> I have no idea whether it's really proper, but it allows us to check >> that instructions are encoded correctly by cross-checking with the >> system's assembler. There might well be a more hygienic way to do >> that, but I don't want to be without it. > > It is perhaps a bit strange to have the test code under src/ and > embedded in the assembler implementation. How about we move it under > test/ using the existing gtest framework for native code tests? That > runs in tier1 and also for release builds. I tried this just now and > it's easy to do. Go on, then! Bear in mind that the idea of this test is that it checks the encoding of all instructions, regardless of whether the processor supports them or not. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Thu Aug 20 08:58:57 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 20 Aug 2020 16:58:57 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> Message-ID: <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> Hi Andrew, On 08/20/20 16:48 pm, Andrew Dinn wrote: >> >> It is perhaps a bit strange to have the test code under src/ and >> embedded in the assembler implementation. How about we move it under >> test/ using the existing gtest framework for native code tests? That >> runs in tier1 and also for release builds. I tried this just now and >> it's easy to do. > I'm not sure that would be an improvement. This python code is used to > generate C code run as part of JVM startup in a debug JVM build i.e. > code that is linked into the JVM itself. So, the code it generates is > really the same as the debug code embedded in the JVM. It doesn't really > bear any relation to the code in the test tree. > I meant move the test itself - entry() and asm_check() in assembler_aarch64.cpp - under test/hotspot/gtest. The generator would move with it. > If the generator code were to go anywhere else it would perhaps make > most sense to put it in the make tree. I'm not sure that is required > though or even appropriate. There is already a precedent for keeping > generator code in the source tree and, when it is specific to a given > arch, keeping it next to the related source. The adlc generator code > sits in the shared source tree. The m4 file used to generate parts of > aarch64.ad is in the aarch64 source tree. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Thu Aug 20 09:08:18 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Aug 2020 10:08:18 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: Hi, On 20/08/2020 09:58, Nick Gasson wrote: > > On 08/20/20 16:48 pm, Andrew Dinn wrote: >>> >>> It is perhaps a bit strange to have the test code under src/ and >>> embedded in the assembler implementation. How about we move it under >>> test/ using the existing gtest framework for native code tests? That >>> runs in tier1 and also for release builds. I tried this just now and >>> it's easy to do. >> I'm not sure that would be an improvement. This python code is used to >> generate C code run as part of JVM startup in a debug JVM build i.e. >> code that is linked into the JVM itself. So, the code it generates is >> really the same as the debug code embedded in the JVM. It doesn't really >> bear any relation to the code in the test tree. > > I meant move the test itself - entry() and asm_check() in > assembler_aarch64.cpp - under test/hotspot/gtest. The generator would > move with it. Hmm. I'm still not sure how this would work. Let's see the patch and we can talk about it. It still sounds to me rather like pointlessly moving the furniture around. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Thu Aug 20 09:40:34 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 20 Aug 2020 17:40:34 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <85364hy7sd.fsf@nicgas01-pc.shanghai.arm.com> On 08/20/20 17:08 pm, Andrew Haley wrote: >> >> I meant move the test itself - entry() and asm_check() in >> assembler_aarch64.cpp - under test/hotspot/gtest. The generator would >> move with it. > > Hmm. I'm still not sure how this would work. Let's see the patch and > we can talk about it. It still sounds to me rather like pointlessly > moving the furniture around. http://cr.openjdk.java.net/~ngasson/asmtest/webrev.0/ Then you'd run it with make exploded-test TEST="gtest:AssemblerAArch64" The downside is that it won't run on every startup of a debug build, but it will run in the tier1 tests, including for release builds, which arguably gives more coverage. It looks a lot tidier to me, but that's clearly subjective. -- Thanks, Nick From magnus.ihse.bursie at oracle.com Thu Aug 20 10:14:36 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Aug 2020 12:14:36 +0200 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <85364hy7sd.fsf@nicgas01-pc.shanghai.arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> <85364hy7sd.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <39664366-1ba9-6eb1-dcee-c8a4f07877b7@oracle.com> On 2020-08-20 11:40, Nick Gasson wrote: > On 08/20/20 17:08 pm, Andrew Haley wrote: >>> I meant move the test itself - entry() and asm_check() in >>> assembler_aarch64.cpp - under test/hotspot/gtest. The generator would >>> move with it. >> Hmm. I'm still not sure how this would work. Let's see the patch and >> we can talk about it. It still sounds to me rather like pointlessly >> moving the furniture around. > http://cr.openjdk.java.net/~ngasson/asmtest/webrev.0/ > > Then you'd run it with > > make exploded-test TEST="gtest:AssemblerAArch64" > > The downside is that it won't run on every startup of a debug build, but > it will run in the tier1 tests, including for release builds, which > arguably gives more coverage. It looks a lot tidier to me, but that's > clearly subjective. FWIW, it definitely looks tidier to me too. /Magnus > > -- > Thanks, > Nick From adinn at redhat.com Thu Aug 20 10:38:32 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 20 Aug 2020 11:38:32 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <39664366-1ba9-6eb1-dcee-c8a4f07877b7@oracle.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> <85364hy7sd.fsf@nicgas01-pc.shanghai.arm.com> <39664366-1ba9-6eb1-dcee-c8a4f07877b7@oracle.com> Message-ID: <4ea979d6-c81f-fa3b-7c23-e563f52141dd@redhat.com> On 20/08/2020 11:14, Magnus Ihse Bursie wrote: > On 2020-08-20 11:40, Nick Gasson wrote: >> http://cr.openjdk.java.net/~ngasson/asmtest/webrev.0/ >> >> Then you'd run it with >> >> ?? make exploded-test TEST="gtest:AssemblerAArch64" >> >> The downside is that it won't run on every startup of a debug build, but >> it will run in the tier1 tests, including for release builds, which >> arguably gives more coverage. It looks a lot tidier to me, but that's >> clearly subjective. > FWIW, it definitely looks tidier to me too. Well, perhaps this check ought to be done as a standalone test rather than as debug build validation. I don't really have any deep commitment either way. However, if we do proceed with this I think it ought to be in a separate follow-up patch and with its own JIRA. It should not stop Ningsheng's SVE patch going in as is since that merely corrects the status quo to allow for SVE instructions. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Thu Aug 20 14:19:18 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Aug 2020 15:19:18 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <4ea979d6-c81f-fa3b-7c23-e563f52141dd@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> <85364hy7sd.fsf@nicgas01-pc.shanghai.arm.com> <39664366-1ba9-6eb1-dcee-c8a4f07877b7@oracle.com> <4ea979d6-c81f-fa3b-7c23-e563f52141dd@redhat.com> Message-ID: <57d07f23-c0f1-31eb-586a-71fa59b80891@redhat.com> On 20/08/2020 11:38, Andrew Dinn wrote: > Well, perhaps this check ought to be done as a standalone test rather > than as debug build validation. I don't really have any deep commitment > either way. However, if we do proceed with this I think it ought to be > in a separate follow-up patch and with its own JIRA. It should not stop > Ningsheng's SVE patch going in as is since that merely corrects the > status quo to allow for SVE instructions. I agree. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From magnus.ihse.bursie at oracle.com Thu Aug 20 14:37:42 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Aug 2020 16:37:42 +0200 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <4ea979d6-c81f-fa3b-7c23-e563f52141dd@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> <85364hy7sd.fsf@nicgas01-pc.shanghai.arm.com> <39664366-1ba9-6eb1-dcee-c8a4f07877b7@oracle.com> <4ea979d6-c81f-fa3b-7c23-e563f52141dd@redhat.com> Message-ID: On 2020-08-20 12:38, Andrew Dinn wrote: > On 20/08/2020 11:14, Magnus Ihse Bursie wrote: >> On 2020-08-20 11:40, Nick Gasson wrote: >>> http://cr.openjdk.java.net/~ngasson/asmtest/webrev.0/ >>> >>> Then you'd run it with >>> >>> ?? make exploded-test TEST="gtest:AssemblerAArch64" >>> >>> The downside is that it won't run on every startup of a debug build, but >>> it will run in the tier1 tests, including for release builds, which >>> arguably gives more coverage. It looks a lot tidier to me, but that's >>> clearly subjective. >> FWIW, it definitely looks tidier to me too. > Well, perhaps this check ought to be done as a standalone test rather > than as debug build validation. I don't really have any deep commitment > either way. However, if we do proceed with this I think it ought to be > in a separate follow-up patch and with its own JIRA. It should not stop > Ningsheng's SVE patch going in as is since that merely corrects the > status quo to allow for SVE instructions. Yes, I fully agree, and never meant to imply anything else. /Magnus > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From Sergey.Bylokhov at oracle.com Fri Aug 21 04:55:46 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 20 Aug 2020 21:55:46 -0700 Subject: RFR: 8251854 [macosx] Java forces the use of discrete GPU Message-ID: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8251854 Fix: http://cr.openjdk.java.net/~serb/8251854/webrev.00 This is a review request for the bug particularly fixed some time ago: https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html In that review request it was found that the old fix does not work well in all cases, see: https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html The current fix updates an embedded plist.info, so the java will not require discrete graphics by default, same as for any other applications. Note that the new "metal" pipeline also does not required the discrete graphics. The documentation for NSSupportsAutomaticGraphicsSwitching: https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching -- Best regards, Sergey. From magnus.ihse.bursie at oracle.com Fri Aug 21 10:02:13 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 21 Aug 2020 12:02:13 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU In-Reply-To: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> Message-ID: On 2020-08-21 06:55, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk/client. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251854 > Fix: http://cr.openjdk.java.net/~serb/8251854/webrev.00 The fix looks good from a build perspective. (But it highlights the fact that we have no consistent placement of those plist files; we should probably address that in a separate fix.) /Magnus > > This is a review request for the bug particularly fixed some time ago: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html > > In that review request it was found that the old fix does not work > well in all cases, see: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html > > The current fix updates an embedded plist.info, so the java will not > require > discrete graphics by default, same as for any other applications. > > Note that the new "metal" pipeline also does not required the discrete > graphics. > > The documentation for NSSupportsAutomaticGraphicsSwitching: > https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching > > From erik.osterlund at oracle.com Fri Aug 21 16:21:53 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 21 Aug 2020 18:21:53 +0200 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Message-ID: Hi, Have you tried this with ZGC on AArch64? It has custom code for saving live registers in the load barrier slow path. I can't see any code changes there, so assuming this will just crash instead. The relevant code is in ZBarrierSetAssembler on aarch64. Maybe I missed something? Thanks, /Erik On 2020-08-19 11:53, Ningsheng Jian wrote: > Hi Andrew, > > I have updated the patch based on the review comments. Would you mind > taking another look? Thanks! > > Full: > http://cr.openjdk.java.net/~njian/8231441/webrev.04/ > > Incremental: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ > > Also add build-dev, as there's a makefile change. > > And the split parts: > > 1) SVE feature detection: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-feature > > 2) c2 register allocation: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-ra > > 3) SVE c2 backend: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-c2 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231441 > CSR: https://bugs.openjdk.java.net/browse/JDK-8248742 > > JTreg tests are still running, and so far no new failure found. > > Thanks, > Ningsheng > > On 8/17/20 5:16 PM, Andrew Dinn wrote: >> Hi Pengfei, >> >> On 17/08/2020 07:00, Ningsheng Jian wrote: >>> Thanks a lot for the review! Sorry for the late reply, as I was on >>> vacation last week. And thanks to Pengfei and Joshua for helping >>> clarifying some details in the patch. >> >> Yes, they did a very good job of answering most of the pending >> questions. >> >>>> I also eyeballed /some/ of the generated code to check that it looked >>>> ok. I'd really like to be able to do that systematically for a >>>> comprehensive test suite that exercised every rule but I only had the >>>> machine for a few days. This really ought to be done as a follow-up to >>>> ensure that all the rules are working as expected. >>> >>> Yes, we would expect Pengfei's OptoAssembly check patch can get merged >>> in future. >> >> I'm fine with that as a follow-up patch if you raise a JIRA for it. >> >>>> I am not clear why you are choosing to re-init ptrue after certain JVM >>>> runtime calls (e.g. when Z calls into the runtime) and not others e.g. >>>> when we call a JVM_ENTRY. Could you explain the rationale you have >>>> followed here? >>> >>> We do the re-init at any possible return points to c2 code, not in any >>> runtime c++ functions, which will reduce the re-init calls. >>> >>> Actually I found those entries by some hack of jvm. In the hacky code >>> below we use gcc option -finstrument-functions to build hotspot. With >>> this option, each C/C++ function entry/exit will call the instrument >>> functions we defined. In instrument functions, we clobber p7 (or other >>> reg for test) register, and in c2 function return we verify that p7 (or >>> other reg) has been reinitialized. >>> >>> http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch >>> >> >> Nice work. It's very good to have that documented. I'm willing to accept >> i) that this has found all current cases and ii) that the verify will >> catch any cases that might get introduced by future changes (e.g. the >> callout introduced by ZGC that you mention below). As the above mot say >> there is a slim chance this might have missed some cases but I think it >> is pretty unlikely. >> >> >>>> Specific Comments (register allocator webrev): >>>> >>>> >>>> aarch64.ad:97-100 >>>> >>>> Why have you added a reg_def for R8 and R9 here and also to >>>> alloc_class >>>> chunk0 at lines 544-545? They aren't used by C2 so why define them? >>>> >>> >>> I think Pengfei has helped to explain that. I will either add clear >>> comments or rename the register name as you suggested. >> >> Ok, good. >> >>> As Joshua clarified, we are also working on predicate scalable reg, >>> which is not in this patch. Thanks for the suggestion, I will try to >>> refactor this a bit. >> >> Ok, I'll wait for an updated patch. Are you planning to include the >> scalable predicate reg code as part of this patch? I think that would be >> better as it would help to clarify the need to distinguish vector regs >> as a subset of scalable regs. >> >>>> zBarrierSetAssembler_aarch64.cpp:434 >>>> >>>> Can you explain why we need to check p7 here and not do so in other >>>> places where we call into the JVM? I'm not saying this is wrong. I >>>> just >>>> want to know how you decided where re-init of p7 was needed. >>>> >>> >>> Actually I found this by my hack patch above while running jtreg tests. >>> The stub slowpath here can be a c++ function. >> >> Yes, good catch. >> >>>> superword.cpp:97 >>>> >>>> Does this mean that is someone sets the maximum vector size to a >>>> non-power of two, such as 384, all superword operations will be >>>> bypassed? Including those which can be done using NEON vectors? >>>> >>> >>> Current SLP vectorizer only supports power-of-2 vector size. We are >>> trying to work out a new vectorizer to support all SVE vector sizes, so >>> we would expect a size like 384 could go to that path. I tried current >>> patch on a 512-bit SVE hardware which does not support 384-bit: >>> >>> $ java -XX:MaxVectorSize=16 -version # (32 and 64 are the same) >>> openjdk version "16-internal" 2021-03-16 >>> >>> $ java -XX:MaxVectorSize=48 -version >>> OpenJDK 64-Bit Server VM warning: Current system only supports max SVE >>> vector length 32. Set MaxVectorSize to 32 >>> >>> (Fallbacks to 32 and issue a warning, as the prctl() call returns 32 >>> instead of unsupported 48: >>> https://www.kernel.org/doc/Documentation/arm64/sve.txt) >>> >>> Do you think we need to exit vm instead of warning and fallbacking >>> to 32 >>> here? >> >> Yes, I think a vm exit would probably be a better choice. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Red Hat Distinguished Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill >> > From ningsheng.jian at arm.com Mon Aug 24 09:59:20 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Mon, 24 Aug 2020 17:59:20 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Message-ID: <5397e0d1-9d40-0107-c164-304740bc5d7f@arm.com> Hi Erik, Thanks for the review! On 8/22/20 12:21 AM, Erik ?sterlund wrote: > Hi, > > Have you tried this with ZGC on AArch64? It has custom code for saving > live registers in the load barrier slow path. > I can't see any code changes there, so assuming this will just crash > instead. > The relevant code is in ZBarrierSetAssembler on aarch64. > > Maybe I missed something? > I didn't add ZGC option while running tests. I think I need to update push_fp() which is called by ZSaveLiveRegisters. But do we need to get size info (float/neon/sve) instead of saving the whole vector register? Currently, it just simply saves the whole NEON register. And in ZBarrierSetAssembler::load_at(), before calling to runtime code, we call push_call_clobbered_registers_except(), which just saves floating point registers instead of the whole NEON vector registers. Similar behavior in x86 implementation. Is that correct (not saving vectors)? Thanks, Ningsheng From erik.joelsson at oracle.com Mon Aug 24 15:19:19 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 24 Aug 2020 08:19:19 -0700 Subject: RFR: JDK-8252145: Unify Info.plist files with correct version strings Message-ID: When fixing JDK-8246094, I concluded that our Info.plist files are in a bit of a mess. This patch tries to address this on a more fundamental level. 1. All Info.plist files and templates are moved to the same location in the source tree. 2. The CFBundleIdentifier is changed to no longer contain the version number. Instead it gets the $VERSION_PRE string if present. 3. The CFBundleShortVersionString is changed to the numeric version part of our version string. 4. The CFBundleVersion is changed to the build number (or a custom number if supplied through a new configure argument). For Oracle builds, this will take the form of .. For more details on why this particular scheme, see bug description, but in short, this is what I think best reflects what the Apple documentation says the fields are for. Bug: https://bugs.openjdk.java.net/browse/JDK-8252145 Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01 /Erik From erik.osterlund at oracle.com Mon Aug 24 15:26:30 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 24 Aug 2020 17:26:30 +0200 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <5397e0d1-9d40-0107-c164-304740bc5d7f@arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <5397e0d1-9d40-0107-c164-304740bc5d7f@arm.com> Message-ID: Hi Ningsheng, On 2020-08-24 11:59, Ningsheng Jian wrote: > Hi Erik, > > Thanks for the review! > > On 8/22/20 12:21 AM, Erik ?sterlund wrote: >> Hi, >> >> Have you tried this with ZGC on AArch64? It has custom code for saving >> live registers in the load barrier slow path. >> I can't see any code changes there, so assuming this will just crash >> instead. >> The relevant code is in ZBarrierSetAssembler on aarch64. >> >> Maybe I missed something? >> > > I didn't add ZGC option while running tests. I think I need to update > push_fp() which is called by ZSaveLiveRegisters. But do we need to get > size info (float/neon/sve) instead of saving the whole vector > register? Currently, it just simply saves the whole NEON register. What we found on x86_64 was that there was a significant cost in saving vector registers in load barriers. That is why we perform some analysis so that only the exact registers that are affected, and only the parts of the registers that are affected, get spilled. It actually mattered. It will of course work either way, but that was our observation on x86_64. But I am okay with that being deferred to a separate RFE. I just wanted to make sure that it at the very least works with the new code, for a start, so it doesn't start crashing. > And in ZBarrierSetAssembler::load_at(), before calling to runtime > code, we call push_call_clobbered_registers_except(), which just saves > floating point registers instead of the whole NEON vector registers. > Similar behavior in x86 implementation. Is that correct (not saving > vectors)? Yes. The call contexts are: 1) Interpreter. Does not use vector registers. 2) Method handle intrinsic. Uses only floats that are part of the Java calling convention, rest is garbage. No vectors here. 3) Checkcast arraycopy. Does not use vectors. Thanks, /Erik > Thanks, > Ningsheng From luhenry at microsoft.com Mon Aug 24 17:21:38 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Mon, 24 Aug 2020 17:21:38 +0000 Subject: Preliminary review for new WINENV support In-Reply-To: References: Message-ID: 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%2F&data=02%7C01%7Cluhenry%40microsoft.com%7C55d5bddc82f142c2312c08d823c33111%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637298668546029073&sdata=k7tQ6%2BfwdrD8AGryNZdqAD%2Fk3Lnc%2B%2B75opEaWASISo0%3D&reserved=0 > > (If you prefer, you can check out the branch "ihse-winenv-branch" on https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fsandbox&data=02%7C01%7Cluhenry%40microsoft.com%7C55d5bddc82f142c2312c08d823c33111%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637298668546029073&sdata=yoknkwhOhji8D43VzTyj4ryiNtNx2CSnCliVTd420nI%3D&reserved=0 instead of downloading the patch from the webrev.) > > > I am leaving on vacation next week, so I won't be doing any more work on this for a while, but I promise to read all emails when I get back and try to rectify all issues that are reported. This means you have some time to try it out, too. > > Here are some technical notes of what is changing, compared to the current Windows build. > > The native "fixpath.exe" tool is gone. This means that we do not need to compile it during configure, which was always tricky to get right (mostly since we did not have fixpath in place to help us...). > > Instead, there is a new fixpath.sh shell script, that does the same job, and more. The script is written in highly optimized shell code (yeah, I see the oxymoron) so only bash internal functionality is used, to avoid calling external tools, which is expensive on Windows. This makes the performance practically roughly at par with the native fixpath.exe. > > Fixpath also has a "print" and "import" mode, apart from the traditional"exec" mode. This makes it possible to use the same tool for converting individual paths at runtime to Windows style ("print"), and it takes the logic needed to "import" paths given by the user to configure, into a format usable internally by the build system, and moves it into a centralized location in the fixpath script. > > A "winenv" is defined by a quartet of variables: PATHTOOL, DRIVEPREFIX, ENVROOT and WINTEMP. For instance, for "cygwin", these are: > PATHTOOL=cygpath > DRIVEPREFIX=/cygdrive (typically) > ENVROOT=C:\Cygwin64 (typically) > WINTEMP=/tmp > > These are needed for fixpath to do it's magic. Fixpath can auto-detect those, but to save on execution time they are normally detected by configure and sent as arguments to fixpath. > > Detection of the Visual Studio environment has been massively simplified. Using fixpath, conversion between Windows and unix paths is not so complex anymore. The bridge Windows batch file that is needed to extract the environment variables is no longer created on the fly, but is instead stored in make/scripts/extract-vs-env.cmd. This is called with fixpath, so all arguments to it can be unix paths. > > Furthermore, TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is now clearly designed to have a single responsibility, to set SYSROOT flags (and TOOLCHAIN_PATH) for the microsoft toolchain. As a result of this, it is now called from FLAGS_SETUP_SYSROOT_FLAGS. Also, the file toolchain_windows.m4 is now more correctly named toolchain_microsoft.m4. A price we had to pay for this was that the old idea that you should be able to start a "Visual Studio console" and then run configure from it to extract the variables do not work anymore. (It had not been tested for ages, and might have been broken anyway.) > > Fixpath also knows about the difference between unix path lists (/foo/bar:/my/dir) and windows path lists (c:\dir;d:\data) and can convert freely and automatically between them. This furthermore means that PATH_SEP is removed, and we only use unix style (colon separated) path lists internally. > > The logic automatically detects if and when .exe is needed, so EXE_SUFFIX is removed too. There are some limitations; when code needs to explicitly test for the presence of a file, the suffix needs to be correct. Also when make files check for e.g. the generated bin/java.exe, the suffix needs to be present. For this, I have introduced an EXECUTABLE_SUFFIX, that has the same value as EXE_SUFFIX -- but not the same semantics! The old code added EXE_SUFFIX here and there, not caring about if we meant "microsoft" as a toolchain or if we were running on Windows as a build platform. Clearly not well adapted for future cross-compilation. > > The old ways of locating programs in configure were messy, complicated and not always correct. We used a mixture of the original autoconf macros, and our own UTIL_PATH_PROGS and UTIL_CHECK_TOOLS. These did not have very well defined semantics, and were frequently mixed up. Also, UTIL_CHECK_TOOLS required UTIL_FIXUP_EXECUTABLE tobe called afterwards, to "rewrite" the result in a second step. This was not needed after UTIL_PATH_PROGS but was frequently done anyway to "be on the safe side". > > I have now replaced: > AC_(PATH|CHECK)_(PROG|PROGS) with UTIL_LOOKUP_PROGS > AC_(PATH|CHECK)_(TOOL|TOOLS) with UTIL_LOOKUP_TOOLCHAIN_PROGS > > This is actually almost the same semantic, but unless you're an autoconf aficionado, you ar not likely to understand the difference between "PROG" and "TOOL". The only difference is that UTIL_LOOKUP_TOOLCHAIN_PROGS will try to look for "host-prefixed" tools first, when cross-compiling, and should therefore be used for all toolchain lookups. > > There is also a fail-fast version of both, UTIL_REQUIRE_PROGS and UTIL_REQUIRE_TOOLCHAIN_PROGS. > > UTIL_LOOKUP_PROGS is the core function, with the rest being thin wrappers around it. This function is created from scratch, to do exactly what we want, on Unix platforms and Windows. So there is no need anymore to call UTIL_FIXUP_EXECUTABLE, unless you have input from elsewhere (e.g. user flag) that you need to verify. I have also collected all this logic in a single file, util_paths.m4, moving parts from util.m4, and just removing util_windows.m4. > > UTIL_LOOKUP_PROGS will use the new and nifty function UTIL_CHECK_WINENV_EXEC_TYPE, which will automatically determine if an executable needs to be prefixed by fixpath! That means that you can match and mix Windows-style and Unix-style programs however you like, with very few limitations. For instance, you can have a Linux version of the BootJDK on WSL. For this to work, the $FIXPATH prefix is now stored in the variables themselves (e.g. in $CC), rather than added as @FIXPATH@ in spec.gmk.in. This has generally worked out OK, but caused some headaches when the code thought that $CC (etc) was not a way to launch a program, but was a file that could be tested for existence, etc. > > I reintroduced support for msys2. This was mostly free, since msys2 is so close to cygwin (which msys never where). To underline the difference, I renamed the winenv windows.msys2 (instead of windows.msys). Msys (version 1) will never be supported in modern OpenJDK due to critical packages being far too old, and not updated. I also clearly separate between WSL1 (which is using a kernel emulation layer, somewhat like Wine) and WSL2 (which is using a Hyper-V VM to run an actual Linux kernel), as windows.wsl1 and windows.wsl2. > > I have also done a ton of small fixes, to make things more convenient and smooth when working in these winenvs. I have adjusted the output from configure to be less verbose and more streamlined. Overall, a lot of odd code in configure has been removed. A few changes that are strictly unneeded for this patch has also been included; mostly removal of dead code I came across, and a few fixes for additional debuggability that I needed when developing this patch, like ExecuteithLog. > > I have also temporarily disabled the javac server, and building without absolute paths. I believe a better way forward is to address these with improved functionality in separate patches, instead of trying to work around the issues introduced by them in this patch. > > I have done substantial testing of the core functionality (building jdk-images) on Cygwin, Msys2 and WSL2, both on my personal machine and on Oracle's CI system. The performance on Cygwin (which we use for our CI builds) is roughly on par with the old Cygwin performance, but the WSL1 performance is roughly 20% faster, so I think we should investigate if it is possible for us to switch to WSL1. Everything seems stable so far, but more testing is definitely needed. I have also not even started testing autxillary functionality, such as the compare script, IDE project file generation etc. > > However, the big disappointment in all of this is WSL2. That was the main driver that got me started on this rewrite. But it turned out that WSL2 is still very immature. :-( There are lot of issues, like stdout and stderr getting messed up, time synchronization issues causing make to complain about "Clock skew detected", extreme slowness when accessing disks cross the OS boundary. But worst of all has been that WSL2 is *extremly* unstable. After a few calls of Window executables, I get the impression that a conversion daemon dies. All further calls to Window binaries just stalls, and the WSL2 instance is unusable until I terminate it using "wsl -t Ubuntu-2004" from a cmd shell. :-( > > So the WSL2 functionality is not very well tested, since I have not been able to build it completely a single time. I do believe that everything is correct, in "theory". So in case this is something broken with my WSL2 installation, I'd encourage anyone with a WSL2 installation to try it out. > > /Magnus > From philip.race at oracle.com Mon Aug 24 20:35:32 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 24 Aug 2020 13:35:32 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU In-Reply-To: References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> Message-ID: <5F442494.8050108@oracle.com> Is there any performance cost to doing this ? I'd expect so. Any estimate ? And there's then no way to explicitly request the discrete card on a 15/16" MBP. Should we release note this ? -phil On 8/21/20, 3:02 AM, Magnus Ihse Bursie wrote: > On 2020-08-21 06:55, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk/client. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8251854 >> Fix: http://cr.openjdk.java.net/~serb/8251854/webrev.00 > The fix looks good from a build perspective. > > (But it highlights the fact that we have no consistent placement of > those plist files; we should probably address that in a separate fix.) > > /Magnus > >> >> This is a review request for the bug particularly fixed some time ago: >> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html >> >> In that review request it was found that the old fix does not work >> well in all cases, see: >> https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html >> >> The current fix updates an embedded plist.info, so the java will not >> require >> discrete graphics by default, same as for any other applications. >> >> Note that the new "metal" pipeline also does not required the >> discrete graphics. >> >> The documentation for NSSupportsAutomaticGraphicsSwitching: >> https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching >> >> > From Sergey.Bylokhov at oracle.com Tue Aug 25 02:18:45 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 24 Aug 2020 19:18:45 -0700 Subject: RFR: JDK-8252145: Unify Info.plist files with correct version strings In-Reply-To: References: Message-ID: <77725336-71e6-b09c-7ede-50a9e429498b@oracle.com> Hi, Erik. I would like to highlight one thing affected by this fix. The text in the default about dialog in the Swing application will be changed. For my local build: - Current text: "Java Version 1.0 (16)" - After the fix: "Java Version 16 (0)" I am not sure why the build version and as a result the CFBundleVersion is zero? On 24.08.2020 08:19, Erik Joelsson wrote: > When fixing JDK-8246094, I concluded that our Info.plist files are in a bit of a mess. This patch tries to address this on a more fundamental level. > > 1. All Info.plist files and templates are moved to the same location in the source tree. > > 2. The CFBundleIdentifier is changed to no longer contain the version number. Instead it gets the $VERSION_PRE string if present. > > 3. The CFBundleShortVersionString is changed to the numeric version part of our version string. > > 4. The CFBundleVersion is changed to the build number (or a custom number if supplied through a new configure argument). For Oracle builds, this will take the form of .. > > For more details on why this particular scheme, see bug description, but in short, this is what I think best reflects what the Apple documentation says the fields are for. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252145 > > Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01 > > /Erik > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 25 06:27:25 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 24 Aug 2020 23:27:25 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU In-Reply-To: <5F442494.8050108@oracle.com> References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> <5F442494.8050108@oracle.com> Message-ID: On 24.08.2020 13:35, Philip Race wrote: > > Is there any performance cost to doing this ? I'd expect so. Any estimate ? Yes, performance is affected for sure: - SwingMark: OGL_Base: 14000 OGL_Fix: 24000 Metal: 18000 - Here is a j2dbench for the common draw operations(new/old/metal): http://cr.openjdk.java.net/~serb/8251854/perf/results.txt Summary: OGL_base: Number of tests: 24 Overall average: 4.556306150323041E8 Best spread: 0.16% variance Worst spread: 4.68% variance (Basis for results comparison) OGL_fix: Number of tests: 24 Overall average: 1.0086929824044746E8 Best spread: 0.04% variance Worst spread: 7.89% variance Comparison to basis: Best result: 83.41% of basis Worst result: 15.73% of basis Number of wins: 0 Number of ties: 0 Number of losses: 24 metal: Number of tests: 24 Overall average: 8.841681616575797E7 Best spread: 0.08% variance Worst spread: 5.64% variance Comparison to basis: Best result: 248.11% of basis Worst result: 19.1% of basis Number of wins: 8 Number of ties: 2 Number of losses: 14 ========================================== - Here is a j2dbench for the common draw operations(newOGL vs metal only): http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt Summary: OGL_fix: Number of tests: 24 Overall average: 2.5871177969681844E7 Best spread: 0.04% variance Worst spread: 7.01% variance (Basis for results comparison) metal: Number of tests: 24 Overall average: 2.1896134898150157E7 Best spread: 0.04% variance Worst spread: 1.98% variance Comparison to basis: Best result: 488.31% of basis Worst result: 30.77% of basis Number of wins: 14 Number of ties: 0 Number of losses: 10 > And there's then no way to explicitly request the discrete card on a 15/16" MBP. I have checked that the discrete card is enabled by the macOS: - if the full screen window is set - if the second monitor is connected Do not know any other ways to enable it. > Should we release note this ? Yes, I think so. Note that it does not affect the bundled applications only apps running via java launcher. But some(most?) bundled java applications use this flag already. -- Best regards, Sergey. From ningsheng.jian at arm.com Tue Aug 25 10:13:14 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Tue, 25 Aug 2020 18:13:14 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <5397e0d1-9d40-0107-c164-304740bc5d7f@arm.com> Message-ID: Hi Erik, On 8/24/20 11:26 PM, Erik ?sterlund wrote: > Hi Ningsheng, > > On 2020-08-24 11:59, Ningsheng Jian wrote: >> Hi Erik, >> >> Thanks for the review! >> >> On 8/22/20 12:21 AM, Erik ?sterlund wrote: >>> Hi, >>> >>> Have you tried this with ZGC on AArch64? It has custom code for saving >>> live registers in the load barrier slow path. >>> I can't see any code changes there, so assuming this will just crash >>> instead. >>> The relevant code is in ZBarrierSetAssembler on aarch64. >>> >>> Maybe I missed something? >>> >> >> I didn't add ZGC option while running tests. I think I need to update >> push_fp() which is called by ZSaveLiveRegisters. But do we need to get >> size info (float/neon/sve) instead of saving the whole vector >> register? Currently, it just simply saves the whole NEON register. > > What we found on x86_64 was that there was a significant cost in saving > vector registers in load barriers. That is why we perform some analysis > so that only the exact registers that are affected, and only the parts > of the registers that are affected, get spilled. It actually mattered. > It will of course work either way, but that was our observation on > x86_64. But I am okay with that being deferred to a separate RFE. I just > wanted to make sure that it at the very least works with the new code, > for a start, so it doesn't start crashing. > OK, I will make it to save the whole reg in this patch and have a separate RFE to optimize as what x86 does. >> And in ZBarrierSetAssembler::load_at(), before calling to runtime >> code, we call push_call_clobbered_registers_except(), which just saves >> floating point registers instead of the whole NEON vector registers. >> Similar behavior in x86 implementation. Is that correct (not saving >> vectors)? > > Yes. The call contexts are: > 1) Interpreter. Does not use vector registers. > 2) Method handle intrinsic. Uses only floats that are part of the Java > calling convention, rest is garbage. No vectors here. > 3) Checkcast arraycopy. Does not use vectors. > Thanks for sharing this. Thanks, Ningsheng From kevin.rushforth at oracle.com Tue Aug 25 12:43:19 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 25 Aug 2020 05:43:19 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU In-Reply-To: References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> <5F442494.8050108@oracle.com> Message-ID: <4f703a37-a42f-2641-f198-d77845387d41@oracle.com> Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time. -- Kevin On 8/24/2020 11:27 PM, Sergey Bylokhov wrote: > On 24.08.2020 13:35, Philip Race wrote: >> >> Is there any performance cost to doing this ? I'd expect so. Any >> estimate ? > > Yes, performance is affected for sure: > > ?- SwingMark: > ?? OGL_Base: 14000 > ?? OGL_Fix: 24000 > ?? Metal: 18000 > > ?- Here is a j2dbench for the common draw operations(new/old/metal): > ?? http://cr.openjdk.java.net/~serb/8251854/perf/results.txt > > ? Summary: > ? OGL_base: > ??? Number of tests:? 24 > ??? Overall average:? 4.556306150323041E8 > ??? Best spread:????? 0.16% variance > ??? Worst spread:???? 4.68% variance > ??? (Basis for results comparison) > > ? OGL_fix: > ??? Number of tests:? 24 > ??? Overall average:? 1.0086929824044746E8 > ??? Best spread:????? 0.04% variance > ??? Worst spread:???? 7.89% variance > ??? Comparison to basis: > ????? Best result:????? 83.41% of basis > ????? Worst result:???? 15.73% of basis > ????? Number of wins:?? 0 > ????? Number of ties:?? 0 > ????? Number of losses: 24 > > ? metal: > ??? Number of tests:? 24 > ??? Overall average:? 8.841681616575797E7 > ??? Best spread:????? 0.08% variance > ??? Worst spread:???? 5.64% variance > ??? Comparison to basis: > ????? Best result:????? 248.11% of basis > ????? Worst result:???? 19.1% of basis > ????? Number of wins:?? 8 > ????? Number of ties:?? 2 > ????? Number of losses: 14 > ========================================== > > ?- Here is a j2dbench for the common draw operations(newOGL vs metal > only): > http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt > ? ? Summary: > ? OGL_fix: > ??? Number of tests:? 24 > ??? Overall average:? 2.5871177969681844E7 > ??? Best spread:????? 0.04% variance > ??? Worst spread:???? 7.01% variance > ??? (Basis for results comparison) > > ? metal: > ??? Number of tests:? 24 > ??? Overall average:? 2.1896134898150157E7 > ??? Best spread:????? 0.04% variance > ??? Worst spread:???? 1.98% variance > ??? Comparison to basis: > ????? Best result:????? 488.31% of basis > ????? Worst result:???? 30.77% of basis > ????? Number of wins:?? 14 > ????? Number of ties:?? 0 > ????? Number of losses: 10 > >> And there's then no way to explicitly request the discrete card on a >> 15/16" MBP. > > ? I have checked that the discrete card is enabled by the macOS: > ? - if the full screen window is set > ? - if the second monitor is connected > ? Do not know any other ways to enable it. > > >> Should we release note this ? > > Yes, I think so. > Note that it does not affect the bundled applications only apps > running via java launcher. > But some(most?) bundled java applications use this flag already. > > From erik.joelsson at oracle.com Tue Aug 25 14:27:23 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 25 Aug 2020 07:27:23 -0700 Subject: RFR: JDK-8252145: Unify Info.plist files with correct version strings In-Reply-To: <77725336-71e6-b09c-7ede-50a9e429498b@oracle.com> References: <77725336-71e6-b09c-7ede-50a9e429498b@oracle.com> Message-ID: <38f8299d-9079-da0a-cdd1-bec67a2822d5@oracle.com> On 2020-08-24 19:18, Sergey Bylokhov wrote: > Hi, Erik. > > I would like to highlight one thing affected by this fix. The text in > the default about dialog in the Swing application will be changed. > > For my local build: > ?- Current text: "Java Version 1.0 (16)" > ?- After the fix: "Java Version 16 (0)" > > I am not sure why the build version and as a result the > CFBundleVersion is zero? > The CFBundleVersion is supposed to have a version number representing the build number. In a developer build, the "VERSION_BUILD" variable is default 0. In a promoted build, that number is set to the promoted build number. In Oracle promoted builds, we will also have a CI build number, so if this change was in effect, the latest JDK 16 promoted build would have 12.477 in CFBundleVersion. /Erik > On 24.08.2020 08:19, Erik Joelsson wrote: >> When fixing JDK-8246094, I concluded that our Info.plist files are in >> a bit of a mess. This patch tries to address this on a more >> fundamental level. >> >> 1. All Info.plist files and templates are moved to the same location >> in the source tree. >> >> 2. The CFBundleIdentifier is changed to no longer contain the version >> number. Instead it gets the $VERSION_PRE string if present. >> >> 3. The CFBundleShortVersionString is changed to the numeric version >> part of our version string. >> >> 4. The CFBundleVersion is changed to the build number (or a custom >> number if supplied through a new configure argument). For Oracle >> builds, this will take the form of >> .. >> >> For more details on why this particular scheme, see bug description, >> but in short, this is what I think best reflects what the Apple >> documentation says the fields are for. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8252145 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01 >> >> /Erik >> > > From huizhe.wang at oracle.com Tue Aug 25 18:47:40 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 25 Aug 2020 11:47:40 -0700 Subject: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package In-Reply-To: References: <3fc299f4-1c0a-1ccd-5d4c-3716775dfa38@oracle.com> Message-ID: Cc-ing build-dev at openjdk.java.net (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: > Hi Joe, > > Eliminating the checking for warnings in org.w3c is fine. Please be > more specific in the comment. > > "Ignore the doclint warnings in the W3C DOM package" Updated. > org/xml/...: If we're suppressing the warnings for org/xml/... then > the files changes are unnecessary? Did you mean org/w3c? We're only suppressing the warnings for org/w3c where the DOM package is in, but not org/xml where SAX is in. > > Remove the addition of -Xmaxwarns, it should stay the default. Done. > > Since its a makefile change, please copy build-dev at openjdk.java.net. Cc-ed > > The first line comments should terminate with a period ".". > > javax/xml/stream/FactoryConfigurationError.java:40 > javax/xml/stream/XMLStreamException.java:41 > javax/xml/xpath/XPathException.java:44? And capitable "Serializable". > > > javax/xml/stream/events/Attribute.java: 50; add "normalized" to the > @return line so it is the same as the first line. > For simple get methods, the @return mimics the first line. > > javax/xml/stream/events/NotationDeclaration.java:43? add "notation" Updated webrev including all of the above: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ > > > > Thanks, Roger > > p.s.? There is lots of other cleanup of the javadoc, using @code > around true, false, > missing periods at the end of first sentences, etc.? But that's a > different task. Created a bug to keep track of this: https://bugs.openjdk.java.net/browse/JDK-8252328 Thanks, Joe > > > > On 8/24/20 5:44 PM, Joe Wang wrote: >> Hi all,? adding Roger's comment for the make file to webrev_02 (the >> only change to webrev_01 is Docs.gmk): >> >> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ >> >> Thanks, >> Joe >> >> On 8/21/20 12:49 PM, naoto.sato at oracle.com wrote: >>> +1 >>> >>> Naoto >>> >>> On 8/21/20 12:24 PM, Lance Andersen wrote: >>>> Hi Joe, >>>> >>>> This looks OK. >>>> >>>> >>>> >>>>> On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: >>>>> >>>>> Pelase review a patch to add the missing @return, @throws, @param >>>>> statements in the java.xml package (excluding the DOM component). >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ >>>>> >>>>> Thanks, >>>>> Joe >>>> >>>> >>>> Best >>>> Lance >>>> ------------------ >>>> >>>> >>>> >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>>> >>>> >> > From erik.joelsson at oracle.com Tue Aug 25 18:58:30 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 25 Aug 2020 11:58:30 -0700 Subject: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package In-Reply-To: References: <3fc299f4-1c0a-1ccd-5d4c-3716775dfa38@oracle.com> Message-ID: <4bb3ded8-6b16-d2ad-a426-7b25c5d61a54@oracle.com> Build change looks ok, but why is it needed? You are fixing a bunch of warnings in one part of the source and disabling them in another part. Is there some other change incoming that will enable more warning categories by default? /Erik On 2020-08-25 11:47, Joe Wang wrote: > Cc-ing build-dev at openjdk.java.net (makefile change: make/Docs.gmk) > Updated webrev: > http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ > > Thanks Roger! Please see inline comments. > > On 8/25/20 8:09 AM, Roger Riggs wrote: >> Hi Joe, >> >> Eliminating the checking for warnings in org.w3c is fine. Please be >> more specific in the comment. >> >> "Ignore the doclint warnings in the W3C DOM package" > > Updated. >> org/xml/...: If we're suppressing the warnings for org/xml/... then >> the files changes are unnecessary? > > Did you mean org/w3c? We're only suppressing the warnings for org/w3c > where the DOM package is in, but not org/xml where SAX is in. > >> >> Remove the addition of -Xmaxwarns, it should stay the default. > > Done. >> >> Since its a makefile change, please copy build-dev at openjdk.java.net. > > Cc-ed >> >> The first line comments should terminate with a period ".". >> >> javax/xml/stream/FactoryConfigurationError.java:40 >> javax/xml/stream/XMLStreamException.java:41 >> javax/xml/xpath/XPathException.java:44? And capitable "Serializable". >> >> >> javax/xml/stream/events/Attribute.java: 50; add "normalized" to the >> @return line so it is the same as the first line. >> For simple get methods, the @return mimics the first line. >> >> javax/xml/stream/events/NotationDeclaration.java:43? add "notation" > > Updated webrev including all of the above: > > http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ > >> >> >> >> Thanks, Roger >> >> p.s.? There is lots of other cleanup of the javadoc, using @code >> around true, false, >> missing periods at the end of first sentences, etc.? But that's a >> different task. > > Created a bug to keep track of this: > https://bugs.openjdk.java.net/browse/JDK-8252328 > > Thanks, > Joe >> >> >> >> On 8/24/20 5:44 PM, Joe Wang wrote: >>> Hi all,? adding Roger's comment for the make file to webrev_02 (the >>> only change to webrev_01 is Docs.gmk): >>> >>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ >>> >>> Thanks, >>> Joe >>> >>> On 8/21/20 12:49 PM, naoto.sato at oracle.com wrote: >>>> +1 >>>> >>>> Naoto >>>> >>>> On 8/21/20 12:24 PM, Lance Andersen wrote: >>>>> Hi Joe, >>>>> >>>>> This looks OK. >>>>> >>>>> >>>>> >>>>>> On Aug 21, 2020, at 2:23 PM, Joe Wang >>>>>> wrote: >>>>>> >>>>>> Pelase review a patch to add the missing @return, @throws, @param >>>>>> statements in the java.xml package (excluding the DOM component). >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ >>>>>> >>>>>> Thanks, >>>>>> Joe >>>>> >>>>> >>>>> Best >>>>> Lance >>>>> ------------------ >>>>> >>>>> >>>>> >>>>> >>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> >>>>> >>>>> >>>>> >>> >> > From Roger.Riggs at oracle.com Tue Aug 25 19:21:33 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 25 Aug 2020 15:21:33 -0400 Subject: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package In-Reply-To: <4bb3ded8-6b16-d2ad-a426-7b25c5d61a54@oracle.com> References: <3fc299f4-1c0a-1ccd-5d4c-3716775dfa38@oracle.com> <4bb3ded8-6b16-d2ad-a426-7b25c5d61a54@oracle.com> Message-ID: Hi Erik, org.w3c is in third party code that is not being updated. There is a balance between ignoring the warnings and doing a bunch of editing that would overwritten by a future update. $.02, Roger On 8/25/20 2:58 PM, Erik Joelsson wrote: > Build change looks ok, but why is it needed? You are fixing a bunch of > warnings in one part of the source and disabling them in another part. > Is there some other change incoming that will enable more warning > categories by default? > > /Erik > > On 2020-08-25 11:47, Joe Wang wrote: >> Cc-ing build-dev at openjdk.java.net (makefile change: make/Docs.gmk) >> Updated webrev: >> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ >> >> Thanks Roger! Please see inline comments. >> >> On 8/25/20 8:09 AM, Roger Riggs wrote: >>> Hi Joe, >>> >>> Eliminating the checking for warnings in org.w3c is fine. Please be >>> more specific in the comment. >>> >>> "Ignore the doclint warnings in the W3C DOM package" >> >> Updated. >>> org/xml/...: If we're suppressing the warnings for org/xml/... then >>> the files changes are unnecessary? >> >> Did you mean org/w3c? We're only suppressing the warnings for org/w3c >> where the DOM package is in, but not org/xml where SAX is in. >> >>> >>> Remove the addition of -Xmaxwarns, it should stay the default. >> >> Done. >>> >>> Since its a makefile change, please copy build-dev at openjdk.java.net. >> >> Cc-ed >>> >>> The first line comments should terminate with a period ".". >>> >>> javax/xml/stream/FactoryConfigurationError.java:40 >>> javax/xml/stream/XMLStreamException.java:41 >>> javax/xml/xpath/XPathException.java:44? And capitable "Serializable". >>> >>> >>> javax/xml/stream/events/Attribute.java: 50; add "normalized" to the >>> @return line so it is the same as the first line. >>> For simple get methods, the @return mimics the first line. >>> >>> javax/xml/stream/events/NotationDeclaration.java:43? add "notation" >> >> Updated webrev including all of the above: >> >> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ >> >>> >>> >>> >>> Thanks, Roger >>> >>> p.s.? There is lots of other cleanup of the javadoc, using @code >>> around true, false, >>> missing periods at the end of first sentences, etc.? But that's a >>> different task. >> >> Created a bug to keep track of this: >> https://bugs.openjdk.java.net/browse/JDK-8252328 >> >> Thanks, >> Joe >>> >>> >>> >>> On 8/24/20 5:44 PM, Joe Wang wrote: >>>> Hi all,? adding Roger's comment for the make file to webrev_02 (the >>>> only change to webrev_01 is Docs.gmk): >>>> >>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ >>>> >>>> Thanks, >>>> Joe >>>> >>>> On 8/21/20 12:49 PM, naoto.sato at oracle.com wrote: >>>>> +1 >>>>> >>>>> Naoto >>>>> >>>>> On 8/21/20 12:24 PM, Lance Andersen wrote: >>>>>> Hi Joe, >>>>>> >>>>>> This looks OK. >>>>>> >>>>>> >>>>>> >>>>>>> On Aug 21, 2020, at 2:23 PM, Joe Wang >>>>>>> wrote: >>>>>>> >>>>>>> Pelase review a patch to add the missing @return, @throws, >>>>>>> @param statements in the java.xml package (excluding the DOM >>>>>>> component). >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 >>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Joe >>>>>> >>>>>> >>>>>> Best >>>>>> Lance >>>>>> ------------------ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Lance Andersen| Principal Member of Technical Staff | >>>>>> +1.781.442.2037 >>>>>> Oracle Java Engineering >>>>>> 1 Network Drive >>>>>> Burlington, MA 01803 >>>>>> Lance.Andersen at oracle.com >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>> >> From Sergey.Bylokhov at oracle.com Tue Aug 25 19:27:53 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 25 Aug 2020 12:27:53 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU In-Reply-To: <4f703a37-a42f-2641-f198-d77845387d41@oracle.com> References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> <5F442494.8050108@oracle.com> <4f703a37-a42f-2641-f198-d77845387d41@oracle.com> Message-ID: <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com> On 25.08.2020 05:43, Kevin Rushforth wrote: > Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time. It is applied if the "automatic graphics switching" is enabled, if the user disables this feature for the "power adapter" mode, then the discrete graphics will be always used. I guess by default they try to "maximize battery life": https://support.apple.com/en-us/HT202043 > > -- Kevin > > > On 8/24/2020 11:27 PM, Sergey Bylokhov wrote: >> On 24.08.2020 13:35, Philip Race wrote: >>> >>> Is there any performance cost to doing this ? I'd expect so. Any estimate ? >> >> Yes, performance is affected for sure: >> >> ?- SwingMark: >> ?? OGL_Base: 14000 >> ?? OGL_Fix: 24000 >> ?? Metal: 18000 >> >> ?- Here is a j2dbench for the common draw operations(new/old/metal): >> ?? http://cr.openjdk.java.net/~serb/8251854/perf/results.txt >> >> ? Summary: >> ? OGL_base: >> ??? Number of tests:? 24 >> ??? Overall average:? 4.556306150323041E8 >> ??? Best spread:????? 0.16% variance >> ??? Worst spread:???? 4.68% variance >> ??? (Basis for results comparison) >> >> ? OGL_fix: >> ??? Number of tests:? 24 >> ??? Overall average:? 1.0086929824044746E8 >> ??? Best spread:????? 0.04% variance >> ??? Worst spread:???? 7.89% variance >> ??? Comparison to basis: >> ????? Best result:????? 83.41% of basis >> ????? Worst result:???? 15.73% of basis >> ????? Number of wins:?? 0 >> ????? Number of ties:?? 0 >> ????? Number of losses: 24 >> >> ? metal: >> ??? Number of tests:? 24 >> ??? Overall average:? 8.841681616575797E7 >> ??? Best spread:????? 0.08% variance >> ??? Worst spread:???? 5.64% variance >> ??? Comparison to basis: >> ????? Best result:????? 248.11% of basis >> ????? Worst result:???? 19.1% of basis >> ????? Number of wins:?? 8 >> ????? Number of ties:?? 2 >> ????? Number of losses: 14 >> ========================================== >> >> ?- Here is a j2dbench for the common draw operations(newOGL vs metal only): >> http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt >> ? ? Summary: >> ? OGL_fix: >> ??? Number of tests:? 24 >> ??? Overall average:? 2.5871177969681844E7 >> ??? Best spread:????? 0.04% variance >> ??? Worst spread:???? 7.01% variance >> ??? (Basis for results comparison) >> >> ? metal: >> ??? Number of tests:? 24 >> ??? Overall average:? 2.1896134898150157E7 >> ??? Best spread:????? 0.04% variance >> ??? Worst spread:???? 1.98% variance >> ??? Comparison to basis: >> ????? Best result:????? 488.31% of basis >> ????? Worst result:???? 30.77% of basis >> ????? Number of wins:?? 14 >> ????? Number of ties:?? 0 >> ????? Number of losses: 10 >> >>> And there's then no way to explicitly request the discrete card on a 15/16" MBP. >> >> ? I have checked that the discrete card is enabled by the macOS: >> ? - if the full screen window is set >> ? - if the second monitor is connected >> ? Do not know any other ways to enable it. >> >> >>> Should we release note this ? >> >> Yes, I think so. >> Note that it does not affect the bundled applications only apps running via java launcher. >> But some(most?) bundled java applications use this flag already. >> >> > -- Best regards, Sergey. From Roger.Riggs at oracle.com Tue Aug 25 19:30:33 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 25 Aug 2020 15:30:33 -0400 Subject: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package In-Reply-To: References: <3fc299f4-1c0a-1ccd-5d4c-3716775dfa38@oracle.com> Message-ID: Hi Joe, The updates to those files are fine, I mixed up the two packages. Roger On 8/25/20 2:47 PM, Joe Wang wrote: >> org/xml/...: If we're suppressing the warnings for org/xml/... then >> the files changes are unnecessary? > > Did you mean org/w3c? We're only suppressing the warnings for org/w3c > where the DOM package is in, but not org/xml where SAX is in. From erik.joelsson at oracle.com Tue Aug 25 19:39:09 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 25 Aug 2020 12:39:09 -0700 Subject: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package In-Reply-To: References: <3fc299f4-1c0a-1ccd-5d4c-3716775dfa38@oracle.com> <4bb3ded8-6b16-d2ad-a426-7b25c5d61a54@oracle.com> Message-ID: On 2020-08-25 12:21, Roger Riggs wrote: > Hi Erik, > > org.w3c is in third party code that is not being updated. There is a > balance between > ignoring the warnings and doing a bunch of editing that would > overwritten by a future update. > Yes, I get that part, but why are those warnings not triggered today? I don't see any change enabling more warnings from the build. /Erik > $.02, Roger > > > On 8/25/20 2:58 PM, Erik Joelsson wrote: >> Build change looks ok, but why is it needed? You are fixing a bunch >> of warnings in one part of the source and disabling them in another >> part. Is there some other change incoming that will enable more >> warning categories by default? >> >> /Erik >> >> On 2020-08-25 11:47, Joe Wang wrote: >>> Cc-ing build-dev at openjdk.java.net (makefile change: make/Docs.gmk) >>> Updated webrev: >>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ >>> >>> Thanks Roger! Please see inline comments. >>> >>> On 8/25/20 8:09 AM, Roger Riggs wrote: >>>> Hi Joe, >>>> >>>> Eliminating the checking for warnings in org.w3c is fine. Please be >>>> more specific in the comment. >>>> >>>> "Ignore the doclint warnings in the W3C DOM package" >>> >>> Updated. >>>> org/xml/...: If we're suppressing the warnings for org/xml/... then >>>> the files changes are unnecessary? >>> >>> Did you mean org/w3c? We're only suppressing the warnings for >>> org/w3c where the DOM package is in, but not org/xml where SAX is in. >>> >>>> >>>> Remove the addition of -Xmaxwarns, it should stay the default. >>> >>> Done. >>>> >>>> Since its a makefile change, please copy build-dev at openjdk.java.net. >>> >>> Cc-ed >>>> >>>> The first line comments should terminate with a period ".". >>>> >>>> javax/xml/stream/FactoryConfigurationError.java:40 >>>> javax/xml/stream/XMLStreamException.java:41 >>>> javax/xml/xpath/XPathException.java:44? And capitable "Serializable". >>>> >>>> >>>> javax/xml/stream/events/Attribute.java: 50; add "normalized" to the >>>> @return line so it is the same as the first line. >>>> For simple get methods, the @return mimics the first line. >>>> >>>> javax/xml/stream/events/NotationDeclaration.java:43? add "notation" >>> >>> Updated webrev including all of the above: >>> >>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ >>> >>>> >>>> >>>> >>>> Thanks, Roger >>>> >>>> p.s.? There is lots of other cleanup of the javadoc, using @code >>>> around true, false, >>>> missing periods at the end of first sentences, etc.? But that's a >>>> different task. >>> >>> Created a bug to keep track of this: >>> https://bugs.openjdk.java.net/browse/JDK-8252328 >>> >>> Thanks, >>> Joe >>>> >>>> >>>> >>>> On 8/24/20 5:44 PM, Joe Wang wrote: >>>>> Hi all,? adding Roger's comment for the make file to webrev_02 >>>>> (the only change to webrev_01 is Docs.gmk): >>>>> >>>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ >>>>> >>>>> Thanks, >>>>> Joe >>>>> >>>>> On 8/21/20 12:49 PM, naoto.sato at oracle.com wrote: >>>>>> +1 >>>>>> >>>>>> Naoto >>>>>> >>>>>> On 8/21/20 12:24 PM, Lance Andersen wrote: >>>>>>> Hi Joe, >>>>>>> >>>>>>> This looks OK. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Aug 21, 2020, at 2:23 PM, Joe Wang >>>>>>>> wrote: >>>>>>>> >>>>>>>> Pelase review a patch to add the missing @return, @throws, >>>>>>>> @param statements in the java.xml package (excluding the DOM >>>>>>>> component). >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 >>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Joe >>>>>>> >>>>>>> >>>>>>> Best >>>>>>> Lance >>>>>>> ------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Lance Andersen| Principal Member of Technical Staff | >>>>>>> +1.781.442.2037 >>>>>>> Oracle Java Engineering >>>>>>> 1 Network Drive >>>>>>> Burlington, MA 01803 >>>>>>> Lance.Andersen at oracle.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> > From naoto.sato at oracle.com Tue Aug 25 20:04:17 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 25 Aug 2020 13:04:17 -0700 Subject: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package In-Reply-To: References: <3fc299f4-1c0a-1ccd-5d4c-3716775dfa38@oracle.com> Message-ID: <636240c9-354b-a1ec-a726-956894a56f58@oracle.com> +1 Naoto On 8/25/20 11:47 AM, Joe Wang wrote: > Cc-ing build-dev at openjdk.java.net (makefile change: make/Docs.gmk) > Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ > > Thanks Roger! Please see inline comments. > > On 8/25/20 8:09 AM, Roger Riggs wrote: >> Hi Joe, >> >> Eliminating the checking for warnings in org.w3c is fine. Please be >> more specific in the comment. >> >> "Ignore the doclint warnings in the W3C DOM package" > > Updated. >> org/xml/...: If we're suppressing the warnings for org/xml/... then >> the files changes are unnecessary? > > Did you mean org/w3c? We're only suppressing the warnings for org/w3c > where the DOM package is in, but not org/xml where SAX is in. > >> >> Remove the addition of -Xmaxwarns, it should stay the default. > > Done. >> >> Since its a makefile change, please copy build-dev at openjdk.java.net. > > Cc-ed >> >> The first line comments should terminate with a period ".". >> >> javax/xml/stream/FactoryConfigurationError.java:40 >> javax/xml/stream/XMLStreamException.java:41 >> javax/xml/xpath/XPathException.java:44? And capitable "Serializable". >> >> >> javax/xml/stream/events/Attribute.java: 50; add "normalized" to the >> @return line so it is the same as the first line. >> For simple get methods, the @return mimics the first line. >> >> javax/xml/stream/events/NotationDeclaration.java:43? add "notation" > > Updated webrev including all of the above: > > http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ > >> >> >> >> Thanks, Roger >> >> p.s.? There is lots of other cleanup of the javadoc, using @code >> around true, false, >> missing periods at the end of first sentences, etc.? But that's a >> different task. > > Created a bug to keep track of this: > https://bugs.openjdk.java.net/browse/JDK-8252328 > > Thanks, > Joe >> >> >> >> On 8/24/20 5:44 PM, Joe Wang wrote: >>> Hi all,? adding Roger's comment for the make file to webrev_02 (the >>> only change to webrev_01 is Docs.gmk): >>> >>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ >>> >>> Thanks, >>> Joe >>> >>> On 8/21/20 12:49 PM, naoto.sato at oracle.com wrote: >>>> +1 >>>> >>>> Naoto >>>> >>>> On 8/21/20 12:24 PM, Lance Andersen wrote: >>>>> Hi Joe, >>>>> >>>>> This looks OK. >>>>> >>>>> >>>>> >>>>>> On Aug 21, 2020, at 2:23 PM, Joe Wang wrote: >>>>>> >>>>>> Pelase review a patch to add the missing @return, @throws, @param >>>>>> statements in the java.xml package (excluding the DOM component). >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ >>>>>> >>>>>> Thanks, >>>>>> Joe >>>>> >>>>> >>>>> Best >>>>> Lance >>>>> ------------------ >>>>> >>>>> >>>>> >>>>> >>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> >>>>> >>>>> >>>>> >>> >> > From jiwon_choe at brown.edu Tue Aug 25 20:06:38 2020 From: jiwon_choe at brown.edu (Choe, Jiwon) Date: Tue, 25 Aug 2020 16:06:38 -0400 Subject: JDK14 cross-compile to arm64 fails to locate c++ header new Message-ID: Hello all, I'm trying to cross-compile JDK 14 to target aarch64-linux-gnu, from a 64-bit x86 Linux machine. I followed the steps described in the documentation ( https://hg.openjdk.java.net/jdk/jdk14/raw-file/tip/doc/building.html#creating-and-using-sysroots-with-qemu-deboostrap), but when I try to make the target image, I get the following error: === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_gtest_objs_precompiled_precompiled.hpp.gch: In file included from /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/classfile/classLoaderData.hpp:28:0, from /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/precompiled/precompiled.hpp:34: /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/memory/allocation.hpp:31:15: fatal error: new: No such file or directory #include ^ compilation terminated. * For target hotspot_variant-server_libjvm_objs_precompiled_precompiled.hpp.gch: In file included from /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/classfile/classLoaderData.hpp:28:0, from /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/precompiled/precompiled.hpp:34: /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/memory/allocation.hpp:31:15: fatal error: new: No such file or directory #include ^ compilation terminated. Could anyone help me figure out how to fix this? This is how I configured the build, and the output I got from configure: $ sudo qemu-debootstrap --arch=arm64 --verbose --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev --resolve-deps trusty /opt/sysroot/ $ CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ bash configure --openjdk-target=aarch64-linux-gnu --with-build-jdk=build/linux-x86_64-server-release/images/jdk --with-sysroot=/opt/sysroot --with-toolchain-path=/opt/sysroot configure: Configuration created at Tue Aug 25 15:55:28 EDT 2020. checking for basename... /usr/bin/basename checking for bash... /bin/bash checking for cat... /bin/cat checking for chmod... /bin/chmod checking for cmp... /usr/bin/cmp checking for comm... /usr/bin/comm checking for cp... /bin/cp checking for cut... /usr/bin/cut checking for date... /bin/date checking for gdiff... no checking for diff... /usr/bin/diff checking for dirname... /usr/bin/dirname checking for echo... /bin/echo checking for expr... /usr/bin/expr checking for file... /usr/bin/file checking for find... /usr/bin/find checking for head... /usr/bin/head checking for gunzip... /bin/gunzip checking for pigz... no checking for gzip... /bin/gzip checking for ln... /bin/ln checking for ls... /bin/ls checking for gmkdir... no checking for mkdir... /bin/mkdir checking for mktemp... /bin/mktemp checking for mv... /bin/mv checking for nawk... /usr/bin/nawk checking for printf... /usr/bin/printf checking for greadlink... no checking for readlink... /bin/readlink checking for rm... /bin/rm checking for rmdir... /bin/rmdir checking for sh... /bin/sh checking for sort... /usr/bin/sort checking for tail... /usr/bin/tail checking for gtar... no checking for tar... /bin/tar checking for tee... /usr/bin/tee checking for touch... /usr/bin/touch checking for tr... /usr/bin/tr checking for uname... /bin/uname checking for uniq... /usr/bin/uniq checking for wc... /usr/bin/wc checking for which... /usr/bin/which checking for xargs... /usr/bin/xargs checking for gawk... gawk checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for a sed that does not truncate output... /bin/sed checking for cygpath... no checking for wslpath... no checking for df... /bin/df checking for cpio... /bin/cpio checking for nice... /usr/bin/nice checking for lsb_release... /usr/bin/lsb_release checking for cmd.exe... no checking for /mnt/c/Windows/System32/cmd.exe... no checking build system type... x86_64-unknown-linux-gnu checking host system type... aarch64-unknown-linux-gnu checking target system type... aarch64-unknown-linux-gnu checking openjdk-build os-cpu... linux-x86_64 checking openjdk-target os-cpu... linux-aarch64 checking compilation type... cross checking for top-level directory... /home/jiwon/jdk-related/jdk14/jdk14 checking if custom source is suppressed (openjdk-only)... no checking which debug level to use... release checking which variants of the JVM to build... server checking for sysroot... /opt/sysroot checking for toolchain path... /opt/sysroot checking for extra path... checking where to store configuration... in default location checking what configuration name to use... linux-aarch64-server-release checking for zypper... no checking for apt-get... apt-get checking for pandoc... no checking for gmake... no checking for make... /usr/bin/make configure: Testing potential make at /usr/bin/make, found using make in PATH configure: Using GNU make at /usr/bin/make (version: GNU Make 3.81) checking if make --output-sync is supported... no checking if find supports -delete... yes checking what type of tar was found... gnu checking that grep (/bin/grep) -Fx handles empty lines in the pattern list correctly... yes checking for unzip... /usr/bin/unzip checking for zip... /usr/bin/zip checking for ldd... /usr/bin/ldd checking for greadelf... no checking for readelf... /usr/bin/readelf checking for dot... /usr/bin/dot checking for hg... /usr/bin/hg checking for git... /usr/bin/git checking for stat... /usr/bin/stat checking for time... /usr/bin/time checking for flock... /usr/bin/flock checking for dtrace... no checking for gpatch... no checking for patch... /usr/bin/patch checking for ulimit... no configure: Required tool ulimit not found in PATH, checking built-in configure: Found ulimit as shell built-in. Using it checking bash version... 4.3.11 checking if bash supports pipefail... yes checking if bash supports errexit (-e)... yes checking for aarch64-linux-gnu-pkg-config... no checking for pkg-config... /usr/bin/pkg-config configure: WARNING: using cross tools not prefixed with host triplet checking pkg-config is at least version 0.9.0... yes checking for default LOG value... checking headless only... no checking for graphviz dot... yes checking for pandoc... no, cannot generate full docs checking full docs... no, missing dependencies checking for cacerts file... default checking for jni library path... default checking if packaged modules are kept... yes (default) checking for version string... 14-internal+0-adhoc.jiwon.jdk14 checking for javac... /usr/bin/javac checking for java... /usr/bin/java configure: Found potential Boot JDK using java(c) in PATH checking for Boot JDK... /usr/lib/jvm/jdk-13.0.2 checking Boot JDK version... openjdk version "13.0.2" 2020-01-14 OpenJDK Runtime Environment (build 13.0.2+8) OpenJDK 64-Bit Server VM (build 13.0.2+8, mixed mode, sharing) checking for java in Boot JDK... ok checking for javac in Boot JDK... ok checking for javadoc in Boot JDK... ok checking for jar in Boot JDK... ok checking for jarsigner in Boot JDK... ok checking if Boot JDK is 32 or 64 bits... 64 checking for local Boot JDK Class Data Sharing (CDS)... yes, created configure: Found potential Build JDK using configure arguments checking for Build JDK... /home/jiwon/jdk-related/jdk14/jdk14/build/linux-x86_64-server-release/images/jdk checking Build JDK version... openjdk version "14-internal" 2020-03-17 OpenJDK Runtime Environment (build 14-internal+0-adhoc.jiwon.jdk14) OpenJDK 64-Bit Server VM (build 14-internal+0-adhoc.jiwon.jdk14, mixed mode, sharing) configure: Using default toolchain gcc (GNU Compiler Collection) configure: Will use user supplied compiler CC=aarch64-linux-gnu-gcc checking for aarch64-linux-gnu-gcc... /usr/bin/aarch64-linux-gnu-gcc checking resolved symbolic links for CC... /usr/bin/aarch64-linux-gnu-gcc-4.8 configure: Using gcc C compiler version 4.8.4 [aarch64-linux-gnu-gcc (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) 4.8.4] checking for aarch64-linux-gnu-/usr/bin/aarch64-linux-gnu-gcc... /usr/bin/aarch64-linux-gnu-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/aarch64-linux-gnu-gcc accepts -g... yes checking for /usr/bin/aarch64-linux-gnu-gcc option to accept ISO C89... none needed configure: Will use user supplied compiler CXX=aarch64-linux-gnu-g++ checking for aarch64-linux-gnu-g++... /usr/bin/aarch64-linux-gnu-g++ checking resolved symbolic links for CXX... /usr/bin/aarch64-linux-gnu-g++-4.8 configure: Using gcc C++ compiler version 4.8.4 [aarch64-linux-gnu-g++ (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) 4.8.4] checking whether we are using the GNU C++ compiler... yes checking whether /usr/bin/aarch64-linux-gnu-g++ accepts -g... yes checking how to run the C preprocessor... /usr/bin/aarch64-linux-gnu-gcc -E checking how to run the C++ preprocessor... /usr/bin/aarch64-linux-gnu-g++ -E checking for aarch64-linux-gnu-ld... aarch64-linux-gnu-ld configure: Rewriting LD_JAOTC to "/usr/bin/aarch64-linux-gnu-ld" configure: Using gcc linker version 2.24 [GNU ld (GNU Binutils for Ubuntu) 2.24] checking for aarch64-linux-gnu-ar... aarch64-linux-gnu-ar configure: Rewriting AR to "/usr/bin/aarch64-linux-gnu-ar" checking for aarch64-linux-gnu-strip... aarch64-linux-gnu-strip configure: Rewriting STRIP to "/usr/bin/aarch64-linux-gnu-strip" checking for aarch64-linux-gnu-nm... aarch64-linux-gnu-nm configure: Rewriting NM to "/usr/bin/aarch64-linux-gnu-nm" checking for aarch64-linux-gnu-gobjcopy... no checking for aarch64-linux-gnu-objcopy... aarch64-linux-gnu-objcopy configure: Rewriting OBJCOPY to "/usr/bin/aarch64-linux-gnu-objcopy" checking for aarch64-linux-gnu-gobjdump... no checking for aarch64-linux-gnu-objdump... aarch64-linux-gnu-objdump configure: Rewriting OBJDUMP to "/usr/bin/aarch64-linux-gnu-objdump" checking for aarch64-linux-gnu-c++filt... aarch64-linux-gnu-c++filt configure: Rewriting CXXFILT to "/usr/bin/aarch64-linux-gnu-c++filt" checking for cl... no checking for cc... /usr/bin/cc checking for cl... no checking for CC... no checking for g++... /usr/bin/g++ checking for nm... /usr/bin/nm checking for ar... /usr/bin/ar checking for objcopy... /usr/bin/objcopy checking for strip... /usr/bin/strip configure: Using gcc BuildC compiler version 4.8.4 [cc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4] configure: Using gcc BuildC++ compiler version 4.8.4 [g++ (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4] configure: Using gcc build linker version 2.24 [GNU ld (GNU Binutils for Ubuntu) 2.24] checking for jtreg... no checking for jtreg test harness... no, not found checking for jmh (Java Microbenchmark Harness)... no, disabled checking for jib... no checking if @file is supported by gcc... yes checking if CC supports "-m64"... no checking if CXX supports "-m64"... no checking if both CC and CXX support "-m64"... no checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking stdio.h usability... yes checking stdio.h presence... yes checking for stdio.h... yes checking size of int *... 8 checking for target address size... 64 bits checking whether byte ordering is bigendian... no checking if native warnings are errors... true (default) checking for library containing clock_gettime... none required checking if CC supports "-Xassembler -mrelax-relocations=no"... no checking if CXX supports "-Xassembler -mrelax-relocations=no"... no checking if both CC and CXX support "-Xassembler -mrelax-relocations=no"... no checking if CXX supports "-std=gnu++98 -Werror"... yes checking if CC supports "-fno-delete-null-pointer-checks -Werror"... yes checking if CXX supports "-fno-delete-null-pointer-checks -Werror"... yes checking if both CC and CXX support "-fno-delete-null-pointer-checks -Werror"... yes checking if CC supports "-fno-lifetime-dse -Werror"... no checking if CXX supports "-fno-lifetime-dse -Werror"... no checking if both CC and CXX support "-fno-lifetime-dse -Werror"... no checking if CC supports "-fmacro-prefix-map=/home/jiwon/jdk-related/jdk14/jdk14/="... no checking if CXX supports "-fmacro-prefix-map=/home/jiwon/jdk-related/jdk14/jdk14/="... no checking if both CC and CXX support "-fmacro-prefix-map=/home/jiwon/jdk-related/jdk14/jdk14/="... no checking if CC supports "-ffp-contract=off"... yes checking if CXX supports "-ffp-contract=off"... yes checking if both CC and CXX support "-ffp-contract=off"... yes checking if BUILD_CXX supports "-std=gnu++98 -Werror"... yes checking if BUILD_CC supports "-fno-delete-null-pointer-checks -Werror"... yes checking if BUILD_CXX supports "-fno-delete-null-pointer-checks -Werror"... yes checking if both BUILD_CC and BUILD_CXX support "-fno-delete-null-pointer-checks -Werror"... yes checking if BUILD_CC supports "-fno-lifetime-dse -Werror"... no checking if BUILD_CXX supports "-fno-lifetime-dse -Werror"... no checking if both BUILD_CC and BUILD_CXX support "-fno-lifetime-dse -Werror"... no checking if BUILD_CC supports "-fmacro-prefix-map=/home/jiwon/jdk-related/jdk14/jdk14/="... no checking if BUILD_CXX supports "-fmacro-prefix-map=/home/jiwon/jdk-related/jdk14/jdk14/="... no checking if both BUILD_CC and BUILD_CXX support "-fmacro-prefix-map=/home/jiwon/jdk-related/jdk14/jdk14/="... no checking if BUILD_CC supports "-ffp-contract=off"... yes checking if BUILD_CXX supports "-ffp-contract=off"... yes checking if both BUILD_CC and BUILD_CXX support "-ffp-contract=off"... yes checking what type of native debug symbols to use... external checking for dtrace tool... not found, cannot build dtrace checking sys/sdt.h usability... no checking sys/sdt.h presence... no checking for sys/sdt.h... no checking if dtrace should be built... no, missing dependencies checking if Hotspot gtest unit tests should be built... yes checking if static link of stdc++ is possible... yes checking how to link with libstdc++... static checking for X... libraries , headers /opt/sysroot/usr/include checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for X11/extensions/shape.h... yes checking for X11/extensions/Xrender.h... yes checking for X11/extensions/XTest.h... yes checking for X11/Intrinsic.h... yes checking for X11/extensions/Xrandr.h... yes checking if XlinearGradient is defined in Xrender.h... yes checking cups/cups.h usability... yes checking cups/cups.h presence... yes checking for cups/cups.h... yes checking cups/ppd.h usability... yes checking cups/ppd.h presence... yes checking for cups/ppd.h... yes checking fontconfig/fontconfig.h usability... yes checking fontconfig/fontconfig.h presence... yes checking for fontconfig/fontconfig.h... yes configure: Found freetype include files at /opt/sysroot/usr/include/freetype2 using well-known location configure: Could not find /opt/sysroot/usr/lib/libfreetype.so. Ignoring location. configure: Found freetype include files at /opt/sysroot/usr/include/freetype2 using well-known location checking for freetype includes... /opt/sysroot/usr/include/freetype2 checking for freetype libraries... /opt/sysroot/usr/lib/aarch64-linux-gnu Using freetype: system checking alsa/asoundlib.h usability... yes checking alsa/asoundlib.h presence... yes checking for alsa/asoundlib.h... yes checking for which libjpeg to use... bundled checking for which giflib to use... bundled checking for PNG... yes checking for which libpng to use... bundled checking for compress in -lz... yes checking for which zlib to use... system checking for system zlib functionality... ok checking for which lcms to use... bundled checking for cos in -lm... yes checking for dlopen in -ldl... yes checking if shenandoah can be built... yes checking if zgc can be built... yes checking if jvmci module jdk.internal.vm.ci should be built... yes checking if graal module jdk.internal.vm.compiler should be built... yes checking if aot should be enabled... yes checking if cds should be enabled... yes checking if elliptic curve crypto implementation is present... yes checking if jtreg failure handler should be built... no, missing jtreg checking if the CDS classlist generation should be enabled... yes checking if any translations should be excluded... no checking if static man pages should be copied... yes checking if a default CDS archive should be generated... no, not possible with cross compilation checking for number of cores... 8 checking for memory size... 32097 MB checking for appropriate number of jobs to run in parallel... 8 checking flags for boot jdk java command ... -Duser.language=en -Duser.country=US -XX:+UnlockDiagnosticVMOptions -XX:-VerifySharedSpaces -XX:SharedArchiveFile=/home/jiwon/jdk-related/jdk14/jdk14/build/linux-aarch64-server-release/configure-support/classes.jsa -Xshare:auto checking flags for boot jdk java command for big workloads... -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 checking flags for bootcycle boot jdk java command for big workloads... -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 checking flags for boot jdk java command for small workloads... -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 checking whether to use sjavac... no checking whether to use javac server... yes checking If precompiled header is enabled... yes checking that precompiled headers work... yes checking is ccache enabled... no checking if build directory is on local disk... yes checking JVM features for JVM variant 'server'... "aot cds compiler1 compiler2 epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs zgc" configure: creating /home/jiwon/jdk-related/jdk14/jdk14/build/linux-aarch64-server-release/configure-support/config.status config.status: creating /home/jiwon/jdk-related/jdk14/jdk14/build/linux-aarch64-server-release/spec.gmk config.status: creating /home/jiwon/jdk-related/jdk14/jdk14/build/linux-aarch64-server-release/bootcycle-spec.gmk config.status: creating /home/jiwon/jdk-related/jdk14/jdk14/build/linux-aarch64-server-release/buildjdk-spec.gmk config.status: creating /home/jiwon/jdk-related/jdk14/jdk14/build/linux-aarch64-server-release/compare.sh config.status: creating /home/jiwon/jdk-related/jdk14/jdk14/build/linux-aarch64-server-release/Makefile ==================================================== A new configuration has been successfully created in /home/jiwon/jdk-related/jdk14/jdk14/build/linux-aarch64-server-release using configure arguments '--openjdk-target=aarch64-linux-gnu --with-build-jdk=build/linux-x86_64-server-release/images/jdk --with-sysroot=/opt/sysroot --with-toolchain-path=/opt/sysroot'. Configuration summary: * Debug level: release * HS debug level: product * JVM variants: server * JVM features: server: 'aot cds compiler1 compiler2 epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs zgc' * OpenJDK target: OS: linux, CPU architecture: aarch64, address length: 64 * Version string: 14-internal+0-adhoc.jiwon.jdk14 (14-internal) Tools summary: * Boot JDK: openjdk version "13.0.2" 2020-01-14 OpenJDK Runtime Environment (build 13.0.2+8) OpenJDK 64-Bit Server VM (build 13.0.2+8, mixed mode, sharing) (at /usr/lib/jvm/jdk-13.0.2) * Toolchain: gcc (GNU Compiler Collection) * C Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-gcc) * C++ Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-g++) Build performance summary: * Cores to use: 8 * Memory limit: 32097 MB The following warnings were produced. Repeated here for convenience: WARNING: using cross tools not prefixed with host triplet Thanks, Jiwon From Roger.Riggs at oracle.com Tue Aug 25 20:09:16 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 25 Aug 2020 16:09:16 -0400 Subject: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package In-Reply-To: References: <3fc299f4-1c0a-1ccd-5d4c-3716775dfa38@oracle.com> <4bb3ded8-6b16-d2ad-a426-7b25c5d61a54@oracle.com> Message-ID: <4b07ca59-e778-3279-627b-d640d5fe86c4@oracle.com> Hi Erik, We're in a cleanup phase of the source before re-enabling disabled warnings. The warnings for "missing" comments are disabled: Docs.gmk: 106: JAVADOC_DISABLED_DOCLINT := accessibility html missing syntax reference Roger On 8/25/20 3:39 PM, Erik Joelsson wrote: > > On 2020-08-25 12:21, Roger Riggs wrote: >> Hi Erik, >> >> org.w3c is in third party code that is not being updated. There is a >> balance between >> ignoring the warnings and doing a bunch of editing that would >> overwritten by a future update. >> > Yes, I get that part, but why are those warnings not triggered today? > I don't see any change enabling more warnings from the build. > > /Erik > >> $.02, Roger >> >> >> On 8/25/20 2:58 PM, Erik Joelsson wrote: >>> Build change looks ok, but why is it needed? You are fixing a bunch >>> of warnings in one part of the source and disabling them in another >>> part. Is there some other change incoming that will enable more >>> warning categories by default? >>> >>> /Erik >>> >>> On 2020-08-25 11:47, Joe Wang wrote: >>>> Cc-ing build-dev at openjdk.java.net (makefile change: make/Docs.gmk) >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ >>>> >>>> Thanks Roger! Please see inline comments. >>>> >>>> On 8/25/20 8:09 AM, Roger Riggs wrote: >>>>> Hi Joe, >>>>> >>>>> Eliminating the checking for warnings in org.w3c is fine. Please >>>>> be more specific in the comment. >>>>> >>>>> "Ignore the doclint warnings in the W3C DOM package" >>>> >>>> Updated. >>>>> org/xml/...: If we're suppressing the warnings for org/xml/... >>>>> then the files changes are unnecessary? >>>> >>>> Did you mean org/w3c? We're only suppressing the warnings for >>>> org/w3c where the DOM package is in, but not org/xml where SAX is in. >>>> >>>>> >>>>> Remove the addition of -Xmaxwarns, it should stay the default. >>>> >>>> Done. >>>>> >>>>> Since its a makefile change, please copy build-dev at openjdk.java.net. >>>> >>>> Cc-ed >>>>> >>>>> The first line comments should terminate with a period ".". >>>>> >>>>> javax/xml/stream/FactoryConfigurationError.java:40 >>>>> javax/xml/stream/XMLStreamException.java:41 >>>>> javax/xml/xpath/XPathException.java:44? And capitable "Serializable". >>>>> >>>>> >>>>> javax/xml/stream/events/Attribute.java: 50; add "normalized" to >>>>> the @return line so it is the same as the first line. >>>>> For simple get methods, the @return mimics the first line. >>>>> >>>>> javax/xml/stream/events/NotationDeclaration.java:43? add "notation" >>>> >>>> Updated webrev including all of the above: >>>> >>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ >>>> >>>>> >>>>> >>>>> >>>>> Thanks, Roger >>>>> >>>>> p.s.? There is lots of other cleanup of the javadoc, using @code >>>>> around true, false, >>>>> missing periods at the end of first sentences, etc.? But that's a >>>>> different task. >>>> >>>> Created a bug to keep track of this: >>>> https://bugs.openjdk.java.net/browse/JDK-8252328 >>>> >>>> Thanks, >>>> Joe >>>>> >>>>> >>>>> >>>>> On 8/24/20 5:44 PM, Joe Wang wrote: >>>>>> Hi all,? adding Roger's comment for the make file to webrev_02 >>>>>> (the only change to webrev_01 is Docs.gmk): >>>>>> >>>>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ >>>>>> >>>>>> Thanks, >>>>>> Joe >>>>>> >>>>>> On 8/21/20 12:49 PM, naoto.sato at oracle.com wrote: >>>>>>> +1 >>>>>>> >>>>>>> Naoto >>>>>>> >>>>>>> On 8/21/20 12:24 PM, Lance Andersen wrote: >>>>>>>> Hi Joe, >>>>>>>> >>>>>>>> This looks OK. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Aug 21, 2020, at 2:23 PM, Joe Wang >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Pelase review a patch to add the missing @return, @throws, >>>>>>>>> @param statements in the java.xml package (excluding the DOM >>>>>>>>> component). >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 >>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Joe >>>>>>>> >>>>>>>> >>>>>>>> Best >>>>>>>> Lance >>>>>>>> ------------------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Lance Andersen| Principal Member of Technical Staff | >>>>>>>> +1.781.442.2037 >>>>>>>> Oracle Java Engineering >>>>>>>> 1 Network Drive >>>>>>>> Burlington, MA 01803 >>>>>>>> Lance.Andersen at oracle.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> From huizhe.wang at oracle.com Tue Aug 25 20:20:02 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 25 Aug 2020 13:20:02 -0700 Subject: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package In-Reply-To: References: <3fc299f4-1c0a-1ccd-5d4c-3716775dfa38@oracle.com> <4bb3ded8-6b16-d2ad-a426-7b25c5d61a54@oracle.com> Message-ID: Hi Erik, We're acting on a report Jon generated separately. The warnings checks are currently disabled (see line 106 JAVADOC_DISABLED_DOCLINT := accessibility html missing syntax reference). -Joe On 8/25/20 12:39 PM, Erik Joelsson wrote: > > On 2020-08-25 12:21, Roger Riggs wrote: >> Hi Erik, >> >> org.w3c is in third party code that is not being updated. There is a >> balance between >> ignoring the warnings and doing a bunch of editing that would >> overwritten by a future update. >> > Yes, I get that part, but why are those warnings not triggered today? > I don't see any change enabling more warnings from the build. > > /Erik > >> $.02, Roger >> >> >> On 8/25/20 2:58 PM, Erik Joelsson wrote: >>> Build change looks ok, but why is it needed? You are fixing a bunch >>> of warnings in one part of the source and disabling them in another >>> part. Is there some other change incoming that will enable more >>> warning categories by default? >>> >>> /Erik >>> >>> On 2020-08-25 11:47, Joe Wang wrote: >>>> Cc-ing build-dev at openjdk.java.net (makefile change: make/Docs.gmk) >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ >>>> >>>> Thanks Roger! Please see inline comments. >>>> >>>> On 8/25/20 8:09 AM, Roger Riggs wrote: >>>>> Hi Joe, >>>>> >>>>> Eliminating the checking for warnings in org.w3c is fine. Please >>>>> be more specific in the comment. >>>>> >>>>> "Ignore the doclint warnings in the W3C DOM package" >>>> >>>> Updated. >>>>> org/xml/...: If we're suppressing the warnings for org/xml/... >>>>> then the files changes are unnecessary? >>>> >>>> Did you mean org/w3c? We're only suppressing the warnings for >>>> org/w3c where the DOM package is in, but not org/xml where SAX is in. >>>> >>>>> >>>>> Remove the addition of -Xmaxwarns, it should stay the default. >>>> >>>> Done. >>>>> >>>>> Since its a makefile change, please copy build-dev at openjdk.java.net. >>>> >>>> Cc-ed >>>>> >>>>> The first line comments should terminate with a period ".". >>>>> >>>>> javax/xml/stream/FactoryConfigurationError.java:40 >>>>> javax/xml/stream/XMLStreamException.java:41 >>>>> javax/xml/xpath/XPathException.java:44? And capitable "Serializable". >>>>> >>>>> >>>>> javax/xml/stream/events/Attribute.java: 50; add "normalized" to >>>>> the @return line so it is the same as the first line. >>>>> For simple get methods, the @return mimics the first line. >>>>> >>>>> javax/xml/stream/events/NotationDeclaration.java:43? add "notation" >>>> >>>> Updated webrev including all of the above: >>>> >>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ >>>> >>>>> >>>>> >>>>> >>>>> Thanks, Roger >>>>> >>>>> p.s.? There is lots of other cleanup of the javadoc, using @code >>>>> around true, false, >>>>> missing periods at the end of first sentences, etc.? But that's a >>>>> different task. >>>> >>>> Created a bug to keep track of this: >>>> https://bugs.openjdk.java.net/browse/JDK-8252328 >>>> >>>> Thanks, >>>> Joe >>>>> >>>>> >>>>> >>>>> On 8/24/20 5:44 PM, Joe Wang wrote: >>>>>> Hi all,? adding Roger's comment for the make file to webrev_02 >>>>>> (the only change to webrev_01 is Docs.gmk): >>>>>> >>>>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ >>>>>> >>>>>> Thanks, >>>>>> Joe >>>>>> >>>>>> On 8/21/20 12:49 PM, naoto.sato at oracle.com wrote: >>>>>>> +1 >>>>>>> >>>>>>> Naoto >>>>>>> >>>>>>> On 8/21/20 12:24 PM, Lance Andersen wrote: >>>>>>>> Hi Joe, >>>>>>>> >>>>>>>> This looks OK. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Aug 21, 2020, at 2:23 PM, Joe Wang >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Pelase review a patch to add the missing @return, @throws, >>>>>>>>> @param statements in the java.xml package (excluding the DOM >>>>>>>>> component). >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 >>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Joe >>>>>>>> >>>>>>>> >>>>>>>> Best >>>>>>>> Lance >>>>>>>> ------------------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Lance Andersen| Principal Member of Technical Staff | >>>>>>>> +1.781.442.2037 >>>>>>>> Oracle Java Engineering >>>>>>>> 1 Network Drive >>>>>>>> Burlington, MA 01803 >>>>>>>> Lance.Andersen at oracle.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> From glaubitz at physik.fu-berlin.de Tue Aug 25 20:27:38 2020 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 25 Aug 2020 22:27:38 +0200 Subject: JDK14 cross-compile to arm64 fails to locate c++ header new In-Reply-To: References: Message-ID: <4a120628-72b5-82af-6656-10e950437be6@physik.fu-berlin.de> Hi Jiwon! On 8/25/20 10:06 PM, Choe, Jiwon wrote: > === Output from failing command(s) repeated here === > * For target > hotspot_variant-server_libjvm_gtest_objs_precompiled_precompiled.hpp.gch: > In file included from > /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/classfile/classLoaderData.hpp:28:0, > from > /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/precompiled/precompiled.hpp:34: > /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/memory/allocation.hpp:31:15: > fatal error: new: No such file or directory > #include Do you have "build-essential" installed on the host system, assuming it's Debian-based? > Tools summary: > * Boot JDK: openjdk version "13.0.2" 2020-01-14 OpenJDK Runtime > Environment (build 13.0.2+8) OpenJDK 64-Bit Server VM (build 13.0.2+8, > mixed mode, sharing) (at /usr/lib/jvm/jdk-13.0.2) > * Toolchain: gcc (GNU Compiler Collection) > * C Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-gcc) > * C++ Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-g++) That version of GCC looks a bit old. I'm not sure whether it's recent enough for OpenJDK 14. FWIW, I'm using a different approach for cross-building OpenJDK which works particularly easy on Debian and Ubuntu due to Multi-Arch support which allows co-installing library packages for different architectures on one system. I have documented it here: https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From erik.joelsson at oracle.com Tue Aug 25 21:49:40 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 25 Aug 2020 14:49:40 -0700 Subject: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package In-Reply-To: References: <3fc299f4-1c0a-1ccd-5d4c-3716775dfa38@oracle.com> <4bb3ded8-6b16-d2ad-a426-7b25c5d61a54@oracle.com> Message-ID: <9c0ca5fa-8edb-5d2e-7544-563fff860aa6@oracle.com> Ah, I was looking for that kind of information in the bug report, but couldn't find any. /Erik On 2020-08-25 13:20, Joe Wang wrote: > Hi Erik, > > We're acting on a report Jon generated separately. The warnings checks > are currently disabled (see line 106 JAVADOC_DISABLED_DOCLINT := > accessibility html missing syntax reference). > > -Joe > > On 8/25/20 12:39 PM, Erik Joelsson wrote: >> >> On 2020-08-25 12:21, Roger Riggs wrote: >>> Hi Erik, >>> >>> org.w3c is in third party code that is not being updated. There is a >>> balance between >>> ignoring the warnings and doing a bunch of editing that would >>> overwritten by a future update. >>> >> Yes, I get that part, but why are those warnings not triggered today? >> I don't see any change enabling more warnings from the build. >> >> /Erik >> >>> $.02, Roger >>> >>> >>> On 8/25/20 2:58 PM, Erik Joelsson wrote: >>>> Build change looks ok, but why is it needed? You are fixing a bunch >>>> of warnings in one part of the source and disabling them in another >>>> part. Is there some other change incoming that will enable more >>>> warning categories by default? >>>> >>>> /Erik >>>> >>>> On 2020-08-25 11:47, Joe Wang wrote: >>>>> Cc-ing build-dev at openjdk.java.net (makefile change: make/Docs.gmk) >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ >>>>> >>>>> Thanks Roger! Please see inline comments. >>>>> >>>>> On 8/25/20 8:09 AM, Roger Riggs wrote: >>>>>> Hi Joe, >>>>>> >>>>>> Eliminating the checking for warnings in org.w3c is fine. Please >>>>>> be more specific in the comment. >>>>>> >>>>>> "Ignore the doclint warnings in the W3C DOM package" >>>>> >>>>> Updated. >>>>>> org/xml/...: If we're suppressing the warnings for org/xml/... >>>>>> then the files changes are unnecessary? >>>>> >>>>> Did you mean org/w3c? We're only suppressing the warnings for >>>>> org/w3c where the DOM package is in, but not org/xml where SAX is in. >>>>> >>>>>> >>>>>> Remove the addition of -Xmaxwarns, it should stay the default. >>>>> >>>>> Done. >>>>>> >>>>>> Since its a makefile change, please copy build-dev at openjdk.java.net. >>>>> >>>>> Cc-ed >>>>>> >>>>>> The first line comments should terminate with a period ".". >>>>>> >>>>>> javax/xml/stream/FactoryConfigurationError.java:40 >>>>>> javax/xml/stream/XMLStreamException.java:41 >>>>>> javax/xml/xpath/XPathException.java:44? And capitable >>>>>> "Serializable". >>>>>> >>>>>> >>>>>> javax/xml/stream/events/Attribute.java: 50; add "normalized" to >>>>>> the @return line so it is the same as the first line. >>>>>> For simple get methods, the @return mimics the first line. >>>>>> >>>>>> javax/xml/stream/events/NotationDeclaration.java:43? add "notation" >>>>> >>>>> Updated webrev including all of the above: >>>>> >>>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ >>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, Roger >>>>>> >>>>>> p.s.? There is lots of other cleanup of the javadoc, using @code >>>>>> around true, false, >>>>>> missing periods at the end of first sentences, etc.? But that's a >>>>>> different task. >>>>> >>>>> Created a bug to keep track of this: >>>>> https://bugs.openjdk.java.net/browse/JDK-8252328 >>>>> >>>>> Thanks, >>>>> Joe >>>>>> >>>>>> >>>>>> >>>>>> On 8/24/20 5:44 PM, Joe Wang wrote: >>>>>>> Hi all,? adding Roger's comment for the make file to webrev_02 >>>>>>> (the only change to webrev_01 is Docs.gmk): >>>>>>> >>>>>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_02/ >>>>>>> >>>>>>> Thanks, >>>>>>> Joe >>>>>>> >>>>>>> On 8/21/20 12:49 PM, naoto.sato at oracle.com wrote: >>>>>>>> +1 >>>>>>>> >>>>>>>> Naoto >>>>>>>> >>>>>>>> On 8/21/20 12:24 PM, Lance Andersen wrote: >>>>>>>>> Hi Joe, >>>>>>>>> >>>>>>>>> This looks OK. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Aug 21, 2020, at 2:23 PM, Joe Wang >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Pelase review a patch to add the missing @return, @throws, >>>>>>>>>> @param statements in the java.xml package (excluding the DOM >>>>>>>>>> component). >>>>>>>>>> >>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8251561 >>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8251995 >>>>>>>>>> >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_01/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Joe >>>>>>>>> >>>>>>>>> >>>>>>>>> Best >>>>>>>>> Lance >>>>>>>>> ------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Lance Andersen| Principal Member of Technical Staff | >>>>>>>>> +1.781.442.2037 >>>>>>>>> Oracle Java Engineering >>>>>>>>> 1 Network Drive >>>>>>>>> Burlington, MA 01803 >>>>>>>>> Lance.Andersen at oracle.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From philip.race at oracle.com Tue Aug 25 22:40:24 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 25 Aug 2020 15:40:24 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU In-Reply-To: <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com> References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> <5F442494.8050108@oracle.com> <4f703a37-a42f-2641-f198-d77845387d41@oracle.com> <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com> Message-ID: <5F459358.7070802@oracle.com> On 8/25/20, 12:27 PM, Sergey Bylokhov wrote: > On 25.08.2020 05:43, Kevin Rushforth wrote: >> Does this only apply when the MacBook is running on battery, or will >> this affect performance even when the laptop is plugged in? If the >> latter, I wonder what Apple's rationale is for including a discrete >> graphics card that isn't used most of the time. Based on the numbers, I wonder if we should make this change ? > > It is applied if the "automatic graphics switching" is enabled, if the > user disables > this feature for the "power adapter" mode, then the discrete graphics > will be always used. That's a bit misleading If I disable automatic graphics switching it is disabled for BOTH batter and power and vice versa. In other words there is no way to express that battery power should fall back to integrated and that you only want discrete when running on the adapter. -phil > > I guess by default they try to "maximize battery life": > https://support.apple.com/en-us/HT202043 > >> >> -- Kevin >> >> >> On 8/24/2020 11:27 PM, Sergey Bylokhov wrote: >>> On 24.08.2020 13:35, Philip Race wrote: >>>> >>>> Is there any performance cost to doing this ? I'd expect so. Any >>>> estimate ? >>> >>> Yes, performance is affected for sure: >>> >>> - SwingMark: >>> OGL_Base: 14000 >>> OGL_Fix: 24000 >>> Metal: 18000 >>> >>> - Here is a j2dbench for the common draw operations(new/old/metal): >>> http://cr.openjdk.java.net/~serb/8251854/perf/results.txt >>> >>> Summary: >>> OGL_base: >>> Number of tests: 24 >>> Overall average: 4.556306150323041E8 >>> Best spread: 0.16% variance >>> Worst spread: 4.68% variance >>> (Basis for results comparison) >>> >>> OGL_fix: >>> Number of tests: 24 >>> Overall average: 1.0086929824044746E8 >>> Best spread: 0.04% variance >>> Worst spread: 7.89% variance >>> Comparison to basis: >>> Best result: 83.41% of basis >>> Worst result: 15.73% of basis >>> Number of wins: 0 >>> Number of ties: 0 >>> Number of losses: 24 >>> >>> metal: >>> Number of tests: 24 >>> Overall average: 8.841681616575797E7 >>> Best spread: 0.08% variance >>> Worst spread: 5.64% variance >>> Comparison to basis: >>> Best result: 248.11% of basis >>> Worst result: 19.1% of basis >>> Number of wins: 8 >>> Number of ties: 2 >>> Number of losses: 14 >>> ========================================== >>> >>> - Here is a j2dbench for the common draw operations(newOGL vs metal >>> only): >>> http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt >>> Summary: >>> OGL_fix: >>> Number of tests: 24 >>> Overall average: 2.5871177969681844E7 >>> Best spread: 0.04% variance >>> Worst spread: 7.01% variance >>> (Basis for results comparison) >>> >>> metal: >>> Number of tests: 24 >>> Overall average: 2.1896134898150157E7 >>> Best spread: 0.04% variance >>> Worst spread: 1.98% variance >>> Comparison to basis: >>> Best result: 488.31% of basis >>> Worst result: 30.77% of basis >>> Number of wins: 14 >>> Number of ties: 0 >>> Number of losses: 10 >>> >>>> And there's then no way to explicitly request the discrete card on >>>> a 15/16" MBP. >>> >>> I have checked that the discrete card is enabled by the macOS: >>> - if the full screen window is set >>> - if the second monitor is connected >>> Do not know any other ways to enable it. >>> >>> >>>> Should we release note this ? >>> >>> Yes, I think so. >>> Note that it does not affect the bundled applications only apps >>> running via java launcher. >>> But some(most?) bundled java applications use this flag already. >>> >>> >> > > From Sergey.Bylokhov at oracle.com Tue Aug 25 23:01:35 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 25 Aug 2020 16:01:35 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU In-Reply-To: <5F459358.7070802@oracle.com> References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> <5F442494.8050108@oracle.com> <4f703a37-a42f-2641-f198-d77845387d41@oracle.com> <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com> <5F459358.7070802@oracle.com> Message-ID: <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com> On 25.08.2020 15:40, Philip Race wrote: > On 8/25/20, 12:27 PM, Sergey Bylokhov wrote: >> On 25.08.2020 05:43, Kevin Rushforth wrote: >>> Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time. > > Based on the numbers, I wonder if we should make this change ? This is how other applications work, some numbers are now aligned to the metal pipeline. Also results are similar to other macbooks without discrete graphics. >> It is applied if the "automatic graphics switching" is enabled, if the user disables >> this feature for the "power adapter" mode, then the discrete graphics will be always used. > > That's a bit misleading > If I disable automatic graphics switching it is disabled for BOTH batter and power > and vice versa. In other words there is no way to express that battery power should fall back > to integrated and that you only want discrete when running on the adapter. It is possible to do it manually, in the "power adapter" mode the user can disable "automatic graphics switching", and enable it in the "battery" mode. BTW I have never did it myself. -- Best regards, Sergey. From kevin.rushforth at oracle.com Tue Aug 25 23:08:41 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 25 Aug 2020 16:08:41 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU In-Reply-To: <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com> References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> <5F442494.8050108@oracle.com> <4f703a37-a42f-2641-f198-d77845387d41@oracle.com> <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com> <5F459358.7070802@oracle.com> <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com> Message-ID: <65cc1055-2695-c71d-f6ce-1d4d790173ad@oracle.com> > This is how other applications work... > ?Also results are similar to other macbooks without discrete graphics. That's sort of what I was getting at with my earlier question: why have a discrete graphics card that never / seldom gets used? This may be more of a question for Apple, but it seems quite strange to me. If it switched automatically based on whether or not you were on battery, or some user setting that favored lower power usages over increased performance, then it would make sense. As it is, I'm having a hard time understanding the motivation. I haven't tested an FX app yet, but since this changes the plist properties, I want to see whether or not FX apps are impacted. -- Kevin On 8/25/2020 4:01 PM, Sergey Bylokhov wrote: > On 25.08.2020 15:40, Philip Race wrote: >> On 8/25/20, 12:27 PM, Sergey Bylokhov wrote: >>> On 25.08.2020 05:43, Kevin Rushforth wrote: >>>> Does this only apply when the MacBook is running on battery, or >>>> will this affect performance even when the laptop is plugged in? If >>>> the latter, I wonder what Apple's rationale is for including a >>>> discrete graphics card that isn't used most of the time. >> >> Based on the numbers, I wonder if we should make this change ? > > This is how other applications work, some numbers are now aligned to > the metal pipeline. > Also results are similar to other macbooks without discrete graphics. > >>> It is applied if the "automatic graphics switching" is enabled, if >>> the user disables >>> this feature for the "power adapter" mode, then the discrete >>> graphics will be always used. >> >> That's a bit misleading >> If I disable automatic graphics switching it is disabled for BOTH >> batter and power >> and vice versa. In other words there is no way to express that >> battery power should fall back >> to integrated and that you only want discrete when running on the >> adapter. > > It is possible to do it manually, in the "power adapter" mode the user > can disable > "automatic graphics switching", and enable it in the "battery" mode. > > BTW I have never did it myself. > From Sergey.Bylokhov at oracle.com Tue Aug 25 23:17:55 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 25 Aug 2020 16:17:55 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU In-Reply-To: <65cc1055-2695-c71d-f6ce-1d4d790173ad@oracle.com> References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> <5F442494.8050108@oracle.com> <4f703a37-a42f-2641-f198-d77845387d41@oracle.com> <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com> <5F459358.7070802@oracle.com> <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com> <65cc1055-2695-c71d-f6ce-1d4d790173ad@oracle.com> Message-ID: <37a7c0b2-adf5-edee-aab7-3e4312b19175@oracle.com> On 25.08.2020 16:08, Kevin Rushforth wrote: > I haven't tested an FX app yet, but since this changes the plist properties, I want to see whether or not FX apps are impacted. It should be affected because the first variation of the fix was pushed to the FX(if nothing changed since then): https://bugs.openjdk.java.net/browse/JDK-8132775 Since FX does not have the launcher it depends on the "bin/java" or the packed application. > > -- Kevin > > > On 8/25/2020 4:01 PM, Sergey Bylokhov wrote: >> On 25.08.2020 15:40, Philip Race wrote: >>> On 8/25/20, 12:27 PM, Sergey Bylokhov wrote: >>>> On 25.08.2020 05:43, Kevin Rushforth wrote: >>>>> Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time. >>> >>> Based on the numbers, I wonder if we should make this change ? >> >> This is how other applications work, some numbers are now aligned to the metal pipeline. >> Also results are similar to other macbooks without discrete graphics. >> >>>> It is applied if the "automatic graphics switching" is enabled, if the user disables >>>> this feature for the "power adapter" mode, then the discrete graphics will be always used. >>> >>> That's a bit misleading >>> If I disable automatic graphics switching it is disabled for BOTH batter and power >>> and vice versa. In other words there is no way to express that battery power should fall back >>> to integrated and that you only want discrete when running on the adapter. >> >> It is possible to do it manually, in the "power adapter" mode the user can disable >> "automatic graphics switching", and enable it in the "battery" mode. >> >> BTW I have never did it myself. >> > -- Best regards, Sergey. From kevin.rushforth at oracle.com Tue Aug 25 23:22:08 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 25 Aug 2020 16:22:08 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU In-Reply-To: <37a7c0b2-adf5-edee-aab7-3e4312b19175@oracle.com> References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> <5F442494.8050108@oracle.com> <4f703a37-a42f-2641-f198-d77845387d41@oracle.com> <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com> <5F459358.7070802@oracle.com> <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com> <65cc1055-2695-c71d-f6ce-1d4d790173ad@oracle.com> <37a7c0b2-adf5-edee-aab7-3e4312b19175@oracle.com> Message-ID: On 8/25/2020 4:17 PM, Sergey Bylokhov wrote: > On 25.08.2020 16:08, Kevin Rushforth wrote: >> I haven't tested an FX app yet, but since this changes the plist >> properties, I want to see whether or not FX apps are impacted. > > It should be affected because the first variation of the fix was > pushed to the FX(if nothing changed since then): > https://bugs.openjdk.java.net/browse/JDK-8132775 > > Since FX does not have the launcher it depends on the "bin/java" or > the packed application. Yes, this is what I remember as well back when we were testing the bug. My recollection is that we only wanted to avoid using the discrete CPU when running on battery, although it's been a while since we first looked at this. -- Kevin > >> >> -- Kevin >> >> >> On 8/25/2020 4:01 PM, Sergey Bylokhov wrote: >>> On 25.08.2020 15:40, Philip Race wrote: >>>> On 8/25/20, 12:27 PM, Sergey Bylokhov wrote: >>>>> On 25.08.2020 05:43, Kevin Rushforth wrote: >>>>>> Does this only apply when the MacBook is running on battery, or >>>>>> will this affect performance even when the laptop is plugged in? >>>>>> If the latter, I wonder what Apple's rationale is for including a >>>>>> discrete graphics card that isn't used most of the time. >>>> >>>> Based on the numbers, I wonder if we should make this change ? >>> >>> This is how other applications work, some numbers are now aligned to >>> the metal pipeline. >>> Also results are similar to other macbooks without discrete graphics. >>> >>>>> It is applied if the "automatic graphics switching" is enabled, if >>>>> the user disables >>>>> this feature for the "power adapter" mode, then the discrete >>>>> graphics will be always used. >>>> >>>> That's a bit misleading >>>> If I disable automatic graphics switching it is disabled for BOTH >>>> batter and power >>>> and vice versa. In other words there is no way to express that >>>> battery power should fall back >>>> to integrated and that you only want discrete when running on the >>>> adapter. >>> >>> It is possible to do it manually, in the "power adapter" mode the >>> user can disable >>> "automatic graphics switching", and enable it in the "battery" mode. >>> >>> BTW I have never did it myself. >>> >> > > From philip.race at oracle.com Tue Aug 25 23:25:53 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 25 Aug 2020 16:25:53 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU In-Reply-To: <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com> References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> <5F442494.8050108@oracle.com> <4f703a37-a42f-2641-f198-d77845387d41@oracle.com> <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com> <5F459358.7070802@oracle.com> <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com> Message-ID: <5F459E01.3070206@oracle.com> On 8/25/20, 4:01 PM, Sergey Bylokhov wrote: > >>> It is applied if the "automatic graphics switching" is enabled, if >>> the user disables >>> this feature for the "power adapter" mode, then the discrete >>> graphics will be always used. >> >> That's a bit misleading >> If I disable automatic graphics switching it is disabled for BOTH >> batter and power >> and vice versa. In other words there is no way to express that >> battery power should fall back >> to integrated and that you only want discrete when running on the >> adapter. > > It is possible to do it manually, in the "power adapter" mode the user > can disable > "automatic graphics switching", and enable it in the "battery" mode. What do you mean by "manually" ? -phil. From Sergey.Bylokhov at oracle.com Tue Aug 25 23:27:22 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 25 Aug 2020 16:27:22 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU In-Reply-To: <5F459E01.3070206@oracle.com> References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com> <5F442494.8050108@oracle.com> <4f703a37-a42f-2641-f198-d77845387d41@oracle.com> <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com> <5F459358.7070802@oracle.com> <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com> <5F459E01.3070206@oracle.com> Message-ID: <147a47a8-4127-1e50-e3c9-21214adc5914@oracle.com> On 25.08.2020 16:25, Philip Race wrote: > > > On 8/25/20, 4:01 PM, Sergey Bylokhov wrote: >> >>>> It is applied if the "automatic graphics switching" is enabled, if the user disables >>>> this feature for the "power adapter" mode, then the discrete graphics will be always used. >>> >>> That's a bit misleading >>> If I disable automatic graphics switching it is disabled for BOTH batter and power >>> and vice versa. In other words there is no way to express that battery power should fall back >>> to integrated and that you only want discrete when running on the adapter. >> >> It is possible to do it manually, in the "power adapter" mode the user can disable >> "automatic graphics switching", and enable it in the "battery" mode. > > What do you mean by "manually" ? Open the preferences and enable/disable the switching then needed. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 25 23:35:17 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 25 Aug 2020 16:35:17 -0700 Subject: RFR: JDK-8252145: Unify Info.plist files with correct version strings In-Reply-To: <38f8299d-9079-da0a-cdd1-bec67a2822d5@oracle.com> References: <77725336-71e6-b09c-7ede-50a9e429498b@oracle.com> <38f8299d-9079-da0a-cdd1-bec67a2822d5@oracle.com> Message-ID: <13d86a7e-76f5-35c4-b280-f68926b61044@oracle.com> Looks fine. On 25.08.2020 07:27, Erik Joelsson wrote: > > On 2020-08-24 19:18, Sergey Bylokhov wrote: >> Hi, Erik. >> >> I would like to highlight one thing affected by this fix. The text in the default about dialog in the Swing application will be changed. >> >> For my local build: >> ?- Current text: "Java Version 1.0 (16)" >> ?- After the fix: "Java Version 16 (0)" >> >> I am not sure why the build version and as a result the CFBundleVersion is zero? >> > The CFBundleVersion is supposed to have a version number representing the build number. In a developer build, the "VERSION_BUILD" variable is default 0. In a promoted build, that number is set to the promoted build number. In Oracle promoted builds, we will also have a CI build number, so if this change was in effect, the latest JDK 16 promoted build would have 12.477 in CFBundleVersion. > > /Erik > >> On 24.08.2020 08:19, Erik Joelsson wrote: >>> When fixing JDK-8246094, I concluded that our Info.plist files are in a bit of a mess. This patch tries to address this on a more fundamental level. >>> >>> 1. All Info.plist files and templates are moved to the same location in the source tree. >>> >>> 2. The CFBundleIdentifier is changed to no longer contain the version number. Instead it gets the $VERSION_PRE string if present. >>> >>> 3. The CFBundleShortVersionString is changed to the numeric version part of our version string. >>> >>> 4. The CFBundleVersion is changed to the build number (or a custom number if supplied through a new configure argument). For Oracle builds, this will take the form of .. >>> >>> For more details on why this particular scheme, see bug description, but in short, this is what I think best reflects what the Apple documentation says the fields are for. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8252145 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01 >>> >>> /Erik >>> >> >> -- Best regards, Sergey. From jiwon_choe at brown.edu Wed Aug 26 02:46:52 2020 From: jiwon_choe at brown.edu (Choe, Jiwon) Date: Tue, 25 Aug 2020 22:46:52 -0400 Subject: JDK14 cross-compile to arm64 fails to locate c++ header new In-Reply-To: <4a120628-72b5-82af-6656-10e950437be6@physik.fu-berlin.de> References: <4a120628-72b5-82af-6656-10e950437be6@physik.fu-berlin.de> Message-ID: Hi Adrian, Thanks for the quick reply. Yes, I do have build-essential installed on the host system. I have cross-compiled jdk14 from a 32-bit x86 system to target aarch32-linux-gnueabihf before, with the same version gcc and g++. Could this still be the issue though? Thanks again, Jiwon On Tue, Aug 25, 2020 at 4:27 PM John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Hi Jiwon! > > On 8/25/20 10:06 PM, Choe, Jiwon wrote: > > === Output from failing command(s) repeated here === > > * For target > > hotspot_variant-server_libjvm_gtest_objs_precompiled_precompiled.hpp.gch: > > In file included from > > > /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/classfile/classLoaderData.hpp:28:0, > > from > > > /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/precompiled/precompiled.hpp:34: > > > /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/memory/allocation.hpp:31:15: > > fatal error: new: No such file or directory > > #include > > Do you have "build-essential" installed on the host system, assuming it's > Debian-based? > > > Tools summary: > > * Boot JDK: openjdk version "13.0.2" 2020-01-14 OpenJDK Runtime > > Environment (build 13.0.2+8) OpenJDK 64-Bit Server VM (build 13.0.2+8, > > mixed mode, sharing) (at /usr/lib/jvm/jdk-13.0.2) > > * Toolchain: gcc (GNU Compiler Collection) > > * C Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-gcc) > > * C++ Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-g++) > > That version of GCC looks a bit old. I'm not sure whether it's recent > enough for > OpenJDK 14. > > FWIW, I'm using a different approach for cross-building OpenJDK which > works particularly > easy on Debian and Ubuntu due to Multi-Arch support which allows > co-installing library > packages for different architectures on one system. > > I have documented it here: > https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From christoph.goettschkes at microdoc.com Wed Aug 26 09:29:54 2020 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Wed, 26 Aug 2020 11:29:54 +0200 Subject: [ping] [11u] RFR 8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC In-Reply-To: <32d6e87j9y-1@aserp2040.oracle.com> References: <32d6e87j9y-1@aserp2040.oracle.com> Message-ID: <335jfxhxk4-1@aserp2050.oracle.com> Hi, the webrev below still applies cleanly to jdk11u-dev. Could someone please review this downport? Thanks, Christoph On 2020-07-20 15:48, Christoph G?ttschkes wrote: > Hi, > > please review this downport of JDK-8234535 to jdk11u-dev. > > The changeset does not apply cleanly because of unrelated differences in > the flags-cflags.m4 file surrounding the patch. Manually applying the > patch was trivial. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8234535 > Commit: https://hg.openjdk.java.net/jdk/jdk/rev/eef0bf57357c > Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev-11u.00/ > > Thanks, > Christoph > From sgehwolf at redhat.com Wed Aug 26 10:10:14 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 26 Aug 2020 12:10:14 +0200 Subject: [ping] [11u] RFR 8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC In-Reply-To: <333phg5kt6-1@userp2020.oracle.com> References: <32d6e87j9y-1@aserp2040.oracle.com> <333phg5kt6-1@userp2020.oracle.com> Message-ID: <4f70b51731937ba872035a01621ec11f39cea626.camel@redhat.com> On Wed, 2020-08-26 at 11:29 +0200, Christoph G?ttschkes wrote: > > Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev-11u.00/ This looks fine to me. Thanks, Severin From christoph.goettschkes at microdoc.com Wed Aug 26 11:08:04 2020 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Wed, 26 Aug 2020 13:08:04 +0200 Subject: [ping] [11u] RFR 8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC In-Reply-To: <4f70b51731937ba872035a01621ec11f39cea626.camel@redhat.com> References: <32d6e87j9y-1@aserp2040.oracle.com> <333phg5kt6-1@userp2020.oracle.com> <4f70b51731937ba872035a01621ec11f39cea626.camel@redhat.com> Message-ID: <333pss6xmt-1@aserp2030.oracle.com> Thank you for the quick review, Severin. -- Christoph On 2020-08-26 12:10, Severin Gehwolf wrote: > On Wed, 2020-08-26 at 11:29 +0200, Christoph G?ttschkes wrote: >>> Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev-11u.00/ > > This looks fine to me. > > Thanks, > Severin > From erik.joelsson at oracle.com Wed Aug 26 12:59:25 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 26 Aug 2020 05:59:25 -0700 Subject: JDK14 cross-compile to arm64 fails to locate c++ header new In-Reply-To: References: <4a120628-72b5-82af-6656-10e950437be6@physik.fu-berlin.de> Message-ID: <6809515a-34aa-37fb-e256-ff6937cc50ea@oracle.com> I'm not familiar with this tool for creating sysroot, but perhaps you need to add the libstdc++ dev package to get access to C++ headers? /Erik On 2020-08-25 19:46, Choe, Jiwon wrote: > Hi Adrian, > > Thanks for the quick reply. Yes, I do have build-essential installed on the > host system. > I have cross-compiled jdk14 from a 32-bit x86 system to target > aarch32-linux-gnueabihf before, with the same version gcc and g++. Could > this still be the issue though? > > Thanks again, > Jiwon > > On Tue, Aug 25, 2020 at 4:27 PM John Paul Adrian Glaubitz < > glaubitz at physik.fu-berlin.de> wrote: > >> Hi Jiwon! >> >> On 8/25/20 10:06 PM, Choe, Jiwon wrote: >>> === Output from failing command(s) repeated here === >>> * For target >>> hotspot_variant-server_libjvm_gtest_objs_precompiled_precompiled.hpp.gch: >>> In file included from >>> >> /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/classfile/classLoaderData.hpp:28:0, >>> from >>> >> /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/precompiled/precompiled.hpp:34: >> /home/jiwon/jdk-related/jdk14/jdk14/src/hotspot/share/memory/allocation.hpp:31:15: >>> fatal error: new: No such file or directory >>> #include >> Do you have "build-essential" installed on the host system, assuming it's >> Debian-based? >> >>> Tools summary: >>> * Boot JDK: openjdk version "13.0.2" 2020-01-14 OpenJDK Runtime >>> Environment (build 13.0.2+8) OpenJDK 64-Bit Server VM (build 13.0.2+8, >>> mixed mode, sharing) (at /usr/lib/jvm/jdk-13.0.2) >>> * Toolchain: gcc (GNU Compiler Collection) >>> * C Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-gcc) >>> * C++ Compiler: Version 4.8.4 (at /usr/bin/aarch64-linux-gnu-g++) >> That version of GCC looks a bit old. I'm not sure whether it's recent >> enough for >> OpenJDK 14. >> >> FWIW, I'm using a different approach for cross-building OpenJDK which >> works particularly >> easy on Debian and Ubuntu due to Multi-Arch support which allows >> co-installing library >> packages for different architectures on one system. >> >> I have documented it here: >> https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK >> >> Adrian >> >> -- >> .''`. John Paul Adrian Glaubitz >> : :' : Debian Developer - glaubitz at debian.org >> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de >> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >> From erik.joelsson at oracle.com Wed Aug 26 15:01:12 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 26 Aug 2020 08:01:12 -0700 Subject: RFR: JDK-8252145: Unify Info.plist files with correct version strings In-Reply-To: <13d86a7e-76f5-35c4-b280-f68926b61044@oracle.com> References: <77725336-71e6-b09c-7ede-50a9e429498b@oracle.com> <38f8299d-9079-da0a-cdd1-bec67a2822d5@oracle.com> <13d86a7e-76f5-35c4-b280-f68926b61044@oracle.com> Message-ID: <312c014f-877a-2d00-bed7-0e0e689513a0@oracle.com> I realized that for LTS releases, the logic adding a numeric only $OPT string will bail out as we (Oracle) are then adding LTS to the $OPT string. To fix this, I've added an explicit setting of the new configure parameter --with-macosx-bundle-build-version from the jib configuration for CI builds. New webrev, only difference is in jib-profiles.js. http://cr.openjdk.java.net/~erikj/8252145/webrev.02/ /Erik On 2020-08-25 16:35, Sergey Bylokhov wrote: > Looks fine. > > On 25.08.2020 07:27, Erik Joelsson wrote: >> >> On 2020-08-24 19:18, Sergey Bylokhov wrote: >>> Hi, Erik. >>> >>> I would like to highlight one thing affected by this fix. The text >>> in the default about dialog in the Swing application will be changed. >>> >>> For my local build: >>> ?- Current text: "Java Version 1.0 (16)" >>> ?- After the fix: "Java Version 16 (0)" >>> >>> I am not sure why the build version and as a result the >>> CFBundleVersion is zero? >>> >> The CFBundleVersion is supposed to have a version number representing >> the build number. In a developer build, the "VERSION_BUILD" variable >> is default 0. In a promoted build, that number is set to the promoted >> build number. In Oracle promoted builds, we will also have a CI build >> number, so if this change was in effect, the latest JDK 16 promoted >> build would have 12.477 in CFBundleVersion. >> >> /Erik >> >>> On 24.08.2020 08:19, Erik Joelsson wrote: >>>> When fixing JDK-8246094, I concluded that our Info.plist files are >>>> in a bit of a mess. This patch tries to address this on a more >>>> fundamental level. >>>> >>>> 1. All Info.plist files and templates are moved to the same >>>> location in the source tree. >>>> >>>> 2. The CFBundleIdentifier is changed to no longer contain the >>>> version number. Instead it gets the $VERSION_PRE string if present. >>>> >>>> 3. The CFBundleShortVersionString is changed to the numeric version >>>> part of our version string. >>>> >>>> 4. The CFBundleVersion is changed to the build number (or a custom >>>> number if supplied through a new configure argument). For Oracle >>>> builds, this will take the form of >>>> .. >>>> >>>> For more details on why this particular scheme, see bug >>>> description, but in short, this is what I think best reflects what >>>> the Apple documentation says the fields are for. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8252145 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01 >>>> >>>> /Erik >>>> >>> >>> > > From Sergey.Bylokhov at oracle.com Thu Aug 27 00:13:01 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 26 Aug 2020 17:13:01 -0700 Subject: RFR: JDK-8252145: Unify Info.plist files with correct version strings In-Reply-To: <312c014f-877a-2d00-bed7-0e0e689513a0@oracle.com> References: <77725336-71e6-b09c-7ede-50a9e429498b@oracle.com> <38f8299d-9079-da0a-cdd1-bec67a2822d5@oracle.com> <13d86a7e-76f5-35c4-b280-f68926b61044@oracle.com> <312c014f-877a-2d00-bed7-0e0e689513a0@oracle.com> Message-ID: <41223ed1-1270-fa4d-54a2-6b805d26fcfe@oracle.com> +1 On 26.08.2020 08:01, Erik Joelsson wrote: > I realized that for LTS releases, the logic adding a numeric only $OPT string will bail out as we (Oracle) are then adding LTS to the $OPT string. To fix this, I've added an explicit setting of the new configure parameter --with-macosx-bundle-build-version from the jib configuration for CI builds. > > New webrev, only difference is in jib-profiles.js. > > http://cr.openjdk.java.net/~erikj/8252145/webrev.02/ > > /Erik > > On 2020-08-25 16:35, Sergey Bylokhov wrote: >> Looks fine. >> >> On 25.08.2020 07:27, Erik Joelsson wrote: >>> >>> On 2020-08-24 19:18, Sergey Bylokhov wrote: >>>> Hi, Erik. >>>> >>>> I would like to highlight one thing affected by this fix. The text in the default about dialog in the Swing application will be changed. >>>> >>>> For my local build: >>>> ?- Current text: "Java Version 1.0 (16)" >>>> ?- After the fix: "Java Version 16 (0)" >>>> >>>> I am not sure why the build version and as a result the CFBundleVersion is zero? >>>> >>> The CFBundleVersion is supposed to have a version number representing the build number. In a developer build, the "VERSION_BUILD" variable is default 0. In a promoted build, that number is set to the promoted build number. In Oracle promoted builds, we will also have a CI build number, so if this change was in effect, the latest JDK 16 promoted build would have 12.477 in CFBundleVersion. >>> >>> /Erik >>> >>>> On 24.08.2020 08:19, Erik Joelsson wrote: >>>>> When fixing JDK-8246094, I concluded that our Info.plist files are in a bit of a mess. This patch tries to address this on a more fundamental level. >>>>> >>>>> 1. All Info.plist files and templates are moved to the same location in the source tree. >>>>> >>>>> 2. The CFBundleIdentifier is changed to no longer contain the version number. Instead it gets the $VERSION_PRE string if present. >>>>> >>>>> 3. The CFBundleShortVersionString is changed to the numeric version part of our version string. >>>>> >>>>> 4. The CFBundleVersion is changed to the build number (or a custom number if supplied through a new configure argument). For Oracle builds, this will take the form of .. >>>>> >>>>> For more details on why this particular scheme, see bug description, but in short, this is what I think best reflects what the Apple documentation says the fields are for. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8252145 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01 >>>>> >>>>> /Erik >>>>> >>>> >>>> >> >> -- Best regards, Sergey. From andrew_m_leonard at uk.ibm.com Thu Aug 27 15:55:47 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 27 Aug 2020 16:55:47 +0100 Subject: RFR: 8252233: Enable debug-image target to support producing a pure debug image package Message-ID: Hi, Please may I request a sponsor and review for this build enhancement to provide a pure debug "image", for those developers that want to accompany a straight jdk image with a debug-image when needed: https://bugs.openjdk.java.net/browse/JDK-8252233 webrev: http://cr.openjdk.java.net/~aleonard/8252233/webrev.00/ We have been providing this as part of the openj9 builds at AdoptOpenJDK for a while now, and would like to contribute it upstream to openjdk. Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From sgehwolf at redhat.com Thu Aug 27 16:20:17 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 27 Aug 2020 18:20:17 +0200 Subject: RFR: 8252233: Enable debug-image target to support producing a pure debug image package In-Reply-To: References: Message-ID: <165b3aab6e3c5668e4669492b889fc30808fe157.camel@redhat.com> Hi Andrew, On Thu, 2020-08-27 at 16:55 +0100, Andrew Leonard wrote: > Hi, > Please may I request a sponsor and review for this build enhancement to > provide a pure debug "image", for those developers that want to accompany > a straight jdk image with a debug-image when needed: > https://bugs.openjdk.java.net/browse/JDK-8252233 > webrev: http://cr.openjdk.java.net/~aleonard/8252233/webrev.00/ Not really a review... If I understand this correctly it's an image of only *debugsymbols* for native files, right? debug-image as a name seems a bit confusing to me. There is already a concept of 'release', 'fastdebug' and 'slowdebug' builds for HotSpot. Perhaps calling it debugsymbols-image would make more sense? Thanks, Severin From philip.race at oracle.com Thu Aug 27 19:39:30 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 27 Aug 2020 12:39:30 -0700 Subject: RFR: 8074844 : Resolve disabled warnings for libfontmanager Message-ID: <5F480BF2.2060300@oracle.com> Bug : https://bugs.openjdk.java.net/browse/JDK-8074844 Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html This resolves the disabled compiler warnings in what is now quite a small fontmanager library. I've built windows, mac and linux in our build system and run our full battery of automated tests and sanity checked manual. A quick run down of how the warnings map to the changes DISABLED_WARNINGS_clang := sign-compare, DISABLED_WARNINGS_gcc := sign-compare unused-function int-to-pointer-cast, Sign compare in both of the above are the reason for the majority of the changes in freetypeScaler.c and also the change in hb-jdk.h unused-function was _free_nothing in src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc int-to-pointer-cast was an issue for 32 bit as raised here https://bugs.openjdk.java.net/browse/JDK-8250605 when a previous removal broke 32 bit Linux. Since we don't build or test that I was flying in the dark here using the warnings from that bug. The changes for this are those in src/java.desktop/share/native/libfontmanager/DrawGlyphList.c src/java.desktop/unix/native/libfontmanager/X11FontScaler.c DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996, The unique windows warnings were ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): error C2220: the following warning is treated as an error ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning C4244: '=': conversion from 'jlong' to 'long', possible loss of data ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): error C2220: the following warning is treated as an error ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): warning C4146: unary minus operator applied to unsigned type, result still unsigned ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error C2220: the following warning is treated as an error [ ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): warning C4996: 'GetVersion': was declared deprecated GetVersion isn't needed any more since we aren't likely to be running on anything older than XP ! -phil. From Sergey.Bylokhov at oracle.com Thu Aug 27 19:45:46 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 27 Aug 2020 12:45:46 -0700 Subject: RFR: 8074844 : Resolve disabled warnings for libfontmanager In-Reply-To: <5F480BF2.2060300@oracle.com> References: <5F480BF2.2060300@oracle.com> Message-ID: Hi, Phil. Probably we could enable WARNINGS_AS_ERRORS_xlc as well? I guess we will need a confirmation from the SAP gurus. On 27.08.2020 12:39, Philip Race wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8074844 > Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html > > This resolves the disabled compiler warnings in what is now quite a small fontmanager library. > > I've built windows, mac and linux in our build system and run our full battery of automated tests and sanity checked manual. > > A quick run down of how the warnings map to the changes > > ????? DISABLED_WARNINGS_clang := sign-compare, > > ????? DISABLED_WARNINGS_gcc := sign-compare unused-function int-to-pointer-cast, > > Sign compare in both of the above are the reason for the majority of the changes in freetypeScaler.c > and also the change in hb-jdk.h > > > unused-function was _free_nothing in > src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > > > int-to-pointer-cast was an issue for 32 bit as raised here https://bugs.openjdk.java.net/browse/JDK-8250605 > when a previous removal broke 32 bit Linux. Since we don't build or test that I was flying in the dark here > using the warnings from that bug. The changes for this are those in > > src/java.desktop/share/native/libfontmanager/DrawGlyphList.c > src/java.desktop/unix/native/libfontmanager/X11FontScaler.c > > > ????? DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996, > > The unique windows warnings were > ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): error C2220: the following warning is treated as an error > ?./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning C4244: '=': conversion from 'jlong' to 'long', possible loss of data > > ?./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): error C2220: the following warning is treated as an error > ?./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): warning C4146: unary minus operator applied to unsigned type, result still unsigned > > ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error C2220: the following warning is treated as an error > [ ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): warning C4996: 'GetVersion': was declared deprecated > > GetVersion isn't needed any more since we aren't likely to be running on anything older than XP ! > > -phil. > > > > -- Best regards, Sergey. From philip.race at oracle.com Thu Aug 27 19:55:13 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 27 Aug 2020 12:55:13 -0700 Subject: RFR: 8074844 : Resolve disabled warnings for libfontmanager In-Reply-To: References: <5F480BF2.2060300@oracle.com> Message-ID: <5F480FA1.5050304@oracle.com> I left that alone on purpose. I have no way of testing it and whereas for the 32 bit linux case I had an idea of what to fix, for xlc all I could find was it came in with https://bugs.openjdk.java.net/browse/JDK-8154087 and I've no idea what the problems were. SAP or IBM can look at it if they want as a separate fix. -phil. On 8/27/20, 12:45 PM, Sergey Bylokhov wrote: > Hi, Phil. > > Probably we could enable WARNINGS_AS_ERRORS_xlc as well? I guess we > will need a confirmation from the SAP gurus. > > On 27.08.2020 12:39, Philip Race wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8074844 >> Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html >> >> This resolves the disabled compiler warnings in what is now quite a >> small fontmanager library. >> >> I've built windows, mac and linux in our build system and run our >> full battery of automated tests and sanity checked manual. >> >> A quick run down of how the warnings map to the changes >> >> DISABLED_WARNINGS_clang := sign-compare, >> >> DISABLED_WARNINGS_gcc := sign-compare unused-function >> int-to-pointer-cast, >> >> Sign compare in both of the above are the reason for the majority of >> the changes in freetypeScaler.c >> and also the change in hb-jdk.h >> >> >> unused-function was _free_nothing in >> src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc >> >> >> int-to-pointer-cast was an issue for 32 bit as raised here >> https://bugs.openjdk.java.net/browse/JDK-8250605 >> when a previous removal broke 32 bit Linux. Since we don't build or >> test that I was flying in the dark here >> using the warnings from that bug. The changes for this are those in >> >> src/java.desktop/share/native/libfontmanager/DrawGlyphList.c >> src/java.desktop/unix/native/libfontmanager/X11FontScaler.c >> >> >> DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996, >> >> The unique windows warnings were >> ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): >> error C2220: the following warning is treated as an error >> ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning >> C4244: '=': conversion from 'jlong' to 'long', possible loss of data >> >> ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): >> error C2220: the following warning is treated as an error >> ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): >> warning C4146: unary minus operator applied to unsigned type, result >> still unsigned >> >> ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error >> C2220: the following warning is treated as an error >> [ >> ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): warning >> C4996: 'GetVersion': was declared deprecated >> >> GetVersion isn't needed any more since we aren't likely to be running >> on anything older than XP ! >> >> -phil. >> >> >> >> > > From erik.joelsson at oracle.com Thu Aug 27 20:38:29 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Aug 2020 13:38:29 -0700 Subject: RFR: 8074844 : Resolve disabled warnings for libfontmanager In-Reply-To: <5F480BF2.2060300@oracle.com> References: <5F480BF2.2060300@oracle.com> Message-ID: <67b9ff5a-8132-4b3d-d5a8-bf02892f3e08@oracle.com> Build change looks good. /Erik On 2020-08-27 12:39, Philip Race wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8074844 > Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html > > This resolves the disabled compiler warnings in what is now quite a > small fontmanager library. > > I've built windows, mac and linux in our build system and run our full > battery of automated tests and sanity checked manual. > > A quick run down of how the warnings map to the changes > > ????? DISABLED_WARNINGS_clang := sign-compare, > > ????? DISABLED_WARNINGS_gcc := sign-compare unused-function > int-to-pointer-cast, > > Sign compare in both of the above are the reason for the majority of > the changes in freetypeScaler.c > and also the change in hb-jdk.h > > > unused-function was _free_nothing in > src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > > > int-to-pointer-cast was an issue for 32 bit as raised here > https://bugs.openjdk.java.net/browse/JDK-8250605 > when a previous removal broke 32 bit Linux. Since we don't build or > test that I was flying in the dark here > using the warnings from that bug. The changes for this are those in > > src/java.desktop/share/native/libfontmanager/DrawGlyphList.c > src/java.desktop/unix/native/libfontmanager/X11FontScaler.c > > > ????? DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996, > > The unique windows warnings were > ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): > error C2220: the following warning is treated as an error > ?./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): > warning C4244: '=': conversion from 'jlong' to 'long', possible loss > of data > > ?./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): > error C2220: the following warning is treated as an error > ?./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): > warning C4146: unary minus operator applied to unsigned type, result > still unsigned > > ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): > error C2220: the following warning is treated as an error > [ > ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): > warning C4996: 'GetVersion': was declared deprecated > > GetVersion isn't needed any more since we aren't likely to be running > on anything older than XP ! > > -phil. > > > > From erik.joelsson at oracle.com Thu Aug 27 21:26:42 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Aug 2020 14:26:42 -0700 Subject: RFR: 8252233: Enable debug-image target to support producing a pure debug image package In-Reply-To: References: Message-ID: Hello Andrew, We certainly appreciate contributions, but this patch as it currently looks does not fit well with our current build system model. I'm however not against adding a target for your usecase. On a high level, just as Severin pointed out, the term "debug" is used for the type configuration we are building (release vs debug). For debug information we have instead chosen the term "symbols", so the target should rather be called symbols-image. Now I realize we already have that target, for something slightly different. I introduced that a long time ago for gcov symbols, with the intention of eventually move the main debug symbols into it too, but that never happened. I think we can just make that change now and let the symbols-image be what you are asking for (in addition to the gcov files if those are enabled). This will be one step in the direction of a bigger overhaul of the images that I want to do anyway. On a lower level, in Main.gmk, all targets should be declared as calls to the macro SetupTarget and in the correct section of the file. In this case it would be around line 418 where the current symbols-image is declared. The new file DebugImage.gmk contains a lot of duplication of logic already implemented in Images.gmk, which can quite easily be extended to cover your usecase. So all that said, this is how I would suggest to solve it: http://cr.openjdk.java.net/~erikj/8252233/webrev.01/index.html With this change, building the symbols image is part of the top level product-images target (but separate from the more specific jdk-image target). In Bundles.gmk, building the jdk bundles tar.gz gets slightly simpler as the files can be found directly in the symbols image. I still need to test this properly on all platforms. /Erik On 2020-08-27 08:55, Andrew Leonard wrote: > Hi, > Please may I request a sponsor and review for this build enhancement to > provide a pure debug "image", for those developers that want to accompany > a straight jdk image with a debug-image when needed: > https://bugs.openjdk.java.net/browse/JDK-8252233 > webrev: http://cr.openjdk.java.net/~aleonard/8252233/webrev.00/ > We have been providing this as part of the openj9 builds at AdoptOpenJDK > for a while now, and would like to contribute it upstream to openjdk. > > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From magnus.ihse.bursie at oracle.com Fri Aug 28 07:11:46 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 28 Aug 2020 09:11:46 +0200 Subject: RFR: JDK-8252145: Unify Info.plist files with correct version strings In-Reply-To: <312c014f-877a-2d00-bed7-0e0e689513a0@oracle.com> References: <77725336-71e6-b09c-7ede-50a9e429498b@oracle.com> <38f8299d-9079-da0a-cdd1-bec67a2822d5@oracle.com> <13d86a7e-76f5-35c4-b280-f68926b61044@oracle.com> <312c014f-877a-2d00-bed7-0e0e689513a0@oracle.com> Message-ID: On 2020-08-26 17:01, Erik Joelsson wrote: > I realized that for LTS releases, the logic adding a numeric only $OPT > string will bail out as we (Oracle) are then adding LTS to the $OPT > string. To fix this, I've added an explicit setting of the new > configure parameter --with-macosx-bundle-build-version from the jib > configuration for CI builds. > > New webrev, only difference is in jib-profiles.js. > > http://cr.openjdk.java.net/~erikj/8252145/webrev.02/ Looks good to me. Thanks for cleaning this up! /Magnus > > /Erik > > On 2020-08-25 16:35, Sergey Bylokhov wrote: >> Looks fine. >> >> On 25.08.2020 07:27, Erik Joelsson wrote: >>> >>> On 2020-08-24 19:18, Sergey Bylokhov wrote: >>>> Hi, Erik. >>>> >>>> I would like to highlight one thing affected by this fix. The text >>>> in the default about dialog in the Swing application will be changed. >>>> >>>> For my local build: >>>> ?- Current text: "Java Version 1.0 (16)" >>>> ?- After the fix: "Java Version 16 (0)" >>>> >>>> I am not sure why the build version and as a result the >>>> CFBundleVersion is zero? >>>> >>> The CFBundleVersion is supposed to have a version number >>> representing the build number. In a developer build, the >>> "VERSION_BUILD" variable is default 0. In a promoted build, that >>> number is set to the promoted build number. In Oracle promoted >>> builds, we will also have a CI build number, so if this change was >>> in effect, the latest JDK 16 promoted build would have 12.477 in >>> CFBundleVersion. >>> >>> /Erik >>> >>>> On 24.08.2020 08:19, Erik Joelsson wrote: >>>>> When fixing JDK-8246094, I concluded that our Info.plist files are >>>>> in a bit of a mess. This patch tries to address this on a more >>>>> fundamental level. >>>>> >>>>> 1. All Info.plist files and templates are moved to the same >>>>> location in the source tree. >>>>> >>>>> 2. The CFBundleIdentifier is changed to no longer contain the >>>>> version number. Instead it gets the $VERSION_PRE string if present. >>>>> >>>>> 3. The CFBundleShortVersionString is changed to the numeric >>>>> version part of our version string. >>>>> >>>>> 4. The CFBundleVersion is changed to the build number (or a custom >>>>> number if supplied through a new configure argument). For Oracle >>>>> builds, this will take the form of >>>>> .. >>>>> >>>>> For more details on why this particular scheme, see bug >>>>> description, but in short, this is what I think best reflects what >>>>> the Apple documentation says the fields are for. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8252145 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01 >>>>> >>>>> /Erik >>>>> >>>> >>>> >> >> From andrew_m_leonard at uk.ibm.com Fri Aug 28 07:03:01 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 28 Aug 2020 08:03:01 +0100 Subject: RFR: 8252233: Enable debug-image target to support producing a pure debug image package In-Reply-To: <165b3aab6e3c5668e4669492b889fc30808fe157.camel@redhat.com> References: <165b3aab6e3c5668e4669492b889fc30808fe157.camel@redhat.com> Message-ID: Hi Severin, So yes I guess maybe "debugsymbols-image" is more precise, we call it "debugimage" at Adopt, see artifacts: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk15u/job/jdk15u-linux-x64-openj9/ that's less of a mouthful and I think we're used to that name, but if the community would prefer that? Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Severin Gehwolf To: Andrew Leonard , build-dev at openjdk.java.net Date: 27/08/2020 17:20 Subject: [EXTERNAL] Re: RFR: 8252233: Enable debug-image target to support producing a pure debug image package Hi Andrew, On Thu, 2020-08-27 at 16:55 +0100, Andrew Leonard wrote: > Hi, > Please may I request a sponsor and review for this build enhancement to > provide a pure debug "image", for those developers that want to accompany > a straight jdk image with a debug-image when needed: > https://bugs.openjdk.java.net/browse/JDK-8252233 > webrev: http://cr.openjdk.java.net/~aleonard/8252233/webrev.00/ Not really a review... If I understand this correctly it's an image of only *debugsymbols* for native files, right? debug-image as a name seems a bit confusing to me. There is already a concept of 'release', 'fastdebug' and 'slowdebug' builds for HotSpot. Perhaps calling it debugsymbols-image would make more sense? Thanks, Severin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From magnus.ihse.bursie at oracle.com Fri Aug 28 07:51:50 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 28 Aug 2020 09:51:50 +0200 Subject: RFR: 8252233: Enable debug-image target to support producing a pure debug image package In-Reply-To: References: Message-ID: <5fdcbdc6-4648-3415-db43-17793b3da019@oracle.com> On 2020-08-27 23:26, Erik Joelsson wrote: > Hello Andrew, > > We certainly appreciate contributions, but this patch as it currently > looks does not fit well with our current build system model. I'm > however not against adding a target for your usecase. > > On a high level, just as Severin pointed out, the term "debug" is used > for the type configuration we are building (release vs debug). For > debug information we have instead chosen the term "symbols", so the > target should rather be called symbols-image. Now I realize we already > have that target, for something slightly different. I introduced that > a long time ago for gcov symbols, with the intention of eventually > move the main debug symbols into it too, but that never happened. I > think we can just make that change now and let the symbols-image be > what you are asking for (in addition to the gcov files if those are > enabled). This will be one step in the direction of a bigger overhaul > of the images that I want to do anyway. > > On a lower level, in Main.gmk, all targets should be declared as calls > to the macro SetupTarget and in the correct section of the file. In > this case it would be around line 418 where the current symbols-image > is declared. > > The new file DebugImage.gmk contains a lot of duplication of logic > already implemented in Images.gmk, which can quite easily be extended > to cover your usecase. > > So all that said, this is how I would suggest to solve it: > > http://cr.openjdk.java.net/~erikj/8252233/webrev.01/index.html Erik, I fully agree with you in your analysis on the proper way to solve this. However, I have a hard time figuring out how the patch you supplied will achieve that. :-) Maybe you can help me understand how this would actually make the debug symbols be added to the symbol image? /Magnus > > With this change, building the symbols image is part of the top level > product-images target (but separate from the more specific jdk-image > target). In Bundles.gmk, building the jdk bundles tar.gz gets slightly > simpler as the files can be found directly in the symbols image. > > I still need to test this properly on all platforms. > > /Erik > > On 2020-08-27 08:55, Andrew Leonard wrote: >> Hi, >> Please may I request a sponsor and review for this build enhancement to >> provide a pure debug "image", for those developers that want to >> accompany >> a straight jdk image with a debug-image when needed: >> ???? https://bugs.openjdk.java.net/browse/JDK-8252233 >> ???? webrev: http://cr.openjdk.java.net/~aleonard/8252233/webrev.00/ >> We have been providing this as part of the openj9 builds at AdoptOpenJDK >> for a while now, and would like to contribute it upstream to openjdk. >> >> Thanks >> Andrew >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> internet email: andrew_m_leonard at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> PO6 3AU >> From magnus.ihse.bursie at oracle.com Fri Aug 28 08:05:22 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 28 Aug 2020 10:05:22 +0200 Subject: RFR: 8074844 : Resolve disabled warnings for libfontmanager In-Reply-To: <5F480BF2.2060300@oracle.com> References: <5F480BF2.2060300@oracle.com> Message-ID: <76911e05-8c83-4916-32a9-675d2590c125@oracle.com> On 2020-08-27 21:39, Philip Race wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8074844 > Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html Looks good to me. Thank you Phil for cleaning this up! /Magnus > > This resolves the disabled compiler warnings in what is now quite a > small fontmanager library. > > I've built windows, mac and linux in our build system and run our full > battery of automated tests and sanity checked manual. > > A quick run down of how the warnings map to the changes > > ????? DISABLED_WARNINGS_clang := sign-compare, > > ????? DISABLED_WARNINGS_gcc := sign-compare unused-function > int-to-pointer-cast, > > Sign compare in both of the above are the reason for the majority of > the changes in freetypeScaler.c > and also the change in hb-jdk.h > > > unused-function was _free_nothing in > src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > > > int-to-pointer-cast was an issue for 32 bit as raised here > https://bugs.openjdk.java.net/browse/JDK-8250605 > when a previous removal broke 32 bit Linux. Since we don't build or > test that I was flying in the dark here > using the warnings from that bug. The changes for this are those in > > src/java.desktop/share/native/libfontmanager/DrawGlyphList.c > src/java.desktop/unix/native/libfontmanager/X11FontScaler.c > > > ????? DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996, > > The unique windows warnings were > ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): > error C2220: the following warning is treated as an error > ?./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): > warning C4244: '=': conversion from 'jlong' to 'long', possible loss > of data > > ?./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): > error C2220: the following warning is treated as an error > ?./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): > warning C4146: unary minus operator applied to unsigned type, result > still unsigned > > ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): > error C2220: the following warning is treated as an error > [ > ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): > warning C4996: 'GetVersion': was declared deprecated > > GetVersion isn't needed any more since we aren't likely to be running > on anything older than XP ! > > -phil. > > > > From magnus.ihse.bursie at oracle.com Fri Aug 28 09:09:19 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 28 Aug 2020 11:09:19 +0200 Subject: Preliminary review for new WINENV support In-Reply-To: References: Message-ID: On 2020-08-24 19:21, Ludovic Henry wrote: > 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. The big blockers for this fix is basically these two issues: >> I have also temporarily disabled the javac server, and building without absolute paths. I believe a better way forward is to address these with improved functionality in separate patches, instead of trying to work around the issues introduced by them in this patch. Until that is fixed, any integration of this patch is a no-go. I have been working on those, but a lot of other stuff has kept me from gaining much progress; everything from long vacations to preparations to the switch to github. Unfortunately, I don't think there's an easy way for you to help on those two blockers. However, there are two more things that I'd like to look into, if possible, before integrating my patch, and there you might be able to help. One is performance. I got a somewhat different performance profile with my patch than without -- some things were faster, and some were slower. I'd like to understand why some things got slower, and if it is possible to do anything about. (Why things got faster I don't care about, I'm just happy :)) So maybe you can help me with some performance analysis? With the limited availability of tooling for makefiles, this is not really trivial. What I usually do is I run with JOBS=1 (to be able to track each task individually without effects of concurrency), and LOG=info,profile. This will give you time stamps for each individual execution in build.log.? And see if there is any interesting differences with and without the patch. The other thing is that WSL2 works awfully bad. :( Maybe there's nothing to be done about it, if the thing being shipped is just too buggy, but maybe we do things incorrectly, or that unnecessarily triggers bugs. Or maybe there are workarounds we could use. But I think it could be worth some more effort to try to get it working. Maybe you can help with this? /Magnus From erik.joelsson at oracle.com Fri Aug 28 12:50:50 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 28 Aug 2020 05:50:50 -0700 Subject: RFR: 8252233: Enable debug-image target to support producing a pure debug image package In-Reply-To: <5fdcbdc6-4648-3415-db43-17793b3da019@oracle.com> References: <5fdcbdc6-4648-3415-db43-17793b3da019@oracle.com> Message-ID: <7557540d-9f20-a370-c3cf-6e45d3384633@oracle.com> On 2020-08-28 00:51, Magnus Ihse Bursie wrote: > On 2020-08-27 23:26, Erik Joelsson wrote: >> Hello Andrew, >> >> We certainly appreciate contributions, but this patch as it currently >> looks does not fit well with our current build system model. I'm >> however not against adding a target for your usecase. >> >> On a high level, just as Severin pointed out, the term "debug" is >> used for the type configuration we are building (release vs debug). >> For debug information we have instead chosen the term "symbols", so >> the target should rather be called symbols-image. Now I realize we >> already have that target, for something slightly different. I >> introduced that a long time ago for gcov symbols, with the intention >> of eventually move the main debug symbols into it too, but that never >> happened. I think we can just make that change now and let the >> symbols-image be what you are asking for (in addition to the gcov >> files if those are enabled). This will be one step in the direction >> of a bigger overhaul of the images that I want to do anyway. >> >> On a lower level, in Main.gmk, all targets should be declared as >> calls to the macro SetupTarget and in the correct section of the >> file. In this case it would be around line 418 where the current >> symbols-image is declared. >> >> The new file DebugImage.gmk contains a lot of duplication of logic >> already implemented in Images.gmk, which can quite easily be extended >> to cover your usecase. >> >> So all that said, this is how I would suggest to solve it: >> >> http://cr.openjdk.java.net/~erikj/8252233/webrev.01/index.html > Erik, > > I fully agree with you in your analysis on the proper way to solve > this. However, I have a hard time figuring out how the patch you > supplied will achieve that. :-) Maybe you can help me understand how > this would actually make the debug symbols be added to the symbol image? Sure! In the already present "Debug symbols" section of Images.gmk, we have a bunch of convoluted logic for finding all debugsymbols in the respective modules_libs and modules_cmds dirs and generate rules for copying them to the relevant images. This logic is already parameterized to do the same job for the JRE and JDK images, so at the bottom, there were already two calls to SetupCopyDebuginfo, one for JDK and one for JRE. For these calls to work, there needs to be 2 variables defined specific to the image we are copying to. The list of modules relevant for this image and the target directory, ALL_$1_MODULES and $_IMAGE_DIR respectively. The patch adds the first variable and the second was already defined as we already have symbols image. In Bundles.gmk, we generate the main JDK bundle by filtering out the debugsymbols from the jdk image, then we generate the symbols image by filtering just the debugsymbols from the jdk image, as well as adding everything from the symbols image. The last part is basically only done in case we built with gcov. Now with this patch, the symbols image always contains the full set of debug symbols, so we would end up with duplicate rules as the same files would be copied from two different places. To fix this, I simply removed the JDK image as a source of files for the symbols bundle. The logic in Bundles.gmk is still unreasonably complex, and I hope to fix this at some point, but I think it's out of scope for this change. What I would like to do is change Images.gmk to generate a pure symbols image (basically done with this patch) and a pure JDK image containing exactly what should go into the bundle, then also (optionally) a 3rd image that looks like our current JDK image with the former two combined which is convenient for development use in local builds. /Erik > > /Magnus >> >> With this change, building the symbols image is part of the top level >> product-images target (but separate from the more specific jdk-image >> target). In Bundles.gmk, building the jdk bundles tar.gz gets >> slightly simpler as the files can be found directly in the symbols >> image. >> >> I still need to test this properly on all platforms. >> >> /Erik >> >> On 2020-08-27 08:55, Andrew Leonard wrote: >>> Hi, >>> Please may I request a sponsor and review for this build enhancement to >>> provide a pure debug "image", for those developers that want to >>> accompany >>> a straight jdk image with a debug-image when needed: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8252233 >>> ???? webrev: http://cr.openjdk.java.net/~aleonard/8252233/webrev.00/ >>> We have been providing this as part of the openj9 builds at >>> AdoptOpenJDK >>> for a while now, and would like to contribute it upstream to openjdk. >>> >>> Thanks >>> Andrew >>> >>> Andrew Leonard >>> Java Runtimes Development >>> IBM Hursley >>> IBM United Kingdom Ltd >>> internet email: andrew_m_leonard at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with >>> number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>> PO6 3AU >>> > From andrew_m_leonard at uk.ibm.com Fri Aug 28 14:23:51 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 28 Aug 2020 15:23:51 +0100 Subject: RFR: 8252233: Enable debug-image target to support producing a pure debug image package In-Reply-To: <7557540d-9f20-a370-c3cf-6e45d3384633@oracle.com> References: <5fdcbdc6-4648-3415-db43-17793b3da019@oracle.com> <7557540d-9f20-a370-c3cf-6e45d3384633@oracle.com> Message-ID: Hi Erik, Thank you for taking a look at this, what you say makes perfect sense, and provides exactly what we're after. I've taken a look at your patch, and have tested it on my Ubuntu VM and it works a treat. I've also run it at Adopt on Windows & Mac, and produced debug symbol images fine: https://ci.adoptopenjdk.net/view/work%20in%20progress/job/andrew-jdk-windows-x64-hotspot/13/ https://ci.adoptopenjdk.net/view/work%20in%20progress/job/andrew-jdk-mac-x64-hotspot/2/ So looks good to me. Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Erik Joelsson To: Magnus Ihse Bursie , Andrew Leonard , build-dev at openjdk.java.net Date: 28/08/2020 13:50 Subject: [EXTERNAL] Re: RFR: 8252233: Enable debug-image target to support producing a pure debug image package On 2020-08-28 00:51, Magnus Ihse Bursie wrote: > On 2020-08-27 23:26, Erik Joelsson wrote: >> Hello Andrew, >> >> We certainly appreciate contributions, but this patch as it currently >> looks does not fit well with our current build system model. I'm >> however not against adding a target for your usecase. >> >> On a high level, just as Severin pointed out, the term "debug" is >> used for the type configuration we are building (release vs debug). >> For debug information we have instead chosen the term "symbols", so >> the target should rather be called symbols-image. Now I realize we >> already have that target, for something slightly different. I >> introduced that a long time ago for gcov symbols, with the intention >> of eventually move the main debug symbols into it too, but that never >> happened. I think we can just make that change now and let the >> symbols-image be what you are asking for (in addition to the gcov >> files if those are enabled). This will be one step in the direction >> of a bigger overhaul of the images that I want to do anyway. >> >> On a lower level, in Main.gmk, all targets should be declared as >> calls to the macro SetupTarget and in the correct section of the >> file. In this case it would be around line 418 where the current >> symbols-image is declared. >> >> The new file DebugImage.gmk contains a lot of duplication of logic >> already implemented in Images.gmk, which can quite easily be extended >> to cover your usecase. >> >> So all that said, this is how I would suggest to solve it: >> >> http://cr.openjdk.java.net/~erikj/8252233/webrev.01/index.html > Erik, > > I fully agree with you in your analysis on the proper way to solve > this. However, I have a hard time figuring out how the patch you > supplied will achieve that. :-) Maybe you can help me understand how > this would actually make the debug symbols be added to the symbol image? Sure! In the already present "Debug symbols" section of Images.gmk, we have a bunch of convoluted logic for finding all debugsymbols in the respective modules_libs and modules_cmds dirs and generate rules for copying them to the relevant images. This logic is already parameterized to do the same job for the JRE and JDK images, so at the bottom, there were already two calls to SetupCopyDebuginfo, one for JDK and one for JRE. For these calls to work, there needs to be 2 variables defined specific to the image we are copying to. The list of modules relevant for this image and the target directory, ALL_$1_MODULES and $_IMAGE_DIR respectively. The patch adds the first variable and the second was already defined as we already have symbols image. In Bundles.gmk, we generate the main JDK bundle by filtering out the debugsymbols from the jdk image, then we generate the symbols image by filtering just the debugsymbols from the jdk image, as well as adding everything from the symbols image. The last part is basically only done in case we built with gcov. Now with this patch, the symbols image always contains the full set of debug symbols, so we would end up with duplicate rules as the same files would be copied from two different places. To fix this, I simply removed the JDK image as a source of files for the symbols bundle. The logic in Bundles.gmk is still unreasonably complex, and I hope to fix this at some point, but I think it's out of scope for this change. What I would like to do is change Images.gmk to generate a pure symbols image (basically done with this patch) and a pure JDK image containing exactly what should go into the bundle, then also (optionally) a 3rd image that looks like our current JDK image with the former two combined which is convenient for development use in local builds. /Erik > > /Magnus >> >> With this change, building the symbols image is part of the top level >> product-images target (but separate from the more specific jdk-image >> target). In Bundles.gmk, building the jdk bundles tar.gz gets >> slightly simpler as the files can be found directly in the symbols >> image. >> >> I still need to test this properly on all platforms. >> >> /Erik >> >> On 2020-08-27 08:55, Andrew Leonard wrote: >>> Hi, >>> Please may I request a sponsor and review for this build enhancement to >>> provide a pure debug "image", for those developers that want to >>> accompany >>> a straight jdk image with a debug-image when needed: >>> https://bugs.openjdk.java.net/browse/JDK-8252233 >>> webrev: http://cr.openjdk.java.net/~aleonard/8252233/webrev.00/ >>> We have been providing this as part of the openj9 builds at >>> AdoptOpenJDK >>> for a while now, and would like to contribute it upstream to openjdk. >>> >>> Thanks >>> Andrew >>> >>> Andrew Leonard >>> Java Runtimes Development >>> IBM Hursley >>> IBM United Kingdom Ltd >>> internet email: andrew_m_leonard at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with >>> number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>> PO6 3AU >>> > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From magnus.ihse.bursie at oracle.com Fri Aug 28 14:26:38 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 28 Aug 2020 16:26:38 +0200 Subject: RFR: 8252233: Enable debug-image target to support producing a pure debug image package In-Reply-To: <7557540d-9f20-a370-c3cf-6e45d3384633@oracle.com> References: <5fdcbdc6-4648-3415-db43-17793b3da019@oracle.com> <7557540d-9f20-a370-c3cf-6e45d3384633@oracle.com> Message-ID: <10c8753c-b328-930c-8439-af9a5855db0b@oracle.com> On 2020-08-28 14:50, Erik Joelsson wrote: > > On 2020-08-28 00:51, Magnus Ihse Bursie wrote: >> On 2020-08-27 23:26, Erik Joelsson wrote: >>> Hello Andrew, >>> >>> We certainly appreciate contributions, but this patch as it >>> currently looks does not fit well with our current build system >>> model. I'm however not against adding a target for your usecase. >>> >>> On a high level, just as Severin pointed out, the term "debug" is >>> used for the type configuration we are building (release vs debug). >>> For debug information we have instead chosen the term "symbols", so >>> the target should rather be called symbols-image. Now I realize we >>> already have that target, for something slightly different. I >>> introduced that a long time ago for gcov symbols, with the intention >>> of eventually move the main debug symbols into it too, but that >>> never happened. I think we can just make that change now and let the >>> symbols-image be what you are asking for (in addition to the gcov >>> files if those are enabled). This will be one step in the direction >>> of a bigger overhaul of the images that I want to do anyway. >>> >>> On a lower level, in Main.gmk, all targets should be declared as >>> calls to the macro SetupTarget and in the correct section of the >>> file. In this case it would be around line 418 where the current >>> symbols-image is declared. >>> >>> The new file DebugImage.gmk contains a lot of duplication of logic >>> already implemented in Images.gmk, which can quite easily be >>> extended to cover your usecase. >>> >>> So all that said, this is how I would suggest to solve it: >>> >>> http://cr.openjdk.java.net/~erikj/8252233/webrev.01/index.html >> Erik, >> >> I fully agree with you in your analysis on the proper way to solve >> this. However, I have a hard time figuring out how the patch you >> supplied will achieve that. :-) Maybe you can help me understand how >> this would actually make the debug symbols be added to the symbol image? > > Sure! In the already present "Debug symbols" section of Images.gmk, we > have a bunch of convoluted logic for finding all debugsymbols in the > respective modules_libs and modules_cmds dirs and generate rules for > copying them to the relevant images. This logic is already > parameterized to do the same job for the JRE and JDK images, so at the > bottom, there were already two calls to SetupCopyDebuginfo, one for > JDK and one for JRE. For these calls to work, there needs to be 2 > variables defined specific to the image we are copying to. The list of > modules relevant for this image and the target directory, > ALL_$1_MODULES and $_IMAGE_DIR respectively. The patch adds the first > variable and the second was already defined as we already have symbols > image. > > In Bundles.gmk, we generate the main JDK bundle by filtering out the > debugsymbols from the jdk image, then we generate the symbols image by > filtering just the debugsymbols from the jdk image, as well as adding > everything from the symbols image. The last part is basically only > done in case we built with gcov. Now with this patch, the symbols > image always contains the full set of debug symbols, so we would end > up with duplicate rules as the same files would be copied from two > different places. To fix this, I simply removed the JDK image as a > source of files for the symbols bundle. > I see. Thanks for the description! It sounds like your patch achieves what was requested, and it looks good. Consider it reviewed by me. Let's just hear that Andrew is satisfied as well. > The logic in Bundles.gmk is still unreasonably complex, and I hope to > fix this at some point, but I think it's out of scope for this change. > What I would like to do is change Images.gmk to generate a pure > symbols image (basically done with this patch) and a pure JDK image > containing exactly what should go into the bundle, then also > (optionally) a 3rd image that looks like our current JDK image with > the former two combined which is convenient for development use in > local builds. Yes, that sounds much better. /Magnus > > /Erik > >> >> /Magnus >>> >>> With this change, building the symbols image is part of the top >>> level product-images target (but separate from the more specific >>> jdk-image target). In Bundles.gmk, building the jdk bundles tar.gz >>> gets slightly simpler as the files can be found directly in the >>> symbols image. >>> >>> I still need to test this properly on all platforms. >>> >>> /Erik >>> >>> On 2020-08-27 08:55, Andrew Leonard wrote: >>>> Hi, >>>> Please may I request a sponsor and review for this build >>>> enhancement to >>>> provide a pure debug "image", for those developers that want to >>>> accompany >>>> a straight jdk image with a debug-image when needed: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8252233 >>>> ???? webrev: http://cr.openjdk.java.net/~aleonard/8252233/webrev.00/ >>>> We have been providing this as part of the openj9 builds at >>>> AdoptOpenJDK >>>> for a while now, and would like to contribute it upstream to openjdk. >>>> >>>> Thanks >>>> Andrew >>>> >>>> Andrew Leonard >>>> Java Runtimes Development >>>> IBM Hursley >>>> IBM United Kingdom Ltd >>>> internet email: andrew_m_leonard at uk.ibm.com >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with >>>> number >>>> 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>>> PO6 3AU >>>> >> From Sergey.Bylokhov at oracle.com Sat Aug 29 00:30:18 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 28 Aug 2020 17:30:18 -0700 Subject: RFR: 8074844 : Resolve disabled warnings for libfontmanager In-Reply-To: <5F480FA1.5050304@oracle.com> References: <5F480BF2.2060300@oracle.com> <5F480FA1.5050304@oracle.com> Message-ID: <82d591ba-8253-3a71-4309-29e8a54610ac@oracle.com> On 27.08.2020 12:55, Philip Race wrote: > SAP or IBM can look at it if they want as a separate fix. ok, +1 > > -phil. > > On 8/27/20, 12:45 PM, Sergey Bylokhov wrote: >> Hi, Phil. >> >> Probably we could enable WARNINGS_AS_ERRORS_xlc as well? I guess we will need a confirmation from the SAP gurus. >> >> On 27.08.2020 12:39, Philip Race wrote: >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8074844 >>> Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html >>> >>> This resolves the disabled compiler warnings in what is now quite a small fontmanager library. >>> >>> I've built windows, mac and linux in our build system and run our full battery of automated tests and sanity checked manual. >>> >>> A quick run down of how the warnings map to the changes >>> >>> ?????? DISABLED_WARNINGS_clang := sign-compare, >>> >>> ?????? DISABLED_WARNINGS_gcc := sign-compare unused-function int-to-pointer-cast, >>> >>> Sign compare in both of the above are the reason for the majority of the changes in freetypeScaler.c >>> and also the change in hb-jdk.h >>> >>> >>> unused-function was _free_nothing in >>> src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc >>> >>> >>> int-to-pointer-cast was an issue for 32 bit as raised here https://bugs.openjdk.java.net/browse/JDK-8250605 >>> when a previous removal broke 32 bit Linux. Since we don't build or test that I was flying in the dark here >>> using the warnings from that bug. The changes for this are those in >>> >>> src/java.desktop/share/native/libfontmanager/DrawGlyphList.c >>> src/java.desktop/unix/native/libfontmanager/X11FontScaler.c >>> >>> >>> ?????? DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996, >>> >>> The unique windows warnings were >>> ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): error C2220: the following warning is treated as an error >>> ? ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning C4244: '=': conversion from 'jlong' to 'long', possible loss of data >>> >>> ? ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): error C2220: the following warning is treated as an error >>> ? ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): warning C4146: unary minus operator applied to unsigned type, result still unsigned >>> >>> ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error C2220: the following warning is treated as an error >>> [ ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): warning C4996: 'GetVersion': was declared deprecated >>> >>> GetVersion isn't needed any more since we aren't likely to be running on anything older than XP ! >>> >>> -phil. >>> >>> >>> >>> >> >> -- Best regards, Sergey. From sgehwolf at redhat.com Mon Aug 31 08:02:11 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 31 Aug 2020 10:02:11 +0200 Subject: [8u] RFR: 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries Message-ID: Hi, Could I get a reivew of this 8u specific bug please? When configured --with-native-debug-symbols=external,zipped the resulting external debuginfo files for binaries (in images/bin folder) aren't there. In OpenJDK 8u there is some special casing involved for bin/java and bin/unpack200. Thus, I had to special case them for the debuginfo variant files too otherwise those files would be missing in the images folders (j2sdk-image, j2re-image). Bug: https://bugs.openjdk.java.net/browse/JDK-8252395 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252395/01/webrev/ Testing: Build in configs --with-native-debugsymbols={zipped,external,internal,none} on Linux x86 and manually debugging some launcher code. Works now with symbols. Symbols were missing before this patch. Thanks, Severin From sgehwolf at redhat.com Mon Aug 31 11:44:32 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 31 Aug 2020 13:44:32 +0200 Subject: [8u] RFR: 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries In-Reply-To: References: Message-ID: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> Sorry, wrong webrev. Now corrected. On Mon, 2020-08-31 at 10:02 +0200, Severin Gehwolf wrote: > Hi, > > Could I get a reivew of this 8u specific bug please? When configured > --with-native-debug-symbols=external,zipped the resulting external > debuginfo files for binaries (in images/bin folder) aren't there. > > In OpenJDK 8u there is some special casing involved for bin/java and > bin/unpack200. Thus, I had to special case them for the debuginfo > variant files too otherwise those files would be missing in the images > folders (j2sdk-image, j2re-image). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252395 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252395/02/webrev/ > > Testing: Build in configs --with-native-debugsymbols={zipped,external,internal,none} > on Linux x86 and manually debugging some launcher code. Works now > with symbols. Symbols were missing before this patch. > Thanks, Severin From gobletfire at vip.qq.com Wed Aug 5 07:47:01 2020 From: gobletfire at vip.qq.com (=?gb18030?B?NDUxNTQxNjk1?=) Date: Wed, 05 Aug 2020 07:47:01 -0000 Subject: jdk14 build failed cause "The header is deprecated and will be removed." Message-ID: Hello,  Thanks for providing java for developers.   I am trying to build jdk-14 to use, but failed to build.   The error is following:    My environment:       Linux: Ubuntu 20.04.1 LTS       autoconfig:  I don't know what happened to