From yyang at openjdk.java.net Fri Apr 2 07:38:32 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 2 Apr 2021 07:38:32 GMT Subject: RFR: 8263028: Windows build fails due to several treat-warning-as-errors In-Reply-To: References: <6cv_HeWJ9HsBrB7NSFU-TGl4PP0Tp820KzwJ-FRn_so=.e4d8ab11-4203-4278-a829-43b6f1626465@github.com> <_4snjvydeDKDu6aZgC1Fqr_kc6sHII7F7Ywinh3H9Rw=.61007752-81c3-44a0-911f-4dd184259966@github.com> Message-ID: On Mon, 29 Mar 2021 14:42:00 GMT, Yi Yang wrote: >> I searched the net once more for setting the locale, and this time I found some creative workarounds on superuser. The suggestion is to create a *secondary* user account, and set US English as locale for that account. Then you can go back to your main account, and us the "Run as..." functionality to execute an arbitrary command as that user. >> >> This could be done by: `%comspec% runas /profile /user:yourotheruser "the_application_you_want_ to_run_in_english"` or using the GUI (shift+right click on the icon, select `Run as different user`). >> >> I assume you would be able to start a cygwin shell like this, and have all processes started in that shell belonging to this US English user. >> >> @kelthuzadx Can you please verify if this method works? If so, I believe it is convenient enough for us to be able to require US English locale for building on Windows. > > Hi Magnus, > >> I searched the net once more for setting the locale, and this time I found some creative workarounds on superuser. The suggestion is to create a secondary user account, and set US English as locale for that account. Then you can go back to your main account, and us the "Run as..." functionality to execute an arbitrary command as that user. > >> This could be done by: %comspec% runas /profile /user:yourotheruser "the_application_you_want_ to_run_in_english" or using the GUI (shift+right click on the icon, select Run as different user). > > Thanks for your investigations and kind suggestions. It is more troublesome to add new a user to the Chinese system and set its system locale to English. Instead of doing this, I prefer to directly change the system locale to English. > > When I set the system locale to English(`Control Panel->Change date, time,...->Administrative->Change System locale->English`), and it indeed works for building! No warnings were generated. All works fine. > >> a) it does not occur in what is at least the "recommended" locale, and > >> b) more issues are likely to creep up in the future (in fact, there might already be testing issues as Jorn says) > >> On the other hand, I am not really comfortable either with just stating in the build document that US English is the only supported Windows locale, since it has such far-reaching consequences for the individual developers. > > You convinced me, I agree with you that stating these has far-reaching consequences and your internal test matrix will become incredibly heavy. However, I think we can add a section in the FAQ or other places in the building document to give a solution for such problems as much as possible, e.g. > > Q: Why I can not build JDK on a non-English system? What should I do next? > A: Maybe you can change your system locale to English and try again > > Just IMHO, :-) > > Best Regards, > Yang In order to avoid disturbing others, I will comment on the https://bugs.openjdk.java.net/browse/JDK-8264425 ------------- PR: https://git.openjdk.java.net/jdk/pull/3107 From yyang at openjdk.java.net Fri Apr 2 07:38:32 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 2 Apr 2021 07:38:32 GMT Subject: Withdrawn: 8263028: Windows build fails due to several treat-warning-as-errors In-Reply-To: References: Message-ID: On Sun, 21 Mar 2021 04:22:42 GMT, Yi Yang wrote: > cl.exe(19.28.29334) can not build JDK on windows_x64 because it treats many warnings as errors thus prohibiting further compilation. (See detailed failure logs on JBS) > > 1. methodMatcher.cpp > > cl.exe can not handle advanced usage of sscanf(i.e. regex-like sscanf) correctly. This looks like an msvc compiler bug, it has been there for a long while, so I temporarily disable these warnings in a limited region. Outside of this region, the compiler still treats them as errors. This change does not affect the functionality of MethodMatcher::parse_method_pattern, it can parse class name and method name in a desired manner. > > 2. vm_version_x86.cpp > > Some comments contain characters(Register Trademark) that cannot be represented in the current code page (936). Replacing them with ASCII-characters makes the compiler happy. > > Best Regards, > Yang This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3107 From akozlov at openjdk.java.net Fri Apr 2 13:35:49 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 2 Apr 2021 13:35:49 GMT Subject: RFR: 8264650: Cross-compilation to macos/aarch64 Message-ID: Please review adding necessary flags for cross-compilation on macos/x86 targeting macos/aarch64. All CFLAGS, CXXFLAGS, LDFLAGS need target CPU flag `-arch arm64`. This patch adds the flag along e.g `-m64`. Tested: * cross-compilation on macos/x86 to macos/aarch64: configure --openjdk-target=aarch64-apple-darwin * native compilation on macos/aarch64 * native compilation on macos/x86 ------------- Commit messages: - Append the flag - macos/aarch64 flags for cross compilation Changes: https://git.openjdk.java.net/jdk/pull/3325/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3325&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264650 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3325.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3325/head:pull/3325 PR: https://git.openjdk.java.net/jdk/pull/3325 From erikj at openjdk.java.net Fri Apr 2 16:26:39 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 2 Apr 2021 16:26:39 GMT Subject: RFR: 8264650: Cross-compilation to macos/aarch64 In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 13:28:31 GMT, Anton Kozlov wrote: > Please review adding necessary flags for cross-compilation on macos/x86 targeting macos/aarch64. > > All CFLAGS, CXXFLAGS, LDFLAGS need target CPU flag `-arch arm64`. > This patch adds the flag along e.g `-m64`. > > Tested: > * cross-compilation on macos/x86 to macos/aarch64: configure --openjdk-target=aarch64-apple-darwin > * native compilation on macos/aarch64 > * native compilation on macos/x86 make/autoconf/flags.m4 line 269: > 267: > 268: if test "x$OPENJDK_TARGET_OS" = xmacosx && > 269: test "x$OPENJDK_TARGET_CPU" = xaarch64; then Thank you for getting on this! For symmetry, and to enable cross compilation on both directions, can we add the necessary flag for x64 too? Also, I doubt it matters much, but we could also only set these flags if COMPILE_TYPE=cross. ------------- PR: https://git.openjdk.java.net/jdk/pull/3325 From erikj at openjdk.java.net Fri Apr 2 16:26:39 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 2 Apr 2021 16:26:39 GMT Subject: RFR: 8264650: Cross-compilation to macos/aarch64 In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 16:21:52 GMT, Erik Joelsson wrote: >> Please review adding necessary flags for cross-compilation on macos/x86 targeting macos/aarch64. >> >> All CFLAGS, CXXFLAGS, LDFLAGS need target CPU flag `-arch arm64`. >> This patch adds the flag along e.g `-m64`. >> >> Tested: >> * cross-compilation on macos/x86 to macos/aarch64: configure --openjdk-target=aarch64-apple-darwin >> * native compilation on macos/aarch64 >> * native compilation on macos/x86 > > make/autoconf/flags.m4 line 269: > >> 267: >> 268: if test "x$OPENJDK_TARGET_OS" = xmacosx && >> 269: test "x$OPENJDK_TARGET_CPU" = xaarch64; then > > Thank you for getting on this! > For symmetry, and to enable cross compilation on both directions, can we add the necessary flag for x64 too? > > Also, I doubt it matters much, but we could also only set these flags if COMPILE_TYPE=cross. Thinking again, it doesn't hurt to be explicit about this. Better always set these flags to avoid surprises. ------------- PR: https://git.openjdk.java.net/jdk/pull/3325 From akozlov at openjdk.java.net Fri Apr 2 19:18:58 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 2 Apr 2021 19:18:58 GMT Subject: RFR: 8264650: Cross-compilation to macos/aarch64 [v2] In-Reply-To: References: Message-ID: > Please review adding necessary flags for cross-compilation on macos/x86 targeting macos/aarch64. > > All CFLAGS, CXXFLAGS, LDFLAGS need target CPU flag `-arch arm64`. > This patch adds the flag along e.g `-m64`. > > Tested: > * cross-compilation > * macos/x86 -> macos/aarch64: configure --openjdk-target=aarch64-apple-darwin > * macos/aarch64 -> macos/x86: configure --openjdk-target=x86_64-apple-darwin > * native compilation: > * macos/aarch64 > * macos/x86 Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Add both ways cross-compilation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3325/files - new: https://git.openjdk.java.net/jdk/pull/3325/files/3938a473..df62dd07 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3325&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3325&range=00-01 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3325.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3325/head:pull/3325 PR: https://git.openjdk.java.net/jdk/pull/3325 From akozlov at openjdk.java.net Fri Apr 2 19:24:29 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 2 Apr 2021 19:24:29 GMT Subject: RFR: 8264650: Cross-compilation to macos/aarch64 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 16:23:05 GMT, Erik Joelsson wrote: >> make/autoconf/flags.m4 line 269: >> >>> 267: >>> 268: if test "x$OPENJDK_TARGET_OS" = xmacosx && >>> 269: test "x$OPENJDK_TARGET_CPU" = xaarch64; then >> >> Thank you for getting on this! >> For symmetry, and to enable cross compilation on both directions, can we add the necessary flag for x64 too? >> >> Also, I doubt it matters much, but we could also only set these flags if COMPILE_TYPE=cross. > > Thinking again, it doesn't hurt to be explicit about this. Better always set these flags to avoid surprises. Cool, I haven't thought it is possible, although clearly it should be :) Thanks! Fixed by always setting the flag. I also rely on Github Action to check this with Xcode 11.3.1, it seems to be fine https://github.com/AntonKozlov/jdk/runs/2256008843 ------------- PR: https://git.openjdk.java.net/jdk/pull/3325 From erikj at openjdk.java.net Fri Apr 2 21:46:27 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 2 Apr 2021 21:46:27 GMT Subject: RFR: 8264650: Cross-compilation to macos/aarch64 [v2] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 19:18:58 GMT, Anton Kozlov wrote: >> Please review adding necessary flags for cross-compilation on macos/x86 targeting macos/aarch64. >> >> All CFLAGS, CXXFLAGS, LDFLAGS need target CPU flag `-arch arm64`. >> This patch adds the flag along e.g `-m64`. >> >> Tested: >> * cross-compilation >> * macos/x86 -> macos/aarch64: configure --openjdk-target=aarch64-apple-darwin >> * macos/aarch64 -> macos/x86: configure --openjdk-target=x86_64-apple-darwin >> * native compilation: >> * macos/aarch64 >> * macos/x86 > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Add both ways cross-compilation Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3325 From akozlov at openjdk.java.net Mon Apr 5 07:01:36 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 5 Apr 2021 07:01:36 GMT Subject: Integrated: 8264650: Cross-compilation to macos/aarch64 In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 13:28:31 GMT, Anton Kozlov wrote: > Please review adding necessary flags for cross-compilation on macos/x86 targeting macos/aarch64. > > All CFLAGS, CXXFLAGS, LDFLAGS need target CPU flag `-arch arm64`. > This patch adds the flag along e.g `-m64`. > > Tested: > * cross-compilation > * macos/x86 -> macos/aarch64: configure --openjdk-target=aarch64-apple-darwin > * macos/aarch64 -> macos/x86: configure --openjdk-target=x86_64-apple-darwin > * native compilation: > * macos/aarch64 > * macos/x86 This pull request has now been integrated. Changeset: 7f9ece23 Author: Anton Kozlov Committer: Vladimir Kempik URL: https://git.openjdk.java.net/jdk/commit/7f9ece23 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod 8264650: Cross-compilation to macos/aarch64 Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3325 From akozlov at openjdk.java.net Tue Apr 6 06:22:47 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 6 Apr 2021 06:22:47 GMT Subject: RFR: 8263856: Github Actions for macos/aarch64 cross-build [v2] In-Reply-To: References: Message-ID: <5EIQ_d9BDHCOy4uo5O8P-hAUTT2e2Ofz3y_DBaNuVmM=.135f6beb-f203-44c3-9d5c-a446d13464e7@github.com> > Please review a change that adds cross-compiled macos/aarch64 platform build into Github Actions test workflow. > > The steps are basically copy-paste of macos/x86-64 build with the necessary platform name adjustments. A default XCode is also used, as macos/aarch64 build requires XCode 12+. > > I've checked the produced build (can be found in https://github.com/AntonKozlov/jdk/actions/runs/667527036), it starts on the actual aarch64 machine. Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Specify Xcode version; don't use --extra-{c,cxx,ld}flags - Merge remote-tracking branch 'upstream/jdk/master' into 8263856-gha-macos-aarch64 - Add macos/aarch64 build workflow ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3270/files - new: https://git.openjdk.java.net/jdk/pull/3270/files/3cc31743..215f4dda Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3270&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3270&range=00-01 Stats: 23610 lines in 431 files changed: 17737 ins; 3221 del; 2652 mod Patch: https://git.openjdk.java.net/jdk/pull/3270.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3270/head:pull/3270 PR: https://git.openjdk.java.net/jdk/pull/3270 From akozlov at openjdk.java.net Tue Apr 6 10:06:37 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 6 Apr 2021 10:06:37 GMT Subject: RFR: 8263856: Github Actions for macos/aarch64 cross-build [v2] In-Reply-To: <0qjy-HoyjwGGs5ehdgVKHjqJ8ffBNXkyppTxpG1G7Bs=.9abeac8b-5746-4a85-a55b-8c8037073292@github.com> References: <0qjy-HoyjwGGs5ehdgVKHjqJ8ffBNXkyppTxpG1G7Bs=.9abeac8b-5746-4a85-a55b-8c8037073292@github.com> Message-ID: On Tue, 30 Mar 2021 16:29:49 GMT, Erik Joelsson wrote: >> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Specify Xcode version; don't use --extra-{c,cxx,ld}flags >> - Merge remote-tracking branch 'upstream/jdk/master' into 8263856-gha-macos-aarch64 >> - Add macos/aarch64 build workflow > > .github/workflows/submit.yml line 1444: > >> 1442: --with-conf-name=macos-aarch64 >> 1443: --openjdk-target=aarch64-apple-darwin >> 1444: --with-extra-cflags="-arch arm64" > > If configure isn't adding these flags automatically, that's something that we should fix. Thanks for review! The problem with flags is resolved by merging in master with https://bugs.openjdk.java.net/browse/JDK-8264650 The Xcode version if fixed to 12.4, which is consistent with the current state of PR #3258 (https://bugs.openjdk.java.net/browse/JDK-8264224) ------------- PR: https://git.openjdk.java.net/jdk/pull/3270 From erikj at openjdk.java.net Tue Apr 6 12:44:30 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 6 Apr 2021 12:44:30 GMT Subject: RFR: 8263856: Github Actions for macos/aarch64 cross-build [v2] In-Reply-To: <5EIQ_d9BDHCOy4uo5O8P-hAUTT2e2Ofz3y_DBaNuVmM=.135f6beb-f203-44c3-9d5c-a446d13464e7@github.com> References: <5EIQ_d9BDHCOy4uo5O8P-hAUTT2e2Ofz3y_DBaNuVmM=.135f6beb-f203-44c3-9d5c-a446d13464e7@github.com> Message-ID: <1IIEC0tKX9IQplHIFUlirqlpdufG82kxzere8RwTDp8=.dea3007b-7ce4-43a5-a424-304e434037c4@github.com> On Tue, 6 Apr 2021 06:22:47 GMT, Anton Kozlov wrote: >> Please review a change that adds cross-compiled macos/aarch64 platform build into Github Actions test workflow. >> >> The steps are basically copy-paste of macos/x86-64 build with the necessary platform name adjustments. Xcode 12.4 is also used for as macos/aarch64 build. >> >> I've checked the produced build (can be found in https://github.com/AntonKozlov/jdk/actions/runs/667527036), it starts on the actual aarch64 machine. > > Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Specify Xcode version; don't use --extra-{c,cxx,ld}flags > - Merge remote-tracking branch 'upstream/jdk/master' into 8263856-gha-macos-aarch64 > - Add macos/aarch64 build workflow Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3270 From robin.westberg at oracle.com Tue Apr 6 13:20:28 2021 From: robin.westberg at oracle.com (Robin Westberg) Date: Tue, 6 Apr 2021 13:20:28 +0000 Subject: CMake replacing Autotools? In-Reply-To: <8093c785-643f-a44a-2688-86b3532427d7@grueninger.de> References: <9a4d5214-1dcd-3d73-b343-1ec37cea612e@grueninger.de> <8973d5a7-ab85-a592-12b8-35002c94350a@oracle.com> <8093c785-643f-a44a-2688-86b3532427d7@grueninger.de> Message-ID: <4B70A19C-1AF3-4AFD-9C47-3521EB1E1D9C@oracle.com> Hi Christoph, > On 19 Mar 2021, at 00:00, Christoph Gr?ninger wrote: > > ... > > 2. More choices to actually build the project: Use integrated build > tools of IDEs (Visual Studio, Xcode) or use Ninja, which is faster than > gmake > > ... > > 4. CMake is better supported by IDEs like Visual Studio, Qt Creator, > KDevelop. Regarding the IDE support points, it?s possible to generate a CMakeLists.txt from the compile_commands.json file created when building using the current make system. You could then use CMake to generate a native project file for your IDE of choice, and use that for compiling and debugging HotSpot (final linking etc would still be done by make). I have a prototype for this that worked reasonably well with at least Xcode, CLion and Visual Studio as I remember it. If this sounds interesting to anyone I could perhaps try to make it available somewhere.. :) Best regards, Robin > > 5. A lot of code bases were ported to CMake like KDE, Qt, or LLVM. Their > arguments apply here, too. Also their trade-offs between investment and > benefit. > >> At various times, I have dreamed of replacing the configure script with >> something that is more modern and easy to maintain than this bash/m4 >> mix. We have a very well-defined API for the configure script: the user >> calls "bash configure" in the root directory of the project, with a set >> of --options, and as a result we create a spec.gmk file that defines the >> configuration. This could easily be replicated in another system. But if >> I were to rewrite this from scratch, I'd rather write the whole >> configure logic in Java (apart from some thin shell script logic needed >> to find the boot jdk), rather than trying to shoehorn in our build model >> in CMake. > > I understand your temptation, but writing and maintaining all the > configure/find logic and quirks will be a burden. I'd try to reduce the > build system code to a minimum and rely on a third-party solution to do > as much as possible for me. > > Bye > Christoph > > -- > Als w?r es nix, leb'?ich von [IT] und mach' nur, was ich lieb' > Lebe wie?im?Paradies,?womit hab' ich?das verdient? > Die Wahrheit?ist: Hab' ich nicht, ich bin nur reicher beschenkt > Als jemand in einem armen Land mit dem gleichen Talent > [frei nach Tua von Die Orsons - Oioioiropa] From akozlov at openjdk.java.net Tue Apr 6 13:49:22 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 6 Apr 2021 13:49:22 GMT Subject: Integrated: 8263856: Github Actions for macos/aarch64 cross-build In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 15:03:29 GMT, Anton Kozlov wrote: > Please review a change that adds cross-compiled macos/aarch64 platform build into Github Actions test workflow. > > The steps are basically copy-paste of macos/x86-64 build with the necessary platform name adjustments. Xcode 12.4 is also used for as macos/aarch64 build. > > I've checked the produced build (can be found in https://github.com/AntonKozlov/jdk/actions/runs/667527036), it starts on the actual aarch64 machine. This pull request has now been integrated. Changeset: 114e3c3e Author: Anton Kozlov Committer: Vladimir Kempik URL: https://git.openjdk.java.net/jdk/commit/114e3c3e Stats: 107 lines in 1 file changed: 107 ins; 0 del; 0 mod 8263856: Github Actions for macos/aarch64 cross-build Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3270 From ccleary at openjdk.java.net Wed Apr 7 13:33:12 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Wed, 7 Apr 2021 13:33:12 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio Message-ID: This fix addresses the following warnings which were generated by building JDK API documentation with the `-Xdoclint:all` option enabled: ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47: warning: no comment private String charsetName; ^ ./open/src/java.base/share/classes/java/nio/charset/MalformedInputException.java:44: warning: no comment private int inputLength; ^ ./open/src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java:44: warning: no comment private int inputLength; ^ ./build/linux-x64/support/gensrc/java.base/java/nio/charset/UnsupportedCharsetException.java:47: warning: no comment private String charsetName; ^ ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @param for s private void readObject(ObjectInputStream s) ^ ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @throws for java.lang.ClassNotFoundException private void readObject(ObjectInputStream s) ^ ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:43: warning: no comment private final String file; ^ ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:44: warning: no comment private final String other; ^ ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:43: warning: no comment private int index; ^ ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:42: warning: no comment private String input; ^ ./open/src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java:43: warning: no comment private final String name; ^ Changes to [`genExceptions.sh`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) and the two [`exceptions`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) templates are to address the warnings concerned with `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java` which are generated when `make jdk-image` is run. A CSR will be filed in due course with respect to these changes. ------------- Commit messages: - 8264779: Doc fixes to generated exceptions - 8264779: Update copyrights and formatting - 8264779: Fix doclint warnings in java/nio Changes: https://git.openjdk.java.net/jdk/pull/3376/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3376&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264779 Stats: 48 lines in 9 files changed: 38 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3376.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3376/head:pull/3376 PR: https://git.openjdk.java.net/jdk/pull/3376 From chegar at openjdk.java.net Wed Apr 7 13:37:40 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 7 Apr 2021 13:37:40 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 13:22:44 GMT, Conor Cleary wrote: > This fix addresses the following warnings which were generated by building JDK API documentation with the `-Xdoclint:all` option enabled: > > ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47: warning: no comment > private String charsetName; > ^ > ./open/src/java.base/share/classes/java/nio/charset/MalformedInputException.java:44: warning: no comment > private int inputLength; > ^ > ./open/src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java:44: warning: no comment > private int inputLength; > ^ > ./build/linux-x64/support/gensrc/java.base/java/nio/charset/UnsupportedCharsetException.java:47: warning: no comment > private String charsetName; > ^ > ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @param for s > private void readObject(ObjectInputStream s) > ^ > ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @throws for java.lang.ClassNotFoundException > private void readObject(ObjectInputStream s) > ^ > ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:43: warning: no comment > private final String file; > ^ > ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:44: warning: no comment > private final String other; > ^ > ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:43: warning: no comment > private int index; > ^ > ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:42: warning: no comment > private String input; > ^ > ./open/src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java:43: warning: no comment > private final String name; > ^ > Changes to [`genExceptions.sh`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) and the two [`exceptions`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) templates are to address the warnings concerned with `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java` which are generated when `make jdk-image` is run. A CSR will be filed in due course with respect to these changes. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From alanb at openjdk.java.net Wed Apr 7 13:51:26 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 7 Apr 2021 13:51:26 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 13:22:44 GMT, Conor Cleary wrote: > This fix addresses the following warnings which were generated by building JDK API documentation with the `-Xdoclint:all` option enabled: > > ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47: warning: no comment > private String charsetName; > ^ > ./open/src/java.base/share/classes/java/nio/charset/MalformedInputException.java:44: warning: no comment > private int inputLength; > ^ > ./open/src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java:44: warning: no comment > private int inputLength; > ^ > ./build/linux-x64/support/gensrc/java.base/java/nio/charset/UnsupportedCharsetException.java:47: warning: no comment > private String charsetName; > ^ > ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @param for s > private void readObject(ObjectInputStream s) > ^ > ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @throws for java.lang.ClassNotFoundException > private void readObject(ObjectInputStream s) > ^ > ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:43: warning: no comment > private final String file; > ^ > ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:44: warning: no comment > private final String other; > ^ > ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:43: warning: no comment > private int index; > ^ > ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:42: warning: no comment > private String input; > ^ > ./open/src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java:43: warning: no comment > private final String name; > ^ > Changes to [`genExceptions.sh`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) and the two [`exceptions`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) templates are to address the warnings concerned with `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java` which are generated when `make jdk-image` is run. A CSR will be filed in due course with respect to these changes. src/java.base/share/classes/java/nio/file/InvalidPathException.java line 44: > 42: /** > 43: * The invalid input path string. > 44: */ This should probably be "The input string" to be consistent with the getInput method. src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java line 44: > 42: > 43: /** > 44: * The name of the {@code UserPrincipal} that does not exist. Probably best to use "user principal name" so that it is consistent with getName. ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From ccleary at openjdk.java.net Wed Apr 7 14:22:29 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Wed, 7 Apr 2021 14:22:29 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 13:48:00 GMT, Alan Bateman wrote: >> This fix addresses the following warnings which were generated by building JDK API documentation with the `-Xdoclint:all` option enabled: >> >> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47: warning: no comment >> private String charsetName; >> ^ >> ./open/src/java.base/share/classes/java/nio/charset/MalformedInputException.java:44: warning: no comment >> private int inputLength; >> ^ >> ./open/src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java:44: warning: no comment >> private int inputLength; >> ^ >> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/UnsupportedCharsetException.java:47: warning: no comment >> private String charsetName; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @param for s >> private void readObject(ObjectInputStream s) >> ^ >> ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @throws for java.lang.ClassNotFoundException >> private void readObject(ObjectInputStream s) >> ^ >> ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:43: warning: no comment >> private final String file; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:44: warning: no comment >> private final String other; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:43: warning: no comment >> private int index; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:42: warning: no comment >> private String input; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java:43: warning: no comment >> private final String name; >> ^ >> Changes to [`genExceptions.sh`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) and the two [`exceptions`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) templates are to address the warnings concerned with `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java` which are generated when `make jdk-image` is run. A CSR will be filed in due course with respect to these changes. > > src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java line 44: > >> 42: >> 43: /** >> 44: * The name of the {@code UserPrincipal} that does not exist. > > Probably best to use "user principal name" so that it is consistent with getName. Thanks Alan, will update as you suggest shortly for both your comments (also thanks for adding the nio label!) ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From ccleary at openjdk.java.net Wed Apr 7 14:40:48 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Wed, 7 Apr 2021 14:40:48 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio [v2] In-Reply-To: References: Message-ID: > This fix addresses the following warnings which were generated by building JDK API documentation with the `-Xdoclint:all` option enabled: > > ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47: warning: no comment > private String charsetName; > ^ > ./open/src/java.base/share/classes/java/nio/charset/MalformedInputException.java:44: warning: no comment > private int inputLength; > ^ > ./open/src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java:44: warning: no comment > private int inputLength; > ^ > ./build/linux-x64/support/gensrc/java.base/java/nio/charset/UnsupportedCharsetException.java:47: warning: no comment > private String charsetName; > ^ > ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @param for s > private void readObject(ObjectInputStream s) > ^ > ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @throws for java.lang.ClassNotFoundException > private void readObject(ObjectInputStream s) > ^ > ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:43: warning: no comment > private final String file; > ^ > ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:44: warning: no comment > private final String other; > ^ > ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:43: warning: no comment > private int index; > ^ > ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:42: warning: no comment > private String input; > ^ > ./open/src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java:43: warning: no comment > private final String name; > ^ > Changes to [`genExceptions.sh`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) and the two [`exceptions`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) templates are to address the warnings concerned with `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java` which are generated when `make jdk-image` is run. A CSR will be filed in due course with respect to these changes. Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: 8264779: Simplified comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3376/files - new: https://git.openjdk.java.net/jdk/pull/3376/files/b729d8ed..0b879f15 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3376&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3376&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3376.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3376/head:pull/3376 PR: https://git.openjdk.java.net/jdk/pull/3376 From iris at openjdk.java.net Wed Apr 7 16:17:24 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 7 Apr 2021 16:17:24 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 14:40:48 GMT, Conor Cleary wrote: >> This fix addresses the following warnings which were generated by building JDK API documentation with the `-Xdoclint:all` option enabled: >> >> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47: warning: no comment >> private String charsetName; >> ^ >> ./open/src/java.base/share/classes/java/nio/charset/MalformedInputException.java:44: warning: no comment >> private int inputLength; >> ^ >> ./open/src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java:44: warning: no comment >> private int inputLength; >> ^ >> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/UnsupportedCharsetException.java:47: warning: no comment >> private String charsetName; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @param for s >> private void readObject(ObjectInputStream s) >> ^ >> ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @throws for java.lang.ClassNotFoundException >> private void readObject(ObjectInputStream s) >> ^ >> ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:43: warning: no comment >> private final String file; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:44: warning: no comment >> private final String other; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:43: warning: no comment >> private int index; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:42: warning: no comment >> private String input; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java:43: warning: no comment >> private final String name; >> ^ >> Changes to [`genExceptions.sh`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) and the two [`exceptions`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) templates are to address the warnings concerned with `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java` which are generated when `make jdk-image` is run. A CSR will be filed in due course with respect to these changes. > > Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: > > 8264779: Simplified comments Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From naoto at openjdk.java.net Wed Apr 7 16:21:45 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 7 Apr 2021 16:21:45 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 14:40:48 GMT, Conor Cleary wrote: >> This fix addresses the following warnings which were generated by building JDK API documentation with the `-Xdoclint:all` option enabled: >> >> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47: warning: no comment >> private String charsetName; >> ^ >> ./open/src/java.base/share/classes/java/nio/charset/MalformedInputException.java:44: warning: no comment >> private int inputLength; >> ^ >> ./open/src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java:44: warning: no comment >> private int inputLength; >> ^ >> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/UnsupportedCharsetException.java:47: warning: no comment >> private String charsetName; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @param for s >> private void readObject(ObjectInputStream s) >> ^ >> ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @throws for java.lang.ClassNotFoundException >> private void readObject(ObjectInputStream s) >> ^ >> ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:43: warning: no comment >> private final String file; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:44: warning: no comment >> private final String other; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:43: warning: no comment >> private int index; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:42: warning: no comment >> private String input; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java:43: warning: no comment >> private final String name; >> ^ >> Changes to [`genExceptions.sh`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) and the two [`exceptions`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) templates are to address the warnings concerned with `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java` which are generated when `make jdk-image` is run. A CSR will be filed in due course with respect to these changes. > > Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: > > 8264779: Simplified comments src/java.base/share/classes/java/nio/charset/MalformedInputException.java line 45: > 43: > 44: /** > 45: * The length of the input byte sequence. Should this comment also refer to the character sequence? src/java.base/share/classes/java/nio/charset/exceptions line 31: > 29: PACKAGE=java.nio.charset > 30: # This year should only change if the generated source is modified. > 31: COPYRIGHT_YEARS="2000, 2021," Do those modifications to the exception sources end up in a change in `generated` sources? src/java.base/share/classes/java/nio/exceptions line 31: > 29: PACKAGE=java.nio > 30: # This year should only change if the generated source is modified. > 31: COPYRIGHT_YEARS="2000, 2021," Does not seem necessary, as I don't see any changes in java.nio package. ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From lucy at openjdk.java.net Wed Apr 7 18:03:09 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 7 Apr 2021 18:03:09 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch Message-ID: May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. ------------- Commit messages: - Update Copyright Header - Merge branch 'JDK-8264848' of github.com:RealLucy/jdk into JDK-8264848 - 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch - cleaned up some spaces - update copyright headers - 8264173: [s390] Improve Hardware Feature Detection And Reporting - 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch Changes: https://git.openjdk.java.net/jdk/pull/3379/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3379&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264848 Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3379.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3379/head:pull/3379 PR: https://git.openjdk.java.net/jdk/pull/3379 From ccleary at openjdk.java.net Wed Apr 7 18:04:41 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Wed, 7 Apr 2021 18:04:41 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 16:09:22 GMT, Naoto Sato wrote: >> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: >> >> 8264779: Simplified comments > > src/java.base/share/classes/java/nio/charset/MalformedInputException.java line 45: > >> 43: >> 44: /** >> 45: * The length of the input byte sequence. > > Should this comment also refer to the character sequence? It could, maybe something like "The length of the input byte (or character) sequence." would work? > src/java.base/share/classes/java/nio/exceptions line 31: > >> 29: PACKAGE=java.nio >> 30: # This year should only change if the generated source is modified. >> 31: COPYRIGHT_YEARS="2000, 2021," > > Does not seem necessary, as I don't see any changes in java.nio package. This makes changes to the copyright headers of of the generated source files `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java`. These can be found under a jdk build in `support/gensrc` and the headers update after running `make jdk-image`. Perhaps the build is out of date? These changes are harder to track as the source is not checked in. ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From alanb at openjdk.java.net Wed Apr 7 18:08:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 7 Apr 2021 18:08:56 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio [v2] In-Reply-To: References: Message-ID: <-pYKVTpbmpbgrNurQIiM184IGTYqaOS0LWh5TzziV7E=.37390828-1920-48da-9f73-4fde1d1f0734@github.com> On Wed, 7 Apr 2021 14:40:48 GMT, Conor Cleary wrote: >> This fix addresses the following warnings which were generated by building JDK API documentation with the `-Xdoclint:all` option enabled: >> >> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47: warning: no comment >> private String charsetName; >> ^ >> ./open/src/java.base/share/classes/java/nio/charset/MalformedInputException.java:44: warning: no comment >> private int inputLength; >> ^ >> ./open/src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java:44: warning: no comment >> private int inputLength; >> ^ >> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/UnsupportedCharsetException.java:47: warning: no comment >> private String charsetName; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @param for s >> private void readObject(ObjectInputStream s) >> ^ >> ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @throws for java.lang.ClassNotFoundException >> private void readObject(ObjectInputStream s) >> ^ >> ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:43: warning: no comment >> private final String file; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:44: warning: no comment >> private final String other; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:43: warning: no comment >> private int index; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:42: warning: no comment >> private String input; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java:43: warning: no comment >> private final String name; >> ^ >> Changes to [`genExceptions.sh`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) and the two [`exceptions`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) templates are to address the warnings concerned with `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java` which are generated when `make jdk-image` is run. A CSR will be filed in due course with respect to these changes. > > Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: > > 8264779: Simplified comments Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From alanb at openjdk.java.net Wed Apr 7 18:08:57 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 7 Apr 2021 18:08:57 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 18:01:25 GMT, Conor Cleary wrote: >> src/java.base/share/classes/java/nio/charset/MalformedInputException.java line 45: >> >>> 43: >>> 44: /** >>> 45: * The length of the input byte sequence. >> >> Should this comment also refer to the character sequence? > > It could, maybe something like "The length of the input byte (or character) sequence." would work? or just "The length of the input" so that it is consistent with the description of the getInputLength method. ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From naoto at openjdk.java.net Wed Apr 7 18:15:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 7 Apr 2021 18:15:41 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 17:58:58 GMT, Conor Cleary wrote: >> src/java.base/share/classes/java/nio/exceptions line 31: >> >>> 29: PACKAGE=java.nio >>> 30: # This year should only change if the generated source is modified. >>> 31: COPYRIGHT_YEARS="2000, 2021," >> >> Does not seem necessary, as I don't see any changes in java.nio package. > > This makes changes to the copyright headers of of the generated source files `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java`. These can be found under a jdk build in `support/gensrc` and the headers update after running `make jdk-image`. Perhaps the build is out of date? These changes are harder to track as the source is not checked in. That's right. Sorry for the false alarm. ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From naoto at openjdk.java.net Wed Apr 7 18:15:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 7 Apr 2021 18:15:40 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 18:04:48 GMT, Alan Bateman wrote: >> It could, maybe something like "The length of the input byte (or character) sequence." would work? > > or just "The length of the input" so that it is consistent with the description of the getInputLength method. That sounds good. ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From shurailine at openjdk.java.net Wed Apr 7 18:21:04 2021 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Wed, 7 Apr 2021 18:21:04 GMT Subject: RFR: 8264863: Update JCov version to support JDK 17 Message-ID: <00sXCPag6OU6pxhk8r0ZHx1sIpjcfYGOaEbGYtNaFTo=.35da1938-1fdd-4b90-a040-4eefcb22051a@github.com> Use a build which uses ASM bundled into JDK. ------------- Commit messages: - 8264863: Update JCov version to support JDK 17 Changes: https://git.openjdk.java.net/jdk/pull/3380/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3380&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264863 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3380/head:pull/3380 PR: https://git.openjdk.java.net/jdk/pull/3380 From shurailine at openjdk.java.net Wed Apr 7 18:21:05 2021 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Wed, 7 Apr 2021 18:21:05 GMT Subject: RFR: 8264863: Update JCov version to support JDK 17 In-Reply-To: <00sXCPag6OU6pxhk8r0ZHx1sIpjcfYGOaEbGYtNaFTo=.35da1938-1fdd-4b90-a040-4eefcb22051a@github.com> References: <00sXCPag6OU6pxhk8r0ZHx1sIpjcfYGOaEbGYtNaFTo=.35da1938-1fdd-4b90-a040-4eefcb22051a@github.com> Message-ID: <3zheaA8hdPOMaJknHTuUzb4RHnv4RLMkxplRXPQzVOk=.056a3ed5-5157-4192-b5e2-ffa06b9720dd@github.com> On Wed, 7 Apr 2021 18:13:53 GMT, Alexandre Iline wrote: > Use a build which uses ASM bundled into JDK. @erikj79 can you take a look? ------------- PR: https://git.openjdk.java.net/jdk/pull/3380 From erikj at openjdk.java.net Wed Apr 7 18:32:31 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 7 Apr 2021 18:32:31 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 16:32:52 GMT, Lutz Schmidt wrote: > May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. So that's where that warning came from! I don't think the comment needs to mention the warning. Otherwise this looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From erikj at openjdk.java.net Wed Apr 7 18:33:37 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 7 Apr 2021 18:33:37 GMT Subject: RFR: 8264863: Update JCov version to support JDK 17 In-Reply-To: <00sXCPag6OU6pxhk8r0ZHx1sIpjcfYGOaEbGYtNaFTo=.35da1938-1fdd-4b90-a040-4eefcb22051a@github.com> References: <00sXCPag6OU6pxhk8r0ZHx1sIpjcfYGOaEbGYtNaFTo=.35da1938-1fdd-4b90-a040-4eefcb22051a@github.com> Message-ID: <69UnK0JVVTeNIv1E4UH7mBc03V5mq7N7Mk8XVm2FvXI=.93fda923-ba5b-410f-a376-8baf5b0a523e@github.com> On Wed, 7 Apr 2021 18:13:53 GMT, Alexandre Iline wrote: > Use a build which uses ASM bundled into JDK. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3380 From shurailine at openjdk.java.net Wed Apr 7 18:44:19 2021 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Wed, 7 Apr 2021 18:44:19 GMT Subject: Integrated: 8264863: Update JCov version to support JDK 17 In-Reply-To: <00sXCPag6OU6pxhk8r0ZHx1sIpjcfYGOaEbGYtNaFTo=.35da1938-1fdd-4b90-a040-4eefcb22051a@github.com> References: <00sXCPag6OU6pxhk8r0ZHx1sIpjcfYGOaEbGYtNaFTo=.35da1938-1fdd-4b90-a040-4eefcb22051a@github.com> Message-ID: On Wed, 7 Apr 2021 18:13:53 GMT, Alexandre Iline wrote: > Use a build which uses ASM bundled into JDK. This pull request has now been integrated. Changeset: ab3be728 Author: Alexandre Iline URL: https://git.openjdk.java.net/jdk/commit/ab3be728 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8264863: Update JCov version to support JDK 17 Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3380 From ccleary at openjdk.java.net Wed Apr 7 18:45:20 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Wed, 7 Apr 2021 18:45:20 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 18:12:20 GMT, Naoto Sato wrote: >> This makes changes to the copyright headers of of the generated source files `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java`. These can be found under a jdk build in `support/gensrc` and the headers update after running `make jdk-image`. Perhaps the build is out of date? These changes are harder to track as the source is not checked in. > > That's right. Sorry for the false alarm. No worries, better safe than sorry! ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From lucy at openjdk.java.net Wed Apr 7 18:48:01 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 7 Apr 2021 18:48:01 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: > May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: Updated comment per request from erikj79 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3379/files - new: https://git.openjdk.java.net/jdk/pull/3379/files/e8da1ccf..323f5014 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3379&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3379&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3379.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3379/head:pull/3379 PR: https://git.openjdk.java.net/jdk/pull/3379 From lucy at openjdk.java.net Wed Apr 7 18:51:45 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 7 Apr 2021 18:51:45 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch In-Reply-To: References: Message-ID: <-Dyy-drsBENbEuLF4hrfSj_gnxeOql6oYFqXbh6Mhnw=.d2659d93-dce4-41fd-b0b7-6bf3957bd348@github.com> On Wed, 7 Apr 2021 18:29:31 GMT, Erik Joelsson wrote: >> May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. > > So that's where that warning came from! > > I don't think the comment needs to mention the warning. Otherwise this looks good to me. Thank you Erik for having a look. Would you also be willing to mark this PR as reviewed? ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From naoto at openjdk.java.net Wed Apr 7 18:57:29 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 7 Apr 2021 18:57:29 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio [v3] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 18:54:26 GMT, Conor Cleary wrote: >> This fix addresses the following warnings which were generated by building JDK API documentation with the `-Xdoclint:all` option enabled: >> >> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47: warning: no comment >> private String charsetName; >> ^ >> ./open/src/java.base/share/classes/java/nio/charset/MalformedInputException.java:44: warning: no comment >> private int inputLength; >> ^ >> ./open/src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java:44: warning: no comment >> private int inputLength; >> ^ >> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/UnsupportedCharsetException.java:47: warning: no comment >> private String charsetName; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @param for s >> private void readObject(ObjectInputStream s) >> ^ >> ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @throws for java.lang.ClassNotFoundException >> private void readObject(ObjectInputStream s) >> ^ >> ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:43: warning: no comment >> private final String file; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:44: warning: no comment >> private final String other; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:43: warning: no comment >> private int index; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:42: warning: no comment >> private String input; >> ^ >> ./open/src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java:43: warning: no comment >> private final String name; >> ^ >> Changes to [`genExceptions.sh`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) and the two [`exceptions`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) templates are to address the warnings concerned with `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java` which are generated when `make jdk-image` is run. A CSR will be filed in due course with respect to these changes. > > Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: > > 8264779: Shortened parameter comment Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From ccleary at openjdk.java.net Wed Apr 7 18:57:28 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Wed, 7 Apr 2021 18:57:28 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio [v3] In-Reply-To: References: Message-ID: > This fix addresses the following warnings which were generated by building JDK API documentation with the `-Xdoclint:all` option enabled: > > ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47: warning: no comment > private String charsetName; > ^ > ./open/src/java.base/share/classes/java/nio/charset/MalformedInputException.java:44: warning: no comment > private int inputLength; > ^ > ./open/src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java:44: warning: no comment > private int inputLength; > ^ > ./build/linux-x64/support/gensrc/java.base/java/nio/charset/UnsupportedCharsetException.java:47: warning: no comment > private String charsetName; > ^ > ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @param for s > private void readObject(ObjectInputStream s) > ^ > ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @throws for java.lang.ClassNotFoundException > private void readObject(ObjectInputStream s) > ^ > ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:43: warning: no comment > private final String file; > ^ > ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:44: warning: no comment > private final String other; > ^ > ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:43: warning: no comment > private int index; > ^ > ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:42: warning: no comment > private String input; > ^ > ./open/src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java:43: warning: no comment > private final String name; > ^ > Changes to [`genExceptions.sh`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) and the two [`exceptions`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) templates are to address the warnings concerned with `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java` which are generated when `make jdk-image` is run. A CSR will be filed in due course with respect to these changes. Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: 8264779: Shortened parameter comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3376/files - new: https://git.openjdk.java.net/jdk/pull/3376/files/0b879f15..9f36eec4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3376&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3376&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3376.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3376/head:pull/3376 PR: https://git.openjdk.java.net/jdk/pull/3376 From ccleary at openjdk.java.net Wed Apr 7 18:57:29 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Wed, 7 Apr 2021 18:57:29 GMT Subject: RFR: 8264779: Fix doclint warnings in java/nio [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 18:11:43 GMT, Naoto Sato wrote: >> or just "The length of the input" so that it is consistent with the description of the getInputLength method. > > That sounds good. Changed to "The length of the input." in the [most recent commit](https://github.com/openjdk/jdk/pull/3376/commits/9f36eec44dec7cd8f75f787c7d386e26d55e6826). ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From erikj at openjdk.java.net Wed Apr 7 19:01:05 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 7 Apr 2021 19:01:05 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 18:48:01 GMT, Lutz Schmidt wrote: >> May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > Updated comment per request from erikj79 Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From dcubed at openjdk.java.net Wed Apr 7 19:06:40 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 7 Apr 2021 19:06:40 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 18:48:01 GMT, Lutz Schmidt wrote: >> May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > Updated comment per request from erikj79 Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3379 From dcubed at openjdk.java.net Wed Apr 7 19:10:08 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 7 Apr 2021 19:10:08 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 19:03:14 GMT, Daniel D. Daugherty wrote: >> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated comment per request from erikj79 > > Thumbs up. Side bar: I don't quite understand the commit history part of this PR. It looks like this PR was used for something else before it was used for this fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From lucy at openjdk.java.net Wed Apr 7 19:28:38 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 7 Apr 2021 19:28:38 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 19:06:26 GMT, Daniel D. Daugherty wrote: >> Thumbs up. > > Side bar: I don't quite understand the commit history part of this PR. > It looks like this PR was used for something else before it was used > for this fix. @dcubed-ojdk Please just ignore the commit history. For some reason I don't understand, my push of JDK-8264848 was appended to the pushes for JDK-8264173. With previous PRs, that did not happen. Luckily, GitHub was smart enough. Btw, thanks a lot for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From clanger at openjdk.java.net Wed Apr 7 22:02:54 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 7 Apr 2021 22:02:54 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 18:48:01 GMT, Lutz Schmidt wrote: >> May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > Updated comment per request from erikj79 Cool, Lutz, you found it ? ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3379 From mikael at openjdk.java.net Wed Apr 7 22:35:43 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 7 Apr 2021 22:35:43 GMT Subject: RFR: 8264623: Change to Xcode 12.4 for building on Macos at Oracle Message-ID: Switch to Xcode 12.4 for building macosx-x64 at Oracle. The new lldb dependency is needed to ensure that we can collect information when testing on older versions of macOS which do not support Xcode 12.4. ------------- Commit messages: - 8264623: Change to Xcode 12.4 for building on Macos at Oracle Changes: https://git.openjdk.java.net/jdk/pull/3388/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3388&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264623 Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3388.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3388/head:pull/3388 PR: https://git.openjdk.java.net/jdk/pull/3388 From iklam at openjdk.java.net Wed Apr 7 22:54:48 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 7 Apr 2021 22:54:48 GMT Subject: RFR: 8264874: Build interim-langtools for HotSpot only if Graal is enabled Message-ID: Many HotSpot developers make only the `hotspot` target, and copy the resulting `libjvm.so` into an already-build JDK image. HotSpot requires `interim-langtools` only when Graal is enabled. When Graal is disabled, we can avoid building `interim-langtools`. This improves the build time of `make hotspot` by about 20 seconds, or about 15%: Old: $ make clean $ time make hotspot .... real 1m57.905s user 42m22.524s sys 3m7.372s New: $ make clean $ time make hotspot .... real 1m39.916s user 41m59.984s sys 3m3.188s ------------- Commit messages: - 8264874: Build interim-langtools for HotSpot only if Graal is enabled Changes: https://git.openjdk.java.net/jdk/pull/3389/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3389&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264874 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3389.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3389/head:pull/3389 PR: https://git.openjdk.java.net/jdk/pull/3389 From kvn at openjdk.java.net Thu Apr 8 01:18:30 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 01:18:30 GMT Subject: RFR: 8264874: Build interim-langtools for HotSpot only if Graal is enabled In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 22:37:28 GMT, Ioi Lam wrote: > Many HotSpot developers make only the `hotspot` target, and copy the resulting `libjvm.so` into an already-build JDK image. > > HotSpot requires `interim-langtools` only when Graal is enabled. When Graal is disabled, we can avoid building `interim-langtools`. This improves the build time of `make hotspot` by about 20 seconds, or about 15%: > > Old: > $ make clean > $ time make hotspot > .... > real 1m57.905s > user 42m22.524s > sys 3m7.372s > > New: > $ make clean > $ time make hotspot > .... > real 1m39.916s > user 41m59.984s > sys 3m3.188s Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3389 From lucy at openjdk.java.net Thu Apr 8 08:00:09 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 8 Apr 2021 08:00:09 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 21:59:15 GMT, Christoph Langer wrote: >> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated comment per request from erikj79 > > Cool, Lutz, you found it ? Thank you for the review, Christoph! I'll integrate the change today, early afternoon (UTC). ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From erikj at openjdk.java.net Thu Apr 8 12:39:19 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 8 Apr 2021 12:39:19 GMT Subject: RFR: 8264623: Change to Xcode 12.4 for building on Macos at Oracle In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 22:22:55 GMT, Mikael Vidstedt wrote: > Switch to Xcode 12.4 for building macosx-x64 at Oracle. The new lldb dependency is needed to ensure that we can collect information when testing on older versions of macOS which do not support Xcode 12.4. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3388 From erikj at openjdk.java.net Thu Apr 8 12:41:19 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 8 Apr 2021 12:41:19 GMT Subject: RFR: 8264874: Build interim-langtools for HotSpot only if Graal is enabled In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 22:37:28 GMT, Ioi Lam wrote: > Many HotSpot developers make only the `hotspot` target, and copy the resulting `libjvm.so` into an already-build JDK image. > > HotSpot requires `interim-langtools` only when Graal is enabled. When Graal is disabled, we can avoid building `interim-langtools`. This improves the build time of `make hotspot` by about 20 seconds, or about 15%: > > Old: > $ make clean > $ time make hotspot > .... > real 1m57.905s > user 42m22.524s > sys 3m7.372s > > New: > $ make clean > $ time make hotspot > .... > real 1m39.916s > user 41m59.984s > sys 3m3.188s Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3389 From lucy at openjdk.java.net Thu Apr 8 13:40:15 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 8 Apr 2021 13:40:15 GMT Subject: Integrated: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 16:32:52 GMT, Lutz Schmidt wrote: > May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. This pull request has now been integrated. Changeset: 04fa1ed4 Author: Lutz Schmidt URL: https://git.openjdk.java.net/jdk/commit/04fa1ed4 Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch Reviewed-by: erikj, dcubed, clanger ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From kvn at openjdk.java.net Thu Apr 8 15:32:40 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 15:32:40 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler Message-ID: As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: - `jdk.aot` module ? the `jaotc` tool - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution - related HotSpot code guarded by `#if INCLUDE_AOT` Additionally, remove tests as well as code in makefiles related to AoT compilation. Tested hs-tier1-4 ------------- Commit messages: - 8264805: Remove the experimental Ahead-of-Time Compiler Changes: https://git.openjdk.java.net/jdk/pull/3398/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264805 Stats: 26903 lines in 375 files changed: 4 ins; 26703 del; 196 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Thu Apr 8 15:58:39 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 15:58:39 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v2] In-Reply-To: References: Message-ID: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into JDK-8264805 - 8264805: Remove the experimental Ahead-of-Time Compiler ------------- Changes: https://git.openjdk.java.net/jdk/pull/3398/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=01 Stats: 26906 lines in 375 files changed: 4 ins; 26709 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Thu Apr 8 16:17:33 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 16:17:33 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v3] In-Reply-To: References: Message-ID: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into JDK-8264805 - Merge branch 'master' into JDK-8264805 - 8264805: Remove the experimental Ahead-of-Time Compiler ------------- Changes: https://git.openjdk.java.net/jdk/pull/3398/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=02 Stats: 26906 lines in 375 files changed: 4 ins; 26709 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Thu Apr 8 17:24:38 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 17:24:38 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Remove exports from Graal module to jdk.aot ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3398/files - new: https://git.openjdk.java.net/jdk/pull/3398/files/3dbc6210..6cce0f6c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=02-03 Stats: 39 lines in 3 files changed: 0 ins; 36 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398 From coleenp at openjdk.java.net Thu Apr 8 19:35:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 19:35:06 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 15:23:52 GMT, Vladimir Kozlov wrote: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) { This function, its caller and the function in jvmtiRedefineClasses.cpp that calls it can be deleted also, but you can file a separate RFE for that if you want. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From coleenp at openjdk.java.net Thu Apr 8 19:42:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 19:42:06 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot I looked at the changes in oops, runtime, classfile and code directories. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From erikj at openjdk.java.net Thu Apr 8 19:54:07 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 8 Apr 2021 19:54:07 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From stefank at openjdk.java.net Thu Apr 8 20:04:07 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 8 Apr 2021 20:04:07 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot GC changes look good. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Thu Apr 8 20:04:08 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 20:04:08 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 19:58:11 GMT, Stefan Karlsson wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > GC changes look good. > void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) { > This function, its caller and the function in jvmtiRedefineClasses.cpp that calls it can be deleted also, but you can file a separate RFE for that if you want. Thank you, Coleen, for review. I will wait other comments and will remove this code. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Thu Apr 8 20:04:08 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 20:04:08 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 20:00:30 GMT, Vladimir Kozlov wrote: >> GC changes look good. > >> void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) { >> This function, its caller and the function in jvmtiRedefineClasses.cpp that calls it can be deleted also, but you can file a separate RFE for that if you want. > > Thank you, Coleen, for review. I will wait other comments and will remove this code. Thank you, Erik and Stefan. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From iignatyev at openjdk.java.net Thu Apr 8 20:31:11 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 8 Apr 2021 20:31:11 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot Test changes look good to me. ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From coleenp at openjdk.java.net Thu Apr 8 21:03:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 21:03:07 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 20:28:27 GMT, Igor Ignatyev wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > Test changes look good to me. There's a comment above void VM_RedefineClasses::mark_dependent_code(InstanceKlass* ik) { that should be rewritten, so I think we should just file an RFE to remove it afterwards. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Thu Apr 8 21:57:07 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 21:57:07 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 20:59:59 GMT, Coleen Phillimore wrote: > There's a comment above > void VM_RedefineClasses::mark_dependent_code(InstanceKlass* ik) { > that should be rewritten, so I think we should just file an RFE to remove it afterwards. https://bugs.openjdk.java.net/browse/JDK-8264941 ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From dholmes at openjdk.java.net Fri Apr 9 04:35:15 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 9 Apr 2021 04:35:15 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot Hi Vladimir, This looks good to me - I went through all the files. It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ?? I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process. Thanks, David src/hotspot/cpu/x86/compiledIC_x86.cpp line 134: > 132: #ifdef ASSERT > 133: CodeBlob *cb = CodeCache::find_blob_unsafe((address) _call); > 134: assert(cb, "sanity"); Nit: implied boolean - use "cb != NULL" src/hotspot/share/memory/heap.hpp line 174: > 172: bool contains(const void* p) const { return low() <= p && p < high(); } > 173: bool contains_blob(const CodeBlob* blob) const { > 174: const void* start = (void*)blob; start seems redundant now ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From iklam at openjdk.java.net Fri Apr 9 04:46:18 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 9 Apr 2021 04:46:18 GMT Subject: RFR: 8264874: Build interim-langtools for HotSpot only if Graal is enabled In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 01:13:45 GMT, Vladimir Kozlov wrote: >> Many HotSpot developers make only the `hotspot` target, and copy the resulting `libjvm.so` into an already-build JDK image. >> >> HotSpot requires `interim-langtools` only when Graal is enabled. When Graal is disabled, we can avoid building `interim-langtools`. This improves the build time of `make hotspot` by about 20 seconds, or about 15%: >> >> Old: >> $ make clean >> $ time make hotspot >> .... >> real 1m57.905s >> user 42m22.524s >> sys 3m7.372s >> >> New: >> $ make clean >> $ time make hotspot >> .... >> real 1m39.916s >> user 41m59.984s >> sys 3m3.188s > > Good. Thanks @vnkozlov and @erikj79 for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3389 From iklam at openjdk.java.net Fri Apr 9 04:46:19 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 9 Apr 2021 04:46:19 GMT Subject: Integrated: 8264874: Build interim-langtools for HotSpot only if Graal is enabled In-Reply-To: References: Message-ID: <3RTQMrqKHQfEsLDsUrOQAh9Tri-ODVBneYSxa-NXaXk=.e169efd4-8d1e-4656-ab61-b7adde86e79c@github.com> On Wed, 7 Apr 2021 22:37:28 GMT, Ioi Lam wrote: > Many HotSpot developers make only the `hotspot` target, and copy the resulting `libjvm.so` into an already-build JDK image. > > HotSpot requires `interim-langtools` only when Graal is enabled. When Graal is disabled, we can avoid building `interim-langtools`. This improves the build time of `make hotspot` by about 20 seconds, or about 15%: > > Old: > $ make clean > $ time make hotspot > .... > real 1m57.905s > user 42m22.524s > sys 3m7.372s > > New: > $ make clean > $ time make hotspot > .... > real 1m39.916s > user 41m59.984s > sys 3m3.188s This pull request has now been integrated. Changeset: 951f277a Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/951f277a Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8264874: Build interim-langtools for HotSpot only if Graal is enabled Reviewed-by: kvn, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3389 From aph at openjdk.java.net Fri Apr 9 08:18:18 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 9 Apr 2021 08:18:18 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: <7ioJ2_GFIK53zxpqFcYLt9LYDd8WS7ronekRuo6O5Ac=.572d87d5-2f1f-41cf-8c9b-6d018926f0cf@github.com> On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot AArch64 looks fine. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From ccleary at openjdk.java.net Fri Apr 9 08:54:18 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Fri, 9 Apr 2021 08:54:18 GMT Subject: Integrated: 8264779: Fix doclint warnings in java/nio In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 13:22:44 GMT, Conor Cleary wrote: > This fix addresses the following warnings which were generated by building JDK API documentation with the `-Xdoclint:all` option enabled: > > ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47: warning: no comment > private String charsetName; > ^ > ./open/src/java.base/share/classes/java/nio/charset/MalformedInputException.java:44: warning: no comment > private int inputLength; > ^ > ./open/src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java:44: warning: no comment > private int inputLength; > ^ > ./build/linux-x64/support/gensrc/java.base/java/nio/charset/UnsupportedCharsetException.java:47: warning: no comment > private String charsetName; > ^ > ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @param for s > private void readObject(ObjectInputStream s) > ^ > ./open/src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java:81: warning: no @throws for java.lang.ClassNotFoundException > private void readObject(ObjectInputStream s) > ^ > ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:43: warning: no comment > private final String file; > ^ > ./open/src/java.base/share/classes/java/nio/file/FileSystemException.java:44: warning: no comment > private final String other; > ^ > ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:43: warning: no comment > private int index; > ^ > ./open/src/java.base/share/classes/java/nio/file/InvalidPathException.java:42: warning: no comment > private String input; > ^ > ./open/src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java:43: warning: no comment > private final String name; > ^ > Changes to [`genExceptions.sh`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) and the two [`exceptions`](https://github.com/openjdk/jdk/commit/b729d8ed7970737a8a2d4e8aa788df33789faea2) templates are to address the warnings concerned with `UnsupportedCharsetException.java` and `IllegalCharsetNameException.java` which are generated when `make jdk-image` is run. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8264844 This pull request has now been integrated. Changeset: a45733f8 Author: Conor Cleary Committer: Chris Hegarty URL: https://git.openjdk.java.net/jdk/commit/a45733f8 Stats: 48 lines in 9 files changed: 38 ins; 0 del; 10 mod 8264779: Fix doclint warnings in java/nio Reviewed-by: chegar, iris, alanb, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/3376 From shade at openjdk.java.net Fri Apr 9 08:54:18 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Apr 2021 08:54:18 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot Shenandoah parts look good. I have a few minor comments after reading the rest. src/hotspot/cpu/x86/globalDefinitions_x86.hpp line 73: > 71: > 72: #if INCLUDE_JVMCI > 73: #define COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS (EnableJVMCI) Minor nit: can probably drop parentheses here. src/hotspot/share/code/compiledIC.cpp line 715: > 713: tty->print("interpreted"); > 714: } else { > 715: tty->print("unknown"); We can probably split this cleanup into the minor issue, your call. The benefit of separate issue: backportability. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From leerho at gmail.com Fri Apr 9 06:08:55 2021 From: leerho at gmail.com (leerho) Date: Thu, 8 Apr 2021 23:08:55 -0700 Subject: Build problems on MacOS Message-ID: Hello, I have forked foreign-memaccess+abi in preparation for making some code contributions. However, I have been unsuccessful in getting this project to pass the 'bash configure' phase as detailed below: This is my environment: > MacBook Pro (15-inch, 2018) > 2.6 GHz 6-core, Intel Core i7 > 32GB RAM, 248GB Flash Storage available of 500GB > MacOS: Big Sur, version 11.2.3 > Xcode Version 12.4 (12D4e) > Xcode Command Line Tools are already installed > Apple clang version 12.0.0 (clang-1200.0.32.29) > Target: x86_64-apple-darwin20.3.0 > autoconf 2.71 installed > echo $JAVA_HOME > AdoptOpenJDK 15: > /Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home Note: In the referenced building.md page from the README.md the reference to the blog page (for suggestions on managing multiple Xcode versions) is a bad link. #### When I run *bash configure * I get the error: > error: Cannot locate libclang! You can download pre-built llvm > binary from http://llvm.org/releases/download.html, then > specify the > location using --with-libclang Specifying the path to libclang, (it expects clang 9.0.0, which I installed in a parallel directory to the clang 12.0.0, which comes with Xcode.) *bash configure --with-libclang=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/clang/9.0.0* I get the error: > checking libclang version to be used... 9 (default) > checking libclang auxiliary include path... > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include > checking for clang-c/Index.h... no > configure: error: Cannot locate libclang or headers at the specified > locations: > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include > configure exiting with result code 1 I also tried overriding the default version of clang with the option *--with-libclang-version=12.0.0, *which also failed. Any suggestions would be greatly appreciated. Lee. From erik.joelsson at oracle.com Fri Apr 9 16:17:59 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 9 Apr 2021 09:17:59 -0700 Subject: Build problems on MacOS In-Reply-To: References: Message-ID: <3fe97b7b-6d5c-a015-66e0-035cb9471578@oracle.com> Hello Lee, The libclang dependency is specific to the Panama project. I would recommend asking for help on this particular problem on panama-dev. /Erik On 2021-04-08 23:08, leerho wrote: > Hello, > > I have forked foreign-memaccess+abi > in > preparation for making some code contributions. > > However, I have been unsuccessful in getting this project to pass the 'bash > configure' phase as detailed below: > > This is my environment: > >> MacBook Pro (15-inch, 2018) >> 2.6 GHz 6-core, Intel Core i7 >> 32GB RAM, 248GB Flash Storage available of 500GB >> MacOS: Big Sur, version 11.2.3 >> Xcode Version 12.4 (12D4e) >> Xcode Command Line Tools are already installed >> Apple clang version 12.0.0 (clang-1200.0.32.29) >> Target: x86_64-apple-darwin20.3.0 >> autoconf 2.71 installed >> echo $JAVA_HOME >> AdoptOpenJDK 15: >> /Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home > > Note: In the referenced building.md > > page > from the README.md the reference to the blog page (for suggestions on > managing multiple Xcode versions) > is > a bad link. > > #### > When I run > *bash configure * > I get the error: > >> error: Cannot locate libclang! You can download pre-built llvm >> binary from http://llvm.org/releases/download.html, then >> specify the >> location using --with-libclang > > Specifying the path to libclang, (it expects clang 9.0.0, which I installed > in a parallel directory to the clang 12.0.0, which comes with Xcode.) > *bash configure > --with-libclang=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/clang/9.0.0* > I get the error: > >> checking libclang version to be used... 9 (default) >> checking libclang auxiliary include path... >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include >> checking for clang-c/Index.h... no >> configure: error: Cannot locate libclang or headers at the specified >> locations: >> >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib >> >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include >> configure exiting with result code 1 > > I also tried overriding the default version of clang with the option > *--with-libclang-version=12.0.0, > *which also failed. > > Any suggestions would be greatly appreciated. > > Lee. From iveresov at openjdk.java.net Fri Apr 9 16:41:20 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 9 Apr 2021 16:41:20 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com> On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 1184: > 1182: } > 1183: } else if (jvmci_env()->isa_HotSpotMetaspaceConstantImpl(constant)) { > 1184: if (!_immutable_pic_compilation) { All _immutable_pic_compilation mentions can be removed as well. It is true only for AOT compiles produced by Graal. It's never going to be used without AOT. src/hotspot/share/oops/instanceKlass.hpp line 257: > 255: _misc_declares_nonstatic_concrete_methods = 1 << 6, // directly declares non-static, concrete methods > 256: _misc_has_been_redefined = 1 << 7, // class has been redefined > 257: _unused = 1 << 8, // Any particular reason we don't want to remove this gap? ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From iklam at openjdk.java.net Fri Apr 9 16:58:23 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 9 Apr 2021 16:58:23 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot LGTM. Just a small nit. src/hotspot/share/oops/methodCounters.cpp line 77: > 75: } > 76: > 77: void MethodCounters::metaspace_pointers_do(MetaspaceClosure* it) { MethodCounters::metaspace_pointers_do can be removed altogether (also need to remove the declaration in methodCounter.hpp). ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 17:13:17 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 17:13:17 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 04:32:14 GMT, David Holmes wrote: > Hi Vladimir, > > This looks good to me - I went through all the files. > > It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ?? > > I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process. > > Thanks, > David Thank you, David. We thought that we could use fingerprint code for other cases that is why we did not put it under `#if INCLUDE_AOT`. I filed CSR for AOT product flags removal: https://bugs.openjdk.java.net/browse/JDK-8265000 ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 17:42:27 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 17:42:27 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 17:09:58 GMT, Vladimir Kozlov wrote: >> Hi Vladimir, >> >> This looks good to me - I went through all the files. >> >> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ?? >> >> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process. >> >> Thanks, >> David > >> Hi Vladimir, >> >> This looks good to me - I went through all the files. >> >> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ?? >> >> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process. >> >> Thanks, >> David > > Thank you, David. > We thought that we could use fingerprint code for other cases that is why we did not put it under `#if INCLUDE_AOT`. > I filed CSR for AOT product flags removal: https://bugs.openjdk.java.net/browse/JDK-8265000 Thank you, Igor Ignatyev, Igor Veresov, Ioi, Aleksey and Andrew for reviews. I will update changes based on your comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 17:43:22 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 17:43:22 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler Message-ID: As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: - `jdk.internal.vm.compiler` ? the Graal compiler - `jdk.internal.vm.compiler.management` ? Graal's `MBean` - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests Remove Graal related code in makefiles. Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: src/jdk.internal.vm.compiler/share/classes/module-info.java src/jdk.internal.vm.compiler.management/share/classes/module-info.java @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. Tested hs-tier1-4 ------------- Depends on: https://git.openjdk.java.net/jdk/pull/3398 Commit messages: - 8264806: Remove the experimental JIT compiler Changes: https://git.openjdk.java.net/jdk/pull/3421/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264806 Stats: 441620 lines in 2886 files changed: 0 ins; 441604 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/3421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421 PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Fri Apr 9 17:45:20 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 17:45:20 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 02:44:23 GMT, David Holmes wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/cpu/x86/compiledIC_x86.cpp line 134: > >> 132: #ifdef ASSERT >> 133: CodeBlob *cb = CodeCache::find_blob_unsafe((address) _call); >> 134: assert(cb, "sanity"); > > Nit: implied boolean - use "cb != NULL" done ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 18:23:26 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 18:23:26 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 03:03:33 GMT, David Holmes wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/share/memory/heap.hpp line 174: > >> 172: bool contains(const void* p) const { return low() <= p && p < high(); } >> 173: bool contains_blob(const CodeBlob* blob) const { >> 174: const void* start = (void*)blob; > > start seems redundant now Done: bool contains_blob(const CodeBlob* blob) const { - const void* start = (void*)blob; - return contains(start); + return contains((void*)blob); } ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 18:23:25 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 18:23:25 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 08:29:21 GMT, Aleksey Shipilev wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/cpu/x86/globalDefinitions_x86.hpp line 73: > >> 71: >> 72: #if INCLUDE_JVMCI >> 73: #define COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS (EnableJVMCI) > > Minor nit: can probably drop parentheses here. done ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 18:32:26 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 18:32:26 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 08:32:59 GMT, Aleksey Shipilev wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/share/code/compiledIC.cpp line 715: > >> 713: tty->print("interpreted"); >> 714: } else { >> 715: tty->print("unknown"); > > We can probably split this cleanup into the minor issue, your call. The benefit of separate issue: backportability. Reverted and filed https://bugs.openjdk.java.net/browse/JDK-8265013 ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 18:36:24 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 18:36:24 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com> References: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com> Message-ID: <8rFTTlGuCqN9XzBEbaAAf9R-YhTTqe45jv9Gh7F506w=.67e92697-68c4-4657-abb4-803231a9d1a9@github.com> On Fri, 9 Apr 2021 16:30:41 GMT, Igor Veresov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/share/oops/instanceKlass.hpp line 257: > >> 255: _misc_declares_nonstatic_concrete_methods = 1 << 6, // directly declares non-static, concrete methods >> 256: _misc_has_been_redefined = 1 << 7, // class has been redefined >> 257: _unused = 1 << 8, // > > Any particular reason we don't want to remove this gap? Less changes. We don't get any benefits from removing it. It is opposite - if we need a new value we will use it without changing following values again. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 19:09:25 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 19:09:25 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com> References: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com> Message-ID: On Fri, 9 Apr 2021 16:34:58 GMT, Igor Veresov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 1184: > >> 1182: } >> 1183: } else if (jvmci_env()->isa_HotSpotMetaspaceConstantImpl(constant)) { >> 1184: if (!_immutable_pic_compilation) { > > All _immutable_pic_compilation mentions can be removed as well. It is true only for AOT compiles produced by Graal. It's never going to be used without AOT. Done. I removed _immutable_pic_compilation in JVMCI in Hotspot. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 19:26:22 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 19:26:22 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> References: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> Message-ID: <9RiwxlBLMiREzNvRHU14RQBW33nieUT8-Pmkod_GvtA=.ad51b2f9-f244-4346-8844-9fee39c9aa5b@github.com> On Fri, 9 Apr 2021 16:54:35 GMT, Ioi Lam wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/share/oops/methodCounters.cpp line 77: > >> 75: } >> 76: >> 77: void MethodCounters::metaspace_pointers_do(MetaspaceClosure* it) { > > MethodCounters::metaspace_pointers_do can be removed altogether (also need to remove the declaration in methodCounter.hpp). Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From erikj at openjdk.java.net Fri Apr 9 19:33:34 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 9 Apr 2021 19:33:34 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler In-Reply-To: References: Message-ID: <9YQ-kwVWOO0OzJO1YcfP9nnzUInhLOJ9yiecsYWBIp4=.22504511-4d72-4a41-8092-820501c1ca35@github.com> On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov wrote: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 make/GraalBuilderImage.gmk line 1: > 1: # This file should not be removed. This outout image is this makefile produces is used as input to the separate GraalVM build. make/Main.gmk line 444: > 442: )) > 443: > 444: $(eval $(call SetupTarget, graal-builder-image, \ Same as above, this needs to stay. make/autoconf/spec.gmk.in line 895: > 893: STATIC_LIBS_IMAGE_DIR := $(IMAGES_OUTPUTDIR)/$(STATIC_LIBS_IMAGE_SUBDIR) > 894: > 895: # Graal builder image Like above, this needs to stay. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From lrhodes at verizonmedia.com Fri Apr 9 16:15:10 2021 From: lrhodes at verizonmedia.com (Lee Rhodes) Date: Fri, 9 Apr 2021 09:15:10 -0700 Subject: Fwd: [E] Fwd: Your message to build-dev awaits moderator approval In-Reply-To: References: Message-ID: Hello, I didn't realize the "build-dev at openjdk.java.net" help site was for "members only" and I'm not sure I qualify as a "member", but I have submitted an OCA using this email address (lrhodes at verizonmedia.com), but my help request was submitted using my other email address "leerho at gmail.com ". Copied below is the text of my request for help and the robot response I received. Lee. ########### Hello, I have forked foreign-memaccess+abi in preparation for making some code contributions. However, I have been unsuccessful in getting this project to pass the 'bash configure' phase as detailed below: This is my environment: > MacBook Pro (15-inch, 2018) > 2.6 GHz 6-core, Intel Core i7 > 32GB RAM, 248GB Flash Storage available of 500GB > MacOS: Big Sur, version 11.2.3 > Xcode Version 12.4 (12D4e) > Xcode Command Line Tools are already installed > Apple clang version 12.0.0 (clang-1200.0.32.29) > Target: x86_64-apple-darwin20.3.0 > autoconf 2.71 installed > echo $JAVA_HOME > AdoptOpenJDK 15: > /Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home Note: In the referenced building.md page from the README.md the reference to the blog page (for suggestions on managing multiple Xcode versions) is a bad link. #### When I run *bash configure * I get the error: > error: Cannot locate libclang! You can download pre-built llvm > binary from http://llvm.org/releases/download.html > , > then specify the > location using --with-libclang Specifying the path to libclang, (it expects clang 9.0.0, which I installed in a parallel directory to the clang 12.0.0, which comes with Xcode.) *bash configure --with-libclang=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/clang/9.0.0* I get the error: > checking libclang version to be used... 9 (default) > checking libclang auxiliary include path... > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include > checking for clang-c/Index.h... no > configure: error: Cannot locate libclang or headers at the specified > locations: > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include > configure exiting with result code 1 I also tried overriding the default version of clang with the option *--with-libclang-version=12.0.0, *which also failed. Any suggestions would be greatly appreciated. Lee. ########## ---------- Forwarded message --------- From: Date: Thu, Apr 8, 2021 at 11:09 PM Subject: Your message to build-dev awaits moderator approval To: Your mail to 'build-dev' with the subject Build problems on MacOS Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://mail.openjdk.java.net/mailman/confirm/build-dev/b7be93c4f2e963db037ede37bcda6a8b0711cd3b From mchung at openjdk.java.net Fri Apr 9 20:53:33 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 9 Apr 2021 20:53:33 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot I reviewed the module-loader-map and non-hotspot non-AOT tests. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 21:59:04 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 21:59:04 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v5] In-Reply-To: References: Message-ID: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3398/files - new: https://git.openjdk.java.net/jdk/pull/3398/files/6cce0f6c..71a166c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=03-04 Stats: 36 lines in 9 files changed: 0 ins; 27 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398 From iveresov at openjdk.java.net Fri Apr 9 22:02:33 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 9 Apr 2021 22:02:33 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v5] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 21:59:04 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by iveresov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 22:26:40 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 22:26:40 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: Message-ID: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Restore Graal Builder image makefile - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 - 8264806: Remove the experimental JIT compiler ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3421/files - new: https://git.openjdk.java.net/jdk/pull/3421/files/8ff9b599..a246aaa6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=00-01 Stats: 102 lines in 12 files changed: 66 ins; 27 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421 PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Fri Apr 9 22:33:36 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 22:33:36 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov wrote: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 Thankyou, @erikj79, for review. I restored code as you asked. For some reasons incremental webrev shows update only in Cdiffs. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From dlong at openjdk.java.net Sat Apr 10 04:05:27 2021 From: dlong at openjdk.java.net (Dean Long) Date: Sat, 10 Apr 2021 04:05:27 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> References: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> Message-ID: On Fri, 9 Apr 2021 16:54:51 GMT, Ioi Lam wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > LGTM. Just a small nit. @iklam I thought the fingerprint code was also used by CDS. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From iklam at openjdk.java.net Sat Apr 10 06:08:33 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 10 Apr 2021 06:08:33 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> References: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> Message-ID: On Fri, 9 Apr 2021 16:54:51 GMT, Ioi Lam wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > LGTM. Just a small nit. > @iklam > I thought the fingerprint code was also used by CDS. CDS actually uses a different mechanism (CRC of the classfile bytes) to validate that a class has not changed between archive dumping time and runtime. See https://github.com/openjdk/jdk/blob/5784f6b7f74d0b8081ac107fea172539d57d6020/src/hotspot/share/classfile/systemDictionaryShared.cpp#L1126-L1130 ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From iignatyev at openjdk.java.net Sat Apr 10 15:28:35 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 10 Apr 2021 15:28:35 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 22:30:32 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` ? the Graal compiler >> - `jdk.internal.vm.compiler.management` ? Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Thankyou, @erikj79, for review. I restored code as you asked. > For some reasons incremental webrev shows update only in Cdiffs. none of the full webrevs seem to render even the list of changed files? is it just me? ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From iignatyev at openjdk.java.net Sat Apr 10 15:41:44 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 10 Apr 2021 15:41:44 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` ? the Graal compiler >> - `jdk.internal.vm.compiler.management` ? Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Restore Graal Builder image makefile > - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 > - 8264806: Remove the experimental JIT compiler should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly? what about `vm.graal.enabled` `@requires` property? ------------- Changes requested by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Sat Apr 10 16:35:40 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 10 Apr 2021 16:35:40 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Sat, 10 Apr 2021 15:38:11 GMT, Igor Ignatyev wrote: > should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly? > what about `vm.graal.enabled` `@requires` property? Thank you, @iignatev for looking on changes. I forgot to mention that `Compiler::isGraalEnabled()` returns always false now. Because 94 tests uses `@requires !vm.graal.enabled` I don't want to include them in these changes which are already very big. I am not sure if I should modify tests if GraalVM group wants to run all these tests. Unfortunately changes in `Compiler.java` are listed the last on `Files changed` tab and GitHub has trouble to load these big changes - it takes time to see them. Here `Compiler.java` chnges for review: diff --git a/test/lib/sun/hotspot/code/Compiler.java b/test/lib/sun/hotspot/code/Compiler.java index 99122bd93b8..71288ae4482 100644 --- a/test/lib/sun/hotspot/code/Compiler.java +++ b/test/lib/sun/hotspot/code/Compiler.java @@ -60,33 +60,10 @@ public class Compiler { /** * Check if Graal is used as JIT compiler. * - * Graal is enabled if following conditions are true: - * - we are not in Interpreter mode - * - UseJVMCICompiler flag is true - * - jvmci.Compiler variable is equal to 'graal' - * - TieredCompilation is not used or TieredStopAtLevel is greater than 3 - * No need to check client mode because it set UseJVMCICompiler to false. - * - * @return true if Graal is used as JIT compiler. + * @return false because Graal is removed from JDK. */ public static boolean isGraalEnabled() { - Boolean useCompiler = WB.getBooleanVMFlag("UseCompiler"); - if (useCompiler == null || !useCompiler) { - return false; - } - Boolean useJvmciComp = WB.getBooleanVMFlag("UseJVMCICompiler"); - if (useJvmciComp == null || !useJvmciComp) { - return false; - } - - Boolean tieredCompilation = WB.getBooleanVMFlag("TieredCompilation"); - Long compLevel = WB.getIntxVMFlag("TieredStopAtLevel"); - // if TieredCompilation is enabled and compilation level is <= 3 then no Graal is used - if (tieredCompilation != null && tieredCompilation && - compLevel != null && compLevel <= 3) { - return false; - } - return true; + return false; } ``` ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Sat Apr 10 16:40:48 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 10 Apr 2021 16:40:48 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Sat, 10 Apr 2021 15:38:11 GMT, Igor Ignatyev wrote: >> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Restore Graal Builder image makefile >> - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 >> - 8264806: Remove the experimental JIT compiler > > should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly? > what about `vm.graal.enabled` `@requires` property? @iignatev If you think that I should clean tests anyway I will file follow up RFE to do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From iignatyev at openjdk.java.net Sat Apr 10 16:50:46 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 10 Apr 2021 16:50:46 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Sat, 10 Apr 2021 16:36:54 GMT, Vladimir Kozlov wrote: >> should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly? >> what about `vm.graal.enabled` `@requires` property? > > @iignatev If you think that I should clean tests anyway I will file follow up RFE to do that. > > should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly? > > what about `vm.graal.enabled` `@requires` property? > > Thank you, @iignatev for looking on changes. > > I forgot to mention that `Compiler::isGraalEnabled()` returns always false now. Because 94 tests uses `@requires !vm.graal.enabled` I don't want to include them in these changes which are already very big. I am not sure if I should modify tests if GraalVM group wants to run all these tests. > If you think that I should clean tests anyway I will file follow up RFE to do that. changing `Compiler::isGraalEnabled()` to always return false effectively makes these tests unrunnable for GraalVM group (unless they are keep the modified `sun/hotspot/code/Compiler` and/or `requires/VMProps` in their forks). on top of that, I foresee that there will be more tests incompatible w/ Graal yet given it won't be run/tested in OpenJDK, these tests won't be marked and hence will fail when run w/ Graal. so Graal people will have to either do marking themselves (I guess in both upstream and their fork) or maintain a list of inapplicable tests in a format that works best for their setup. that's to say, I think we should clean up the tests, yet I totally agree there is no need to do it as part of this PR. we can discuss how to do it better for both OpenJDK and GraalVM folks in the follow-up RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From iignatyev at openjdk.java.net Sat Apr 10 16:50:46 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 10 Apr 2021 16:50:46 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` ? the Graal compiler >> - `jdk.internal.vm.compiler.management` ? Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Restore Graal Builder image makefile > - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 > - 8264806: Remove the experimental JIT compiler Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Sat Apr 10 17:44:34 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 10 Apr 2021 17:44:34 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Sat, 10 Apr 2021 16:47:45 GMT, Igor Ignatyev wrote: >> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Restore Graal Builder image makefile >> - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 >> - 8264806: Remove the experimental JIT compiler > > Marked as reviewed by iignatyev (Reviewer). Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032 ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From dnsimon at openjdk.java.net Sun Apr 11 10:28:36 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sun, 11 Apr 2021 10:28:36 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Sat, 10 Apr 2021 17:41:05 GMT, Vladimir Kozlov wrote: >> Marked as reviewed by iignatyev (Reviewer). > > Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032 We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From mikael at openjdk.java.net Mon Apr 12 15:59:35 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Mon, 12 Apr 2021 15:59:35 GMT Subject: Integrated: 8264623: Change to Xcode 12.4 for building on Macos at Oracle In-Reply-To: References: Message-ID: <5IHD-fCYjTOqFXXr86ralwF33huCv5wG0L0smfFCOwQ=.186f416b-b386-428c-9b13-f0f0ebeb1608@github.com> On Wed, 7 Apr 2021 22:22:55 GMT, Mikael Vidstedt wrote: > Switch to Xcode 12.4 for building macosx-x64 at Oracle. The new lldb dependency is needed to ensure that we can collect information when testing on older versions of macOS which do not support Xcode 12.4. This pull request has now been integrated. Changeset: 27f4b271 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/27f4b271 Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod 8264623: Change to Xcode 12.4 for building on Macos at Oracle Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3388 From erikj at openjdk.java.net Mon Apr 12 16:21:50 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 12 Apr 2021 16:21:50 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` ? the Graal compiler >> - `jdk.internal.vm.compiler.management` ? Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: >> >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> >> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Restore Graal Builder image makefile > - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 > - 8264806: Remove the experimental JIT compiler make/common/Modules.gmk line 68: > 66: > 67: # Filter out Graal specific modules > 68: MODULES_FILTER += jdk.internal.vm.compiler If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all? ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Mon Apr 12 17:22:00 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 12 Apr 2021 17:22:00 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Mon, 12 Apr 2021 16:18:32 GMT, Erik Joelsson wrote: >> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Restore Graal Builder image makefile >> - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 >> - 8264806: Remove the experimental JIT compiler > > make/common/Modules.gmk line 68: > >> 66: >> 67: # Filter out Graal specific modules >> 68: MODULES_FILTER += jdk.internal.vm.compiler > > If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all? We filter out because we can't build Graal anymore. But we need these module-info.java files because JVMCI's module-info.java references them: https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/module-info.java#L26 Otherwise we can't build JVMCI which we continue to support. I filed followup RFE to implement Alan's suggestion to use Module API which will allow to remove these files later: https://bugs.openjdk.java.net/browse/JDK-8265091 ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From mikael at openjdk.java.net Mon Apr 12 20:54:17 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Mon, 12 Apr 2021 20:54:17 GMT Subject: RFR: 8264224: Add macosx-aarch64 to Oracle build configurations [v4] In-Reply-To: References: Message-ID: <0-gqa-8I92ztye5jnswrAhME6QOskwvg4ZGKm0C4AjE=.247b2ce9-b635-418b-bcb9-5e6c57a51146@github.com> > This adds the necessary macosx-aarch64 support to the build configurations at Oracle. Mikael Vidstedt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into 8264224-macosx-aarch64 - Merge branch 'master' into 8264224-macosx-aarch64 - Merge branch 'master' into 8264224-macosx-aarch64 - Remove SETFILE override - 8264224: Add macosx-aarch64 to Oracle build configurations ------------- Changes: https://git.openjdk.java.net/jdk/pull/3258/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3258&range=03 Stats: 41 lines in 1 file changed: 25 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/3258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3258/head:pull/3258 PR: https://git.openjdk.java.net/jdk/pull/3258 From mikael at openjdk.java.net Mon Apr 12 20:55:07 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Mon, 12 Apr 2021 20:55:07 GMT Subject: RFR: 8264224: Add macosx-aarch64 to Oracle build configurations [v3] In-Reply-To: <1Vs5on1M3lGHB5AfHPvH1g4iThGKFtjN6BV5ZMPq4Y4=.90589535-02f6-46bc-b994-0055972b1de1@github.com> References: <1Vs5on1M3lGHB5AfHPvH1g4iThGKFtjN6BV5ZMPq4Y4=.90589535-02f6-46bc-b994-0055972b1de1@github.com> Message-ID: <7FnEjlrXA-3bkIwbtWUkOsQxRislqvB1sofZNUQXfRg=.4d6d1544-b17e-425f-b3a3-7324ae428d30@github.com> On Wed, 31 Mar 2021 19:02:46 GMT, Mikael Vidstedt wrote: >> This adds the necessary macosx-aarch64 support to the build configurations at Oracle. > > Mikael Vidstedt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into 8264224-macosx-aarch64 > - Remove SETFILE override > - 8264224: Add macosx-aarch64 to Oracle build configurations The Xcode12.4 pre-requisite change (JDK-8264623) was integrated earlier today and I have merged in latest master in the PR. Please review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3258 From erikj at openjdk.java.net Mon Apr 12 20:58:35 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 12 Apr 2021 20:58:35 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: <7HS0ES8bIxSFNXrIiGQRIgm5w30UQqGIHP7TmfWNDAg=.3a2af723-79ee-4ce8-9e1c-3873b09ed9c0@github.com> On Mon, 12 Apr 2021 17:18:36 GMT, Vladimir Kozlov wrote: >> make/common/Modules.gmk line 68: >> >>> 66: >>> 67: # Filter out Graal specific modules >>> 68: MODULES_FILTER += jdk.internal.vm.compiler >> >> If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all? > > We filter out because we can't build Graal anymore. But we need these module-info.java files because JVMCI's module-info.java references them: > https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/module-info.java#L26 > > Otherwise we can't build JVMCI which we continue to support. > > I filed followup RFE to implement Alan's suggestion to use Module API which will allow to remove these files later: > https://bugs.openjdk.java.net/browse/JDK-8265091 Right, I thought I saw something about modules that Alan commented on, but couldn't find it. All good then. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From erikj at openjdk.java.net Mon Apr 12 20:58:32 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 12 Apr 2021 20:58:32 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` ? the Graal compiler >> - `jdk.internal.vm.compiler.management` ? Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: >> >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> >> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Restore Graal Builder image makefile > - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 > - 8264806: Remove the experimental JIT compiler Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3421 From erikj at openjdk.java.net Mon Apr 12 21:17:00 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 12 Apr 2021 21:17:00 GMT Subject: RFR: 8264224: Add macosx-aarch64 to Oracle build configurations [v4] In-Reply-To: <0-gqa-8I92ztye5jnswrAhME6QOskwvg4ZGKm0C4AjE=.247b2ce9-b635-418b-bcb9-5e6c57a51146@github.com> References: <0-gqa-8I92ztye5jnswrAhME6QOskwvg4ZGKm0C4AjE=.247b2ce9-b635-418b-bcb9-5e6c57a51146@github.com> Message-ID: On Mon, 12 Apr 2021 20:54:17 GMT, Mikael Vidstedt wrote: >> This adds the necessary macosx-aarch64 support to the build configurations at Oracle. > > Mikael Vidstedt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into 8264224-macosx-aarch64 > - Merge branch 'master' into 8264224-macosx-aarch64 > - Merge branch 'master' into 8264224-macosx-aarch64 > - Remove SETFILE override > - 8264224: Add macosx-aarch64 to Oracle build configurations Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3258 From kvn at openjdk.java.net Mon Apr 12 22:10:06 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 12 Apr 2021 22:10:06 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v3] In-Reply-To: References: Message-ID: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Restore Compiler::isGraalEnabled() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3421/files - new: https://git.openjdk.java.net/jdk/pull/3421/files/a246aaa6..9d6bd42c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=01-02 Stats: 25 lines in 1 file changed: 23 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421 PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Mon Apr 12 22:26:09 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 12 Apr 2021 22:26:09 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Sun, 11 Apr 2021 10:25:47 GMT, Doug Simon wrote: >> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Restore Graal Builder image makefile >> - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 >> - 8264806: Remove the experimental JIT compiler > > We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important. @dougxc I restored Compiler::isGraalEnabled(). ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From mikael at openjdk.java.net Tue Apr 13 01:01:57 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 13 Apr 2021 01:01:57 GMT Subject: Integrated: 8264224: Add macosx-aarch64 to Oracle build configurations In-Reply-To: References: Message-ID: <9etWJKnrWrNUMn-PqyOPFBdai6tYqXc7Wg4iIg3vLN4=.3d96b8f6-c4f0-486c-b4a9-3e4ddf22ee6d@github.com> On Tue, 30 Mar 2021 06:25:21 GMT, Mikael Vidstedt wrote: > This adds the necessary macosx-aarch64 support to the build configurations at Oracle. This pull request has now been integrated. Changeset: 008fc75a Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/008fc75a Stats: 41 lines in 1 file changed: 25 ins; 0 del; 16 mod 8264224: Add macosx-aarch64 to Oracle build configurations Reviewed-by: serb, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3258 From lutz.schmidt at sap.com Tue Apr 13 07:51:04 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 13 Apr 2021 07:51:04 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Message-ID: <12835CAD-871B-4B8E-8719-8E09D8AF1F0A@sap.com> Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From dnsimon at openjdk.java.net Tue Apr 13 09:33:11 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 13 Apr 2021 09:33:11 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com> On Sun, 11 Apr 2021 10:25:47 GMT, Doug Simon wrote: >> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Restore Graal Builder image makefile >> - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 >> - 8264806: Remove the experimental JIT compiler > > We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important. > @dougxc I restored Compiler::isGraalEnabled(). Thanks. I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later). ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Tue Apr 13 17:55:20 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 13 Apr 2021 17:55:20 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com> Message-ID: On Tue, 13 Apr 2021 09:30:23 GMT, Doug Simon wrote: >> We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important. > >> @dougxc I restored Compiler::isGraalEnabled(). > > Thanks. I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later). @dougxc Renaming should be done separately. May be use RFE I filed: https://bugs.openjdk.java.net/browse/JDK-8265032 Do you approve these Graal removal changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From dnsimon at openjdk.java.net Tue Apr 13 21:22:14 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 13 Apr 2021 21:22:14 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v3] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 22:10:06 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` ? the Graal compiler >> - `jdk.internal.vm.compiler.management` ? Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: >> >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> >> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Restore Compiler::isGraalEnabled() Approved. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From ngasson at openjdk.java.net Wed Apr 14 09:09:05 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 14 Apr 2021 09:09:05 GMT Subject: RFR: 8265192: [macos_aarch64] configure script fails if GNU uname in PATH Message-ID: With GNU coreutils from Homebrew in the PATH, configure fails on Apple silicon Macs with: checking build system type... Invalid configuration `arm64-apple-darwin20.2.0': machine `arm64-apple' not recognized configure: error: /opt/homebrew/bin/bash /Users/nicgas01/jdk/make/autoconf/build-aux/config.sub arm64-apple-darwin20.2.0 failed configure exiting with result code 1 The system `uname -p` prints "arm" but GNU's version prints "arm64". This patch just extends config.guess to handle this case. ------------- Commit messages: - 8265192: [macos_aarch64] configure script fails if GNU uname in PATH Changes: https://git.openjdk.java.net/jdk/pull/3487/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3487&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265192 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3487.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3487/head:pull/3487 PR: https://git.openjdk.java.net/jdk/pull/3487 From erikj at openjdk.java.net Wed Apr 14 12:47:51 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 14 Apr 2021 12:47:51 GMT Subject: RFR: 8265192: [macos_aarch64] configure script fails if GNU uname in PATH In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 09:02:49 GMT, Nick Gasson wrote: > With GNU coreutils from Homebrew in the PATH, configure fails on Apple > silicon Macs with: > > > checking build system type... Invalid configuration `arm64-apple-darwin20.2.0': machine `arm64-apple' not recognized > configure: error: /opt/homebrew/bin/bash /Users/nicgas01/jdk/make/autoconf/build-aux/config.sub arm64-apple-darwin20.2.0 failed > configure exiting with result code 1 > > > The system `uname -p` prints "arm" but GNU's version prints "arm64". > This patch just extends config.guess to handle this case. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3487 From vkempik at azul.com Wed Apr 14 16:24:36 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 14 Apr 2021 16:24:36 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes In-Reply-To: <12835CAD-871B-4B8E-8719-8E09D8AF1F0A@sap.com> References: <12835CAD-871B-4B8E-8719-8E09D8AF1F0A@sap.com> Message-ID: Hello this backport is pretty much needed in jdk11u-dev as it?s one of prerequests (soft one tho) for jep-391 to apply more cleanly. I was doing this backport multiple times (including to zulu11) and know what a PITA it is. Looking forward for integration of this into 11u. Regards, Vladimir. > 13 ???. 2021 ?., ? 10:51, Schmidt, Lutz ???????(?): > > Dear Community, > > I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 > Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ > Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts > Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve > > Tests: > SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. > > Your effort is very much appreciated! > > Thanks, > Lutz > > P.S.: build-dev on CC: because a small build change is included. > From hohensee at amazon.com Wed Apr 14 17:01:20 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 14 Apr 2021 17:01:20 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Message-ID: <275E669F-DFF5-45ED-AE2D-F691CA6D07EC@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 12:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From lutz.schmidt at sap.com Wed Apr 14 17:05:26 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 14 Apr 2021 17:05:26 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes In-Reply-To: <275E669F-DFF5-45ED-AE2D-F691CA6D07EC@amazon.com> References: <275E669F-DFF5-45ED-AE2D-F691CA6D07EC@amazon.com> Message-ID: Thanks for reviewing, Paul! Best, Lutz ?On 14.04.21, 19:01, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 12:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From vlivanov at openjdk.java.net Wed Apr 14 17:17:40 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 14 Apr 2021 17:17:40 GMT Subject: RFR: 8264188: Improve handling of assembly files in the JDK [v2] In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 10:48:55 GMT, Magnus Ihse Bursie wrote: >> We have a handful of assembly files in the JDK. They have long been left aside, with a "if it ain't broken, don't fix it" attitude. >> >> In the current panama-vector, there is a lot more assembly files incoming, including for the Windows platforrm, which has not existed for a long time in the JDK. >> >> It is time to give assembly files some more love and care. This patch cleans up the handling in the build system, and it unifies between .s and .S files. >> >> For historical reasons, .s has been the suffix used in the posix world to signify assembly output as generated by a compiler, and .S to signify "hand-written" precious assembly. One effect of this is that gcc and clang will run the preprocessor on files named .S but not on files named .s. >> >> All our files are "hand-written" in this sense, and should have the .S suffix. But not all had. On mac, it was even worse, where the files were named .s but the option `-x assembler-with-cpp` was used to force clang to treat them as .S files instead... This change however made the preprocesser try to parse comments of the form >> >> # if (a) { >> >> as preprocessor directives, and balk at them. In one of the files, I had to wrap this in preprocessor comments (`/* ... */`). >> >> We also had inconsistent handling on dependencies. For preprocessed assembly files, it really makes sense to have dependency tracking, exactly as for C/C++ files. Now the dependency tracking in NativeCompilation is simplified, and applies to all files. (The sole exception is Windows assembly, since masm is unable to output dependency information, even though it is able to include files :-(). >> >> This patch has been partly written by Sandhya Viswanathan for the panama-vector repo. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Use OPENJDK_BUILD_CPU_BITS instead Looks good! Thanks a lot for taking care of it. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3198 From naoto at openjdk.java.net Wed Apr 14 21:21:10 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 14 Apr 2021 21:21:10 GMT Subject: RFR: 8258794: Support for CLDR version 39 Message-ID: Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698) ------------- Commit messages: - 8258794: Support for CLDR version 39 - CLDR 38.1 Changes: https://git.openjdk.java.net/jdk/pull/3502/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3502&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258794 Stats: 26326 lines in 815 files changed: 761 ins; 23140 del; 2425 mod Patch: https://git.openjdk.java.net/jdk/pull/3502.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3502/head:pull/3502 PR: https://git.openjdk.java.net/jdk/pull/3502 From joehw at openjdk.java.net Wed Apr 14 21:54:43 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 14 Apr 2021 21:54:43 GMT Subject: RFR: 8258794: Support for CLDR version 39 In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato wrote: > Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698) Naoto, are you testing GitHub ('s ability to handle a large number of files) ;-) Indeed, the majority changes were version and copyright. If you hadn't mentioned the changed class, it would be almost impossible to find it :-) ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3502 From naoto at openjdk.java.net Wed Apr 14 22:01:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 14 Apr 2021 22:01:40 GMT Subject: RFR: 8258794: Support for CLDR version 39 In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato wrote: > Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698) Thanks, Joe. > Naoto, are you testing GitHub ('s ability to handle a large number of files) ;-) CLDR itself has been hosted on GitHub too, so it shouldn't be a problem ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3502 From erikj at openjdk.java.net Wed Apr 14 22:30:13 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 14 Apr 2021 22:30:13 GMT Subject: RFR: 8258794: Support for CLDR version 39 In-Reply-To: References: Message-ID: <5HWDRokYdhdJciJWcGWySJoDe7dTxtIX4nzLA1he1eY=.f67d81f3-8d2d-443a-9f1f-09d5133953fe@github.com> On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato wrote: > Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698) Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3502 From dholmes at openjdk.java.net Wed Apr 14 23:42:51 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Apr 2021 23:42:51 GMT Subject: RFR: 8262501: jdk17 libjvm link failure with --as-needed and clock_gettime in librt Message-ID: The fix for JDK-8246112 put the -lrt link flag in the wrong place, causing it to appear too early in the linker command-line. This changes puts it in the right place. Contributed by: Matthias Klose (~doko) Testing: - local testing by Matthias - tiers 1-3 - GHA builds ------------- Commit messages: - Fixed whitespace - 8262501: jdk17 libjvm link failure with --as-needed and clock_gettime in librt Changes: https://git.openjdk.java.net/jdk/pull/3503/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3503&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262501 Stats: 17 lines in 2 files changed: 9 ins; 7 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3503.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3503/head:pull/3503 PR: https://git.openjdk.java.net/jdk/pull/3503 From ngasson at openjdk.java.net Thu Apr 15 01:46:36 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 15 Apr 2021 01:46:36 GMT Subject: Integrated: 8265192: [macos_aarch64] configure script fails if GNU uname in PATH In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 09:02:49 GMT, Nick Gasson wrote: > With GNU coreutils from Homebrew in the PATH, configure fails on Apple > silicon Macs with: > > > checking build system type... Invalid configuration `arm64-apple-darwin20.2.0': machine `arm64-apple' not recognized > configure: error: /opt/homebrew/bin/bash /Users/nicgas01/jdk/make/autoconf/build-aux/config.sub arm64-apple-darwin20.2.0 failed > configure exiting with result code 1 > > > The system `uname -p` prints "arm" but GNU's version prints "arm64". > This patch just extends config.guess to handle this case. This pull request has now been integrated. Changeset: f4c3efd9 Author: Nick Gasson URL: https://git.openjdk.java.net/jdk/commit/f4c3efd9 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8265192: [macos_aarch64] configure script fails if GNU uname in PATH Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3487 From erikj at openjdk.java.net Thu Apr 15 12:29:36 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 15 Apr 2021 12:29:36 GMT Subject: RFR: 8262501: jdk17 libjvm link failure with --as-needed and clock_gettime in librt In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 23:32:32 GMT, David Holmes wrote: > The fix for JDK-8246112 put the -lrt link flag in the wrong place, causing it to appear too early in the linker command-line. This changes puts it in the right place. > > Contributed by: Matthias Klose (~doko) > > Testing: > - local testing by Matthias > - tiers 1-3 > - GHA builds Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3503 From dholmes at openjdk.java.net Thu Apr 15 13:02:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Apr 2021 13:02:36 GMT Subject: RFR: 8262501: jdk17 libjvm link failure with --as-needed and clock_gettime in librt In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 23:32:32 GMT, David Holmes wrote: > The fix for JDK-8246112 put the -lrt link flag in the wrong place, causing it to appear too early in the linker command-line. This changes puts it in the right place. > > Contributed by: Matthias Klose (~doko) > > Testing: > - local testing by Matthias > - tiers 1-3 > - GHA builds Thanks Erik! ------------- PR: https://git.openjdk.java.net/jdk/pull/3503 From dholmes at openjdk.java.net Thu Apr 15 13:02:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Apr 2021 13:02:36 GMT Subject: Integrated: 8262501: jdk17 libjvm link failure with --as-needed and clock_gettime in librt In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 23:32:32 GMT, David Holmes wrote: > The fix for JDK-8246112 put the -lrt link flag in the wrong place, causing it to appear too early in the linker command-line. This changes puts it in the right place. > > Contributed by: Matthias Klose (~doko) > > Testing: > - local testing by Matthias > - tiers 1-3 > - GHA builds This pull request has now been integrated. Changeset: 81877f7d Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/81877f7d Stats: 17 lines in 2 files changed: 9 ins; 7 del; 1 mod 8262501: jdk17 libjvm link failure with --as-needed and clock_gettime in librt Co-authored-by: Matthias Klose Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3503 From lutz.schmidt at sap.com Thu Apr 15 14:14:41 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 15 Apr 2021 14:14:41 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes In-Reply-To: References: <275E669F-DFF5-45ED-AE2D-F691CA6D07EC@amazon.com> Message-ID: <192F3A84-7CDC-4A3F-90CC-68BA8900E60A@sap.com> Dear all, would somebody please be willing to sponsor this backport patch? Thank you, Lutz ?On 14.04.21, 19:05, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: Thanks for reviewing, Paul! Best, Lutz On 14.04.21, 19:01, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 12:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From hohensee at amazon.com Thu Apr 15 17:55:12 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 15 Apr 2021 17:55:12 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Message-ID: I'll sponsor. ?-----Original Message----- From: "Schmidt, Lutz" Date: Thursday, April 15, 2021 at 7:16 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: RE: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear all, would somebody please be willing to sponsor this backport patch? Thank you, Lutz On 14.04.21, 19:05, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: Thanks for reviewing, Paul! Best, Lutz On 14.04.21, 19:01, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 12:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From hohensee at amazon.com Thu Apr 15 19:02:40 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 15 Apr 2021 19:02:40 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes In-Reply-To: References: Message-ID: <5A04F6E7-CEF3-479E-BE6C-9EDCFD563098@amazon.com> Pushed. ?-----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Thursday, April 15, 2021 at 10:55 AM To: "Schmidt, Lutz" , "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: RE: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes I'll sponsor. -----Original Message----- From: "Schmidt, Lutz" Date: Thursday, April 15, 2021 at 7:16 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: RE: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear all, would somebody please be willing to sponsor this backport patch? Thank you, Lutz On 14.04.21, 19:05, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: Thanks for reviewing, Paul! Best, Lutz On 14.04.21, 19:01, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 12:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From naoto at openjdk.java.net Thu Apr 15 21:31:36 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 15 Apr 2021 21:31:36 GMT Subject: Integrated: 8258794: Support for CLDR version 39 In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato wrote: > Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698) This pull request has now been integrated. Changeset: f6e54f2f Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/f6e54f2f Stats: 26326 lines in 815 files changed: 761 ins; 23140 del; 2425 mod 8258794: Support for CLDR version 39 Reviewed-by: joehw, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3502 From vromero at openjdk.java.net Fri Apr 16 01:15:58 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 16 Apr 2021 01:15:58 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature Message-ID: Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Thanks ------------- Commit messages: - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - JVM related changes - 8260517: Compiler implementation for Sealed Classes Changes: https://git.openjdk.java.net/jdk/pull/3526/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260517 Stats: 450 lines in 56 files changed: 48 ins; 282 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From dholmes at openjdk.java.net Fri Apr 16 02:14:02 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Apr 2021 02:14:02 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v2] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 02:11:10 GMT, Vicente Romero wrote: >> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) >> >> Thanks >> >> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > removing javax.lang.model changes Hi Vincente, Hotspot and hotspot tests all look fine. One query: why was this test removed? test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java is that functionality tested elsewhere? (The other deleted test seemed obviously trivial.) Thanks, David src/hotspot/share/classfile/classFileParser.cpp line 3916: > 3914: record_attribute_start = cfs->current(); > 3915: record_attribute_length = attribute_length; > 3916: } else if (_major_version >= JAVA_17_VERSION) { Can you update the comment at L3932 to say JAVA_17_VERSION please. src/hotspot/share/classfile/classFileParser.hpp line 345: > 343: > 344: bool supports_sealed_types(); > 345: bool supports_records(); Good catch! ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3526 From vromero at openjdk.java.net Fri Apr 16 02:14:01 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 16 Apr 2021 02:14:01 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v2] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing javax.lang.model changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/6e2a99c6..5aef5108 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=00-01 Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From vromero at openjdk.java.net Fri Apr 16 03:26:34 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 16 Apr 2021 03:26:34 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v2] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 02:10:05 GMT, David Holmes wrote: > Hi Vicente, > > Hotspot and hotspot tests all look fine. One query: why was this test removed? > > test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java > > is that functionality tested elsewhere? (The other deleted test seemed obviously trivial.) > > Thanks, > David Hi David, thanks for your comments, yes regarding `test test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java`, it was removed because the functionality is tested in `test/langtools/tools/javac/sealed/SealedCompilationTests.java` > src/hotspot/share/classfile/classFileParser.cpp line 3916: > >> 3914: record_attribute_start = cfs->current(); >> 3915: record_attribute_length = attribute_length; >> 3916: } else if (_major_version >= JAVA_17_VERSION) { > > Can you update the comment at L3932 to say JAVA_17_VERSION please. sure ------------- PR: https://git.openjdk.java.net/jdk/pull/3526 From vromero at openjdk.java.net Fri Apr 16 03:35:06 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 16 Apr 2021 03:35:06 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v3] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: updating comment after review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/5aef5108..8ebe56fd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From lutz.schmidt at sap.com Fri Apr 16 10:15:34 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 16 Apr 2021 10:15:34 +0000 Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes In-Reply-To: <5A04F6E7-CEF3-479E-BE6C-9EDCFD563098@amazon.com> References: <5A04F6E7-CEF3-479E-BE6C-9EDCFD563098@amazon.com> Message-ID: Wonderful! Thank you, Paul. Regards, Lutz ?On 15.04.21, 21:02, "Hohensee, Paul" wrote: Pushed. -----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Thursday, April 15, 2021 at 10:55 AM To: "Schmidt, Lutz" , "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: RE: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes I'll sponsor. -----Original Message----- From: "Schmidt, Lutz" Date: Thursday, April 15, 2021 at 7:16 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: RE: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear all, would somebody please be willing to sponsor this backport patch? Thank you, Lutz On 14.04.21, 19:05, "jdk-updates-dev on behalf of Schmidt, Lutz" wrote: Thanks for reviewing, Paul! Best, Lutz On 14.04.21, 19:01, "Hohensee, Paul" wrote: Lgtm. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Schmidt, Lutz" Date: Tuesday, April 13, 2021 at 12:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: build-dev Subject: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes Dear Community, I would appreciate receiving reviews for this downport change. It consists of many modified files. In most cases, it?s only #include statement changes, caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. The change did not apply cleanly, for the most part because of this split. The other merge conflicts were trivial (include rearrangement and copyright headers). Original bug: https://bugs.openjdk.java.net/browse/JDK-8233787 Downport webrev: https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/ Merge conflicts: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts Conflict resolve diff: https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve Tests: SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No issues found. Your effort is very much appreciated! Thanks, Lutz P.S.: build-dev on CC: because a small build change is included. From shade at openjdk.java.net Fri Apr 16 12:03:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 16 Apr 2021 12:03:53 GMT Subject: RFR: 8265343: Update Debian-based cross-compilation recipes Message-ID: After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do not need to set a whole lot of options for cross-compiled builds. Docs should be updated to reflect that fact. Also put in more configurations that are buildable with Debian ports: these build routinely at [builds.shipilev.net](https://builds.shipilev.net/openjdk-jdk/). Maybe @glaubitz wants to chime in here too :) ------------- Commit messages: - 8265343: Update Debian-based cross-compilation recipes Changes: https://git.openjdk.java.net/jdk/pull/3545/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3545&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265343 Stats: 132 lines in 2 files changed: 88 ins; 17 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/3545.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3545/head:pull/3545 PR: https://git.openjdk.java.net/jdk/pull/3545 From erikj at openjdk.java.net Fri Apr 16 13:51:35 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 16 Apr 2021 13:51:35 GMT Subject: RFR: 8265343: Update Debian-based cross-compilation recipes In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 11:57:32 GMT, Aleksey Shipilev wrote: > After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do not need to set a whole lot of options for cross-compiled builds. Docs should be updated to reflect that fact. Also put in more configurations that are buildable with Debian ports: these build routinely at [builds.shipilev.net](https://builds.shipilev.net/openjdk-jdk/). > > Maybe @glaubitz wants to chime in here too :) Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3545 From erikj at openjdk.java.net Fri Apr 16 19:06:00 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 16 Apr 2021 19:06:00 GMT Subject: RFR: JDK-8265371: Change to Visual Studio 2019 16.9.3 for building on Windows at Oracle Message-ID: Oracle is updating the minor version of Visual Studio for building the JDK to 16.9.3. ------------- Commit messages: - JDK-8265371: Change to Visual Studio 2019 16.9.3 for building on Windows at Oracle Changes: https://git.openjdk.java.net/jdk/pull/3550/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3550&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265371 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3550.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3550/head:pull/3550 PR: https://git.openjdk.java.net/jdk/pull/3550 From erikj at openjdk.java.net Fri Apr 16 19:27:59 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 16 Apr 2021 19:27:59 GMT Subject: RFR: JDK-8265373: Change to GCC 10.3 for building on Linux at Oracle Message-ID: Oracle is updating the version of GCC for building the JDK to 10.3. In addition to the version bump, I'm also enabling cross compilation OOTB using jib from a linux-aarch64 to linux-x64 binaries, which was the last missing combination. (Native x64, native aarch64, cross from x64 to aarch64 all worked already and will continue to do so.) ------------- Commit messages: - Finalize devkits - Merge branch 'master' into gcc-10.3-devkit - Corrected condition for --build-devkit - Enable cross building from aarch64 to x64 - Use GCC 10.3 by default for devkit creation Changes: https://git.openjdk.java.net/jdk/pull/3551/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3551&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265373 Stats: 27 lines in 2 files changed: 14 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3551.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3551/head:pull/3551 PR: https://git.openjdk.java.net/jdk/pull/3551 From mikael at openjdk.java.net Fri Apr 16 19:34:42 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 16 Apr 2021 19:34:42 GMT Subject: RFR: JDK-8265371: Change to Visual Studio 2019 16.9.3 for building on Windows at Oracle In-Reply-To: References: Message-ID: <7v5zCQIXZfhxWiUhoDtx3YhbG4wsvAIkFnh7WOPsR0Y=.5e596564-41f7-448c-a137-3ca53e317ee5@github.com> On Fri, 16 Apr 2021 18:58:27 GMT, Erik Joelsson wrote: > Oracle is updating the minor version of Visual Studio for building the JDK to 16.9.3. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3550 From mikael at openjdk.java.net Fri Apr 16 19:39:36 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 16 Apr 2021 19:39:36 GMT Subject: RFR: JDK-8265373: Change to GCC 10.3 for building on Linux at Oracle In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 19:21:11 GMT, Erik Joelsson wrote: > Oracle is updating the version of GCC for building the JDK to 10.3. > > In addition to the version bump, I'm also enabling cross compilation OOTB using jib from a linux-aarch64 to linux-x64 binaries, which was the last missing combination. (Native x64, native aarch64, cross from x64 to aarch64 all worked already and will continue to do so.) make/conf/jib-profiles.js line 426: > 424: (input.build_cpu == "x64" ? common.configure_args_64bit : "--openjdk-target=x86_64-linux-gnu"), > 425: "--with-zlib=system", "--disable-dtrace", > 426: (input.build_cpu != "x64" ? "--openjdk-target=x86_64-linux-gnu" : null), Doesn't this add `--openjdk-target=x86_64-linux-gnu` twice when build_cpu is not "x64"? ------------- PR: https://git.openjdk.java.net/jdk/pull/3551 From erikj at openjdk.java.net Fri Apr 16 20:36:05 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 16 Apr 2021 20:36:05 GMT Subject: RFR: JDK-8265373: Change to GCC 10.3 for building on Linux at Oracle [v2] In-Reply-To: References: Message-ID: > Oracle is updating the version of GCC for building the JDK to 10.3. > > In addition to the version bump, I'm also enabling cross compilation OOTB using jib from a linux-aarch64 to linux-x64 binaries, which was the last missing combination. (Native x64, native aarch64, cross from x64 to aarch64 all worked already and will continue to do so.) Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Fix configure args for linux-x64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3551/files - new: https://git.openjdk.java.net/jdk/pull/3551/files/9c4b1b6c..dec3ae2a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3551&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3551&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3551.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3551/head:pull/3551 PR: https://git.openjdk.java.net/jdk/pull/3551 From erikj at openjdk.java.net Fri Apr 16 20:36:06 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 16 Apr 2021 20:36:06 GMT Subject: RFR: JDK-8265373: Change to GCC 10.3 for building on Linux at Oracle [v2] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 19:35:26 GMT, Mikael Vidstedt wrote: >> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix configure args for linux-x64 > > make/conf/jib-profiles.js line 426: > >> 424: (input.build_cpu == "x64" ? common.configure_args_64bit : "--openjdk-target=x86_64-linux-gnu"), >> 425: "--with-zlib=system", "--disable-dtrace", >> 426: (input.build_cpu != "x64" ? "--openjdk-target=x86_64-linux-gnu" : null), > > Doesn't this add `--openjdk-target=x86_64-linux-gnu` twice when build_cpu is not "x64"? You are correct, I never finished that edit. Uploaded fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/3551 From mikael at openjdk.java.net Fri Apr 16 20:49:34 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 16 Apr 2021 20:49:34 GMT Subject: RFR: JDK-8265373: Change to GCC 10.3 for building on Linux at Oracle [v2] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 20:36:05 GMT, Erik Joelsson wrote: >> Oracle is updating the version of GCC for building the JDK to 10.3. >> >> In addition to the version bump, I'm also enabling cross compilation OOTB using jib from a linux-aarch64 to linux-x64 binaries, which was the last missing combination. (Native x64, native aarch64, cross from x64 to aarch64 all worked already and will continue to do so.) > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix configure args for linux-x64 Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3551 From naoto at openjdk.java.net Fri Apr 16 21:16:59 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 16 Apr 2021 21:16:59 GMT Subject: RFR: 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter Message-ID: Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`). ------------- Commit messages: - 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter Changes: https://git.openjdk.java.net/jdk/pull/3553/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3553&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265375 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3553.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3553/head:pull/3553 PR: https://git.openjdk.java.net/jdk/pull/3553 From joehw at openjdk.java.net Fri Apr 16 21:29:34 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 16 Apr 2021 21:29:34 GMT Subject: RFR: 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter In-Reply-To: References: Message-ID: <6UEEUmoNYsRc6LSvDR8Nr2wwPQHbZg9iYFS8TZYqONk=.9e5fc2ca-88e9-4dd8-9ace-4a35fd795625@github.com> On Fri, 16 Apr 2021 21:10:42 GMT, Naoto Sato wrote: > Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`). Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3553 From naoto at openjdk.java.net Fri Apr 16 22:20:08 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 16 Apr 2021 22:20:08 GMT Subject: RFR: 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter [v2] In-Reply-To: References: Message-ID: > Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`). Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Copyright year update. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3553/files - new: https://git.openjdk.java.net/jdk/pull/3553/files/91326786..e54cb6ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3553&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3553&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3553.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3553/head:pull/3553 PR: https://git.openjdk.java.net/jdk/pull/3553 From naoto at openjdk.java.net Fri Apr 16 22:26:46 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 16 Apr 2021 22:26:46 GMT Subject: Integrated: 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter In-Reply-To: References: Message-ID: <5VUdiDhBm9E-XcRwHzd0K7gntyW0r0KfKbzUk01XoGU=.fbd8772f-b00c-4bc5-8ca8-4f0024679bb0@github.com> On Fri, 16 Apr 2021 21:10:42 GMT, Naoto Sato wrote: > Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`). This pull request has now been integrated. Changeset: ff499701 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/ff499701 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/3553 From mikael at openjdk.java.net Sat Apr 17 07:26:56 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Sat, 17 Apr 2021 07:26:56 GMT Subject: RFR: 8257459: Bump minimum boot jdk to JDK 16 Message-ID: With JDK 16 having gone GA about a month ago it's time to bump the minimum boot JDK version for mainline/JDK 17. Testing: tier1-5. ------------- Commit messages: - Update GHA configuration - 8257459: Bump minimum boot jdk to JDK 16 Changes: https://git.openjdk.java.net/jdk/pull/3555/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3555&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257459 Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3555.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3555/head:pull/3555 PR: https://git.openjdk.java.net/jdk/pull/3555 From darcy at openjdk.java.net Sat Apr 17 16:04:40 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 17 Apr 2021 16:04:40 GMT Subject: RFR: 8257459: Bump minimum boot jdk to JDK 16 In-Reply-To: References: Message-ID: <8hrP3FjW6LjzM7QcQ9YmuD6M-v9F0ioMZy-jxf1UJGo=.03e5e4fe-6d74-482f-9f5a-4bdaed93ea19@github.com> On Sat, 17 Apr 2021 07:20:21 GMT, Mikael Vidstedt wrote: > With JDK 16 having gone GA about a month ago it's time to bump the minimum boot JDK version for mainline/JDK 17. > > Testing: tier1-5. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3555 From dnsimon at openjdk.java.net Sat Apr 17 20:48:07 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sat, 17 Apr 2021 20:48:07 GMT Subject: RFR: 8252600: [JVMCI] update JVMCI code style and mx configuration Message-ID: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> This PR updates the configuration files used to develop the JVMCI Java and C++ sources with mx and Eclipse. ------------- Commit messages: - 8252600: [JVMCI] update JVMCI code style and mx configuration Changes: https://git.openjdk.java.net/jdk/pull/3559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3559&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252600 Stats: 2096 lines in 14 files changed: 752 ins; 1344 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3559/head:pull/3559 PR: https://git.openjdk.java.net/jdk/pull/3559 From iris at openjdk.java.net Sun Apr 18 00:17:37 2021 From: iris at openjdk.java.net (Iris Clark) Date: Sun, 18 Apr 2021 00:17:37 GMT Subject: RFR: 8257459: Bump minimum boot jdk to JDK 16 In-Reply-To: References: Message-ID: On Sat, 17 Apr 2021 07:20:21 GMT, Mikael Vidstedt wrote: > With JDK 16 having gone GA about a month ago it's time to bump the minimum boot JDK version for mainline/JDK 17. > > Testing: tier1-5. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3555 From alanb at openjdk.java.net Sun Apr 18 07:34:55 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 18 Apr 2021 07:34:55 GMT Subject: RFR: 8252600: [JVMCI] update JVMCI code style and mx configuration In-Reply-To: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> Message-ID: On Sat, 17 Apr 2021 20:37:08 GMT, Doug Simon wrote: > This PR updates the configuration files used to develop the JVMCI Java and C++ sources with mx and Eclipse. Are you sure it make sense to have this dev config in the openjdk/jdk repo? I would think this is something for the downstream Graal repos. ------------- PR: https://git.openjdk.java.net/jdk/pull/3559 From dnsimon at openjdk.java.net Sun Apr 18 09:53:41 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sun, 18 Apr 2021 09:53:41 GMT Subject: RFR: 8252600: [JVMCI] update JVMCI code style and mx configuration In-Reply-To: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> Message-ID: On Sat, 17 Apr 2021 20:37:08 GMT, Doug Simon wrote: > This PR updates the configuration files used to develop the JVMCI Java and C++ sources with mx and Eclipse. Until we have downstream repos for JDK 17, it's very handy to have this config in the JDK. I've tried to keep it only in JVMCI related directories so as to not perturb non-JVMCI sources. However, if the consensus is that this config does not belong in the JDK at all, I will repurpose this PR to remove all such config as it's current broken as is. ------------- PR: https://git.openjdk.java.net/jdk/pull/3559 From dnsimon at openjdk.java.net Sun Apr 18 11:53:11 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sun, 18 Apr 2021 11:53:11 GMT Subject: RFR: 8265403: consolidate definition of CPU features In-Reply-To: References: Message-ID: On Sat, 17 Apr 2021 20:18:31 GMT, Doug Simon wrote: > While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 198: > 196: sprintf(buf, "0x%02x:0x%x:0x%03x:%d", _cpu, _variant, _model, _revision); > 197: if (_model2) sprintf(buf+strlen(buf), "(0x%03x)", _model2); > 198: #define ADD_FEATURE_IF_SUPPORTED(id, name, bit) if (_features & CPU_##id) strcat(buf, ", " name); I'm not sure why only some of the supported AArch64 CPU features were being added to `_features_string` but I assume there's no harm in adding them all. src/hotspot/cpu/x86/vm_version_x86.hpp line 382: > 380: static const char* _features_names[]; > 381: > 382: // NB! When adding new CPU feature detection consider updating vmStructs_x86.hpp, vmStructs_jvmci.hpp, and VM_Version::get_processor_features(). No need for this comment any more as the derivative declarations are now automatically kept up to date. src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java line 57: > 55: > 56: Map constants = config.getStore().getConstants(); > 57: Function nameToFeature = name -> name.equals("3DNOW_PREFETCH") ? CPUFeature.AMD_3DNOW_PREFETCH : CPUFeature.valueOf(name); The `AMD_3DNOW_PREFETCH` enum constant has to keep its old name to preserve backward compatibility. ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From dnsimon at openjdk.java.net Sun Apr 18 11:53:10 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sun, 18 Apr 2021 11:53:10 GMT Subject: RFR: 8265403: consolidate definition of CPU features Message-ID: While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. ------------- Commit messages: - 8265403: consolidate definition of CPU features Changes: https://git.openjdk.java.net/jdk/pull/3558/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265403 Stats: 481 lines in 15 files changed: 144 ins; 230 del; 107 mod Patch: https://git.openjdk.java.net/jdk/pull/3558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3558/head:pull/3558 PR: https://git.openjdk.java.net/jdk/pull/3558 From glaubitz at openjdk.java.net Sun Apr 18 17:36:48 2021 From: glaubitz at openjdk.java.net (John Paul Adrian Glaubitz) Date: Sun, 18 Apr 2021 17:36:48 GMT Subject: RFR: 8265343: Update Debian-based cross-compilation recipes In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 11:57:32 GMT, Aleksey Shipilev wrote: > After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do not need to set a whole lot of options for cross-compiled builds. Docs should be updated to reflect that fact. Also put in more configurations that are buildable with Debian ports: these build routinely at [builds.shipilev.net](https://builds.shipilev.net/openjdk-jdk/). > > Maybe @glaubitz wants to chime in here too :) @shipilev Nice work. I'll have a go at testing this next week. I didn't get to look this week as I was busy with my dayjob. In any case, I'm very happy to see build instructions for so many architectures :-). I should also try to push some more Debian patches upstream so that most cross-builds will work out of the box. ------------- PR: https://git.openjdk.java.net/jdk/pull/3545 From dnsimon at openjdk.java.net Sun Apr 18 20:17:14 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sun, 18 Apr 2021 20:17:14 GMT Subject: RFR: 8252600: remove mx configuration [v2] In-Reply-To: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> Message-ID: <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com> > This PR updates the configuration files used to develop the JVMCI Java and C++ sources with mx and Eclipse. Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8252600: [JVMCI] remove mx configuration ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3559/files - new: https://git.openjdk.java.net/jdk/pull/3559/files/7026605f..7c18d2d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3559&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3559&range=00-01 Stats: 754 lines in 8 files changed: 0 ins; 754 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3559/head:pull/3559 PR: https://git.openjdk.java.net/jdk/pull/3559 From dnsimon at openjdk.java.net Sun Apr 18 20:20:43 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sun, 18 Apr 2021 20:20:43 GMT Subject: RFR: 8252600: remove mx configuration [v2] In-Reply-To: <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com> References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com> Message-ID: <9BHFJ8Vurf3bVA12x8Fo0iaZGzQmUrXCbImXjY56Wtw=.daf237c0-2368-48dd-9fc0-5936431ddd56@github.com> On Sun, 18 Apr 2021 20:17:14 GMT, Doug Simon wrote: >> This PR removes the mx configuration files in the JDK as they do not really belong here. Instead, I've updated and moved them to https://github.com/dougxc/mx_jdk. > > Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8252600: [JVMCI] remove mx configuration On second thoughts, I concur with you Alan and am thus using this PR to remove the mx configuration files. ------------- PR: https://git.openjdk.java.net/jdk/pull/3559 From dnsimon at openjdk.java.net Mon Apr 19 09:42:02 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 09:42:02 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v2] In-Reply-To: References: Message-ID: <4M8_w76Ai_dnNI4LbRClcxhhBaJ7XVHpCeYr-p5ilZs=.01a7ad3a-2855-45f6-b2ad-d439bf282e50@github.com> > While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: avoid use of a lambda in JVMCI initialization ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3558/files - new: https://git.openjdk.java.net/jdk/pull/3558/files/b69675f4..bdf9eefb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=00-01 Stats: 23 lines in 3 files changed: 5 ins; 9 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3558/head:pull/3558 PR: https://git.openjdk.java.net/jdk/pull/3558 From dnsimon at openjdk.java.net Mon Apr 19 09:46:17 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 09:46:17 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v3] In-Reply-To: References: Message-ID: > While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: avoid use of a lambda in JVMCI initialization ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3558/files - new: https://git.openjdk.java.net/jdk/pull/3558/files/bdf9eefb..124019d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3558/head:pull/3558 PR: https://git.openjdk.java.net/jdk/pull/3558 From erikj at openjdk.java.net Mon Apr 19 12:53:34 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 19 Apr 2021 12:53:34 GMT Subject: RFR: 8257459: Bump minimum boot jdk to JDK 16 In-Reply-To: References: Message-ID: On Sat, 17 Apr 2021 07:20:21 GMT, Mikael Vidstedt wrote: > With JDK 16 having gone GA about a month ago it's time to bump the minimum boot JDK version for mainline/JDK 17. > > Testing: tier1-5. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3555 From erikj at openjdk.java.net Mon Apr 19 12:55:46 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 19 Apr 2021 12:55:46 GMT Subject: RFR: 8252600: remove mx configuration [v2] In-Reply-To: <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com> References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com> Message-ID: On Sun, 18 Apr 2021 20:17:14 GMT, Doug Simon wrote: >> This PR removes the mx configuration files in the JDK as they do not really belong here. Instead, I've updated and moved them to https://github.com/dougxc/mx_jdk. > > Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8252600: [JVMCI] remove mx configuration Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3559 From erikj at openjdk.java.net Mon Apr 19 13:51:35 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 19 Apr 2021 13:51:35 GMT Subject: Integrated: JDK-8265371: Change to Visual Studio 2019 16.9.3 for building on Windows at Oracle In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 18:58:27 GMT, Erik Joelsson wrote: > Oracle is updating the minor version of Visual Studio for building the JDK to 16.9.3. This pull request has now been integrated. Changeset: b14e0ee4 Author: Erik Joelsson URL: https://git.openjdk.java.net/jdk/commit/b14e0ee4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8265371: Change to Visual Studio 2019 16.9.3 for building on Windows at Oracle Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/3550 From kvn at openjdk.java.net Mon Apr 19 17:24:35 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 19 Apr 2021 17:24:35 GMT Subject: RFR: 8252600: remove mx configuration [v2] In-Reply-To: <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com> References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> <1PPeQbsoW3AFDIt1L2dYfg5WwykGVftJ47L6AE0aWXE=.ded1e016-5781-44ea-9a3a-46a719c7f584@github.com> Message-ID: <2840qz4etikwMFvVnTMvthHrn-2dfmqWCFwI5Sb3nnY=.6ab2e3b6-da00-4614-9be3-b5d76c7ff9d4@github.com> On Sun, 18 Apr 2021 20:17:14 GMT, Doug Simon wrote: >> This PR removes the mx configuration files in the JDK as they do not really belong here. Instead, I've updated and moved them to https://github.com/dougxc/mx_jdk. > > Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8252600: [JVMCI] remove mx configuration The PR is missing `[JVMCI] ` in title to match RFE title. Otherwise it is good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3559 From dnsimon at openjdk.java.net Mon Apr 19 17:47:48 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 17:47:48 GMT Subject: Integrated: 8252600: [JVMCI] remove mx configuration In-Reply-To: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> Message-ID: On Sat, 17 Apr 2021 20:37:08 GMT, Doug Simon wrote: > This PR removes the mx configuration files in the JDK as they do not really belong here. Instead, I've updated and moved them to https://github.com/dougxc/mx_jdk. This pull request has now been integrated. Changeset: 54cb388d Author: Doug Simon URL: https://git.openjdk.java.net/jdk/commit/54cb388d Stats: 1346 lines in 7 files changed: 0 ins; 1346 del; 0 mod 8252600: [JVMCI] remove mx configuration Reviewed-by: erikj, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/3559 From dnsimon at openjdk.java.net Mon Apr 19 17:47:48 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 17:47:48 GMT Subject: RFR: 8252600: [JVMCI] remove mx configuration In-Reply-To: References: <5_y5r2sWg9i6sNhcJrg_GvODVPAPDs60KVqOw8z8jrI=.4e633372-2ba1-4b58-a9ca-04b38c9a91fa@github.com> Message-ID: On Sun, 18 Apr 2021 07:32:07 GMT, Alan Bateman wrote: >> This PR removes the mx configuration files in the JDK as they do not really belong here. Instead, I've updated and moved them to https://github.com/dougxc/mx_jdk. > > Are you sure it make sense to have this dev config in the openjdk/jdk repo? I would think this is something for the downstream Graal repos. Thanks @AlanBateman , @erikj79 and @vnkozlov for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/3559 From kvn at openjdk.java.net Mon Apr 19 19:15:06 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 19 Apr 2021 19:15:06 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 09:46:17 GMT, Doug Simon wrote: >> While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. >> >> In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. > > Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > avoid use of a lambda in JVMCI initialization Please, update copyright years in files you touched. src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 118: > 116: decl(STXR_PREFETCH, "stxr_prefetch", 29) \ > 117: decl(A53MAC, "a53mac", 30) > 118: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = (1 << bit), Add empty line before to separate `CPU_FEATURE_FLAGS` macro. src/hotspot/cpu/x86/vmStructs_x86.hpp line 45: > 43: > 44: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id) > 45: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT) Do we need to keep `VM_LONG_CONSTANTS_CPU` after you removed its body here and in vmStructs_jvmci.cpp? What about `VM_INT_CONSTANTS_CPU` here? vmStructs_jvmci.cpp duplicates it. src/hotspot/cpu/x86/vm_version_x86.hpp line 363: > 361: decl(AVX512_VBMI, "avx512_vbmi", 45) /* Vector BMI instructions */ \ > 362: decl(HV, "hv", 46) /* Hypervisor instructions */ > 363: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = (1ULL << bit), Add empty line before it to separate `CPU_FEATURE_FLAGS` macro more clear. src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 753: > 751: > 752: #define DECLARE_INT_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_INT_CONSTANT_ENTRY(VM_Version::CPU_##id) > 753: #define VM_INT_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_INT_CPU_FEATURE_CONSTANT) Missing `#undef DECLARE_INT_CPU_FEATURE_CONSTANT`. src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 769: > 767: > 768: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id) > 769: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT) Missing `#undef DECLARE_LONG_CPU_FEATURE_CONSTANT`. src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java line 66: > 64: long bitMask = e.getValue(); > 65: String key = e.getKey(); > 66: if (key.startsWith("VM_Version::CPU_")) { As I understand this code, it goes over `constants` values passed from VM and Trying to map them to `enumType`. It catches cases when a value is missing in `enumType`. What about case when `enumType` has `extra` value which is not defined in `constants`? ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From dnsimon at openjdk.java.net Mon Apr 19 19:38:08 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 19:38:08 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 18:57:37 GMT, Vladimir Kozlov wrote: >> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> avoid use of a lambda in JVMCI initialization > > src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 118: > >> 116: decl(STXR_PREFETCH, "stxr_prefetch", 29) \ >> 117: decl(A53MAC, "a53mac", 30) >> 118: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = (1 << bit), > > Add empty line before to separate `CPU_FEATURE_FLAGS` macro. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From dnsimon at openjdk.java.net Mon Apr 19 19:42:05 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 19:42:05 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 18:58:46 GMT, Vladimir Kozlov wrote: >> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> avoid use of a lambda in JVMCI initialization > > src/hotspot/cpu/x86/vmStructs_x86.hpp line 45: > >> 43: >> 44: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id) >> 45: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT) > > Do we need to keep `VM_LONG_CONSTANTS_CPU` after you removed its body here and in vmStructs_jvmci.cpp? > > What about `VM_INT_CONSTANTS_CPU` here? vmStructs_jvmci.cpp duplicates it. `vmStructs.cpp` and `vmStructs_jvmci.cpp` are disjoint. This file (i.e. `vmStructs_x86.hpp`) is only used by `vmStructs.cpp`. `vmStructs.cpp` expects all macros such as `VM_LONG_CONSTANTS_CPU` to be defined. `vmStructs_jvmci.cpp` will provide a dummy definition for missing macros. ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From dnsimon at openjdk.java.net Mon Apr 19 19:49:07 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 19:49:07 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:00:09 GMT, Vladimir Kozlov wrote: >> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> avoid use of a lambda in JVMCI initialization > > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 753: > >> 751: >> 752: #define DECLARE_INT_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_INT_CONSTANT_ENTRY(VM_Version::CPU_##id) >> 753: #define VM_INT_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_INT_CPU_FEATURE_CONSTANT) > > Missing `#undef DECLARE_INT_CPU_FEATURE_CONSTANT`. No, it must stay defined up to the point `VM_INT_CPU_FEATURE_CONSTANTS` is used. Since this is a `.cpp` file, it's ok to leave it defined. > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 769: > >> 767: >> 768: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id) >> 769: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT) > > Missing `#undef DECLARE_LONG_CPU_FEATURE_CONSTANT`. So comment as for `DECLARE_INT_CPU_FEATURE_CONSTANT`. > src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java line 66: > >> 64: long bitMask = e.getValue(); >> 65: String key = e.getKey(); >> 66: if (key.startsWith("VM_Version::CPU_")) { > > As I understand this code, it goes over `constants` values passed from VM and Trying to map them to `enumType`. It catches cases when a value is missing in `enumType`. What about case when `enumType` has `extra` value which is not defined in `constants`? We could warn about that but cannot remove it without breaking backwards capability for JVMCI wrt Graal. Such a deleted capability will simply be seen as "not supported" by Graal. ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From erikj at openjdk.java.net Mon Apr 19 19:49:33 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 19 Apr 2021 19:49:33 GMT Subject: RFR: JDK-8265373: Change to GCC 10.3 for building on Linux at Oracle [v3] In-Reply-To: References: Message-ID: > Oracle is updating the version of GCC for building the JDK to 10.3. > > In addition to the version bump, I'm also enabling cross compilation OOTB using jib from a linux-aarch64 to linux-x64 binaries, which was the last missing combination. (Native x64, native aarch64, cross from x64 to aarch64 all worked already and will continue to do so.) Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into gcc-10.3-devkit - Fix configure args for linux-x64 - Finalize devkits - Merge branch 'master' into gcc-10.3-devkit - Corrected condition for --build-devkit - Enable cross building from aarch64 to x64 - Use GCC 10.3 by default for devkit creation ------------- Changes: https://git.openjdk.java.net/jdk/pull/3551/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3551&range=02 Stats: 27 lines in 2 files changed: 14 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3551.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3551/head:pull/3551 PR: https://git.openjdk.java.net/jdk/pull/3551 From erikj at openjdk.java.net Mon Apr 19 19:49:34 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 19 Apr 2021 19:49:34 GMT Subject: Integrated: JDK-8265373: Change to GCC 10.3 for building on Linux at Oracle In-Reply-To: References: Message-ID: <2r_qkvQlEv9EskYNDAfUUjscKvXhd3JrWDdFyur5gDs=.91fbdace-5fbc-46f6-92ee-e68dabfba3d1@github.com> On Fri, 16 Apr 2021 19:21:11 GMT, Erik Joelsson wrote: > Oracle is updating the version of GCC for building the JDK to 10.3. > > In addition to the version bump, I'm also enabling cross compilation OOTB using jib from a linux-aarch64 to linux-x64 binaries, which was the last missing combination. (Native x64, native aarch64, cross from x64 to aarch64 all worked already and will continue to do so.) This pull request has now been integrated. Changeset: 713483c7 Author: Erik Joelsson URL: https://git.openjdk.java.net/jdk/commit/713483c7 Stats: 27 lines in 2 files changed: 14 ins; 4 del; 9 mod 8265373: Change to GCC 10.3 for building on Linux at Oracle Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/3551 From dnsimon at openjdk.java.net Mon Apr 19 19:56:45 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 19:56:45 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v4] In-Reply-To: References: Message-ID: > While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. Doug Simon has updated the pull request incrementally with two additional commits since the last revision: - updated date in copyright - added blank lines after macros ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3558/files - new: https://git.openjdk.java.net/jdk/pull/3558/files/124019d7..c6be1437 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=02-03 Stats: 11 lines in 10 files changed: 2 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3558/head:pull/3558 PR: https://git.openjdk.java.net/jdk/pull/3558 From kvn at openjdk.java.net Mon Apr 19 20:05:06 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 19 Apr 2021 20:05:06 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:38:52 GMT, Doug Simon wrote: >> src/hotspot/cpu/x86/vmStructs_x86.hpp line 45: >> >>> 43: >>> 44: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id) >>> 45: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT) >> >> Do we need to keep `VM_LONG_CONSTANTS_CPU` after you removed its body here and in vmStructs_jvmci.cpp? >> >> What about `VM_INT_CONSTANTS_CPU` here? vmStructs_jvmci.cpp duplicates it. > > `vmStructs.cpp` and `vmStructs_jvmci.cpp` are disjoint. This file (i.e. `vmStructs_x86.hpp`) is only used by `vmStructs.cpp`. > `vmStructs.cpp` expects all macros such as `VM_LONG_CONSTANTS_CPU` to be defined. > `vmStructs_jvmci.cpp` will provide a dummy definition for missing macros. Got it. Even so they are empty everywhere :( >> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 753: >> >>> 751: >>> 752: #define DECLARE_INT_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_INT_CONSTANT_ENTRY(VM_Version::CPU_##id) >>> 753: #define VM_INT_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_INT_CPU_FEATURE_CONSTANT) >> >> Missing `#undef DECLARE_INT_CPU_FEATURE_CONSTANT`. > > No, it must stay defined up to the point `VM_INT_CPU_FEATURE_CONSTANTS` is used. Since this is a `.cpp` file, it's ok to leave it defined. I see. >> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java line 66: >> >>> 64: long bitMask = e.getValue(); >>> 65: String key = e.getKey(); >>> 66: if (key.startsWith("VM_Version::CPU_")) { >> >> As I understand this code, it goes over `constants` values passed from VM and Trying to map them to `enumType`. It catches cases when a value is missing in `enumType`. What about case when `enumType` has `extra` value which is not defined in `constants`? > > We could warn about that but cannot remove it without breaking backwards capability for JVMCI wrt Graal. Such a deleted capability will simply be seen as "not supported" by Graal. Okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From kvn at openjdk.java.net Mon Apr 19 20:05:05 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 19 Apr 2021 20:05:05 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v4] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:56:45 GMT, Doug Simon wrote: >> While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. >> >> In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. > > Doug Simon has updated the pull request incrementally with two additional commits since the last revision: > > - updated date in copyright > - added blank lines after macros You need review from Runtime group too. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3558 From mikael at openjdk.java.net Tue Apr 20 14:40:09 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 20 Apr 2021 14:40:09 GMT Subject: RFR: 8257459: Bump minimum boot jdk to JDK 16 In-Reply-To: References: Message-ID: On Sat, 17 Apr 2021 07:20:21 GMT, Mikael Vidstedt wrote: > With JDK 16 having gone GA about a month ago it's time to bump the minimum boot JDK version for mainline/JDK 17. > > Testing: tier1-5. Joe, Iris, Erik - thank you for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3555 From mikael at openjdk.java.net Tue Apr 20 14:40:10 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 20 Apr 2021 14:40:10 GMT Subject: Integrated: 8257459: Bump minimum boot jdk to JDK 16 In-Reply-To: References: Message-ID: On Sat, 17 Apr 2021 07:20:21 GMT, Mikael Vidstedt wrote: > With JDK 16 having gone GA about a month ago it's time to bump the minimum boot JDK version for mainline/JDK 17. > > Testing: tier1-5. This pull request has now been integrated. Changeset: 72c88fc4 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/72c88fc4 Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod 8257459: Bump minimum boot jdk to JDK 16 Reviewed-by: darcy, iris, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3555 From jjg at openjdk.java.net Tue Apr 20 22:45:30 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 20 Apr 2021 22:45:30 GMT Subject: RFR: JDK-8265483: All-caps =?UTF-8?B?4oCcSkFWQeKAnQ==?= in the top navigation bar Message-ID: <2oVXkC-NTAzowmtYV5Yk9b_0BIAkuiIMM0otRygCZNs=.6a5c53a2-2629-4a6e-82f6-76ee489da532@github.com> Please review a moderately simple change to `make/Docs.gmk` to move the link for "Other Versions" from a "hidden" link in the top nav bar to an explicit link in the "bottom" text. The link is placed to appear after the sentence beginning "For more information..." and before all the legal text (i.e. trademark, copyright, license, etc) A side effect of moving the link is that the top text reverts to its intended appearance of "Java ...", without all-caps. As before, the presence of the link is optional, and depends on the specific docs target. It is set up to just appear for the main JDK/JavaSE documentation, and not the other docs bundles, such as docs-reference. ------------- Commit messages: - JDK-8265483: All-caps ?JAVA? in the top navigation bar Changes: https://git.openjdk.java.net/jdk/pull/3594/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3594&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265483 Stats: 16 lines in 1 file changed: 6 ins; 6 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3594/head:pull/3594 PR: https://git.openjdk.java.net/jdk/pull/3594 From iris at openjdk.java.net Tue Apr 20 22:53:07 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 20 Apr 2021 22:53:07 GMT Subject: RFR: JDK-8265483: All-caps =?UTF-8?B?4oCcSkFWQeKAnQ==?= in the top navigation bar In-Reply-To: <2oVXkC-NTAzowmtYV5Yk9b_0BIAkuiIMM0otRygCZNs=.6a5c53a2-2629-4a6e-82f6-76ee489da532@github.com> References: <2oVXkC-NTAzowmtYV5Yk9b_0BIAkuiIMM0otRygCZNs=.6a5c53a2-2629-4a6e-82f6-76ee489da532@github.com> Message-ID: On Tue, 20 Apr 2021 22:36:28 GMT, Jonathan Gibbons wrote: > Please review a moderately simple change to `make/Docs.gmk` to move the link for "Other Versions" from a "hidden" link in the top nav bar to an explicit link in the "bottom" text. The link is placed to appear after the sentence beginning "For more information..." and before all the legal text (i.e. trademark, copyright, license, etc) > > A side effect of moving the link is that the top text reverts to its intended appearance of "Java ...", without all-caps. > > As before, the presence of the link is optional, and depends on the specific docs target. It is set up to just appear for the main JDK/JavaSE documentation, and not the other docs bundles, such as docs-reference. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3594 From erikj at openjdk.java.net Tue Apr 20 23:25:04 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 20 Apr 2021 23:25:04 GMT Subject: RFR: JDK-8265483: All-caps =?UTF-8?B?4oCcSkFWQeKAnQ==?= in the top navigation bar In-Reply-To: <2oVXkC-NTAzowmtYV5Yk9b_0BIAkuiIMM0otRygCZNs=.6a5c53a2-2629-4a6e-82f6-76ee489da532@github.com> References: <2oVXkC-NTAzowmtYV5Yk9b_0BIAkuiIMM0otRygCZNs=.6a5c53a2-2629-4a6e-82f6-76ee489da532@github.com> Message-ID: <1fFV9P-UQuY04VUFa49qhlhaPZ_t_S31jB_-N_SIxHk=.1e02534e-eb9e-406e-b421-3f03b51ddf27@github.com> On Tue, 20 Apr 2021 22:36:28 GMT, Jonathan Gibbons wrote: > Please review a moderately simple change to `make/Docs.gmk` to move the link for "Other Versions" from a "hidden" link in the top nav bar to an explicit link in the "bottom" text. The link is placed to appear after the sentence beginning "For more information..." and before all the legal text (i.e. trademark, copyright, license, etc) > > A side effect of moving the link is that the top text reverts to its intended appearance of "Java ...", without all-caps. > > As before, the presence of the link is optional, and depends on the specific docs target. It is set up to just appear for the main JDK/JavaSE documentation, and not the other docs bundles, such as docs-reference. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3594 From jjg at openjdk.java.net Wed Apr 21 04:40:07 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 21 Apr 2021 04:40:07 GMT Subject: Integrated: JDK-8265483: All-caps =?UTF-8?B?4oCcSkFWQeKAnQ==?= in the top navigation bar In-Reply-To: <2oVXkC-NTAzowmtYV5Yk9b_0BIAkuiIMM0otRygCZNs=.6a5c53a2-2629-4a6e-82f6-76ee489da532@github.com> References: <2oVXkC-NTAzowmtYV5Yk9b_0BIAkuiIMM0otRygCZNs=.6a5c53a2-2629-4a6e-82f6-76ee489da532@github.com> Message-ID: <3pc04ixFLSNIioL6We6u2VQHdGk_WAkj9i--KLQdkJY=.ee778de9-fe23-44c5-892c-11f02a231696@github.com> On Tue, 20 Apr 2021 22:36:28 GMT, Jonathan Gibbons wrote: > Please review a moderately simple change to `make/Docs.gmk` to move the link for "Other Versions" from a "hidden" link in the top nav bar to an explicit link in the "bottom" text. The link is placed to appear after the sentence beginning "For more information..." and before all the legal text (i.e. trademark, copyright, license, etc) > > A side effect of moving the link is that the top text reverts to its intended appearance of "Java ...", without all-caps. > > As before, the presence of the link is optional, and depends on the specific docs target. It is set up to just appear for the main JDK/JavaSE documentation, and not the other docs bundles, such as docs-reference. This pull request has now been integrated. Changeset: 3de0dcba Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/3de0dcba Stats: 16 lines in 1 file changed: 6 ins; 6 del; 4 mod 8265483: All-caps ?JAVA? in the top navigation bar Reviewed-by: iris, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3594 From shade at openjdk.java.net Wed Apr 21 10:34:32 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Apr 2021 10:34:32 GMT Subject: RFR: 8265343: Update Debian-based cross-compilation recipes In-Reply-To: References: Message-ID: <3X3QVqk9vu97sX_4pk2uGUWm84KeuSlUy6iAgEk9ITI=.54e4a479-a059-4193-ac97-6c82793b17e0@github.com> On Sun, 18 Apr 2021 17:33:56 GMT, John Paul Adrian Glaubitz wrote: >> After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do not need to set a whole lot of options for cross-compiled builds. Docs should be updated to reflect that fact. Also put in more configurations that are buildable with Debian ports: these build routinely at [builds.shipilev.net](https://builds.shipilev.net/openjdk-jdk/). >> >> Maybe @glaubitz wants to chime in here too :) > > @shipilev Nice work. I'll have a go at testing this next week. I didn't get to look this week as I was busy with my dayjob. > > In any case, I'm very happy to see build instructions for so many architectures :-). I should also try to push some more Debian patches upstream so that most cross-builds will work out of the box. @glaubitz Yes, please take a look if you can. If not, I'll integrate this as is. ------------- PR: https://git.openjdk.java.net/jdk/pull/3545 From glaubitz at openjdk.java.net Wed Apr 21 10:42:32 2021 From: glaubitz at openjdk.java.net (John Paul Adrian Glaubitz) Date: Wed, 21 Apr 2021 10:42:32 GMT Subject: RFR: 8265343: Update Debian-based cross-compilation recipes In-Reply-To: References: Message-ID: On Sun, 18 Apr 2021 17:33:56 GMT, John Paul Adrian Glaubitz wrote: >> After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do not need to set a whole lot of options for cross-compiled builds. Docs should be updated to reflect that fact. Also put in more configurations that are buildable with Debian ports: these build routinely at [builds.shipilev.net](https://builds.shipilev.net/openjdk-jdk/). >> >> Maybe @glaubitz wants to chime in here too :) > > @shipilev Nice work. I'll have a go at testing this next week. I didn't get to look this week as I was busy with my dayjob. > > In any case, I'm very happy to see build instructions for so many architectures :-). I should also try to push some more Debian patches upstream so that most cross-builds will work out of the box. > @glaubitz Yes, please take a look if you can. If not, I'll integrate this as is. Looks good to me. It should be noted that in some cases such as m68k additional patches may be required to fix alignment issues, but I wanted to get these upstreamed anyway. ------------- PR: https://git.openjdk.java.net/jdk/pull/3545 From shade at openjdk.java.net Wed Apr 21 10:47:33 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Apr 2021 10:47:33 GMT Subject: RFR: 8265343: Update Debian-based cross-compilation recipes In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 11:57:32 GMT, Aleksey Shipilev wrote: > After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do not need to set a whole lot of options for cross-compiled builds. Docs should be updated to reflect that fact. Also put in more configurations that are buildable with Debian ports: these build routinely at [builds.shipilev.net](https://builds.shipilev.net/openjdk-jdk/). > > Maybe @glaubitz wants to chime in here too :) Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3545 From shade at openjdk.java.net Wed Apr 21 10:47:34 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Apr 2021 10:47:34 GMT Subject: Integrated: 8265343: Update Debian-based cross-compilation recipes In-Reply-To: References: Message-ID: <1lUwuPVKbETL2nWWITiNzyXlNv3jOBKvE2KyXRYr-MA=.0d76c8e6-45b7-4569-a5c4-09c43ebeca8c@github.com> On Fri, 16 Apr 2021 11:57:32 GMT, Aleksey Shipilev wrote: > After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do not need to set a whole lot of options for cross-compiled builds. Docs should be updated to reflect that fact. Also put in more configurations that are buildable with Debian ports: these build routinely at [builds.shipilev.net](https://builds.shipilev.net/openjdk-jdk/). > > Maybe @glaubitz wants to chime in here too :) This pull request has now been integrated. Changeset: 7879adbe Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/7879adbe Stats: 132 lines in 2 files changed: 88 ins; 17 del; 27 mod 8265343: Update Debian-based cross-compilation recipes Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3545 From haosun at openjdk.java.net Wed Apr 21 13:29:47 2021 From: haosun at openjdk.java.net (Hao Sun) Date: Wed, 21 Apr 2021 13:29:47 GMT Subject: RFR: 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion [v2] In-Reply-To: <_9mxRc0vDta95wVWJLFWkO9iRWCt5g1Ni5Dg19xoOKw=.c32e32f7-b564-4a08-9ea9-645d4d9d1442@github.com> References: <_9mxRc0vDta95wVWJLFWkO9iRWCt5g1Ni5Dg19xoOKw=.c32e32f7-b564-4a08-9ea9-645d4d9d1442@github.com> Message-ID: On Tue, 9 Feb 2021 05:17:06 GMT, Hao Sun wrote: >> Making the conversion explicit would fix it. >> >> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. >> Therefore clang-8 and clang-9 are not affected. The flag with similar >> functionality in gcc is '-Wfloat-conversion', but it is not enabled by >> '-Wall' or '-Wextra'. That's why this warning does not appear when >> building with gcc. >> >> >> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. >> Note that '--with-extra-cxxflags=-Wno-deprecated-copy' should be added when configuration. It's another issue (See JDK-8258010) > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Use static_cast > > To match the style in this file, use static_cast to perform type > casting. Ping? ------------- PR: https://git.openjdk.java.net/jdk/pull/1956 From duke at openjdk.java.net Wed Apr 21 13:34:36 2021 From: duke at openjdk.java.net (duke) Date: Wed, 21 Apr 2021 13:34:36 GMT Subject: Withdrawn: 8258477: Pre-submit testing using GitHub Actions should merge changes from target branch In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 10:47:50 GMT, Robin Westberg wrote: > Normally when running GitHub Actions on a pull request, what is checked out is the merge of the pull request with the latest changes on the target branch. This ensure that what is tested is as close as possible to what will actually be the result of integrating said pull request. > > In our use of GitHub Actions, we don't run directly on pull requests but instead allow contributors to run them in their own personal forks. In that context, there is no notion of a target branch. However, we can infer the target project and branch by encoding this in the workflow file. This allows us to perform the same merge manually, and achieve the same behaviour. > > The change also adds an option to disable this automated merge when launching the workflow manually, which could be useful when investigating unexpected test failures. > > Note that downstream projects picking up this change will have to adapt the workflow file to keep using these actions for pre-submit testing. This has been a common request from downstream projects, but could also be done in a separate change (or not at all). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1801 From duke at openjdk.java.net Wed Apr 21 13:38:41 2021 From: duke at openjdk.java.net (duke) Date: Wed, 21 Apr 2021 13:38:41 GMT Subject: Withdrawn: 8257733: Move module-specific data from make to respective module In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From mcimadamore at openjdk.java.net Wed Apr 21 14:45:34 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 21 Apr 2021 14:45:34 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v3] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 03:35:06 GMT, Vicente Romero wrote: >> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) >> >> Thanks >> >> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > updating comment after review feedback Compiler changes look good (I have not checked SymbolGenerator). Why were some tests removed? ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3526 From vromero at openjdk.java.net Wed Apr 21 15:13:33 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 21 Apr 2021 15:13:33 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v3] In-Reply-To: References: Message-ID: <2gJQiuoDTZDgr62xRlnZLCoL1-EFjUCSHsKBrSpPV2U=.1918b494-34bb-4f1a-939b-9a931b583117@github.com> On Wed, 21 Apr 2021 14:42:39 GMT, Maurizio Cimadamore wrote: > Compiler changes look good (I have not checked SymbolGenerator). > > Why were some tests removed? thanks for the review. The removed tests were already covered in langtools regression tests, so I only removed duplicated tests ------------- PR: https://git.openjdk.java.net/jdk/pull/3526 From pliden at openjdk.java.net Wed Apr 21 21:16:48 2021 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 21 Apr 2021 21:16:48 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 Message-ID: This patch enables ZGC on macOS/aarch64. It does three things: 1) Enables building of ZGC on this platform. 2) Adds `os::processor_id()`, which for now always returns 0. 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). ------------- Commit messages: - 8265702: ZGC on macOS/aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3609/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3609&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265702 Stats: 13 lines in 3 files changed: 7 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3609/head:pull/3609 PR: https://git.openjdk.java.net/jdk/pull/3609 From iklam at openjdk.java.net Wed Apr 21 22:57:51 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 22:57:51 GMT Subject: RFR: 8265696 move cds sources Message-ID: The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. - src/hotspot/share/classfile/classListParser.cpp - src/hotspot/share/classfile/classListParser.hpp - src/hotspot/share/classfile/classListWriter.hpp - src/hotspot/share/classfile/compactHashtable.cpp - src/hotspot/share/classfile/compactHashtable.hpp - src/hotspot/share/classfile/lambdaFormInvokers.cpp - src/hotspot/share/classfile/lambdaFormInvokers.hpp - src/hotspot/share/memory/archiveBuilder.cpp - src/hotspot/share/memory/archiveBuilder.hpp - src/hotspot/share/memory/archiveUtils.cpp - src/hotspot/share/memory/archiveUtils.hpp - src/hotspot/share/memory/archiveUtils.inline.hpp - src/hotspot/share/memory/cppVtables.cpp - src/hotspot/share/memory/cppVtables.hpp - src/hotspot/share/memory/dumpAllocStats.cpp - src/hotspot/share/memory/dumpAllocStats.hpp - src/hotspot/share/memory/dynamicArchive.cpp - src/hotspot/share/memory/dynamicArchive.hpp - src/hotspot/share/memory/filemap.cpp - src/hotspot/share/memory/filemap.hpp - src/hotspot/share/memory/heapShared.cpp - src/hotspot/share/memory/heapShared.hpp - src/hotspot/share/memory/heapShared.inline.hpp - src/hotspot/share/memory/metaspaceShared.cpp - src/hotspot/share/memory/metaspaceShared.hpp - src/hotspot/share/prims/cdsoffsets.cpp - src/hotspot/share/prims/cdsoffsets.hpp Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- Commit messages: - fixed copyright - moved more files - fixed include lines - 8265696: Move CDS sources from shared/memory to shared/cds Changes: https://git.openjdk.java.net/jdk/pull/3610/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265696 Stats: 275 lines in 78 files changed: 116 ins; 134 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/3610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3610/head:pull/3610 PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Wed Apr 21 22:57:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 22:57:52 GMT Subject: RFR: 8265696 move cds sources In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. make/hotspot/lib/JvmFeatures.gmk line 134: > 132: metaspaceShared_$(HOTSPOT_TARGET_CPU_ARCH).cpp \ > 133: sharedClassUtil.cpp \ > 134: sharedPathsMiscInfo.cpp \ Removed obsolete files that no longer exist. src/hotspot/os/windows/os_windows.cpp line 42: > 40: #include "logging/logStream.hpp" > 41: #include "memory/allocation.inline.hpp" > 42: #include "oops/oop.inline.hpp" Removed some unnecessary inclusions. ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From erikj at openjdk.java.net Wed Apr 21 23:07:20 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 21 Apr 2021 23:07:20 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:10:02 GMT, Per Liden wrote: > This patch enables ZGC on macOS/aarch64. It does three things: > 1) Enables building of ZGC on this platform. > 2) Adds `os::processor_id()`, which for now always returns 0. > 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. > > Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). Build change looks good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3609 From erikj at openjdk.java.net Wed Apr 21 23:10:22 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 21 Apr 2021 23:10:22 GMT Subject: RFR: 8265696 move cds sources In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 22:04:13 GMT, Ioi Lam wrote: >> The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. >> >> - src/hotspot/share/classfile/classListParser.cpp >> - src/hotspot/share/classfile/classListParser.hpp >> - src/hotspot/share/classfile/classListWriter.hpp >> - src/hotspot/share/classfile/compactHashtable.cpp >> - src/hotspot/share/classfile/compactHashtable.hpp >> - src/hotspot/share/classfile/lambdaFormInvokers.cpp >> - src/hotspot/share/classfile/lambdaFormInvokers.hpp >> - src/hotspot/share/memory/archiveBuilder.cpp >> - src/hotspot/share/memory/archiveBuilder.hpp >> - src/hotspot/share/memory/archiveUtils.cpp >> - src/hotspot/share/memory/archiveUtils.hpp >> - src/hotspot/share/memory/archiveUtils.inline.hpp >> - src/hotspot/share/memory/cppVtables.cpp >> - src/hotspot/share/memory/cppVtables.hpp >> - src/hotspot/share/memory/dumpAllocStats.cpp >> - src/hotspot/share/memory/dumpAllocStats.hpp >> - src/hotspot/share/memory/dynamicArchive.cpp >> - src/hotspot/share/memory/dynamicArchive.hpp >> - src/hotspot/share/memory/filemap.cpp >> - src/hotspot/share/memory/filemap.hpp >> - src/hotspot/share/memory/heapShared.cpp >> - src/hotspot/share/memory/heapShared.hpp >> - src/hotspot/share/memory/heapShared.inline.hpp >> - src/hotspot/share/memory/metaspaceShared.cpp >> - src/hotspot/share/memory/metaspaceShared.hpp >> - src/hotspot/share/prims/cdsoffsets.cpp >> - src/hotspot/share/prims/cdsoffsets.hpp >> >> Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > make/hotspot/lib/JvmFeatures.gmk line 134: > >> 132: metaspaceShared_$(HOTSPOT_TARGET_CPU_ARCH).cpp \ >> 133: sharedClassUtil.cpp \ >> 134: sharedPathsMiscInfo.cpp \ > > Removed obsolete files that no longer exist. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From erikj at openjdk.java.net Wed Apr 21 23:10:21 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 21 Apr 2021 23:10:21 GMT Subject: RFR: 8265696 move cds sources In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3610 From haosun at openjdk.java.net Thu Apr 22 02:09:23 2021 From: haosun at openjdk.java.net (Hao Sun) Date: Thu, 22 Apr 2021 02:09:23 GMT Subject: RFR: 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion [v2] In-Reply-To: References: <_9mxRc0vDta95wVWJLFWkO9iRWCt5g1Ni5Dg19xoOKw=.c32e32f7-b564-4a08-9ea9-645d4d9d1442@github.com> Message-ID: On Thu, 22 Apr 2021 02:04:05 GMT, David Holmes wrote: >> Hao Sun has updated the pull request incrementally with one additional commit since the last revision: >> >> Use static_cast >> >> To match the style in this file, use static_cast to perform type >> casting. > > Sorry this slipped through the cracks without getting reviewed. > > The fix seems fine and trivial so you can integrate straight away. > > Thanks, > David Thanks for your review. @dholmes-ora ------------- PR: https://git.openjdk.java.net/jdk/pull/1956 From dholmes at openjdk.java.net Thu Apr 22 02:09:23 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 02:09:23 GMT Subject: RFR: 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion [v2] In-Reply-To: <_9mxRc0vDta95wVWJLFWkO9iRWCt5g1Ni5Dg19xoOKw=.c32e32f7-b564-4a08-9ea9-645d4d9d1442@github.com> References: <_9mxRc0vDta95wVWJLFWkO9iRWCt5g1Ni5Dg19xoOKw=.c32e32f7-b564-4a08-9ea9-645d4d9d1442@github.com> Message-ID: On Tue, 9 Feb 2021 05:17:06 GMT, Hao Sun wrote: >> Making the conversion explicit would fix it. >> >> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. >> Therefore clang-8 and clang-9 are not affected. The flag with similar >> functionality in gcc is '-Wfloat-conversion', but it is not enabled by >> '-Wall' or '-Wextra'. That's why this warning does not appear when >> building with gcc. >> >> >> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. >> Note that '--with-extra-cxxflags=-Wno-deprecated-copy' should be added when configuration. It's another issue (See JDK-8258010) > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Use static_cast > > To match the style in this file, use static_cast to perform type > casting. Sorry this slipped through the cracks without getting reviewed. The fix seems fine and trivial so you can integrate straight away. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1956 From dholmes at openjdk.java.net Thu Apr 22 04:22:25 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 04:22:25 GMT Subject: RFR: 8265696 move cds sources In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 23:05:26 GMT, Erik Joelsson wrote: >> make/hotspot/lib/JvmFeatures.gmk line 134: >> >>> 132: metaspaceShared_$(HOTSPOT_TARGET_CPU_ARCH).cpp \ >>> 133: sharedClassUtil.cpp \ >>> 134: sharedPathsMiscInfo.cpp \ >> >> Removed obsolete files that no longer exist. > > Thank you! I don't suppose we can just exclude the new directory rather than listing individual files? ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From dholmes at openjdk.java.net Thu Apr 22 04:22:25 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 04:22:25 GMT Subject: RFR: 8265696 move cds sources In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Hi Ioi, Moving these files to their own directory is fine, but all the moved headers need further adjustments for the include guards. Thanks, David src/hotspot/share/cds/archiveUtils.inline.hpp line 25: > 23: */ > 24: > 25: #ifndef SHARE_MEMORY_ARCHIVEUTILS_INLINE_HPP The header file include guards all need updating for the new path. src/hotspot/share/cds/dynamicArchive.hpp line 38: > 36: #include "utilities/resourceHash.hpp" > 37: > 38: #if INCLUDE_CDS I have to wonder who is including this file and why, if CDS is not enabled. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3610 From dholmes at openjdk.java.net Thu Apr 22 04:37:20 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 04:37:20 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:10:02 GMT, Per Liden wrote: > This patch enables ZGC on macOS/aarch64. It does three things: > 1) Enables building of ZGC on this platform. > 2) Adds `os::processor_id()`, which for now always returns 0. > 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. > > Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). Hi Per, Looks good. One minor nit. Thanks, David src/hotspot/os/bsd/os_bsd.cpp line 2149: > 2147: > 2148: return (uint)processor_id; > 2149: #else Please add a comment indicating what platform this else is referring to. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3609 From haosun at openjdk.java.net Thu Apr 22 04:44:23 2021 From: haosun at openjdk.java.net (Hao Sun) Date: Thu, 22 Apr 2021 04:44:23 GMT Subject: Integrated: 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 06:16:43 GMT, Hao Sun wrote: > Making the conversion explicit would fix it. > > Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. > Therefore clang-8 and clang-9 are not affected. The flag with similar > functionality in gcc is '-Wfloat-conversion', but it is not enabled by > '-Wall' or '-Wextra'. That's why this warning does not appear when > building with gcc. > > > Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. > Note that '--with-extra-cxxflags=-Wno-deprecated-copy' should be added when configuration. It's another issue (See JDK-8258010) This pull request has now been integrated. Changeset: 28c35aed Author: Hao Sun Committer: David Holmes URL: https://git.openjdk.java.net/jdk/commit/28c35aed Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1956 From stefank at openjdk.java.net Thu Apr 22 06:01:26 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 22 Apr 2021 06:01:26 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:10:02 GMT, Per Liden wrote: > This patch enables ZGC on macOS/aarch64. It does three things: > 1) Enables building of ZGC on this platform. > 2) Adds `os::processor_id()`, which for now always returns 0. > 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. > > Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3609 From stuefe at openjdk.java.net Thu Apr 22 06:13:20 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 22 Apr 2021 06:13:20 GMT Subject: RFR: 8265696 move cds sources In-Reply-To: References: Message-ID: <3ivrvr2C4ouw_Pv1-7TuY2Ugn5KK_-MgoGBre3ij4TY=.f6e507f9-7b17-46c5-b836-540b807cec5a@github.com> On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Hi @iklam, this is a very welcome change! Nothing much to add to what David wrote (include guards need renaming). Apart from that, I was surprised that no gtests needed to be adapted, but seems cds has no gtests? I tested building without cds, works fine. Thanks for doing this! If you fix the include guards, this is fine by me. ..Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Thu Apr 22 06:18:11 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 06:18:11 GMT Subject: RFR: 8265696 move cds sources [v2] In-Reply-To: References: Message-ID: <-pjc1lfaVdvDcDXtulHWrE_OLkJm73_FXvy-4WoyzKw=.165c328e-1f6d-4ce1-b188-91be4e11ef7f@github.com> > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled - fixed include guards -> #ifndef SHARE_CDS_xxxxx ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3610/files - new: https://git.openjdk.java.net/jdk/pull/3610/files/ba45831f..a1a2699f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=00-01 Stats: 66 lines in 19 files changed: 6 ins; 16 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/3610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3610/head:pull/3610 PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Thu Apr 22 06:23:21 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 06:23:21 GMT Subject: RFR: 8265696 move cds sources [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 04:14:38 GMT, David Holmes wrote: >> Thank you! > > I don't suppose we can just exclude the new directory rather than listing individual files? Fixed. Now all files under share/cds are excluded. I needed to move compactHashtable.cpp back to its old location since a little of it is used even when CDS is not used. ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Thu Apr 22 06:23:20 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 06:23:20 GMT Subject: RFR: 8265696 move cds sources [v2] In-Reply-To: <3ivrvr2C4ouw_Pv1-7TuY2Ugn5KK_-MgoGBre3ij4TY=.f6e507f9-7b17-46c5-b836-540b807cec5a@github.com> References: <3ivrvr2C4ouw_Pv1-7TuY2Ugn5KK_-MgoGBre3ij4TY=.f6e507f9-7b17-46c5-b836-540b807cec5a@github.com> Message-ID: On Thu, 22 Apr 2021 06:10:17 GMT, Thomas Stuefe wrote: > Hi @iklam, > > this is a very welcome change! > > Nothing much to add to what David wrote (include guards need renaming). > > Apart from that, I was surprised that no gtests needed to be adapted, but seems cds has no gtests? > > I tested building without cds, works fine. > > Thanks for doing this! > > If you fix the include guards, this is fine by me. > > ..Thomas Hi Thomas, thanks for the review. You're right that we don't have any gtests .... that should be fixed at some point. ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Thu Apr 22 06:23:23 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 06:23:23 GMT Subject: RFR: 8265696 move cds sources [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 04:16:57 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: >> >> - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled >> - fixed include guards -> #ifndef SHARE_CDS_xxxxx > > src/hotspot/share/cds/archiveUtils.inline.hpp line 25: > >> 23: */ >> 24: >> 25: #ifndef SHARE_MEMORY_ARCHIVEUTILS_INLINE_HPP > > The header file include guards all need updating for the new path. Fixed. > src/hotspot/share/cds/dynamicArchive.hpp line 38: > >> 36: #include "utilities/resourceHash.hpp" >> 37: >> 38: #if INCLUDE_CDS > > I have to wonder who is including this file and why, if CDS is not enabled. E.g., jvm.cpp includes dynamicArchive.hpp, but only uses its declarations inside INCLUDE_CDS blocks. It would be too verbose to do this in jvm.cpp #if INCLUDE_CDS #include "cds/dynamicArchive.hpp" #endif ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Thu Apr 22 06:27:45 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 06:27:45 GMT Subject: RFR: 8265696 move cds sources [v3] In-Reply-To: References: Message-ID: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into 8265696-move-cds-sources - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled - fixed include guards -> #ifndef SHARE_CDS_xxxxx - fixed copyright - moved more files - fixed include lines - 8265696: Move CDS sources from shared/memory to shared/cds ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3610/files - new: https://git.openjdk.java.net/jdk/pull/3610/files/a1a2699f..729c6519 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=01-02 Stats: 338 lines in 63 files changed: 131 ins; 143 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/3610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3610/head:pull/3610 PR: https://git.openjdk.java.net/jdk/pull/3610 From dholmes at openjdk.java.net Thu Apr 22 06:41:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 06:41:33 GMT Subject: RFR: 8265696 move cds sources [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 06:27:45 GMT, Ioi Lam wrote: >> The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. >> >> - src/hotspot/share/classfile/classListParser.cpp >> - src/hotspot/share/classfile/classListParser.hpp >> - src/hotspot/share/classfile/classListWriter.hpp >> - src/hotspot/share/classfile/compactHashtable.cpp >> - src/hotspot/share/classfile/compactHashtable.hpp >> - src/hotspot/share/classfile/lambdaFormInvokers.cpp >> - src/hotspot/share/classfile/lambdaFormInvokers.hpp >> - src/hotspot/share/memory/archiveBuilder.cpp >> - src/hotspot/share/memory/archiveBuilder.hpp >> - src/hotspot/share/memory/archiveUtils.cpp >> - src/hotspot/share/memory/archiveUtils.hpp >> - src/hotspot/share/memory/archiveUtils.inline.hpp >> - src/hotspot/share/memory/cppVtables.cpp >> - src/hotspot/share/memory/cppVtables.hpp >> - src/hotspot/share/memory/dumpAllocStats.cpp >> - src/hotspot/share/memory/dumpAllocStats.hpp >> - src/hotspot/share/memory/dynamicArchive.cpp >> - src/hotspot/share/memory/dynamicArchive.hpp >> - src/hotspot/share/memory/filemap.cpp >> - src/hotspot/share/memory/filemap.hpp >> - src/hotspot/share/memory/heapShared.cpp >> - src/hotspot/share/memory/heapShared.hpp >> - src/hotspot/share/memory/heapShared.inline.hpp >> - src/hotspot/share/memory/metaspaceShared.cpp >> - src/hotspot/share/memory/metaspaceShared.hpp >> - src/hotspot/share/prims/cdsoffsets.cpp >> - src/hotspot/share/prims/cdsoffsets.hpp >> >> Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into 8265696-move-cds-sources > - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled > - fixed include guards -> #ifndef SHARE_CDS_xxxxx > - fixed copyright > - moved more files > - fixed include lines > - 8265696: Move CDS sources from shared/memory to shared/cds Updates look good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3610 From dholmes at openjdk.java.net Thu Apr 22 06:41:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 06:41:33 GMT Subject: RFR: 8265696 move cds sources [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 06:19:19 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/dynamicArchive.hpp line 38: >> >>> 36: #include "utilities/resourceHash.hpp" >>> 37: >>> 38: #if INCLUDE_CDS >> >> I have to wonder who is including this file and why, if CDS is not enabled. > > E.g., jvm.cpp includes dynamicArchive.hpp, but only uses its declarations inside INCLUDE_CDS blocks. It would be too verbose to do this in jvm.cpp > > > #if INCLUDE_CDS > #include "cds/dynamicArchive.hpp" > #endif We routinely do that for other INCLUDE_X features. ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From pliden at openjdk.java.net Thu Apr 22 06:43:46 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 22 Apr 2021 06:43:46 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 [v2] In-Reply-To: References: Message-ID: <2yB8guCDtonp_f251AssKN1-8TuSYqH2zjqjrEmO7ks=.704854fb-c601-4417-a34c-46e7242f2743@github.com> On Thu, 22 Apr 2021 04:26:11 GMT, David Holmes wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment to #else > > src/hotspot/os/bsd/os_bsd.cpp line 2149: > >> 2147: >> 2148: return (uint)processor_id; >> 2149: #else > > Please add a comment indicating what platform this else is referring to. Will fix! ------------- PR: https://git.openjdk.java.net/jdk/pull/3609 From pliden at openjdk.java.net Thu Apr 22 06:43:45 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 22 Apr 2021 06:43:45 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 [v2] In-Reply-To: References: Message-ID: <7qkG6INxywBIAyzPqO812c7Pn7IUp5gZzfcjl27lE2E=.73fa7b17-7f51-4cdc-b621-e44d3b619740@github.com> > This patch enables ZGC on macOS/aarch64. It does three things: > 1) Enables building of ZGC on this platform. > 2) Adds `os::processor_id()`, which for now always returns 0. > 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. > > Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). Per Liden has updated the pull request incrementally with one additional commit since the last revision: Add comment to #else ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3609/files - new: https://git.openjdk.java.net/jdk/pull/3609/files/c8913936..dd8c42ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3609&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3609&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3609/head:pull/3609 PR: https://git.openjdk.java.net/jdk/pull/3609 From erikj at openjdk.java.net Thu Apr 22 12:34:27 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 22 Apr 2021 12:34:27 GMT Subject: RFR: 8265696 move cds sources [v3] In-Reply-To: References: Message-ID: <3Wpcv8EYtsrZFR0wsASnEgR32CNbCSZGLbYo56q5PdQ=.57993606-1efc-4e0a-b7e2-29417818068b@github.com> On Thu, 22 Apr 2021 06:27:45 GMT, Ioi Lam wrote: >> The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. >> >> - src/hotspot/share/classfile/classListParser.cpp >> - src/hotspot/share/classfile/classListParser.hpp >> - src/hotspot/share/classfile/classListWriter.hpp >> - src/hotspot/share/classfile/compactHashtable.cpp >> - src/hotspot/share/classfile/compactHashtable.hpp >> - src/hotspot/share/classfile/lambdaFormInvokers.cpp >> - src/hotspot/share/classfile/lambdaFormInvokers.hpp >> - src/hotspot/share/memory/archiveBuilder.cpp >> - src/hotspot/share/memory/archiveBuilder.hpp >> - src/hotspot/share/memory/archiveUtils.cpp >> - src/hotspot/share/memory/archiveUtils.hpp >> - src/hotspot/share/memory/archiveUtils.inline.hpp >> - src/hotspot/share/memory/cppVtables.cpp >> - src/hotspot/share/memory/cppVtables.hpp >> - src/hotspot/share/memory/dumpAllocStats.cpp >> - src/hotspot/share/memory/dumpAllocStats.hpp >> - src/hotspot/share/memory/dynamicArchive.cpp >> - src/hotspot/share/memory/dynamicArchive.hpp >> - src/hotspot/share/memory/filemap.cpp >> - src/hotspot/share/memory/filemap.hpp >> - src/hotspot/share/memory/heapShared.cpp >> - src/hotspot/share/memory/heapShared.hpp >> - src/hotspot/share/memory/heapShared.inline.hpp >> - src/hotspot/share/memory/metaspaceShared.cpp >> - src/hotspot/share/memory/metaspaceShared.hpp >> - src/hotspot/share/prims/cdsoffsets.cpp >> - src/hotspot/share/prims/cdsoffsets.hpp >> >> Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into 8265696-move-cds-sources > - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled > - fixed include guards -> #ifndef SHARE_CDS_xxxxx > - fixed copyright > - moved more files > - fixed include lines > - 8265696: Move CDS sources from shared/memory to shared/cds Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From erikj at openjdk.java.net Thu Apr 22 12:34:28 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 22 Apr 2021 12:34:28 GMT Subject: RFR: 8265696 move cds sources [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 06:19:29 GMT, Ioi Lam wrote: >> I don't suppose we can just exclude the new directory rather than listing individual files? > > Fixed. Now all files under share/cds are excluded. I needed to move compactHashtable.cpp back to its old location since a little of it is used even when CDS is not used. That's indeed a better idea. ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From github.com+20224954+gdams at openjdk.java.net Thu Apr 22 14:30:45 2021 From: github.com+20224954+gdams at openjdk.java.net (George Adams) Date: Thu, 22 Apr 2021 14:30:45 GMT Subject: RFR: 8265531: doc/building.md should mention homebrew install freetype Message-ID: Updates the docs/building.html guide to include steps to install FreeType on macOS using homebrew. ------------- Commit messages: - add macOS freetype install steps to docs/building.html Changes: https://git.openjdk.java.net/jdk/pull/3590/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3590&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265531 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3590.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3590/head:pull/3590 PR: https://git.openjdk.java.net/jdk/pull/3590 From gziemski at openjdk.java.net Thu Apr 22 16:00:33 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 22 Apr 2021 16:00:33 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 [v2] In-Reply-To: <7qkG6INxywBIAyzPqO812c7Pn7IUp5gZzfcjl27lE2E=.73fa7b17-7f51-4cdc-b621-e44d3b619740@github.com> References: <7qkG6INxywBIAyzPqO812c7Pn7IUp5gZzfcjl27lE2E=.73fa7b17-7f51-4cdc-b621-e44d3b619740@github.com> Message-ID: On Thu, 22 Apr 2021 06:43:45 GMT, Per Liden wrote: >> This patch enables ZGC on macOS/aarch64. It does three things: >> 1) Enables building of ZGC on this platform. >> 2) Adds `os::processor_id()`, which for now always returns 0. >> 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. >> >> Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Add comment to #else Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3609 From erikj at openjdk.java.net Thu Apr 22 16:15:20 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 22 Apr 2021 16:15:20 GMT Subject: RFR: 8265531: doc/building.md should mention homebrew install freetype In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 14:58:02 GMT, George Adams wrote: > Updates the docs/building.html guide to include steps to install FreeType on macOS using homebrew. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3590 From iignatyev at openjdk.java.net Thu Apr 22 18:27:34 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Apr 2021 18:27:34 GMT Subject: RFR: 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle In-Reply-To: References: Message-ID: <136KnefxhOEoN2VlKsKGhVW0Wfy2GQsHmAY-x7IFYFE=.d09f2533-0a0d-4b0f-b916-4c0adc00103e@github.com> On Thu, 22 Apr 2021 18:15:58 GMT, Mikael Vidstedt wrote: > The bootjdk used for macosx-aarch64 at Oracle is a custom build of JDK 16 from early December, so does not include all the JDK 16 GA functionality. This leads to build issues after JDK-8263621 which uses a method not included in the custom version. Let's bump the bootjdk used for macosx-aarch64 to jdk-17+19 instead. Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3636 From mikael at openjdk.java.net Thu Apr 22 18:27:34 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 22 Apr 2021 18:27:34 GMT Subject: RFR: 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle Message-ID: The bootjdk used for macosx-aarch64 at Oracle is a custom build of JDK 16 from early December, so does not include all the JDK 16 GA functionality. This leads to build issues after JDK-8263621 which uses a method not included in the custom version. Let's bump the bootjdk used for macosx-aarch64 to jdk-17+19 instead. ------------- Commit messages: - 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle Changes: https://git.openjdk.java.net/jdk/pull/3636/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3636&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265782 Stats: 28 lines in 1 file changed: 5 ins; 12 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3636.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3636/head:pull/3636 PR: https://git.openjdk.java.net/jdk/pull/3636 From tbell at openjdk.java.net Thu Apr 22 18:31:25 2021 From: tbell at openjdk.java.net (Tim Bell) Date: Thu, 22 Apr 2021 18:31:25 GMT Subject: RFR: 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 18:15:58 GMT, Mikael Vidstedt wrote: > The bootjdk used for macosx-aarch64 at Oracle is a custom build of JDK 16 from early December, so does not include all the JDK 16 GA functionality. This leads to build issues after JDK-8263621 which uses a method not included in the custom version. Let's bump the bootjdk used for macosx-aarch64 to jdk-17+19 instead. Marked as reviewed by tbell (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3636 From iris at openjdk.java.net Thu Apr 22 18:41:27 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 22 Apr 2021 18:41:27 GMT Subject: RFR: 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 18:15:58 GMT, Mikael Vidstedt wrote: > The bootjdk used for macosx-aarch64 at Oracle is a custom build of JDK 16 from early December, so does not include all the JDK 16 GA functionality. This leads to build issues after JDK-8263621 which uses a method not included in the custom version. Let's bump the bootjdk used for macosx-aarch64 to jdk-17+19 instead. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3636 From erikj at openjdk.java.net Thu Apr 22 18:47:24 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 22 Apr 2021 18:47:24 GMT Subject: RFR: 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 18:15:58 GMT, Mikael Vidstedt wrote: > The bootjdk used for macosx-aarch64 at Oracle is a custom build of JDK 16 from early December, so does not include all the JDK 16 GA functionality. This leads to build issues after JDK-8263621 which uses a method not included in the custom version. Let's bump the bootjdk used for macosx-aarch64 to jdk-17+19 instead. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3636 From mikael at openjdk.java.net Thu Apr 22 20:59:26 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 22 Apr 2021 20:59:26 GMT Subject: Integrated: 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 18:15:58 GMT, Mikael Vidstedt wrote: > The bootjdk used for macosx-aarch64 at Oracle is a custom build of JDK 16 from early December, so does not include all the JDK 16 GA functionality. This leads to build issues after JDK-8263621 which uses a method not included in the custom version. Let's bump the bootjdk used for macosx-aarch64 to jdk-17+19 instead. This pull request has now been integrated. Changeset: 0e005989 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/0e005989 Stats: 28 lines in 1 file changed: 5 ins; 12 del; 11 mod 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle Reviewed-by: iignatyev, tbell, iris, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3636 From sviswanathan at openjdk.java.net Thu Apr 22 22:27:50 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 22 Apr 2021 22:27:50 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics Message-ID: Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. The following changes are made: The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. Changes are made to build system to support dependency tracking for assembly files with includes. The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). This work is part of second round of incubation of the Vector API. JEP: https://bugs.openjdk.java.net/browse/JDK-8261663 Please review. Performance: Micro benchmark Base Optimized Unit Gain(Optimized/Base) Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 Double128Vector.COS 49.94 245.89 ops/ms 4.92 Double128Vector.COSH 26.91 126.00 ops/ms 4.68 Double128Vector.EXP 71.64 379.65 ops/ms 5.30 Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 Double128Vector.LOG 61.95 279.84 ops/ms 4.52 Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 Double128Vector.SIN 49.36 240.79 ops/ms 4.88 Double128Vector.SINH 26.59 103.75 ops/ms 3.90 Double128Vector.TAN 41.05 152.39 ops/ms 3.71 Double128Vector.TANH 45.29 169.53 ops/ms 3.74 Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 Double256Vector.COS 58.26 389.77 ops/ms 6.69 Double256Vector.COSH 29.44 151.11 ops/ms 5.13 Double256Vector.EXP 86.67 564.68 ops/ms 6.52 Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 Double256Vector.LOG 71.52 394.90 ops/ms 5.52 Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 Double256Vector.SIN 57.06 380.98 ops/ms 6.68 Double256Vector.SINH 29.40 117.37 ops/ms 3.99 Double256Vector.TAN 44.90 279.90 ops/ms 6.23 Double256Vector.TANH 54.08 274.71 ops/ms 5.08 Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 Double512Vector.COS 59.88 837.04 ops/ms 13.98 Double512Vector.COSH 30.34 172.76 ops/ms 5.70 Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 Double512Vector.LOG 74.84 996.00 ops/ms 13.31 Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 Double512Vector.POW 37.42 384.13 ops/ms 10.26 Double512Vector.SIN 59.74 728.45 ops/ms 12.19 Double512Vector.SINH 29.47 143.38 ops/ms 4.87 Double512Vector.TAN 46.20 587.21 ops/ms 12.71 Double512Vector.TANH 57.36 495.42 ops/ms 8.64 Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 Double64Vector.COS 23.42 152.01 ops/ms 6.49 Double64Vector.COSH 17.34 113.34 ops/ms 6.54 Double64Vector.EXP 27.08 203.53 ops/ms 7.52 Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 Double64Vector.LOG 26.75 142.63 ops/ms 5.33 Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 Double64Vector.SIN 23.28 146.91 ops/ms 6.31 Double64Vector.SINH 17.62 88.59 ops/ms 5.03 Double64Vector.TAN 21.00 86.43 ops/ms 4.12 Double64Vector.TANH 23.75 111.35 ops/ms 4.69 Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 Float128Vector.COS 42.82 803.02 ops/ms 18.75 Float128Vector.COSH 31.44 118.34 ops/ms 3.76 Float128Vector.EXP 72.43 855.33 ops/ms 11.81 Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 Float128Vector.LOG 52.95 877.94 ops/ms 16.58 Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 Float128Vector.SIN 43.38 745.31 ops/ms 17.18 Float128Vector.SINH 31.11 112.91 ops/ms 3.63 Float128Vector.TAN 37.25 332.13 ops/ms 8.92 Float128Vector.TANH 57.63 453.77 ops/ms 7.87 Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 Float256Vector.COS 43.75 926.69 ops/ms 21.18 Float256Vector.COSH 33.52 130.46 ops/ms 3.89 Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 Float256Vector.SIN 44.07 911.04 ops/ms 20.67 Float256Vector.SINH 33.16 122.50 ops/ms 3.69 Float256Vector.TAN 37.85 497.75 ops/ms 13.15 Float256Vector.TANH 64.27 537.20 ops/ms 8.36 Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 Float512Vector.COS 40.92 1567.93 ops/ms 38.32 Float512Vector.COSH 33.42 138.36 ops/ms 4.14 Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 Float512Vector.POW 32.73 1015.85 ops/ms 31.04 Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 Float512Vector.SINH 33.05 129.39 ops/ms 3.91 Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 Float64Vector.COS 44.28 394.33 ops/ms 8.91 Float64Vector.COSH 28.35 95.27 ops/ms 3.36 Float64Vector.EXP 65.80 486.37 ops/ms 7.39 Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 Float64Vector.LOG 51.93 163.25 ops/ms 3.14 Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 Float64Vector.SIN 44.41 382.09 ops/ms 8.60 Float64Vector.SINH 28.20 90.68 ops/ms 3.22 Float64Vector.TAN 36.29 160.89 ops/ms 4.43 Float64Vector.TANH 47.65 214.04 ops/ms 4.49 ------------- Commit messages: - remove whitespace - Merge master - Small fix - cleanup - x86 short vector math optimization for Vector API Changes: https://git.openjdk.java.net/jdk/pull/3638/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265783 Stats: 417153 lines in 124 files changed: 416959 ins; 126 del; 68 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From iklam at openjdk.java.net Fri Apr 23 01:12:58 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 01:12:58 GMT Subject: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v4] In-Reply-To: References: Message-ID: <54irbsjsyoXMzokCiBLZ6tA8du9aTbn1viKvfVArHb0=.ac9d7bec-bb98-4033-a4f6-eea95f8e38e9@github.com> > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into 8265696-move-cds-sources - Merge branch 'master' into 8265696-move-cds-sources - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled - fixed include guards -> #ifndef SHARE_CDS_xxxxx - fixed copyright - moved more files - fixed include lines - 8265696: Move CDS sources from shared/memory to shared/cds ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3610/files - new: https://git.openjdk.java.net/jdk/pull/3610/files/729c6519..43c75a72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=02-03 Stats: 5509 lines in 251 files changed: 2774 ins; 1594 del; 1141 mod Patch: https://git.openjdk.java.net/jdk/pull/3610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3610/head:pull/3610 PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Fri Apr 23 01:23:56 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 01:23:56 GMT Subject: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v5] In-Reply-To: References: Message-ID: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - fixed merge - Merge branch 'master' into 8265696-move-cds-sources - Merge branch 'master' into 8265696-move-cds-sources - Merge branch 'master' into 8265696-move-cds-sources - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled - fixed include guards -> #ifndef SHARE_CDS_xxxxx - fixed copyright - moved more files - fixed include lines - 8265696: Move CDS sources from shared/memory to shared/cds ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3610/files - new: https://git.openjdk.java.net/jdk/pull/3610/files/43c75a72..5ca1c512 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=03-04 Stats: 47 lines in 6 files changed: 17 ins; 12 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/3610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3610/head:pull/3610 PR: https://git.openjdk.java.net/jdk/pull/3610 From dholmes at openjdk.java.net Fri Apr 23 02:07:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Apr 2021 02:07:31 GMT Subject: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v5] In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 01:23:56 GMT, Ioi Lam wrote: >> The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. >> >> - src/hotspot/share/classfile/classListParser.cpp >> - src/hotspot/share/classfile/classListParser.hpp >> - src/hotspot/share/classfile/classListWriter.hpp >> - src/hotspot/share/classfile/compactHashtable.cpp >> - src/hotspot/share/classfile/compactHashtable.hpp >> - src/hotspot/share/classfile/lambdaFormInvokers.cpp >> - src/hotspot/share/classfile/lambdaFormInvokers.hpp >> - src/hotspot/share/memory/archiveBuilder.cpp >> - src/hotspot/share/memory/archiveBuilder.hpp >> - src/hotspot/share/memory/archiveUtils.cpp >> - src/hotspot/share/memory/archiveUtils.hpp >> - src/hotspot/share/memory/archiveUtils.inline.hpp >> - src/hotspot/share/memory/cppVtables.cpp >> - src/hotspot/share/memory/cppVtables.hpp >> - src/hotspot/share/memory/dumpAllocStats.cpp >> - src/hotspot/share/memory/dumpAllocStats.hpp >> - src/hotspot/share/memory/dynamicArchive.cpp >> - src/hotspot/share/memory/dynamicArchive.hpp >> - src/hotspot/share/memory/filemap.cpp >> - src/hotspot/share/memory/filemap.hpp >> - src/hotspot/share/memory/heapShared.cpp >> - src/hotspot/share/memory/heapShared.hpp >> - src/hotspot/share/memory/heapShared.inline.hpp >> - src/hotspot/share/memory/metaspaceShared.cpp >> - src/hotspot/share/memory/metaspaceShared.hpp >> - src/hotspot/share/prims/cdsoffsets.cpp >> - src/hotspot/share/prims/cdsoffsets.hpp >> >> Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - fixed merge > - Merge branch 'master' into 8265696-move-cds-sources > - Merge branch 'master' into 8265696-move-cds-sources > - Merge branch 'master' into 8265696-move-cds-sources > - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled > - fixed include guards -> #ifndef SHARE_CDS_xxxxx > - fixed copyright > - moved more files > - fixed include lines > - 8265696: Move CDS sources from shared/memory to shared/cds Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From vromero at openjdk.java.net Fri Apr 23 02:16:04 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 23 Apr 2021 02:16:04 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v4] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into JDK-8260517 - updating comment after review feedback - removing javax.lang.model changes - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - JVM related changes - 8260517: Compiler implementation for Sealed Classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/8ebe56fd..43e9cb5f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=02-03 Stats: 40790 lines in 1391 files changed: 8730 ins; 27464 del; 4596 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From iklam at openjdk.java.net Fri Apr 23 03:07:02 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 03:07:02 GMT Subject: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v6] In-Reply-To: References: Message-ID: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' into 8265696-move-cds-sources - fixed merge - Merge branch 'master' into 8265696-move-cds-sources - Merge branch 'master' into 8265696-move-cds-sources - Merge branch 'master' into 8265696-move-cds-sources - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled - fixed include guards -> #ifndef SHARE_CDS_xxxxx - fixed copyright - moved more files - fixed include lines - ... and 1 more: https://git.openjdk.java.net/jdk/compare/ba1998d8...8a9e7bdf ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3610/files - new: https://git.openjdk.java.net/jdk/pull/3610/files/5ca1c512..8a9e7bdf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=04-05 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3610/head:pull/3610 PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Fri Apr 23 04:16:32 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 04:16:32 GMT Subject: Integrated: 8265696: Move CDS sources to src/hotspot/shared/cds In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. This pull request has now been integrated. Changeset: 95f0fd6c Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/95f0fd6c Stats: 588 lines in 81 files changed: 254 ins; 282 del; 52 mod 8265696: Move CDS sources to src/hotspot/shared/cds Reviewed-by: erikj, dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Fri Apr 23 04:16:31 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 04:16:31 GMT Subject: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v6] In-Reply-To: <3ivrvr2C4ouw_Pv1-7TuY2Ugn5KK_-MgoGBre3ij4TY=.f6e507f9-7b17-46c5-b836-540b807cec5a@github.com> References: <3ivrvr2C4ouw_Pv1-7TuY2Ugn5KK_-MgoGBre3ij4TY=.f6e507f9-7b17-46c5-b836-540b807cec5a@github.com> Message-ID: On Thu, 22 Apr 2021 06:10:17 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge branch 'master' into 8265696-move-cds-sources >> - fixed merge >> - Merge branch 'master' into 8265696-move-cds-sources >> - Merge branch 'master' into 8265696-move-cds-sources >> - Merge branch 'master' into 8265696-move-cds-sources >> - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled >> - fixed include guards -> #ifndef SHARE_CDS_xxxxx >> - fixed copyright >> - moved more files >> - fixed include lines >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/f8227451...8a9e7bdf > > Hi @iklam, > > this is a very welcome change! > > Nothing much to add to what David wrote (include guards need renaming). > > Apart from that, I was surprised that no gtests needed to be adapted, but seems cds has no gtests? > > I tested building without cds, works fine. > > Thanks for doing this! > > If you fix the include guards, this is fine by me. > > ..Thomas Thanks @tstuefe @erikj79 @dholmes-ora for the review. The latest merged code passes Mach5 build tiers 1-5. I also manually tested the minimal VM build to verify the exclusion of CDS object files. ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From github.com+20224954+gdams at openjdk.java.net Fri Apr 23 10:25:23 2021 From: github.com+20224954+gdams at openjdk.java.net (George Adams) Date: Fri, 23 Apr 2021 10:25:23 GMT Subject: RFR: 8265531: doc/building.md should mention homebrew install freetype In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 16:12:24 GMT, Erik Joelsson wrote: >> Updates the docs/building.html guide to include steps to install FreeType on macOS using homebrew. > > Marked as reviewed by erikj (Reviewer). @erikj79 are you happy to sponsor this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/3590 From erikj at openjdk.java.net Fri Apr 23 13:31:26 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 23 Apr 2021 13:31:26 GMT Subject: RFR: 8265531: doc/building.md should mention homebrew install freetype In-Reply-To: References: Message-ID: <7vqd7AqJzslPh9ggT1x8lfAadrsUZ38qJo9xc5ZgiNY=.4c813a09-c50b-45bf-89c2-6512bf6f0862@github.com> On Tue, 20 Apr 2021 14:58:02 GMT, George Adams wrote: > Updates the docs/building.html guide to include steps to install FreeType on macOS using homebrew. Sure, you need to initiate with the integrate command though. ------------- PR: https://git.openjdk.java.net/jdk/pull/3590 From iklam at openjdk.java.net Fri Apr 23 16:27:40 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 16:27:40 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v4] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:56:45 GMT, Doug Simon wrote: >> While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. >> >> In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. > > Doug Simon has updated the pull request incrementally with two additional commits since the last revision: > > - updated date in copyright > - added blank lines after macros LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3558 From github.com+20224954+gdams at openjdk.java.net Fri Apr 23 17:55:28 2021 From: github.com+20224954+gdams at openjdk.java.net (George Adams) Date: Fri, 23 Apr 2021 17:55:28 GMT Subject: Integrated: 8265531: doc/building.md should mention homebrew install freetype In-Reply-To: References: Message-ID: <7K5UB0MI0ZOD4EPt9-ES4XxM5k7cgVPgIwQ_nMjAtww=.46b011c5-f09b-4689-a590-e4791362f73f@github.com> On Tue, 20 Apr 2021 14:58:02 GMT, George Adams wrote: > Updates the docs/building.html guide to include steps to install FreeType on macOS using homebrew. This pull request has now been integrated. Changeset: 5aab1609 Author: George Adams Committer: Erik Joelsson URL: https://git.openjdk.java.net/jdk/commit/5aab1609 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod 8265531: doc/building.md should mention homebrew install freetype Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3590 From dnsimon at openjdk.java.net Fri Apr 23 23:35:27 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 23 Apr 2021 23:35:27 GMT Subject: Integrated: 8265403: consolidate definition of CPU features In-Reply-To: References: Message-ID: On Sat, 17 Apr 2021 20:18:31 GMT, Doug Simon wrote: > While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. This pull request has now been integrated. Changeset: 5aed446e Author: Doug Simon URL: https://git.openjdk.java.net/jdk/commit/5aed446e Stats: 493 lines in 15 files changed: 146 ins; 235 del; 112 mod 8265403: consolidate definition of CPU features Reviewed-by: kvn, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From dnsimon at openjdk.java.net Fri Apr 23 23:35:25 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 23 Apr 2021 23:35:25 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v4] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 20:01:46 GMT, Vladimir Kozlov wrote: >> Doug Simon has updated the pull request incrementally with two additional commits since the last revision: >> >> - updated date in copyright >> - added blank lines after macros > > You need review from Runtime group too. Thanks for the reviews @vnkozlov and @iklam. ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From manavjeet18295 at iiitd.ac.in Sat Apr 24 14:19:14 2021 From: manavjeet18295 at iiitd.ac.in (Manavjeet Singh) Date: Sat, 24 Apr 2021 19:49:14 +0530 Subject: Error while using self compiled openJDK14 in eclipse In-Reply-To: References: Message-ID: Moved this thread to build-dev at openjdk.java.net from hotspot-gc-dev at openjdk.java.net. On Sat, Apr 24, 2021 at 7:44 PM Guoxiong Li wrote: > Hi Manavjeet, > > It seems like an issue about building. Could you move this thread to > build-dev at openjdk.java.net ? > We can continue the discussion there. > > ---- > Best Regards, > Guoxiong. > > On Sat, Apr 24, 2021 at 9:28 PM Manavjeet Singh < > manavjeet18295 at iiitd.ac.in> wrote: > >> Hi Guoxiong, >> There isn't any images folder under 'linux-x86_64-server-release'. I have >> only the following files(not bold ones are the folders). >> bootcycle-spec.gmk build.log.old configure.log hotspot >> Makefile support >> buildjdk-spec.gmk buildtools configure.log.old jdk >> make-support >> build.log compare.sh configure-support jdk.code-workspace >> spec.gmk >> >> And the following filed under 'linux-x86_64-server-release/jdk/' >> bin include man _optimize_image_exec.cmdline >> _optimize_image_exec.marker >> conf lib modules _optimize_image_exec.log release >> >> >> >> On Sat, Apr 24, 2021 at 6:40 PM Guoxiong Li wrote: >> >>> Hi Manavjeet, >>> >>> I haven't used eclipse for a long time so my idea may be wrong. >>> According to your description, I think you should use >>> the path `jdk14/build/linux-x86_64-server-release*/images/jdk*` instead. >>> >>> --- >>> Best Regards, >>> Guoxiong. >>> >>> On Sat, Apr 24, 2021 at 8:59 PM Manavjeet Singh < >>> manavjeet18295 at iiitd.ac.in> wrote: >>> >>>> Hi! >>>> I compiled OpenJDK-14 on my machine and it is working fine when used >>>> from >>>> the command line. I want to build a program using it but when trying to >>>> add >>>> it to Eclipse(v4.18) through Window->Preferences->Installed >>>> JREs->Add->StandardVM and giving the path >>>> jdk14/build/linux-x86_64-server-release/jdk/. >>>> But it is showing the error: "Target is not a JDK root. System library >>>> not >>>> found". >>>> Have I made some mistake while compiling the jdk? Any help would be >>>> appreciated. >>>> Thanks >>>> >>> From lgxbslgx at gmail.com Sat Apr 24 14:30:07 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Sat, 24 Apr 2021 22:30:07 +0800 Subject: Error while using self compiled openJDK14 in eclipse In-Reply-To: References: Message-ID: After building, the sub-directories under 'linux-x86_64-server-release' are shown as below. *bootcycle-spec.gmk build.log.old configure.log hotspot Makefile supportbuildjdk-spec.gmk buildtools configure.log.old images make-supportbuild.log compare.sh configure-support jdk spec.gmk* What you are missing is the folder `images`. Could you give the brief steps on how you build the jdk? Did you use `make images` or `make all`? On Sat, Apr 24, 2021 at 10:19 PM Manavjeet Singh wrote: > Moved this thread to build-dev at openjdk.java.net from > hotspot-gc-dev at openjdk.java.net. > > > On Sat, Apr 24, 2021 at 7:44 PM Guoxiong Li wrote: > >> Hi Manavjeet, >> >> It seems like an issue about building. Could you move this thread to >> build-dev at openjdk.java.net ? >> We can continue the discussion there. >> >> ---- >> Best Regards, >> Guoxiong. >> >> On Sat, Apr 24, 2021 at 9:28 PM Manavjeet Singh < >> manavjeet18295 at iiitd.ac.in> wrote: >> >>> Hi Guoxiong, >>> There isn't any images folder under 'linux-x86_64-server-release'. I >>> have only the following files(not bold ones are the folders). >>> bootcycle-spec.gmk build.log.old configure.log hotspot >>> Makefile support >>> buildjdk-spec.gmk buildtools configure.log.old jdk >>> make-support >>> build.log compare.sh configure-support jdk.code-workspace >>> spec.gmk >>> >>> And the following filed under 'linux-x86_64-server-release/jdk/' >>> bin include man _optimize_image_exec.cmdline >>> _optimize_image_exec.marker >>> conf lib modules _optimize_image_exec.log release >>> >>> >>> >>> On Sat, Apr 24, 2021 at 6:40 PM Guoxiong Li wrote: >>> >>>> Hi Manavjeet, >>>> >>>> I haven't used eclipse for a long time so my idea may be wrong. >>>> According to your description, I think you should use >>>> the path `jdk14/build/linux-x86_64-server-release*/images/jdk*` >>>> instead. >>>> >>>> --- >>>> Best Regards, >>>> Guoxiong. >>>> >>>> On Sat, Apr 24, 2021 at 8:59 PM Manavjeet Singh < >>>> manavjeet18295 at iiitd.ac.in> wrote: >>>> >>>>> Hi! >>>>> I compiled OpenJDK-14 on my machine and it is working fine when used >>>>> from >>>>> the command line. I want to build a program using it but when trying >>>>> to add >>>>> it to Eclipse(v4.18) through Window->Preferences->Installed >>>>> JREs->Add->StandardVM and giving the path >>>>> jdk14/build/linux-x86_64-server-release/jdk/. >>>>> But it is showing the error: "Target is not a JDK root. System library >>>>> not >>>>> found". >>>>> Have I made some mistake while compiling the jdk? Any help would be >>>>> appreciated. >>>>> Thanks >>>>> >>>> From lgxbslgx at gmail.com Sun Apr 25 23:49:45 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Mon, 26 Apr 2021 07:49:45 +0800 Subject: Error while using self compiled openJDK14 in eclipse In-Reply-To: References: Message-ID: Hi Manavjeet, Glad to see that your issue has been solved. FYI: I found your last email was only sent to me and not sent(or CC) to ` build-dev at openjdk.java.net`. It makes it impossible for others to receive and reply to your email. Just a reminder for you. --- Best Regards, Guoxiong. On Sat, Apr 24, 2021 at 11:32 PM Manavjeet Singh wrote: > I used 'make CONF=linux-x86_64-server-release'. After using `make images > CONF=linux-x86_64-server-release` I got the folder images in > 'linux-x86_64-server-release'. > Thanks! > Manavjeet Singh > CSD Undergraduate | 2018295 > Indraprastha Institute of Information Technology (IIITD) > From manavjeet18295 at iiitd.ac.in Mon Apr 26 04:07:08 2021 From: manavjeet18295 at iiitd.ac.in (Manavjeet Singh) Date: Mon, 26 Apr 2021 09:37:08 +0530 Subject: Error while using self compiled openJDK14 in eclipse In-Reply-To: References: Message-ID: I used 'make CONF=linux-x86_64-server-release'. After using `make images CONF=linux-x86_64-server-release` I got the folder images in 'linux-x86_64-server-release'. Thanks! Manavjeet Singh CSD Undergraduate | 2018295 Indraprastha Institute of Information Technology (IIITD) On Sat, Apr 24, 2021 at 8:00 PM Guoxiong Li wrote: > > After building, the sub-directories under 'linux-x86_64-server-release' > are shown as below. > > > *bootcycle-spec.gmk build.log.old configure.log hotspot Makefile > supportbuildjdk-spec.gmk buildtools configure.log.old images > make-supportbuild.log compare.sh configure-support jdk > spec.gmk* > > What you are missing is the folder `images`. > Could you give the brief steps on how you build the jdk? > Did you use `make images` or `make all`? > > > On Sat, Apr 24, 2021 at 10:19 PM Manavjeet Singh < > manavjeet18295 at iiitd.ac.in> wrote: > >> Moved this thread to build-dev at openjdk.java.net from >> hotspot-gc-dev at openjdk.java.net. >> >> >> On Sat, Apr 24, 2021 at 7:44 PM Guoxiong Li wrote: >> >>> Hi Manavjeet, >>> >>> It seems like an issue about building. Could you move this thread to >>> build-dev at openjdk.java.net ? >>> We can continue the discussion there. >>> >>> ---- >>> Best Regards, >>> Guoxiong. >>> >>> On Sat, Apr 24, 2021 at 9:28 PM Manavjeet Singh < >>> manavjeet18295 at iiitd.ac.in> wrote: >>> >>>> Hi Guoxiong, >>>> There isn't any images folder under 'linux-x86_64-server-release'. I >>>> have only the following files(not bold ones are the folders). >>>> bootcycle-spec.gmk build.log.old configure.log hotspot >>>> Makefile support >>>> buildjdk-spec.gmk buildtools configure.log.old jdk >>>> make-support >>>> build.log compare.sh configure-support >>>> jdk.code-workspace spec.gmk >>>> >>>> And the following filed under 'linux-x86_64-server-release/jdk/' >>>> bin include man _optimize_image_exec.cmdline >>>> _optimize_image_exec.marker >>>> conf lib modules _optimize_image_exec.log release >>>> >>>> >>>> >>>> On Sat, Apr 24, 2021 at 6:40 PM Guoxiong Li wrote: >>>> >>>>> Hi Manavjeet, >>>>> >>>>> I haven't used eclipse for a long time so my idea may be wrong. >>>>> According to your description, I think you should use >>>>> the path `jdk14/build/linux-x86_64-server-release*/images/jdk*` >>>>> instead. >>>>> >>>>> --- >>>>> Best Regards, >>>>> Guoxiong. >>>>> >>>>> On Sat, Apr 24, 2021 at 8:59 PM Manavjeet Singh < >>>>> manavjeet18295 at iiitd.ac.in> wrote: >>>>> >>>>>> Hi! >>>>>> I compiled OpenJDK-14 on my machine and it is working fine when used >>>>>> from >>>>>> the command line. I want to build a program using it but when trying >>>>>> to add >>>>>> it to Eclipse(v4.18) through Window->Preferences->Installed >>>>>> JREs->Add->StandardVM and giving the path >>>>>> jdk14/build/linux-x86_64-server-release/jdk/. >>>>>> But it is showing the error: "Target is not a JDK root. System >>>>>> library not >>>>>> found". >>>>>> Have I made some mistake while compiling the jdk? Any help would be >>>>>> appreciated. >>>>>> Thanks >>>>>> >>>>> From pliden at openjdk.java.net Mon Apr 26 08:49:31 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 26 Apr 2021 08:49:31 GMT Subject: Integrated: 8265702: ZGC on macOS/aarch64 In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:10:02 GMT, Per Liden wrote: > This patch enables ZGC on macOS/aarch64. It does three things: > 1) Enables building of ZGC on this platform. > 2) Adds `os::processor_id()`, which for now always returns 0. > 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. > > Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). This pull request has now been integrated. Changeset: 0d08d735 Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/0d08d735 Stats: 13 lines in 3 files changed: 7 ins; 1 del; 5 mod 8265702: ZGC on macOS/aarch64 Reviewed-by: erikj, dholmes, stefank, gziemski ------------- PR: https://git.openjdk.java.net/jdk/pull/3609 From pliden at openjdk.java.net Mon Apr 26 08:49:30 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 26 Apr 2021 08:49:30 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 23:04:43 GMT, Erik Joelsson wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment to #else > > Build change looks good. Thanks @erikj79, @dholmes-ora, @stefank and @gerard-ziemski for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/3609 From ihse at openjdk.java.net Mon Apr 26 12:56:50 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 26 Apr 2021 12:56:50 GMT Subject: RFR: 8264188: Improve handling of assembly files in the JDK [v3] In-Reply-To: References: Message-ID: > We have a handful of assembly files in the JDK. They have long been left aside, with a "if it ain't broken, don't fix it" attitude. > > In the current panama-vector, there is a lot more assembly files incoming, including for the Windows platforrm, which has not existed for a long time in the JDK. > > It is time to give assembly files some more love and care. This patch cleans up the handling in the build system, and it unifies between .s and .S files. > > For historical reasons, .s has been the suffix used in the posix world to signify assembly output as generated by a compiler, and .S to signify "hand-written" precious assembly. One effect of this is that gcc and clang will run the preprocessor on files named .S but not on files named .s. > > All our files are "hand-written" in this sense, and should have the .S suffix. But not all had. On mac, it was even worse, where the files were named .s but the option `-x assembler-with-cpp` was used to force clang to treat them as .S files instead... This change however made the preprocesser try to parse comments of the form > > # if (a) { > > as preprocessor directives, and balk at them. In one of the files, I had to wrap this in preprocessor comments (`/* ... */`). > > We also had inconsistent handling on dependencies. For preprocessed assembly files, it really makes sense to have dependency tracking, exactly as for C/C++ files. Now the dependency tracking in NativeCompilation is simplified, and applies to all files. (The sole exception is Windows assembly, since masm is unable to output dependency information, even though it is able to include files :-(). > > This patch has been partly written by Sandhya Viswanathan for the panama-vector repo. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into improve-asm-handling - Use OPENJDK_BUILD_CPU_BITS instead - Fix comments that trip up the preprocessor - Transplant over more fixes from panama-vector - -Ta needs to be prefixed to source file - Remove support for non-preprocessed assembly files in gcc/clang - Rename all *.s files to *.S - Port over initial fixes from panama-vector ------------- Changes: https://git.openjdk.java.net/jdk/pull/3198/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3198&range=02 Stats: 78 lines in 12 files changed: 33 ins; 9 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/3198.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3198/head:pull/3198 PR: https://git.openjdk.java.net/jdk/pull/3198 From ihse at openjdk.java.net Mon Apr 26 13:00:33 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 26 Apr 2021 13:00:33 GMT Subject: Integrated: 8264188: Improve handling of assembly files in the JDK In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 16:25:32 GMT, Magnus Ihse Bursie wrote: > We have a handful of assembly files in the JDK. They have long been left aside, with a "if it ain't broken, don't fix it" attitude. > > In the current panama-vector, there is a lot more assembly files incoming, including for the Windows platforrm, which has not existed for a long time in the JDK. > > It is time to give assembly files some more love and care. This patch cleans up the handling in the build system, and it unifies between .s and .S files. > > For historical reasons, .s has been the suffix used in the posix world to signify assembly output as generated by a compiler, and .S to signify "hand-written" precious assembly. One effect of this is that gcc and clang will run the preprocessor on files named .S but not on files named .s. > > All our files are "hand-written" in this sense, and should have the .S suffix. But not all had. On mac, it was even worse, where the files were named .s but the option `-x assembler-with-cpp` was used to force clang to treat them as .S files instead... This change however made the preprocesser try to parse comments of the form > > # if (a) { > > as preprocessor directives, and balk at them. In one of the files, I had to wrap this in preprocessor comments (`/* ... */`). > > We also had inconsistent handling on dependencies. For preprocessed assembly files, it really makes sense to have dependency tracking, exactly as for C/C++ files. Now the dependency tracking in NativeCompilation is simplified, and applies to all files. (The sole exception is Windows assembly, since masm is unable to output dependency information, even though it is able to include files :-(). > > This patch has been partly written by Sandhya Viswanathan for the panama-vector repo. This pull request has now been integrated. Changeset: b9f66d93 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/b9f66d93 Stats: 78 lines in 12 files changed: 33 ins; 9 del; 36 mod 8264188: Improve handling of assembly files in the JDK Co-authored-by: Sandhya Viswanathan Co-authored-by: Magnus Ihse Bursie Reviewed-by: erikj, vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/3198 From github.com+20224954+gdams at openjdk.java.net Mon Apr 26 17:51:29 2021 From: github.com+20224954+gdams at openjdk.java.net (George Adams) Date: Mon, 26 Apr 2021 17:51:29 GMT Subject: RFR: 8254846 Warn before building if Xcode has no disk space left Message-ID: This PR creates a simple sanity check for all systems to verify that there is at least 6 GB available disk space before compiling. I got the 6 GB requirement from https://github.com/openjdk/jdk/blob/master/doc/building.md#building-on-x86 ------------- Commit messages: - ensure that system has enough disk space before building Changes: https://git.openjdk.java.net/jdk/pull/3693/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3693&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254846 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3693.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3693/head:pull/3693 PR: https://git.openjdk.java.net/jdk/pull/3693 From kvn at openjdk.java.net Mon Apr 26 22:45:25 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 26 Apr 2021 22:45:25 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v6] In-Reply-To: References: Message-ID: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into JDK-8264805 - Address review comments - Remove exports from Graal module to jdk.aot - Merge branch 'master' into JDK-8264805 - Merge branch 'master' into JDK-8264805 - 8264805: Remove the experimental Ahead-of-Time Compiler ------------- Changes: https://git.openjdk.java.net/jdk/pull/3398/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=05 Stats: 26972 lines in 378 files changed: 2 ins; 26772 del; 198 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Tue Apr 27 01:15:37 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 27 Apr 2021 01:15:37 GMT Subject: Integrated: 8264805: Remove the experimental Ahead-of-Time Compiler In-Reply-To: References: Message-ID: <3MIAR4n0RJot9rerXkZf7hB7NlYhJbPI6ri5q9IP3SM=.c6fecb4a-0d84-4c78-bf41-b750ee03d6df@github.com> On Thu, 8 Apr 2021 15:23:52 GMT, Vladimir Kozlov wrote: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 This pull request has now been integrated. Changeset: 694acedf Author: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/694acedf Stats: 26972 lines in 378 files changed: 2 ins; 26772 del; 198 mod 8264805: Remove the experimental Ahead-of-Time Compiler Reviewed-by: coleenp, erikj, stefank, iignatyev, dholmes, aph, shade, iklam, mchung, iveresov ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Tue Apr 27 02:18:40 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 27 Apr 2021 02:18:40 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v4] In-Reply-To: References: Message-ID: <0mJY3m49euRLBowk0WfgXqx6bGSqNJFykEXZdJ9cO6k=.87753850-16f7-4c15-b526-c29898caf5ac@github.com> > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'JDK-8264805' into JDK-8264806 - Merge branch 'master' into JDK-8264805 - Restore Compiler::isGraalEnabled() - Restore Graal Builder image makefile - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 - Address review comments - 8264806: Remove the experimental JIT compiler - Remove exports from Graal module to jdk.aot - Merge branch 'master' into JDK-8264805 - Merge branch 'master' into JDK-8264805 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b524a81a...db7c9aaf ------------- Changes: https://git.openjdk.java.net/jdk/pull/3421/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=03 Stats: 468493 lines in 3247 files changed: 2 ins; 468290 del; 201 mod Patch: https://git.openjdk.java.net/jdk/pull/3421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421 PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Tue Apr 27 04:44:17 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 27 Apr 2021 04:44:17 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v5] In-Reply-To: References: Message-ID: <9SR3Bnj0ywpPcSx4uU4G9oH7cXJv6dWPIkvyIb_rnKo=.30180267-aeb7-4ab3-947a-cdf80e62c81c@github.com> > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into JDK-8264806 - Merge branch 'JDK-8264805' into JDK-8264806 - Merge branch 'master' into JDK-8264805 - Restore Compiler::isGraalEnabled() - Restore Graal Builder image makefile - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 - Address review comments - 8264806: Remove the experimental JIT compiler - Remove exports from Graal module to jdk.aot - Merge branch 'master' into JDK-8264805 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/694acedf...b1e9ba63 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3421/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=04 Stats: 441532 lines in 2884 files changed: 0 ins; 441518 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421 PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Tue Apr 27 06:26:53 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 27 Apr 2021 06:26:53 GMT Subject: Integrated: 8264806: Remove the experimental JIT compiler In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov wrote: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 This pull request has now been integrated. Changeset: 4785e112 Author: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/4785e112 Stats: 441532 lines in 2884 files changed: 0 ins; 441518 del; 14 mod 8264806: Remove the experimental JIT compiler Reviewed-by: iignatyev, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From iignatyev at openjdk.java.net Tue Apr 27 19:10:50 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 27 Apr 2021 19:10:50 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com> Message-ID: <95GbTmxTIqVaWrUNi-Tj9vpkSVATyUA7HoFF2v6N6GQ=.7ffe5ebb-c815-48e2-883a-797742c741ce@github.com> On Tue, 13 Apr 2021 09:30:23 GMT, Doug Simon wrote: > I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later). @dougxc, I don't think that we should (or even can) rename it to `vm.jvmcicompiler.enabled`. although the value of the property is indeed `true` whenever a jvmci compiler is enabled, it is used to filter out tests that are incompatible with a particular compiler -- graal. so what we can do is to change `requires/VMProps.java` to set `vm.graal.enabled` only if the jvmci compiler is indeed graal, but on the other hand, we haven't heard anyone complaining that the test coverage for their jvmci compiler has been reduced, so I don't see much of the benefit here. -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From dnsimon at openjdk.java.net Tue Apr 27 19:52:22 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 27 Apr 2021 19:52:22 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <95GbTmxTIqVaWrUNi-Tj9vpkSVATyUA7HoFF2v6N6GQ=.7ffe5ebb-c815-48e2-883a-797742c741ce@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com> <95GbTmxTIqVaWrUNi-Tj9vpkSVATyUA7HoFF2v6N6GQ=.7ffe5ebb-c815-48e2-883a-797742c741ce@github.com> Message-ID: On Tue, 27 Apr 2021 19:07:45 GMT, Igor Ignatyev wrote: > > I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later). > > @dougxc, I don't think that we should (or even can) rename it to `vm.jvmcicompiler.enabled`. although the value of the property is indeed `true` whenever a jvmci compiler is enabled, it is used to filter out tests that are incompatible with a particular compiler -- graal. so what we can do is to change `requires/VMProps.java` to set `vm.graal.enabled` only if the jvmci compiler is indeed graal, but on the other hand, we haven't heard anyone complaining that the test coverage for their jvmci compiler has been reduced, so I don't see much of the benefit here. > > -- Igor Yes, we should just it as is until a second JVMCI compiler shows up. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From aleonard at openjdk.java.net Wed Apr 28 14:48:15 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Wed, 28 Apr 2021 14:48:15 GMT Subject: RFR: 8265666: Enable AIX build platform to make external debug symbols Message-ID: Signed-off-by: Andrew Leonard ------------- Commit messages: - 8265666: Enable AIX build platform to make external debug symbols Changes: https://git.openjdk.java.net/jdk/pull/3763/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3763&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265666 Stats: 15 lines in 2 files changed: 4 ins; 9 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3763.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3763/head:pull/3763 PR: https://git.openjdk.java.net/jdk/pull/3763 From anleonar at redhat.com Wed Apr 28 15:01:55 2021 From: anleonar at redhat.com (Andrew Leonard) Date: Wed, 28 Apr 2021 16:01:55 +0100 Subject: RFR: 8265666: Enable AIX build platform to make external debug symbols Message-ID: This change simply enables the specification of configure args to build external AIX debug symbols: --with-native-debug-symbols=external/zipped Now that we build using XLC/xlclang++ v16+ which supports standard external .debuginfo generation, it is simply a matter of enabling the option for AIX, and the rules for the debug info files and copy. This change has also been tested at AdoptOpenJDK build Jenkins. Thanks Andrew From erikj at openjdk.java.net Wed Apr 28 15:16:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 28 Apr 2021 15:16:53 GMT Subject: RFR: 8265666: Enable AIX build platform to make external debug symbols In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 14:41:26 GMT, Andrew Leonard wrote: > Signed-off-by: Andrew Leonard make/common/NativeCompilation.gmk line 979: > 977: else ifeq ($(call isTargetOs, aix), true) > 978: $1_DEBUGINFO_FILES := $$($1_SYMBOLS_DIR)/$$($1_NOSUFFIX).debuginfo > 979: $1_CREATE_DEBUGINFO_CMDS := $(CP) $$($1_TARGET) $$($1_DEBUGINFO_FILES) This looks like you are just copying the linked binary and calling it .debuginfo. Is the idea that the original binary then gets stripped and this is just saving the unstripped binary? I don't know how things are done in AIX, but this seems like a rather strange way of achieving external symbol information to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3763 From redestad at openjdk.java.net Wed Apr 28 15:52:13 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 28 Apr 2021 15:52:13 GMT Subject: RFR: 8264678: Incomplete comment in build.tools.generatecharacter.GenerateCharacter Message-ID: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com> I'm not exactly sure what I intended to say in this partial comment. Removing it. ------------- Commit messages: - Incomplete comment in build.tools.generatecharacter.GenerateCharacter Changes: https://git.openjdk.java.net/jdk/pull/3766/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3766&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264678 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3766.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3766/head:pull/3766 PR: https://git.openjdk.java.net/jdk/pull/3766 From erikj at openjdk.java.net Wed Apr 28 16:00:54 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 28 Apr 2021 16:00:54 GMT Subject: RFR: 8264678: Incomplete comment in build.tools.generatecharacter.GenerateCharacter In-Reply-To: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com> References: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com> Message-ID: On Wed, 28 Apr 2021 15:44:47 GMT, Claes Redestad wrote: > I'm not exactly sure what I intended to say in this partial comment. Removing it. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3766 From naoto at openjdk.java.net Wed Apr 28 16:19:53 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 28 Apr 2021 16:19:53 GMT Subject: RFR: 8264678: Incomplete comment in build.tools.generatecharacter.GenerateCharacter In-Reply-To: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com> References: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com> Message-ID: <-xGo8ZUpK052EsjXyGYZoBvU8aILNrFPTEgQPSZ6tSI=.8eded174-da64-4c19-96b9-8b69fe5865e2@github.com> On Wed, 28 Apr 2021 15:44:47 GMT, Claes Redestad wrote: > I'm not exactly sure what I intended to say in this partial comment. Removing it. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3766 From iris at openjdk.java.net Wed Apr 28 16:35:54 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 28 Apr 2021 16:35:54 GMT Subject: RFR: 8264678: Incomplete comment in build.tools.generatecharacter.GenerateCharacter In-Reply-To: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com> References: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com> Message-ID: <7eBURBdNl7QUFH1-qqlJwWlmdu_lOCouuLg3RaRs1Bk=.c48baad9-4a22-45fd-aeec-35089e5a748e@github.com> On Wed, 28 Apr 2021 15:44:47 GMT, Claes Redestad wrote: > I'm not exactly sure what I intended to say in this partial comment. Removing it. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3766 From aleonard at openjdk.java.net Wed Apr 28 17:05:04 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Wed, 28 Apr 2021 17:05:04 GMT Subject: RFR: 8265666: Enable AIX build platform to make external debug symbols In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 15:14:24 GMT, Erik Joelsson wrote: >> Signed-off-by: Andrew Leonard > > make/common/NativeCompilation.gmk line 979: > >> 977: else ifeq ($(call isTargetOs, aix), true) >> 978: $1_DEBUGINFO_FILES := $$($1_SYMBOLS_DIR)/$$($1_NOSUFFIX).debuginfo >> 979: $1_CREATE_DEBUGINFO_CMDS := $(CP) $$($1_TARGET) $$($1_DEBUGINFO_FILES) > > This looks like you are just copying the linked binary and calling it .debuginfo. Is the idea that the original binary then gets stripped and this is just saving the unstripped binary? I don't know how things are done in AIX, but this seems like a rather strange way of achieving external symbol information to me. You're essentially correct Erik, on AIX there is no such tool as OBJCOPY on Linux platforms, so you cannot physically remove the symbolic information from the native compiled object. So this CREATE_DEBUG_INFO_CMDS copies the object containing symbols, prior to the STRIP_CMD being executed as part of the make of $$($1_TARGET) recipe: $$($1_CREATE_DEBUGINFO_CMDS) $$($1_STRIP_CMD) The external debuginfo is then passed by the user of AIX dbx using -B <.debuginfo> You make a good point though that this looks confusing, so I will update the PR with a comment to this rule. thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/3763 From aleonard at openjdk.java.net Wed Apr 28 17:23:18 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Wed, 28 Apr 2021 17:23:18 GMT Subject: RFR: 8265666: Enable AIX build platform to make external debug symbols [v2] In-Reply-To: References: Message-ID: <6DiZfO3kZxxlhWLPNxlr-o1zngWxf8hodVf8Pot0QCg=.5f0d5c19-93b4-434a-95d5-9c8b49513b13@github.com> > Signed-off-by: Andrew Leonard Andrew Leonard has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8265666: Enable AIX build platform to make external debug symbols Signed-off-by: Andrew Leonard ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3763/files - new: https://git.openjdk.java.net/jdk/pull/3763/files/731bd9c3..d457570c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3763&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3763&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3763.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3763/head:pull/3763 PR: https://git.openjdk.java.net/jdk/pull/3763 From aleonard at openjdk.java.net Wed Apr 28 17:47:10 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Wed, 28 Apr 2021 17:47:10 GMT Subject: RFR: 8265666: Enable AIX build platform to make external debug symbols [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 17:00:13 GMT, Andrew Leonard wrote: >> make/common/NativeCompilation.gmk line 982: >> >>> 980: >>> 981: else ifeq ($(call isTargetOs, macosx), true) >>> 982: $1_DEBUGINFO_FILES := \ >> >> This looks like you are just copying the linked binary and calling it .debuginfo. Is the idea that the original binary then gets stripped and this is just saving the unstripped binary? I don't know how things are done in AIX, but this seems like a rather strange way of achieving external symbol information to me. > > You're essentially correct Erik, on AIX there is no such tool as OBJCOPY on Linux platforms, so you cannot physically remove the symbolic information from the native compiled object. So this CREATE_DEBUG_INFO_CMDS copies the object containing symbols, prior to the STRIP_CMD being executed as part of the make of $$($1_TARGET) recipe: > > $$($1_CREATE_DEBUGINFO_CMDS) > $$($1_STRIP_CMD) > > The external debuginfo is then passed by the user of AIX dbx using -B <.debuginfo> > > You make a good point though that this looks confusing, so I will update the PR with a comment to this rule. > thanks I've added a comment in the make file in the refresh ------------- PR: https://git.openjdk.java.net/jdk/pull/3763 From erikj at openjdk.java.net Wed Apr 28 19:46:52 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 28 Apr 2021 19:46:52 GMT Subject: RFR: 8265666: Enable AIX build platform to make external debug symbols [v2] In-Reply-To: <6DiZfO3kZxxlhWLPNxlr-o1zngWxf8hodVf8Pot0QCg=.5f0d5c19-93b4-434a-95d5-9c8b49513b13@github.com> References: <6DiZfO3kZxxlhWLPNxlr-o1zngWxf8hodVf8Pot0QCg=.5f0d5c19-93b4-434a-95d5-9c8b49513b13@github.com> Message-ID: On Wed, 28 Apr 2021 17:23:18 GMT, Andrew Leonard wrote: >> Signed-off-by: Andrew Leonard > > Andrew Leonard has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8265666: Enable AIX build platform to make external debug symbols > > Signed-off-by: Andrew Leonard Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3763 From erikj at openjdk.java.net Wed Apr 28 19:46:52 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 28 Apr 2021 19:46:52 GMT Subject: RFR: 8265666: Enable AIX build platform to make external debug symbols [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 17:43:39 GMT, Andrew Leonard wrote: >> You're essentially correct Erik, on AIX there is no such tool as OBJCOPY on Linux platforms, so you cannot physically remove the symbolic information from the native compiled object. So this CREATE_DEBUG_INFO_CMDS copies the object containing symbols, prior to the STRIP_CMD being executed as part of the make of $$($1_TARGET) recipe: >> >> $$($1_CREATE_DEBUGINFO_CMDS) >> $$($1_STRIP_CMD) >> >> The external debuginfo is then passed by the user of AIX dbx using -B <.debuginfo> >> >> You make a good point though that this looks confusing, so I will update the PR with a comment to this rule. >> thanks > > I've added a comment in the make file in the refresh Thanks for the clarification and the comment! ------------- PR: https://git.openjdk.java.net/jdk/pull/3763 From redestad at openjdk.java.net Wed Apr 28 19:53:52 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 28 Apr 2021 19:53:52 GMT Subject: Integrated: 8264678: Incomplete comment in build.tools.generatecharacter.GenerateCharacter In-Reply-To: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com> References: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com> Message-ID: On Wed, 28 Apr 2021 15:44:47 GMT, Claes Redestad wrote: > I'm not exactly sure what I intended to say in this partial comment. Removing it. This pull request has now been integrated. Changeset: 9df6cc7c Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/9df6cc7cc2633e4231b9b69bed8a0f9e13ec74a7 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8264678: Incomplete comment in build.tools.generatecharacter.GenerateCharacter Reviewed-by: erikj, naoto, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/3766 From sviswanathan at openjdk.java.net Wed Apr 28 21:11:26 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 28 Apr 2021 21:11:26 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > This work is part of second round of incubation of the Vector API. > JEP: https://bugs.openjdk.java.net/browse/JDK-8261663 > > Please review. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge master - remove whitespace - Merge master - Small fix - cleanup - x86 short vector math optimization for Vector API ------------- Changes: https://git.openjdk.java.net/jdk/pull/3638/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=01 Stats: 417102 lines in 120 files changed: 416935 ins; 123 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From mdoerr at openjdk.java.net Thu Apr 29 12:28:53 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 29 Apr 2021 12:28:53 GMT Subject: RFR: 8265666: Enable AIX build platform to make external debug symbols [v2] In-Reply-To: <6DiZfO3kZxxlhWLPNxlr-o1zngWxf8hodVf8Pot0QCg=.5f0d5c19-93b4-434a-95d5-9c8b49513b13@github.com> References: <6DiZfO3kZxxlhWLPNxlr-o1zngWxf8hodVf8Pot0QCg=.5f0d5c19-93b4-434a-95d5-9c8b49513b13@github.com> Message-ID: On Wed, 28 Apr 2021 17:23:18 GMT, Andrew Leonard wrote: >> Signed-off-by: Andrew Leonard > > Andrew Leonard has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8265666: Enable AIX build platform to make external debug symbols > > Signed-off-by: Andrew Leonard Looks good to me. Thanks! ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3763 From aleonard at openjdk.java.net Thu Apr 29 12:38:51 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Thu, 29 Apr 2021 12:38:51 GMT Subject: RFR: 8265666: Enable AIX build platform to make external debug symbols [v2] In-Reply-To: References: <6DiZfO3kZxxlhWLPNxlr-o1zngWxf8hodVf8Pot0QCg=.5f0d5c19-93b4-434a-95d5-9c8b49513b13@github.com> Message-ID: On Thu, 29 Apr 2021 12:26:01 GMT, Martin Doerr wrote: >> Andrew Leonard has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8265666: Enable AIX build platform to make external debug symbols >> >> Signed-off-by: Andrew Leonard > > Looks good to me. Thanks! Thank you @TheRealMDoerr @erikj79 ------------- PR: https://git.openjdk.java.net/jdk/pull/3763 From aleonard at openjdk.java.net Thu Apr 29 12:38:51 2021 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Thu, 29 Apr 2021 12:38:51 GMT Subject: Integrated: 8265666: Enable AIX build platform to make external debug symbols In-Reply-To: References: Message-ID: <5Gigyp9SS972AYe8sUSWgJvEaOIveNSOoTVGA597Jbo=.0a98fccc-6493-4f03-999c-c14bcb26cda8@github.com> On Wed, 28 Apr 2021 14:41:26 GMT, Andrew Leonard wrote: > Signed-off-by: Andrew Leonard This pull request has now been integrated. Changeset: 84b52db9 Author: Andrew Leonard URL: https://git.openjdk.java.net/jdk/commit/84b52db931943db5aa2df7edca7103776f2f2092 Stats: 18 lines in 2 files changed: 7 ins; 9 del; 2 mod 8265666: Enable AIX build platform to make external debug symbols Reviewed-by: erikj, mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/3763 From mikael at openjdk.java.net Thu Apr 29 19:21:09 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 29 Apr 2021 19:21:09 GMT Subject: RFR: 8266318: Switch to macos prefix for macOS bundles Message-ID: Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles files are still use the legacy "osx" string. They should be modernized to use "macos" instead. ------------- Commit messages: - 8266318: Switch to macos prefix for macOS bundles Changes: https://git.openjdk.java.net/jdk/pull/3801/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3801&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266318 Stats: 11 lines in 2 files changed: 2 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3801.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3801/head:pull/3801 PR: https://git.openjdk.java.net/jdk/pull/3801 From prr at openjdk.java.net Thu Apr 29 19:28:50 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 29 Apr 2021 19:28:50 GMT Subject: RFR: 8266318: Switch to macos prefix for macOS bundles In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 19:15:52 GMT, Mikael Vidstedt wrote: > Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles files are still use the legacy "osx" string. They should be modernized to use "macos" instead. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3801 From erikj at openjdk.java.net Thu Apr 29 19:33:50 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 29 Apr 2021 19:33:50 GMT Subject: RFR: 8266318: Switch to macos prefix for macOS bundles In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 19:15:52 GMT, Mikael Vidstedt wrote: > Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles files are still use the legacy "osx" string. They should be modernized to use "macos" instead. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3801 From iris at openjdk.java.net Thu Apr 29 19:36:53 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 29 Apr 2021 19:36:53 GMT Subject: RFR: 8266318: Switch to macos prefix for macOS bundles In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 19:15:52 GMT, Mikael Vidstedt wrote: > Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles files are still use the legacy "osx" string. They should be modernized to use "macos" instead. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3801 From mikael at openjdk.java.net Fri Apr 30 03:51:18 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 30 Apr 2021 03:51:18 GMT Subject: RFR: 8266318: Switch to macos prefix for macOS bundles [v2] In-Reply-To: References: Message-ID: <3MN8VI7Fg9qHzHgs-R9lmnnfzBJD9EsUPZJVdbJ1UCk=.5409787c-1586-4a8a-bb82-eed12d689d2a@github.com> > Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles files are still use the legacy "osx" string. They should be modernized to use "macos" instead. Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: Fix GHA ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3801/files - new: https://git.openjdk.java.net/jdk/pull/3801/files/1732c917..fb851a34 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3801&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3801&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3801.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3801/head:pull/3801 PR: https://git.openjdk.java.net/jdk/pull/3801 From iris at openjdk.java.net Fri Apr 30 04:20:58 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 30 Apr 2021 04:20:58 GMT Subject: RFR: 8266318: Switch to macos prefix for macOS bundles [v2] In-Reply-To: <3MN8VI7Fg9qHzHgs-R9lmnnfzBJD9EsUPZJVdbJ1UCk=.5409787c-1586-4a8a-bb82-eed12d689d2a@github.com> References: <3MN8VI7Fg9qHzHgs-R9lmnnfzBJD9EsUPZJVdbJ1UCk=.5409787c-1586-4a8a-bb82-eed12d689d2a@github.com> Message-ID: On Fri, 30 Apr 2021 03:51:18 GMT, Mikael Vidstedt wrote: >> Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles files are still use the legacy "osx" string. They should be modernized to use "macos" instead. > > Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: > > Fix GHA Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3801 From dholmes at openjdk.java.net Fri Apr 30 09:34:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Apr 2021 09:34:13 GMT Subject: RFR: 8255566: Initialize JDK_Version direct from the build system Message-ID: The existing logic does: build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static buffers -> JDK_Version class we can simply do: build system -> JDK_Version class reduces footprint, loc and startup time. Testing tiers 1-3 and manual visual inspection of version strings Thanks, David ------------- Commit messages: - 8255566: Initialize JDK_Version direct from the build system Changes: https://git.openjdk.java.net/jdk/pull/3812/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3812&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255566 Stats: 86 lines in 5 files changed: 7 ins; 74 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3812/head:pull/3812 PR: https://git.openjdk.java.net/jdk/pull/3812 From erikj at openjdk.java.net Fri Apr 30 12:47:51 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 30 Apr 2021 12:47:51 GMT Subject: RFR: 8255566: Initialize JDK_Version direct from the build system In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 09:19:57 GMT, David Holmes wrote: > The existing logic does: > > build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static buffers -> JDK_Version class > > we can simply do: > > build system -> JDK_Version class > > reduces footprint, loc and startup time. > > Testing tiers 1-3 and manual visual inspection of version strings > > Thanks, > David Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3812 From dholmes at openjdk.java.net Fri Apr 30 12:47:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Apr 2021 12:47:52 GMT Subject: RFR: 8255566: Initialize JDK_Version direct from the build system In-Reply-To: References: Message-ID: <1kv8EogCRlZa5u4wzSxW-5ttSbon-kIFr72IMvJcGhg=.3ddfc9eb-07cb-45a0-b4db-48dbe7fb7a95@github.com> On Fri, 30 Apr 2021 09:19:57 GMT, David Holmes wrote: > The existing logic does: > > build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static buffers -> JDK_Version class > > we can simply do: > > build system -> JDK_Version class > > reduces footprint, loc and startup time. > > Testing tiers 1-3 and manual visual inspection of version strings > > Thanks, > David I think I may have overlooked something here as I have a failing test. It looks like there may be a way to override the build-time values. ------------- PR: https://git.openjdk.java.net/jdk/pull/3812 From dholmes at openjdk.java.net Fri Apr 30 12:47:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Apr 2021 12:47:52 GMT Subject: Withdrawn: 8255566: Initialize JDK_Version direct from the build system In-Reply-To: References: Message-ID: <01Y6KrP6qw8MGaYo67K-McJaCLogfdeEDsspNuv_y9g=.3274a87d-bbc3-4978-8fc7-3b7edaf00af4@github.com> On Fri, 30 Apr 2021 09:19:57 GMT, David Holmes wrote: > The existing logic does: > > build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static buffers -> JDK_Version class > > we can simply do: > > build system -> JDK_Version class > > reduces footprint, loc and startup time. > > Testing tiers 1-3 and manual visual inspection of version strings > > Thanks, > David This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3812 From dholmes at openjdk.java.net Fri Apr 30 12:52:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Apr 2021 12:52:56 GMT Subject: RFR: 8255566: Initialize JDK_Version direct from the build system In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 09:19:57 GMT, David Holmes wrote: > The existing logic does: > > build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static buffers -> JDK_Version class > > we can simply do: > > build system -> JDK_Version class > > reduces footprint, loc and startup time. > > Testing tiers 1-3 and manual visual inspection of version strings > > Thanks, > David I missed the fact that the VENDOR_VERSION and VENDOR_URL_VM_BUG values can be set programmatically by the jlink plugin, and so are different from the configure-time values. The VM has to continue to read those from VersionProps. ------------- PR: https://git.openjdk.java.net/jdk/pull/3812 From coleenp at openjdk.java.net Fri Apr 30 13:15:52 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 30 Apr 2021 13:15:52 GMT Subject: RFR: 8255566: Initialize JDK_Version direct from the build system In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 09:19:57 GMT, David Holmes wrote: > The existing logic does: > > build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static buffers -> JDK_Version class > > we can simply do: > > build system -> JDK_Version class > > reduces footprint, loc and startup time. > > Testing tiers 1-3 and manual visual inspection of version strings > > Thanks, > David A bit late but this is a nice cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/3812 From vromero at openjdk.java.net Fri Apr 30 17:40:47 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 30 Apr 2021 17:40:47 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v5] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - updating comment after review feedback - removing javax.lang.model changes - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - JVM related changes - 8260517: Compiler implementation for Sealed Classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/43e9cb5f..2744f615 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=03-04 Stats: 506473 lines in 3844 files changed: 20558 ins; 483521 del; 2394 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From mikael at openjdk.java.net Fri Apr 30 19:08:55 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 30 Apr 2021 19:08:55 GMT Subject: RFR: 8266318: Switch to macos prefix for macOS bundles [v2] In-Reply-To: <3MN8VI7Fg9qHzHgs-R9lmnnfzBJD9EsUPZJVdbJ1UCk=.5409787c-1586-4a8a-bb82-eed12d689d2a@github.com> References: <3MN8VI7Fg9qHzHgs-R9lmnnfzBJD9EsUPZJVdbJ1UCk=.5409787c-1586-4a8a-bb82-eed12d689d2a@github.com> Message-ID: <_bRcbbXDNSBZ_Ns9Q7BiH7tIYWvNM1AFkgqKV8Z_jSs=.40b1a8ff-4c80-4de6-9487-f184c6d6de0b@github.com> On Fri, 30 Apr 2021 03:51:18 GMT, Mikael Vidstedt wrote: >> Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles files are still use the legacy "osx" string. They should be modernized to use "macos" instead. > > Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: > > Fix GHA Phil, Iris, Erik - thank you for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3801 From mikael at openjdk.java.net Fri Apr 30 19:08:56 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 30 Apr 2021 19:08:56 GMT Subject: Integrated: 8266318: Switch to macos prefix for macOS bundles In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 19:15:52 GMT, Mikael Vidstedt wrote: > Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles files are still use the legacy "osx" string. They should be modernized to use "macos" instead. This pull request has now been integrated. Changeset: 096e9e5d Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/096e9e5d13183f947089b5c7923890591490a2ce Stats: 21 lines in 3 files changed: 2 ins; 4 del; 15 mod 8266318: Switch to macos prefix for macOS bundles Reviewed-by: prr, erikj, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/3801 From prr at openjdk.java.net Fri Apr 30 20:14:22 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 30 Apr 2021 20:14:22 GMT Subject: RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0 Message-ID: Upgrade to harfbuzz 2.8 ------------- Commit messages: - 8261169: Upgrade HarfBuzz to the latest 2.8.0 Changes: https://git.openjdk.java.net/jdk/pull/3826/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3826&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261169 Stats: 13120 lines in 123 files changed: 7021 ins; 2757 del; 3342 mod Patch: https://git.openjdk.java.net/jdk/pull/3826.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3826/head:pull/3826 PR: https://git.openjdk.java.net/jdk/pull/3826