From aph at redhat.com Tue Sep 1 08:05:20 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 1 Sep 2020 09:05:20 +0100 Subject: [8u] RFR: 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries In-Reply-To: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> References: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> Message-ID: <84178a29-89ac-8b17-c304-96606c8b1218@redhat.com> On 31/08/2020 12:44, Severin Gehwolf wrote: > Sorry, wrong webrev. Now corrected. > > On Mon, 2020-08-31 at 10:02 +0200, Severin Gehwolf wrote: >> Hi, >> >> Could I get a reivew of this 8u specific bug please? When configured >> --with-native-debug-symbols=external,zipped the resulting external >> debuginfo files for binaries (in images/bin folder) aren't there. >> >> In OpenJDK 8u there is some special casing involved for bin/java and >> bin/unpack200. Thus, I had to special case them for the debuginfo >> variant files too otherwise those files would be missing in the images >> folders (j2sdk-image, j2re-image). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8252395 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252395/02/webrev/ > >> >> Testing: Build in configs --with-native-debugsymbols={zipped,external,internal,none} >> on Linux x86 and manually debugging some launcher code. Works now >> with symbols. Symbols were missing before this patch. OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aleksei.voitylov at bell-sw.com Tue Sep 1 11:41:52 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Tue, 1 Sep 2020 14:41:52 +0300 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port Message-ID: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Hi, JEP 386 is now Candidate [1] and as we resolved all outstanding issues within the Portola project I'd like to ask for comments from HotSpot, Core Libs (changes in libjli/java_md.c), and Build groups before moving the JEP to Proposed to Target: http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ Testing: JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no regressions. A downport of these changes to 14 passes JCK 14 on these platforms. The port was tested on Alpine Linux 3.8 and 3.11 with JTReg, VM TestBase. There are no differences with Linux x86_64? with the exception of SA which is not supported as per the JEP. A downport of these changes to 14 passes JCK 14 on Alpine Linux. Thanks, -Aleksei [1] https://bugs.openjdk.java.net/browse/JDK-8229469 From erik.joelsson at oracle.com Tue Sep 1 12:47:42 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 1 Sep 2020 05:47:42 -0700 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Message-ID: Build changes look ok. /Erik On 2020-09-01 04:41, Aleksei Voitylov wrote: > Hi, > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Proposed to Target: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ > > Testing: > > JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, > Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no > regressions. A downport of these changes to 14 passes JCK 14 on these > platforms. > > The port was tested on Alpine Linux 3.8 and 3.11 with JTReg, VM > TestBase. There are no differences with Linux x86_64? with the exception > of SA which is not supported as per the JEP. A downport of these changes > to 14 passes JCK 14 on Alpine Linux. > > Thanks, > > -Aleksei > > [1] https://bugs.openjdk.java.net/browse/JDK-8229469 > > From magnus.ihse.bursie at oracle.com Tue Sep 1 13:21:30 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 1 Sep 2020 15:21:30 +0200 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Message-ID: On 2020-09-01 13:41, Aleksei Voitylov wrote: > Hi, > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Proposed to Target: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ Looks good to me. /Magnus > > Testing: > > JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, > Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no > regressions. A downport of these changes to 14 passes JCK 14 on these > platforms. > > The port was tested on Alpine Linux 3.8 and 3.11 with JTReg, VM > TestBase. There are no differences with Linux x86_64? with the exception > of SA which is not supported as per the JEP. A downport of these changes > to 14 passes JCK 14 on Alpine Linux. > > Thanks, > > -Aleksei > > [1] https://bugs.openjdk.java.net/browse/JDK-8229469 > > From mikael.vidstedt at oracle.com Tue Sep 1 21:29:55 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 1 Sep 2020 14:29:55 -0700 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Message-ID: Great to see this - thank you for all the great work you?re putting into it! The changes are in line with what I?m expecting given that I?ve looked at them before, so looks good to me! That said, I?ve looked at this so many times now - and after all even authored some of the original changes - so I would very much appreciate some other hotspot and core libs eyes on it. :) One very minor thing I realized: WB_GetLibcName now returns ?glibc? by default (unless MUSL_LIBC is defined) which means it may return ?glibc? on platforms where the default library really isn?t GNU libc. I will work just fine for what it?s currently being used for (isMusl), but is potentially a bit misleading. Cheers, Mikael > On Sep 1, 2020, at 4:41 AM, Aleksei Voitylov wrote: > > Hi, > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Proposed to Target: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ > > Testing: > > JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, > Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no > regressions. A downport of these changes to 14 passes JCK 14 on these > platforms. > > The port was tested on Alpine Linux 3.8 and 3.11 with JTReg, VM > TestBase. There are no differences with Linux x86_64 with the exception > of SA which is not supported as per the JEP. A downport of these changes > to 14 passes JCK 14 on Alpine Linux. > > Thanks, > > -Aleksei > > [1] https://bugs.openjdk.java.net/browse/JDK-8229469 > > From ningsheng.jian at arm.com Wed Sep 2 06:40:59 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 2 Sep 2020 14:40:59 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Message-ID: <39965f4d-af53-524c-36db-917509b2198f@arm.com> Hi, Thanks a lot for the reviews! I think I have addressed the review comments from Andrew, Vladimir and Erik. This is the new webrev: Full: http://cr.openjdk.java.net/~njian/8231441/webrev.05/ Incremental: http://cr.openjdk.java.net/~njian/8231441/webrev.05-vs-04/ Tests: Tested with jtreg hotspot_all_no_apps, jdk_core and langtools:tier1 on AArch64 systems with and without SVE as well as some x86_64 systems. Mach5 submit test also reported passed. Could you please help to take a look again? OK for jdk/jdk? Thanks, Ningsheng On 8/19/20 5:53 PM, Ningsheng Jian wrote: > Hi Andrew, > > I have updated the patch based on the review comments. Would you mind > taking another look? Thanks! > > Full: > http://cr.openjdk.java.net/~njian/8231441/webrev.04/ > > Incremental: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ > > Also add build-dev, as there's a makefile change. > > And the split parts: > > 1) SVE feature detection: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-feature > > 2) c2 register allocation: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-ra > > 3) SVE c2 backend: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-c2 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231441 > CSR: https://bugs.openjdk.java.net/browse/JDK-8248742 > From nick.gasson at arm.com Wed Sep 2 09:42:44 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Wed, 02 Sep 2020 17:42:44 +0800 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Message-ID: <85tuwgy0ob.fsf@nicgas01-pc.shanghai.arm.com> Hi Aleksei, On 09/01/20 19:41 pm, Aleksei Voitylov wrote: > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Proposed to Target: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ > I see the JEP only mentions support for x86_64, so maybe this is out of scope, but with this trivial change to os_linux_aarch64.cpp your patch works on Alpine/AArch64 too: --- a/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp +++ b/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp @@ -74,7 +74,6 @@ # include # include # include -# include #define REG_FP 29 #define REG_LR 30 -- Thanks, Nick From adinn at redhat.com Wed Sep 2 13:58:38 2020 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 2 Sep 2020 14:58:38 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <39965f4d-af53-524c-36db-917509b2198f@arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <39965f4d-af53-524c-36db-917509b2198f@arm.com> Message-ID: Hi Ningsheng, On 02/09/2020 07:40, Ningsheng Jian wrote: > Thanks a lot for the reviews! I think I have addressed the review > comments from Andrew, Vladimir and Erik. This is the new webrev: > > Full: > http://cr.openjdk.java.net/~njian/8231441/webrev.05/ > > Incremental: > http://cr.openjdk.java.net/~njian/8231441/webrev.05-vs-04/ > > Tests: > Tested with jtreg hotspot_all_no_apps, jdk_core and langtools:tier1 on > AArch64 systems with and without SVE as well as some x86_64 systems. > Mach5 submit test also reported passed. > > Could you please help to take a look again? OK for jdk/jdk? That looks good to me. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From erik.joelsson at oracle.com Wed Sep 2 14:13:31 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 2 Sep 2020 07:13:31 -0700 Subject: RFR: JDK-8206311: Add docs-javase, docs-reference to CI build Message-ID: In order to regularly build the javase and reference docs images, I have made the following changes: 1. Introduced bundle targets for the javase and reference docs images. 2. To run this in CI without adding more unnecessary build time to the linux-x64 target (where the current docs are built), I created a new jib profile "docs". This will run in a separate task and will build all 3 docs targets. 3. To enable the docs targets to run standalone without having to build a full JDK, I had to tweak the "build-jdk" concept a bit, to allow it to also function when not cross compiling for certain parts of the build. Specifically the buildtools-modules can now be built by a "build-jdk" instead of the exploded image. 4. For symmetry, I renamed variables and targets involving docs images to always include one of "jdk", "javase" or "reference" in the name. See below for targets. The new top level targets are: docs-{jdk.javase,reference}-image: Aliases for the existing docs-{jdk,javase,reference} added for consistency. The old docs-image is now an alias for docs-jdk-image. all-docs-images: Builds all 3 of the above docs images. docs-{jdk,javase,reference}-bundles: Builds the bundles for each kind of docs image. The existing docs-bundles is now an alias for docs-jdk-bundles. all-docs-bundles: Builds all the docs bundles. Bug: https://bugs.openjdk.java.net/browse/JDK-8206311 Webrev: http://cr.openjdk.java.net/~erikj/8206311/webrev.01/index.html /Erik From ningsheng.jian at arm.com Thu Sep 3 02:58:23 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Thu, 3 Sep 2020 10:58:23 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <39965f4d-af53-524c-36db-917509b2198f@arm.com> Message-ID: On 9/2/20 9:58 PM, Andrew Dinn wrote: > Hi Ningsheng, > > On 02/09/2020 07:40, Ningsheng Jian wrote: >> Thanks a lot for the reviews! I think I have addressed the review >> comments from Andrew, Vladimir and Erik. This is the new webrev: >> >> Full: >> http://cr.openjdk.java.net/~njian/8231441/webrev.05/ >> >> Incremental: >> http://cr.openjdk.java.net/~njian/8231441/webrev.05-vs-04/ >> >> Tests: >> Tested with jtreg hotspot_all_no_apps, jdk_core and langtools:tier1 on >> AArch64 systems with and without SVE as well as some x86_64 systems. >> Mach5 submit test also reported passed. >> >> Could you please help to take a look again? OK for jdk/jdk? > That looks good to me. > Thank you Andrew! Regards, Ningsheng From david.holmes at oracle.com Thu Sep 3 05:00:28 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Sep 2020 15:00:28 +1000 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Message-ID: <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> Hi Aleksei, Overall this all seems okay. A few minor comments below. On 1/09/2020 9:41 pm, Aleksei Voitylov wrote: > Hi, > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Proposed to Target: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ src/hotspot/os/linux/os_linux.cpp 624 os::Linux::set_libc_version("unknown"); 625 os::Linux::set_libpthread_version("unknown"); Surely we can do better than "unknown"? Surely different releases of Alpine linux must identify different version of the libraries? -- The PaX related error message belongs in release notes not the source code - the error message should be much more succint: "Failed to mark memory page as executable - check if grsecurity/PaX is enabled" -- src/hotspot/os/linux/os_linux.hpp numa_node_to_cpus is too big to be in the header file now. --- src/hotspot/share/prims/whitebox.cpp I would expect this to use the version string set in os_linux.cpp. --- src/hotspot/share/runtime/abstract_vm_version.cpp Ideally LIBC_STR would come from the build system - as we do for FLOAT_ARCH. See flags.m4. --- src/java.base/unix/native/libjli/java_md.c The comment is way too long - see the AIX case below it. :) --- src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c 282 // To improve portability across platforms and avoid conflicts 283 // between GNU and XSI versions of strerror_r, plain strerror is used. 284 // It's safe because this code is not used in any multithreaded environment. It is not at all clear to me that this code is not used in a multi-threaded environment. The VM is always multi-threaded. This usage was added here: http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-December/018419.html But this code also uses strerror in another place (as does other code) so ... --- test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c Why is this change needed? --- In general the busybox changes are bit unpleasant in the tests. Pity Alpine didn't try to present a familiar binary environment. :( --- test/jdk/java/lang/ProcessBuilder/RedirectWithLongFilename.java @comment is not needed That said I don't think that test should be using the Basic class. --- Thanks, David > Testing: > > JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, > Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no > regressions. A downport of these changes to 14 passes JCK 14 on these > platforms. > > The port was tested on Alpine Linux 3.8 and 3.11 with JTReg, VM > TestBase. There are no differences with Linux x86_64? with the exception > of SA which is not supported as per the JEP. A downport of these changes > to 14 passes JCK 14 on Alpine Linux. > > Thanks, > > -Aleksei > > [1] https://bugs.openjdk.java.net/browse/JDK-8229469 > > From Alan.Bateman at oracle.com Thu Sep 3 13:37:34 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 3 Sep 2020 14:37:34 +0100 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Message-ID: On 01/09/2020 12:41, Aleksei Voitylov wrote: > Hi, > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Proposed to Target: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ > .02, .03, .04 seem to be older and seem to include the changes to JDK-8252248 that Alexander Scherbatiy had out for review separately so I'll ignore those and just look at .01, I hope that is right. I agree with David that the comment in java_md.c is excessive and unnecessary. The WB API is mostly for the hotspot tests and looks a bit strange to be using it in the launcher tests to check for musl. Have you look at alternatives? The changes to the Process test to check for busybox is okay. -Alan From magnus.ihse.bursie at oracle.com Thu Sep 3 13:43:33 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 Sep 2020 15:43:33 +0200 Subject: RFR: JDK-8252769 Fail-fast in configure if git config autocrlf has invalid value Message-ID: Over and over again, people are running into issues when their git config has core.autocrlf set to true or input. (This is apparently done by default by some Windows git installations.) This will not work with the OpenJDK build system. We should check this at configure time and give suitable error message if this is detected. Bug: https://bugs.openjdk.java.net/browse/JDK-8252769 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8252769-warn-on-autocrlf/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Thu Sep 3 14:53:07 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 Sep 2020 16:53:07 +0200 Subject: Withdrawn: RFR: JDK-8252769 Fail-fast in configure if git config autocrlf has invalid value In-Reply-To: References: Message-ID: <2b41ae6c-9191-24ab-1dde-be121753ec34@oracle.com> I withdraw this RFR. Erik H and I have found a superior solution. I'll get back later with a completely different approach to the problem. /Magnus On 2020-09-03 15:43, Magnus Ihse Bursie wrote: > Over and over again, people are running into issues when their git > config has core.autocrlf set to true or input. (This is apparently > done by default by some Windows git installations.) > > This will not work with the OpenJDK build system. > > We should check this at configure time and give suitable error message > if this is detected. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252769 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8252769-warn-on-autocrlf/webrev.01 > > /Magnus From maurizio.cimadamore at oracle.com Thu Sep 3 15:48:58 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 3 Sep 2020 16:48:58 +0100 Subject: RFR: JDK-8251193 bin/idea.sh generating wrong source folders for JVMCI modules In-Reply-To: References: Message-ID: <42d1ce63-9eac-fe26-40c0-fa77aa770147@oracle.com> Sorry for the delay, overall this looks like a good improvement, so I'll approve. Is there some colleague that can help you do the push? Let me know if you need help. Thanks Maurizio On 06/08/2020 15:28, Galder Zamarreno wrote: > Hi, > > `bin/idea.sh` is not generating the right source folders for > jdk.internal.vm.ci and jdk.internal.vm.compiler modules. > > These modules have different directory structures to the rest and so should > be handled exceptionally so that the IDE has the right source folder > definitions. > > The fix takes these two modules, inspects all the subdirectories within > each module root and generates a source folder definition for each. As > example, for jdk.internal.vm.ci, there should be a source folder for: > > * src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.aarch64/src > * src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src > * ... > > I've tested this in the patch on IDEA 2020.2. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251193 > WebRev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/galder/JDK-8251193/01/webrev/ > > Galder From magnus.ihse.bursie at oracle.com Thu Sep 3 15:49:12 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 Sep 2020 17:49:12 +0200 Subject: RFR: JDK-8241768 git needs .gitattributes Message-ID: <2b7e7e1b-89c8-d15f-1f66-0789b3089c5a@oracle.com> This is an old bug that was opened long time ago, but with a much better solution for the "autocrlf" problem. Erik and I have agreed that using "-text" as attribute for all files is the best solution to mimic the old mercurial behavior. In the future, we might reconsider this, but then our files and tooling need to be adapted. Bug: https://bugs.openjdk.java.net/browse/JDK-8241768 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241768-gitattributes/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Sep 3 15:52:08 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 Sep 2020 08:52:08 -0700 Subject: RFR: JDK-8241768 git needs .gitattributes In-Reply-To: <2b7e7e1b-89c8-d15f-1f66-0789b3089c5a@oracle.com> References: <2b7e7e1b-89c8-d15f-1f66-0789b3089c5a@oracle.com> Message-ID: Looks good. /Erik On 2020-09-03 08:49, Magnus Ihse Bursie wrote: > This is an old bug that was opened long time ago, but with a much > better solution for the "autocrlf" problem. Erik and I have agreed > that using "-text" as attribute for all files is the best solution to > mimic the old mercurial behavior. In the future, we might reconsider > this, but then our files and tooling need to be adapted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241768 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241768-gitattributes/webrev.01 > > /Magnus From erik.helin at oracle.com Thu Sep 3 16:43:15 2020 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 3 Sep 2020 18:43:15 +0200 Subject: RFR: JDK-8241768 git needs .gitattributes In-Reply-To: <2b7e7e1b-89c8-d15f-1f66-0789b3089c5a@oracle.com> References: <2b7e7e1b-89c8-d15f-1f66-0789b3089c5a@oracle.com> Message-ID: <8b017020-ee65-1bca-d147-537535f7edc3@oracle.com> Looks good, Reviewed. Thanks! Erik On 9/3/20 5:49 PM, Magnus Ihse Bursie wrote: > This is an old bug that was opened long time ago, but with a much better > solution for the "autocrlf" problem. Erik and I have agreed that using > "-text" as attribute for all files is the best solution to mimic the old > mercurial behavior. In the future, we might reconsider this, but then > our files and tooling need to be adapted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241768 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241768-gitattributes/webrev.01 > > /Magnus From jorn.vernee at oracle.com Thu Sep 3 16:50:22 2020 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Thu, 3 Sep 2020 18:50:22 +0200 Subject: RFR: JDK-8241768 git needs .gitattributes In-Reply-To: <2b7e7e1b-89c8-d15f-1f66-0789b3089c5a@oracle.com> References: <2b7e7e1b-89c8-d15f-1f66-0789b3089c5a@oracle.com> Message-ID: Looks good. Jorn On 03/09/2020 17:49, Magnus Ihse Bursie wrote: > This is an old bug that was opened long time ago, but with a much > better solution for the "autocrlf" problem. Erik and I have agreed > that using "-text" as attribute for all files is the best solution to > mimic the old mercurial behavior. In the future, we might reconsider > this, but then our files and tooling need to be adapted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241768 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241768-gitattributes/webrev.01 > > /Magnus From aleksei.voitylov at bell-sw.com Fri Sep 4 07:55:07 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 4 Sep 2020 10:55:07 +0300 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> Message-ID: <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> Hi Erik, Magnus, Mikael, Nick, David, and Alan, thank you for looking into it. I grouped together all the comments in one response to avoid polluting the mailing lists. Here is an updated version of the patch which addresses the comments: http://cr.openjdk.java.net/~avoitylov/webrev.8247589.06/ Please also find inline answers to the comments by Mikael, Nick, Alan and David, in order. Testing is in progress. [Mikael] > WB_GetLibcName now returns ?glibc? by default (unless MUSL_LIBC is > defined) which means it may return ?glibc? on platforms where the > default library really isn?t GNU libc. I will work just fine for what > it?s currently being used for (isMusl), but is potentially a bit > misleading. I agree. In the updated version WB_GetLibcName returns the LIBC the JDK is build for. [Nick] > I see the JEP only mentions support for x86_64, so maybe this is out of > scope, but with this trivial change to os_linux_aarch64.cpp your patch > works on Alpine/AArch64 too: I planned to add additional platforms it a follow-up enhancement but updated the webrev to include AArch64 now. Testing is in progress, and, if the same level of quality is reached as on x64, I will slightly update the JEP to make it clear AArch64 is also known to work. I hope this will be fine. [Alan] > .02, .03, .04 seem to be older and seem to include the changes to > JDK-8252248 that Alexander Scherbatiy had out for review separately so > I'll ignore those and just look at .01, I hope that is right. This is correct. > I agree with David that the comment in java_md.c is excessive and > unnecessary. Fixed in the updated version. > > The WB API is mostly for the hotspot tests and looks a bit strange to > be using it in the launcher tests to check for musl. Have you look at > alternatives? The changes to the Process test to check for busybox is > okay. The WhiteBox API is used in JDK tests for JFR [1], CollectionUsageThreshold.java [2], TimSortStackSize2.java [3], so we are not adding an extra dependency. Tests tools/launcher/Test7029048.java and tools/launcher/ExecutionEnvironment.java need to change behavior on systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we first considered was to detect the libc of the OS with ldd in the test and avoid WhiteBox dependency. This approach has a significant drawback: some distributions bundle glibc and OpenJDK and launch it on a musl-based Linux OS, so we really need to detect the libc the JDK was compiled for, not the default libc present in the OS. To avoid such problems all together it was decided to detect the libc flavor the JDK was compiled for through WhiteBox. [David] > src/hotspot/os/linux/os_linux.cpp > > ?624?? os::Linux::set_libc_version("unknown"); > ?625?? os::Linux::set_libpthread_version("unknown"); > > Surely we can do better than "unknown"? Surely different releases of > Alpine linux must identify different version of the libraries? The author of musl indicated it currently does not provide a way to obtain the library version programmatically [4]. > The PaX related error message belongs in release notes not the source > code - the error message should be much more succint: > > "Failed to mark memory page as executable - check if grsecurity/PaX is > enabled" Fixed. > src/hotspot/os/linux/os_linux.hpp > > numa_node_to_cpus is too big to be in the header file now. Fixed. > src/hotspot/share/prims/whitebox.cpp > > I would expect this to use the version string set in os_linux.cpp. In the updated version of the patch the libc variant now comes from the build system. The libc version would probably be unused at this point in WhiteBox, also see answer to your first comment. > src/hotspot/share/runtime/abstract_vm_version.cpp > > Ideally LIBC_STR would come from the build system - as we do for > FLOAT_ARCH. See flags.m4. Yes, thank you for the suggestion. It now comes from the build system, as above. > src/java.base/unix/native/libjli/java_md.c > > The comment is way too long - see the AIX case below it. :) OK, trimmed it down :) > src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c > > ?282???? // To improve portability across platforms and avoid conflicts > ?283???? // between GNU and XSI versions of strerror_r, plain strerror > is used. > ?284???? // It's safe because this code is not used in any > multithreaded environment. > > It is not at all clear to me that this code is not used in a > multi-threaded environment. The VM is always multi-threaded.? This > usage was added here: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-December/018419.html > > > But this code also uses strerror in another place (as does other code) > so ... I checked LinuxDebuggerLocal.java and all attach0 calls using this functionality are guarded by corresponding syncronized constructs. That's because nobody claims that ptrace_attach is thread-safe or re-enterant. It depends to kernel implementation and attempt to use it from multiple threads could lead to unpredictable results. If ptrace_attach is run from different threads but with the same PID, it could crash the target process or fail. And it doesn't have any sense from serviceability agent point of view. Running ptrace_attach from multiple threads with different PIDs should be more or less OK - I trust modern kernel, but I don't see any usecase or command line support for using hotspot agent with multiple PIDs. So it was concluded that using strerror instead of strerror_r to mitigate compatibility issues should not be a problem. > > test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c > > Why is this change needed? Both? tests fail without it because res = (*_jvm)->AttachCurrentThread(_jvm, (void **)&env, NULL); returned with an error (res != JNI_OK). AttachCurrentThread uses the current thread as JavaThread and allocates a java level Thread object and needs to run initializing java code (JavaThread::allocate_threadObj). In order to run java code, the remaining stack space is checked. There must be sufficient? space for an interpreter frame, the java frame and shadow pages ( JavaCalls::call_helper() ). The default for the number of shadow pages is 10 for a release build. If this check fails a StackOverflowException is thrown. As we return with a pending exception the attach fails and we return JNI_ERR. This is only a problem as we call AttachCurrentThread from a thread that we created with the default stacksize. Threads created by the JVM are created with a much higher stacksize. > In general the busybox changes are bit unpleasant in the tests. Pity > Alpine didn't try to present a familiar binary environment. :( By doing so, it managed to significantly trim down the image size. > test/jdk/java/lang/ProcessBuilder/RedirectWithLongFilename.java > > @comment is not needed > > That said I don't think that test should be using the Basic class. Fixed by removing the dependency on Basic class and adding windows to @requires. Thanks, -Aleksei [1] https://hg.openjdk.java.net/jdk/jdk/file/8f642d0b0f63/test/jdk/jdk/jfr/event/compiler/TestCodeCacheConfig.java [2] https://hg.openjdk.java.net/jdk/jdk/file/8f642d0b0f63/test/jdk/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java [3] https://hg.openjdk.java.net/jdk/jdk/file/8f642d0b0f63/test/jdk/java/util/Arrays/TimSortStackSize2.java [4] https://www.openwall.com/lists/musl/2020/05/27/2 From Alan.Bateman at oracle.com Fri Sep 4 09:00:24 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Sep 2020 10:00:24 +0100 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> Message-ID: <0ae99863-f6b1-6b14-b896-b8ed4fb7b1a5@oracle.com> On 04/09/2020 08:55, Aleksei Voitylov wrote: > : > Tests tools/launcher/Test7029048.java and > tools/launcher/ExecutionEnvironment.java need to change behavior on > systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we > first considered was to detect the libc of the OS with ldd in the test > and avoid WhiteBox dependency. This approach has a significant drawback: > some distributions bundle glibc and OpenJDK and launch it on a > musl-based Linux OS, so we really need to detect the libc the JDK was > compiled for, not the default libc present in the OS. To avoid such > problems all together it was decided to detect the libc flavor the JDK > was compiled for through WhiteBox. > I really dislike the changes to the launcher tests and I don't think the WB API is the right place for this. I think we need to find something cleaner and maybe expose it as a method on jdk.test.lib.Platform. -Alan From Alan.Bateman at oracle.com Fri Sep 4 09:08:39 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Sep 2020 10:08:39 +0100 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <0ae99863-f6b1-6b14-b896-b8ed4fb7b1a5@oracle.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> <0ae99863-f6b1-6b14-b896-b8ed4fb7b1a5@oracle.com> Message-ID: On 04/09/2020 10:00, Alan Bateman wrote: > On 04/09/2020 08:55, Aleksei Voitylov wrote: >> : >> Tests tools/launcher/Test7029048.java and >> tools/launcher/ExecutionEnvironment.java need to change behavior on >> systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we >> first considered was to detect the libc of the OS with ldd in the test >> and avoid WhiteBox dependency. This approach has a significant drawback: >> some distributions bundle glibc and OpenJDK and launch it on a >> musl-based Linux OS, so we really need to detect the libc the JDK was >> compiled for, not the default libc present in the OS. To avoid such >> problems all together it was decided to detect the libc flavor the JDK >> was compiled for through WhiteBox. >> > I really dislike the changes to the launcher tests and I don't think > the WB API is the right place for this. I think we need to find > something cleaner and maybe expose it as a method on > jdk.test.lib.Platform. > or alternatively, a new class in jdk.test.lib that gives provide methods to introspect the runtime, whatever is simplest and doesn't depend on the WB API as it's independent of HotSpot. -Alan From aleksei.voitylov at bell-sw.com Fri Sep 4 12:51:34 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 4 Sep 2020 15:51:34 +0300 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> <0ae99863-f6b1-6b14-b896-b8ed4fb7b1a5@oracle.com> Message-ID: <5f68767a-67cd-e788-7765-45f6ec78462e@bell-sw.com> Alan, in this case I'm leaning towards a new class jdk.test.lib.LibcHelper with a native implementation which calls (*env)->NewStringUTF(env, libc), which will be used by the tests which require it. Otherwise we'd have to specify nativepath for all tests which use jdk.test.lib.Platform. What do you think? -Aleksei On 04/09/2020 12:08, Alan Bateman wrote: > On 04/09/2020 10:00, Alan Bateman wrote: >> On 04/09/2020 08:55, Aleksei Voitylov wrote: >>> : >>> Tests tools/launcher/Test7029048.java and >>> tools/launcher/ExecutionEnvironment.java need to change behavior on >>> systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we >>> first considered was to detect the libc of the OS with ldd in the test >>> and avoid WhiteBox dependency. This approach has a significant >>> drawback: >>> some distributions bundle glibc and OpenJDK and launch it on a >>> musl-based Linux OS, so we really need to detect the libc the JDK was >>> compiled for, not the default libc present in the OS. To avoid such >>> problems all together it was decided to detect the libc flavor the JDK >>> was compiled for through WhiteBox. >>> >> I really dislike the changes to the launcher tests and I don't think >> the WB API is the right place for this. I think we need to find >> something cleaner and maybe expose it as a method on >> jdk.test.lib.Platform. >> > or alternatively, a new class in jdk.test.lib that gives provide > methods to introspect the runtime, whatever is simplest and doesn't > depend on the WB API as it's independent of HotSpot. > > -Alan From aleksei.voitylov at bell-sw.com Fri Sep 4 20:55:41 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 4 Sep 2020 23:55:41 +0300 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <5f68767a-67cd-e788-7765-45f6ec78462e@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> <0ae99863-f6b1-6b14-b896-b8ed4fb7b1a5@oracle.com> <5f68767a-67cd-e788-7765-45f6ec78462e@bell-sw.com> Message-ID: Alan, here is a simpler version which, for the two tests in question, refers to a local helper class with a native method: http://cr.openjdk.java.net/~avoitylov/webrev.8247589.07/ If there is a preference to avoid JNI, there is yet another alternative: split the two launcher tests in question into tests? with @requires vm.musl | os.family = "aix" and with @requires !vm.musl & os.family != "aix". -Aleksei On 04/09/2020 15:51, Aleksei Voitylov wrote: > Alan, > > in this case I'm leaning towards a new class jdk.test.lib.LibcHelper > with a native implementation which calls (*env)->NewStringUTF(env, > libc), which will be used by the tests which require it. Otherwise we'd > have to specify nativepath for all tests which use > jdk.test.lib.Platform. What do you think? > > -Aleksei > > On 04/09/2020 12:08, Alan Bateman wrote: >> On 04/09/2020 10:00, Alan Bateman wrote: >>> On 04/09/2020 08:55, Aleksei Voitylov wrote: >>>> : >>>> Tests tools/launcher/Test7029048.java and >>>> tools/launcher/ExecutionEnvironment.java need to change behavior on >>>> systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we >>>> first considered was to detect the libc of the OS with ldd in the test >>>> and avoid WhiteBox dependency. This approach has a significant >>>> drawback: >>>> some distributions bundle glibc and OpenJDK and launch it on a >>>> musl-based Linux OS, so we really need to detect the libc the JDK was >>>> compiled for, not the default libc present in the OS. To avoid such >>>> problems all together it was decided to detect the libc flavor the JDK >>>> was compiled for through WhiteBox. >>>> >>> I really dislike the changes to the launcher tests and I don't think >>> the WB API is the right place for this. I think we need to find >>> something cleaner and maybe expose it as a method on >>> jdk.test.lib.Platform. >>> >> or alternatively, a new class in jdk.test.lib that gives provide >> methods to introspect the runtime, whatever is simplest and doesn't >> depend on the WB API as it's independent of HotSpot. >> >> -Alan From ehelin at openjdk.java.net Sat Sep 5 10:22:51 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Sat, 5 Sep 2020 10:22:51 GMT Subject: RFR: 8252819: This is just a test Message-ID: Hi all, please ignore this "RFR" e-mail, this is just a final test of the Skara [0] tooling. Thanks, Erik [0]: https://openjdk.java.net/projects/skara/ ------------- Commit messages: - 8252819: This is just a test Changes: https://git.openjdk.java.net/jdk/pull/18/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=18&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252819 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/18.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/18/head:pull/18 PR: https://git.openjdk.java.net/jdk/pull/18 From erik.helin at oracle.com Sat Sep 5 12:42:05 2020 From: erik.helin at oracle.com (Erik Helin) Date: Sat, 5 Sep 2020 14:42:05 +0200 Subject: RFR: 8252819: This is just a test In-Reply-To: References: Message-ID: <11bd68fb-2e67-58e5-d613-b7647e47027f@oracle.com> Please ignore this reply as well, this is just testing the Skara mailing list synchronization. Thanks, Erik On 9/5/20 12:22 PM, Erik Helin wrote: > Hi all, > > please ignore this "RFR" e-mail, this is just a final test of the Skara [0] tooling. > > Thanks, > Erik > > [0]: https://openjdk.java.net/projects/skara/ > > ------------- > > Commit messages: > - 8252819: This is just a test > > Changes: https://git.openjdk.java.net/jdk/pull/18/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=18&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8252819 > Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jdk/pull/18.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/18/head:pull/18 > > PR: https://git.openjdk.java.net/jdk/pull/18 > From darcy at openjdk.java.net Sat Sep 5 20:21:54 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 5 Sep 2020 20:21:54 GMT Subject: RFR: 8251549: Update docs on building for Git Message-ID: 8251549: Update docs on building for Git ------------- Commit messages: - Update building docs for git. Changes: https://git.openjdk.java.net/jdk/pull/21/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=21&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251549 Stats: 56 lines in 1 file changed: 0 ins; 39 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/21.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/21/head:pull/21 PR: https://git.openjdk.java.net/jdk/pull/21 From lancea at openjdk.java.net Sat Sep 5 20:40:29 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 5 Sep 2020 20:40:29 GMT Subject: RFR: 8251549: Update docs on building for Git In-Reply-To: References: Message-ID: On Sat, 5 Sep 2020 20:13:18 GMT, Joe Darcy wrote: > 8251549: Update docs on building for Git Hi Joe, This looks OK. Are similar changes being made to http://openjdk.java.net/guide/producingChangeset.html as well given it refers to mercurial? ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/21 From glaubitz at physik.fu-berlin.de Sat Sep 5 21:04:12 2020 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 5 Sep 2020 23:04:12 +0200 Subject: RFR: 8251549: Update docs on building for Git In-Reply-To: References: Message-ID: <67770985-d3f3-9742-a8d8-c3c47b3aa30d@physik.fu-berlin.de> Hi Joe! On 9/5/20 10:21 PM, Joe Darcy wrote: > 8251549: Update docs on building for Git > (...) > PR: https://git.openjdk.java.net/jdk/pull/21 Does that mean that OpenJDK development has officially moved to Github now? And are all OpenJDK members becoming members of the OpenJDK Github project? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From joe.darcy at oracle.com Sat Sep 5 21:20:02 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 5 Sep 2020 14:20:02 -0700 Subject: RFR: 8251549: Update docs on building for Git In-Reply-To: <67770985-d3f3-9742-a8d8-c3c47b3aa30d@physik.fu-berlin.de> References: <67770985-d3f3-9742-a8d8-c3c47b3aa30d@physik.fu-berlin.de> Message-ID: <3a24e970-0fad-65a4-f7c4-8a0eedc87ed9@oracle.com> Hello Adrian, On 9/5/2020 2:04 PM, John Paul Adrian Glaubitz wrote: > Hi Joe! > > On 9/5/20 10:21 PM, Joe Darcy wrote: >> 8251549: Update docs on building for Git >> (...) >> PR: https://git.openjdk.java.net/jdk/pull/21 > Does that mean that OpenJDK development has officially moved to Github now? > > And are all OpenJDK members becoming members of the OpenJDK Github project? See the announcements about this transition, with instructions, on jdk-dev: https://mail.openjdk.java.net/pipermail/jdk-dev/2020-August/004588.html https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004694.html -Joe From Alan.Bateman at oracle.com Sun Sep 6 08:13:24 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 6 Sep 2020 09:13:24 +0100 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> <0ae99863-f6b1-6b14-b896-b8ed4fb7b1a5@oracle.com> <5f68767a-67cd-e788-7765-45f6ec78462e@bell-sw.com> Message-ID: <3bb90ff9-61b5-0bb2-0476-4d52d4c8766d@oracle.com> On 04/09/2020 21:55, Aleksei Voitylov wrote: > Alan, > > here is a simpler version which, for the two tests in question, refers > to a local helper class with a native method: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.07/ > > If there is a preference to avoid JNI, there is yet another alternative: > split the two launcher tests in question into tests? with @requires > vm.musl | os.family = "aix" and with @requires !vm.musl & os.family != > "aix". > The download side of using JNI in these tests is that it complicates the setup a bit for those that run jtreg directly and/or just build the JDK and not the test libraries. You could reduce this burden a bit by limiting the load library/isMusl check to Linux only, meaning isMusl would not be called on other platforms. The alternative you suggest above might indeed be better. I assume you don't mean splitting the tests but rather just adding a second @test description so that the vm.musl case runs the test with a system property that allows the test know the expected load library path behavior. The updated comment in java_md.c in this looks good. A minor comment on Platform.isBusybox is Files.isSymbolicLink returning true implies that the link exists so no need to check for exists too. Also the if-then-else style for the new class in ProcessBuilder/Basic.java is inconsistent with the rest of the test so it stands out. Given the repo transition this weekend then I assume you'll create a PR for the final review at least. Also I see JEP 386 hasn't been targeted yet but I assume Boris, as owner, will propose-to-target and wait for it to be targeted before it is integrated. -Alan From goetz.lindenmaier at sap.com Mon Sep 7 06:35:04 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 7 Sep 2020 06:35:04 +0000 Subject: Crashes on ppc/s390 after 8231441: AArch64: Initial SVE backend support Message-ID: Hi Since that change was pushed, the vm crashes in the build: To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/type.cpp:1022 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/usr/work/... /share/opto/type.cpp:1022), pid=28717, tid=28983 # assert(_type_info[base()].dual_type != Bad) failed: implement with v-call # # JRE version: OpenJDK Runtime Environment (16.0.0.1) (fastdebug build 16.0.0.1-internal+0-adhoc.openjdk.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 16.0.0.1-internal+0-adhoc.openjdk.jdk, mixed mode, tiered, compressed oops, g1 gc, linux-ppc64) # Problematic frame: # V [libjvm.so+0x1bfe22c] Type::xdual() const+0xfc # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again Do you have an ad-hoc idea of the problem? I locally backed out the change which fixed the issue. Best regards, Goetz. From Ningsheng.Jian at arm.com Mon Sep 7 06:50:36 2020 From: Ningsheng.Jian at arm.com (Ningsheng Jian) Date: Mon, 7 Sep 2020 06:50:36 +0000 Subject: Crashes on ppc/s390 after 8231441: AArch64: Initial SVE backend support In-Reply-To: References: Message-ID: Hi Goetz, I am sorry about that and thanks for helping to identify the issue. As I cannot reproduce this on x86 and AArch64, a quick guess is that I may have missed the code like: diff --git a/src/hotspot/share/opto/type.cpp b/src/hotspot/share/opto/type.cpp index 2f4047dfa8e..f7d2f5b2320 100644 --- a/src/hotspot/share/opto/type.cpp +++ b/src/hotspot/share/opto/type.cpp @@ -62,12 +62,14 @@ const Type::TypeInfo Type::_type_info[Type::lastype] = { { Bad, T_ARRAY, "array:", false, Node::NotAMachineReg, relocInfo::none }, // Array #if defined(PPC64) + { Bad, T_ILLEGAL, "vectora:", false, Op_VecA, relocInfo::none }, // VectorA. { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD { Bad, T_ILLEGAL, "vectorx:", false, Op_VecX, relocInfo::none }, // VectorX { Bad, T_ILLEGAL, "vectory:", false, 0, relocInfo::none }, // VectorY { Bad, T_ILLEGAL, "vectorz:", false, 0, relocInfo::none }, // VectorZ #elif defined(S390) + { Bad, T_ILLEGAL, "vectora:", false, Op_VecA, relocInfo::none }, // VectorA. { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD { Bad, T_ILLEGAL, "vectorx:", false, 0, relocInfo::none }, // VectorX Could you please help to have a try? Thanks, Ningsheng > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Monday, September 7, 2020 2:35 PM > To: Ningsheng Jian ; Andrew Dinn ; > hotspot-compiler-dev at openjdk.java.net; build-dev at openjdk.java.net; Vladimir > Ivanov ; Erik ?sterlund > Cc: aarch64-port-dev at openjdk.java.net; Doerr, Martin > Subject: Crashes on ppc/s390 after 8231441: AArch64: Initial SVE backend support > > Hi > > Since that change was pushed, the vm crashes in the build: > > To suppress the following error report, specify this argument # after -XX: or > in .hotspotrc: SuppressErrorAt=/type.cpp:1022 # # A fatal error has been detected by > the Java Runtime Environment: > # > # Internal Error (/usr/work/... /share/opto/type.cpp:1022), pid=28717, tid=28983 # > assert(_type_info[base()].dual_type != Bad) failed: implement with v-call # # JRE > version: OpenJDK Runtime Environment (16.0.0.1) (fastdebug build 16.0.0.1- > internal+0-adhoc.openjdk.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 16.0.0.1-internal+0- > adhoc.openjdk.jdk, mixed mode, tiered, compressed oops, g1 gc, linux-ppc64) # > Problematic frame: > # V [libjvm.so+0x1bfe22c] Type::xdual() const+0xfc # # No core dump will be written. > Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" > before starting Java again > > Do you have an ad-hoc idea of the problem? > > I locally backed out the change which fixed the issue. > > Best regards, > Goetz. From ihse at openjdk.java.net Mon Sep 7 07:25:06 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 7 Sep 2020 07:25:06 GMT Subject: RFR: 8251549: Update docs on building for Git In-Reply-To: References: Message-ID: On Sat, 5 Sep 2020 20:13:18 GMT, Joe Darcy wrote: > 8251549: Update docs on building for Git Overall looks good, but please restore the recommendation to stick with Cygwin tools. doc/building.md line 92: > 90: spaces and/or mixed upper and lower case letters. > 91: > 92: * Clone the JDK repository using [Git for Windows](https://gitforwindows.org). I think I said before, this is *not* a recommended way! Instead, git from Cygwin is still recommended. Git for Windows will for instance set the coreautolf flag. Now we have pushed a work-around for this, but I object to *recommending* git for windows. ------------- Changes requested by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/21 From rwestberg at openjdk.java.net Mon Sep 7 07:25:51 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Mon, 7 Sep 2020 07:25:51 GMT Subject: RFR: 8252844: Update check configuration to Skara format Message-ID: Now that the JDK main-line repository is using the Skara tooling, the jcheck configuration file should be updated to the new format. Best regards, Robin ------------- Commit messages: - Initial update Changes: https://git.openjdk.java.net/jdk/pull/39/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=39&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252844 Stats: 29 lines in 1 file changed: 28 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/39.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/39/head:pull/39 PR: https://git.openjdk.java.net/jdk/pull/39 From ehelin at openjdk.java.net Mon Sep 7 08:06:14 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Mon, 7 Sep 2020 08:06:14 GMT Subject: RFR: 8252844: Update check configuration to Skara format [v2] In-Reply-To: References: Message-ID: <_yp0PjVrF7H5zfON-8EVwo0Q1-LSCTFA5P63X64Q8pM=.83004ceb-e9b6-4cd8-91e7-36c7a88cbff7@github.com> On Mon, 7 Sep 2020 08:03:25 GMT, Robin Westberg wrote: >> Now that the JDK main-line repository is using the Skara tooling, the jcheck configuration file should be updated to >> the new format. >> Best regards, >> Robin > > Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: > > Apply review suggestion > > Co-authored-by: Erik Duveblad Looks good! .jcheck/conf line 27: > 25: > 26: [checks "committer"] > 27: role=contributor Suggestion: role=committer ------------- Marked as reviewed by ehelin (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/39 From rwestberg at openjdk.java.net Mon Sep 7 08:06:13 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Mon, 7 Sep 2020 08:06:13 GMT Subject: RFR: 8252844: Update check configuration to Skara format [v2] In-Reply-To: References: Message-ID: > Now that the JDK main-line repository is using the Skara tooling, the jcheck configuration file should be updated to > the new format. > Best regards, > Robin Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: Apply review suggestion Co-authored-by: Erik Duveblad ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/39/files - new: https://git.openjdk.java.net/jdk/pull/39/files/ee32112a..a23e3d6f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=39&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=39&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/39.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/39/head:pull/39 PR: https://git.openjdk.java.net/jdk/pull/39 From rwestberg at openjdk.java.net Mon Sep 7 08:06:14 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Mon, 7 Sep 2020 08:06:14 GMT Subject: RFR: 8252844: Update check configuration to Skara format [v2] In-Reply-To: <_yp0PjVrF7H5zfON-8EVwo0Q1-LSCTFA5P63X64Q8pM=.83004ceb-e9b6-4cd8-91e7-36c7a88cbff7@github.com> References: <_yp0PjVrF7H5zfON-8EVwo0Q1-LSCTFA5P63X64Q8pM=.83004ceb-e9b6-4cd8-91e7-36c7a88cbff7@github.com> Message-ID: On Mon, 7 Sep 2020 08:01:54 GMT, Erik Helin wrote: >> Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply review suggestion >> >> Co-authored-by: Erik Duveblad > > Looks good! Thanks for reviewing Erik! As this is blocking other pull requests from completing, I plan to integrate it right away. ------------- PR: https://git.openjdk.java.net/jdk/pull/39 From rwestberg at openjdk.java.net Mon Sep 7 08:23:14 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Mon, 7 Sep 2020 08:23:14 GMT Subject: Integrated: 8252844: Update check configuration to Skara format In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 07:19:50 GMT, Robin Westberg wrote: > Now that the JDK main-line repository is using the Skara tooling, the jcheck configuration file should be updated to > the new format. > Best regards, > Robin This pull request has now been integrated. Changeset: e0c8d442 Author: Robin Westberg URL: https://git.openjdk.java.net/jdk/commit/e0c8d442 Stats: 29 lines in 1 file changed: 0 ins; 28 del; 1 mod 8252844: Update check configuration to Skara format Reviewed-by: ehelin ------------- PR: https://git.openjdk.java.net/jdk/pull/39 From serb at openjdk.java.net Mon Sep 7 10:07:52 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 7 Sep 2020 10:07:52 GMT Subject: RFR: 8251549: Update docs on building for Git In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 07:20:02 GMT, Magnus Ihse Bursie wrote: >> 8251549: Update docs on building for Git > > doc/building.md line 92: > >> 90: spaces and/or mixed upper and lower case letters. >> 91: >> 92: * Clone the JDK repository using [Git for Windows](https://gitforwindows.org). > > I think I said before, this is *not* a recommended way! Instead, git from Cygwin is still recommended. > > Git for Windows will for instance set the coreautolf flag. Now we have pushed a work-around for this, but I object > to *recommending* git for windows. BTW the value of coreautolf flag is asked during the installation of Git for windows, it is should be mentioned in the docs, since it is quite common issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/21 From avoitylov at openjdk.java.net Mon Sep 7 11:29:29 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Mon, 7 Sep 2020 11:29:29 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port Message-ID: continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > The download side of using JNI in these tests is that it complicates the > setup a bit for those that run jtreg directly and/or just build the JDK > and not the test libraries. You could reduce this burden a bit by > limiting the load library/isMusl check to Linux only, meaning isMusl > would not be called on other platforms. > > The alternative you suggest above might indeed be better. I assume you > don't mean splitting the tests but rather just adding a second @test > description so that the vm.musl case runs the test with a system > property that allows the test know the expected load library path behavior. I have updated the PR to split the two tests in multiple @test s. > The updated comment in java_md.c in this looks good. A minor comment on > Platform.isBusybox is Files.isSymbolicLink returning true implies that > the link exists so no need to check for exists too. Also the > if-then-else style for the new class in ProcessBuilder/Basic.java is > inconsistent with the rest of the test so it stands out. Thank you, these changes are done in the updated PR. > Given the repo transition this weekend then I assume you'll create a PR > for the final review at least. Also I see JEP 386 hasn't been targeted > yet but I assume Boris, as owner, will propose-to-target and wait for it > to be targeted before it is integrated. Yes. How can this be best accomplished with the new git workflow? - we can continue the review process till the end and I will request the integration to happen only after the JEP is targeted. I guess this step is now done by typing "slash integrate" in a comment. - we can pause the review process now until the JEP is targeted. In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. ------------- Commit messages: - JDK-8247589: Implementation of Alpine Linux/x64 Port Changes: https://git.openjdk.java.net/jdk/pull/49/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247589 Stats: 403 lines in 30 files changed: 346 ins; 17 del; 40 mod Patch: https://git.openjdk.java.net/jdk/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/49/head:pull/49 PR: https://git.openjdk.java.net/jdk/pull/49 From alanb at openjdk.java.net Mon Sep 7 12:20:40 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 7 Sep 2020 12:20:40 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov wrote: > continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. Marked as reviewed by alanb (Reviewer). This change was in review on core-libs-dev and other mailing lists before the switch to skara/git. The issues that I brought up have been added in the PR and I don't have any further comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From goetz.lindenmaier at sap.com Mon Sep 7 07:06:50 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 7 Sep 2020 07:06:50 +0000 Subject: Crashes on ppc/s390 after 8231441: AArch64: Initial SVE backend support In-Reply-To: References: Message-ID: HI, Thanks for the hint! Sounds good, I'll give it a try. ... I removed some emails to reduce traffic. Best regads, Goetz. -----Original Message----- From: Ningsheng Jian Sent: Montag, 7. September 2020 08:51 To: Lindenmaier, Goetz ; Andrew Dinn ; hotspot-compiler-dev at openjdk.java.net; build-dev at openjdk.java.net; Vladimir Ivanov ; Erik ?sterlund Cc: aarch64-port-dev at openjdk.java.net; Doerr, Martin Subject: RE: Crashes on ppc/s390 after 8231441: AArch64: Initial SVE backend support Hi Goetz, I am sorry about that and thanks for helping to identify the issue. As I cannot reproduce this on x86 and AArch64, a quick guess is that I may have missed the code like: diff --git a/src/hotspot/share/opto/type.cpp b/src/hotspot/share/opto/type.cpp index 2f4047dfa8e..f7d2f5b2320 100644 --- a/src/hotspot/share/opto/type.cpp +++ b/src/hotspot/share/opto/type.cpp @@ -62,12 +62,14 @@ const Type::TypeInfo Type::_type_info[Type::lastype] = { { Bad, T_ARRAY, "array:", false, Node::NotAMachineReg, relocInfo::none }, // Array #if defined(PPC64) + { Bad, T_ILLEGAL, "vectora:", false, Op_VecA, relocInfo::none }, // VectorA. { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD { Bad, T_ILLEGAL, "vectorx:", false, Op_VecX, relocInfo::none }, // VectorX { Bad, T_ILLEGAL, "vectory:", false, 0, relocInfo::none }, // VectorY { Bad, T_ILLEGAL, "vectorz:", false, 0, relocInfo::none }, // VectorZ #elif defined(S390) + { Bad, T_ILLEGAL, "vectora:", false, Op_VecA, relocInfo::none }, // VectorA. { Bad, T_ILLEGAL, "vectors:", false, 0, relocInfo::none }, // VectorS { Bad, T_ILLEGAL, "vectord:", false, Op_RegL, relocInfo::none }, // VectorD { Bad, T_ILLEGAL, "vectorx:", false, 0, relocInfo::none }, // VectorX Could you please help to have a try? Thanks, Ningsheng > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Monday, September 7, 2020 2:35 PM > To: Ningsheng Jian ; Andrew Dinn ; > hotspot-compiler-dev at openjdk.java.net; build-dev at openjdk.java.net; Vladimir > Ivanov ; Erik ?sterlund > Cc: aarch64-port-dev at openjdk.java.net; Doerr, Martin > Subject: Crashes on ppc/s390 after 8231441: AArch64: Initial SVE backend support > > Hi > > Since that change was pushed, the vm crashes in the build: > > To suppress the following error report, specify this argument # after -XX: or > in .hotspotrc: SuppressErrorAt=/type.cpp:1022 # # A fatal error has been detected by > the Java Runtime Environment: > # > # Internal Error (/usr/work/... /share/opto/type.cpp:1022), pid=28717, tid=28983 # > assert(_type_info[base()].dual_type != Bad) failed: implement with v-call # # JRE > version: OpenJDK Runtime Environment (16.0.0.1) (fastdebug build 16.0.0.1- > internal+0-adhoc.openjdk.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 16.0.0.1-internal+0- > adhoc.openjdk.jdk, mixed mode, tiered, compressed oops, g1 gc, linux-ppc64) # > Problematic frame: > # V [libjvm.so+0x1bfe22c] Type::xdual() const+0xfc # # No core dump will be written. > Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" > before starting Java again > > Do you have an ad-hoc idea of the problem? > > I locally backed out the change which fixed the issue. > > Best regards, > Goetz. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From sgehwolf at redhat.com Mon Sep 7 16:00:13 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 07 Sep 2020 18:00:13 +0200 Subject: RFR: JDK-8251193 bin/idea.sh generating wrong source folders for JVMCI modules In-Reply-To: <42d1ce63-9eac-fe26-40c0-fa77aa770147@oracle.com> References: <42d1ce63-9eac-fe26-40c0-fa77aa770147@oracle.com> Message-ID: <1a467c1d4ae99a12cc88cf372e121b6ae917e58a.camel@redhat.com> Hi, On Thu, 2020-09-03 at 16:48 +0100, Maurizio Cimadamore wrote: > Sorry for the delay, > overall this looks like a good improvement, so I'll approve. > > Is there some colleague that can help you do the push? > > Let me know if you need help. I'll sponsor the patch for Galder. Yet, sponsoring with git works differently now. Maurizio: I guess approving this PR would be sufficient? https://github.com/openjdk/jdk/pull/63 Thanks, Severin > Thanks > Maurizio > > On 06/08/2020 15:28, Galder Zamarreno wrote: > > Hi, > > > > `bin/idea.sh` is not generating the right source folders for > > jdk.internal.vm.ci and jdk.internal.vm.compiler modules. > > > > These modules have different directory structures to the rest and so should > > be handled exceptionally so that the IDE has the right source folder > > definitions. > > > > The fix takes these two modules, inspects all the subdirectories within > > each module root and generates a source folder definition for each. As > > example, for jdk.internal.vm.ci, there should be a source folder for: > > > > * src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.aarch64/src > > * src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src > > * ... > > > > I've tested this in the patch on IDEA 2020.2. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251193 > > WebRev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/galder/JDK-8251193/01/webrev/ > > > > Galder From maurizio.cimadamore at oracle.com Mon Sep 7 16:15:57 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Sep 2020 17:15:57 +0100 Subject: RFR: JDK-8251193 bin/idea.sh generating wrong source folders for JVMCI modules In-Reply-To: <1a467c1d4ae99a12cc88cf372e121b6ae917e58a.camel@redhat.com> References: <42d1ce63-9eac-fe26-40c0-fa77aa770147@oracle.com> <1a467c1d4ae99a12cc88cf372e121b6ae917e58a.camel@redhat.com> Message-ID: <0d2b5072-764a-3dd9-351f-1a78ce429bda@oracle.com> I've approved - seems to me that you can now just integrate. (otherwise, I could have just typed "/sponsor" if the author did not have commit rights) Maurizio On 07/09/2020 17:00, Severin Gehwolf wrote: > Hi, > > On Thu, 2020-09-03 at 16:48 +0100, Maurizio Cimadamore wrote: >> Sorry for the delay, >> overall this looks like a good improvement, so I'll approve. >> >> Is there some colleague that can help you do the push? >> >> Let me know if you need help. > I'll sponsor the patch for Galder. Yet, sponsoring with git works > differently now. > > Maurizio: I guess approving this PR would be sufficient? > https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/63__;!!GqivPVa7Brio!IOP7rxQacZCWlIbDaIJWne0Iho8A9heq5mfLqqk8X6X8Wyq2JT_nSFwVsX9gjaaHTxWNjVQ$ > > Thanks, > Severin > > > >> Thanks >> Maurizio >> >> On 06/08/2020 15:28, Galder Zamarreno wrote: >>> Hi, >>> >>> `bin/idea.sh` is not generating the right source folders for >>> jdk.internal.vm.ci and jdk.internal.vm.compiler modules. >>> >>> These modules have different directory structures to the rest and so should >>> be handled exceptionally so that the IDE has the right source folder >>> definitions. >>> >>> The fix takes these two modules, inspects all the subdirectories within >>> each module root and generates a source folder definition for each. As >>> example, for jdk.internal.vm.ci, there should be a source folder for: >>> >>> * src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.aarch64/src >>> * src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src >>> * ... >>> >>> I've tested this in the patch on IDEA 2020.2. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8251193 >>> WebRev: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/galder/JDK-8251193/01/webrev/ >>> >>> Galder From github.com+471021+marschall at openjdk.java.net Mon Sep 7 17:08:40 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Mon, 7 Sep 2020 17:08:40 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package Message-ID: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Hello, newbie here I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. - I tried to update the copyright year to 2020 in every file. - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. - All tier1 tests pass. - One jpackage/jlink tier2 test fails but I don't believe it is related. - Some tier3 Swing tests fail but I don't think they are related. ------------- Commit messages: - 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8138732 Stats: 747 lines in 63 files changed: 149 ins; 148 del; 450 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From alanb at openjdk.java.net Mon Sep 7 17:53:50 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 7 Sep 2020 17:53:50 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. This one probably needs discussion on hotspot-dev to get agreement on the rename/move. It might need coordination with Graal. If the change does go ahead then please check if java.base's module-info.java still needs to export jdk.internal to jdk.jfr, I suspect that qualified export can be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From david.holmes at oracle.com Tue Sep 8 00:32:12 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Sep 2020 10:32:12 +1000 Subject: jdk14 build failed cause "The header is deprecated and will be removed." In-Reply-To: References: Message-ID: <18d6edb5-a8db-88c5-45ff-f40de6e6c704@oracle.com> Hi, On 5/08/2020 5:46 pm, 451541695 wrote: > Hello,  Thanks for providing java for developers. >   I am trying to build jdk-14 to use, but failed to build. >   The error is following: > >    My environment: >       Linux: Ubuntu 20.04.1 LTS >       autoconfig: > >  I don't know what happened to Long for your replying. sysctl.h is only included on BSD and macOS builds, not Linux. There is something strange with your build if you are seeing this error and you need to supply more details from the configure log and build log when the error occurs. Cheers, David From david.holmes at oracle.com Tue Sep 8 01:11:09 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Sep 2020 11:11:09 +1000 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: <369201b2-087d-44c5-d020-26c239d172aa@oracle.com> Hi Philippe, On 8/09/2020 3:08 am, Philippe Marschall wrote: > Hello, newbie here Welcome aboard! > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. That's somewhat debatable, but I don't think @since really serves any useful purpose on non-public APIs, so I'm fine either way. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. The changes all look good to me. Thanks, David ----- > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. > > ------------- > > Commit messages: > - 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate > > Changes: https://git.openjdk.java.net/jdk/pull/45/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8138732 > Stats: 747 lines in 63 files changed: 149 ins; 148 del; 450 mod > Patch: https://git.openjdk.java.net/jdk/pull/45.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 > > PR: https://git.openjdk.java.net/jdk/pull/45 > From dholmes at openjdk.java.net Tue Sep 8 01:13:41 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Sep 2020 01:13:41 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: <7422UelQpc0A_Q-YQ_TIQ-ihtR0d-7lTmQVaG2o0owg=.fea1ee30-463d-44e2-b63a-26b6baa2559b@github.com> On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. The changes all look good to me. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/45 From sgehwolf at redhat.com Tue Sep 8 08:21:22 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 Sep 2020 10:21:22 +0200 Subject: jdk14 build failed cause "The header is deprecated and will be removed." In-Reply-To: References: Message-ID: On Wed, 2020-08-05 at 15:46 +0800, 451541695 wrote: > Hello,  Thanks for providing java for developers. >   I am trying to build jdk-14 to use, but failed to build. >   The error is following: > >    My environment: >       Linux: Ubuntu 20.04.1 LTS >       autoconfig: > >  I don't know what happened to Long for your replying. Could this be: https://bugs.openjdk.java.net/browse/JDK-8235833 Looks like it's fixed in 14.0.2. Are you building from the updates tree? http://hg.openjdk.java.net/jdk-updates/jdk14u/ Thanks, Severin From rwestberg at openjdk.java.net Tue Sep 8 10:37:50 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Tue, 8 Sep 2020 10:37:50 GMT Subject: RFR: 8252897: Minor .jcheck/conf update Message-ID: The initial version of the Skara-formatted jcheck configuration file contained a small error, this change corrects it. Best regards, Robin ------------- Commit messages: - Fix mistake in jcheck configuration file Changes: https://git.openjdk.java.net/jdk/pull/70/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=70&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252897 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/70.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/70/head:pull/70 PR: https://git.openjdk.java.net/jdk/pull/70 From ehelin at openjdk.java.net Tue Sep 8 11:44:08 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Tue, 8 Sep 2020 11:44:08 GMT Subject: RFR: 8252897: Minor .jcheck/conf update In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 10:31:42 GMT, Robin Westberg wrote: > The initial version of the Skara-formatted jcheck configuration file contained a small error, this change corrects it. > > Best regards, > Robin Looks good, thanks for fixing! ------------- Marked as reviewed by ehelin (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/70 From rwestberg at openjdk.java.net Tue Sep 8 11:52:27 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Tue, 8 Sep 2020 11:52:27 GMT Subject: RFR: 8252897: Minor .jcheck/conf update In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 11:41:31 GMT, Erik Helin wrote: >> The initial version of the Skara-formatted jcheck configuration file contained a small error, this change corrects it. >> >> Best regards, >> Robin > > Looks good, thanks for fixing! Thanks for reviewing Erik! As this problem affects other pull requests, I'm going to integrate it right away. ------------- PR: https://git.openjdk.java.net/jdk/pull/70 From rwestberg at openjdk.java.net Tue Sep 8 12:07:17 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Tue, 8 Sep 2020 12:07:17 GMT Subject: Integrated: 8252897: Minor .jcheck/conf update In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 10:31:42 GMT, Robin Westberg wrote: > The initial version of the Skara-formatted jcheck configuration file contained a small error, this change corrects it. > > Best regards, > Robin This pull request has now been integrated. Changeset: bf5da0c7 Author: Robin Westberg URL: https://git.openjdk.java.net/jdk/commit/bf5da0c7 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8252897: Minor .jcheck/conf update Reviewed-by: ehelin ------------- PR: https://git.openjdk.java.net/jdk/pull/70 From erikj at openjdk.java.net Tue Sep 8 13:04:24 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Sep 2020 13:04:24 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov wrote: > continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. Build changes look ok. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/49 From gnu.andrew at redhat.com Tue Sep 8 16:05:06 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 8 Sep 2020 17:05:06 +0100 Subject: [8u] RFR: 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries In-Reply-To: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> References: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> Message-ID: <20200908160506.GD1846517@stopbrexit> On 13:44 Mon 31 Aug , Severin Gehwolf wrote: > Sorry, wrong webrev. Now corrected. > > On Mon, 2020-08-31 at 10:02 +0200, Severin Gehwolf wrote: > > Hi, > > > > Could I get a reivew of this 8u specific bug please? When configured > > --with-native-debug-symbols=external,zipped the resulting external > > debuginfo files for binaries (in images/bin folder) aren't there. > > > > In OpenJDK 8u there is some special casing involved for bin/java and > > bin/unpack200. Thus, I had to special case them for the debuginfo > > variant files too otherwise those files would be missing in the images > > folders (j2sdk-image, j2re-image). > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252395 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252395/02/webrev/ > > > > > Testing: Build in configs --with-native-debugsymbols={zipped,external,internal,none} > > on Linux x86 and manually debugging some launcher code. Works now > > with symbols. Symbols were missing before this patch. > > > > Thanks, > Severin > Patch looks ok, particularly when there is a comment in the original, "For unknown reason the debuginfo files for executables are not put into images" :) This was all removed on mass in JDK-8049367 for the module system, so there is no obvious backport. Is any follow-on change for Windows necessary? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From iklam at openjdk.java.net Tue Sep 8 16:28:49 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Sep 2020 16:28:49 GMT Subject: RFR: 8244778: Archive full module graph in CDS Message-ID: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> This is the same patch as [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/) published in [hotspot-runtime-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html). The rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. ------------- Commit messages: - fixed trailing spaces - Renamed ModuleEntry::write_growable_array - Update to latest repo (JDK-8251557); added comments - 8244778: Archive full module graph in CDS Changes: https://git.openjdk.java.net/jdk/pull/80/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244778 Stats: 2039 lines in 59 files changed: 1887 ins; 26 del; 126 mod Patch: https://git.openjdk.java.net/jdk/pull/80.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/80/head:pull/80 PR: https://git.openjdk.java.net/jdk/pull/80 From sgehwolf at redhat.com Tue Sep 8 16:29:51 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 Sep 2020 18:29:51 +0200 Subject: [8u] RFR: 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries In-Reply-To: <20200908160506.GD1846517@stopbrexit> References: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> <20200908160506.GD1846517@stopbrexit> Message-ID: Hi, On Tue, 2020-09-08 at 17:05 +0100, Andrew Hughes wrote: > On 13:44 Mon 31 Aug , Severin Gehwolf wrote: > > Sorry, wrong webrev. Now corrected. > > > > On Mon, 2020-08-31 at 10:02 +0200, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I get a reivew of this 8u specific bug please? When configured > > > --with-native-debug-symbols=external,zipped the resulting external > > > debuginfo files for binaries (in images/bin folder) aren't there. > > > > > > In OpenJDK 8u there is some special casing involved for bin/java and > > > bin/unpack200. Thus, I had to special case them for the debuginfo > > > variant files too otherwise those files would be missing in the images > > > folders (j2sdk-image, j2re-image). > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252395 > > > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252395/02/webrev/ > > > > > Testing: Build in configs --with-native-debugsymbols={zipped,external,internal,none} > > > on Linux x86 and manually debugging some launcher code. Works now > > > with symbols. Symbols were missing before this patch. > > > > > > > Thanks, > > Severin > > > > Patch looks ok Thanks for the review! > Is any follow-on change for Windows necessary? I don't know as I don't have a way to test/develop it. It shouldn't make anything worse on the Windows side, though. Thanks, Severin From gnu.andrew at redhat.com Tue Sep 8 16:38:11 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 8 Sep 2020 17:38:11 +0100 Subject: [8u] RFR: 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries In-Reply-To: References: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> <20200908160506.GD1846517@stopbrexit> Message-ID: <20200908163811.GF1846517@stopbrexit> On 18:29 Tue 08 Sep , Severin Gehwolf wrote: snip... > > > Is any follow-on change for Windows necessary? > > I don't know as I don't have a way to test/develop it. It shouldn't > make anything worse on the Windows side, though. > Yes, I can see that and have approved this fix for 8u now. I just wondered if there was work here for someone to fix on that platform as well. > Thanks, > Severin > Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From iklam at openjdk.java.net Tue Sep 8 16:45:41 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Sep 2020 16:45:41 GMT Subject: RFR: 8244778: Archive full module graph in CDS In-Reply-To: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: On Tue, 8 Sep 2020 15:59:33 GMT, Ioi Lam wrote: > This is the same patch as > [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/) > published in > [hotspot-runtime-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html). > The rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. In response to Lois Foltain's comments on [hotspot-runtime-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041616.html): > Minor nit in moduleEntry.cpp & packageEntry.cpp when dealing with the ModuleEntry's reads list and a PackageEntry's > exports list. The names of the methods to write and read those arrays is somewhat confusing. > > ModuleEntry::write_archived_entry_array > ModuleEntry::read_archived_entry_array > > At first I thought you were reading/writing an array of archived entries, not the array within an archived entry > itself. I was trying to think of a better name. Please consider adding a comment at line #400 & line #417 ahead of > those methods in moduleEntry.cpp to indicate that they are used for both reading/writing a ModuleEntry's reads list and > a PackageEntry's exports list. I renamed the functions to `ModuleEntry's::write_growable_array` and `ModuleEntry::restore_growable_array`, and added comments as you suggested. See commit [4f90e77](https://github.com/openjdk/jdk/pull/80/commits/4f90e77207de5fc7cf09a12fb89b75087be57225) // This function is used to archive ModuleEntry::_reads and PackageEntry::_qualified_exports. // GrowableArray cannot be directly archived, as it needs to be expandable at runtime. // Write it out as an Array, and convert it back to GrowableArray at runtime. Array* ModuleEntry::write_growable_array(GrowableArray* array) { > A question about this because a user's program can define modules post module initialization via > ModuleDescriptor.newModule(). See for example, tests within open/test/hotspot/jtreg/runtime/module/AccessCheck. So > all of these tests would trigger check_cds_restrictions() if -Xshare:dump was turned on. Is that a concern? Arbitrary user code cannot be executed during -Xshare:dump. The only way to do it is to use a JVMTI agent, which requires specifying `-XX:+AllowArchivingWithJavaAgent`. You can see an example in the [GCDuringDump.java](https://github.com/openjdk/jdk/blob/704f784c88ee282837c980948167e741e7227f27/test/hotspot/jtreg/runtime/cds/appcds/javaldr/GCDuringDump.java#L65) test. If the agent tries to define an extra module, it will get an `UnsupportedOperationException` thrown by `check_cds_restrictions()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/80 From dholmes at openjdk.java.net Wed Sep 9 00:11:23 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Sep 2020 00:11:23 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov wrote: > continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. Attempting to use the GitHub UI for further review. If this doesn't work out well I will revert to direct email. make/autoconf/platform.m4 line 536: > 534: AC_SUBST(HOTSPOT_$1_CPU_DEFINE) > 535: > 536: if test "x$OPENJDK_$1_LIBC" = "xmusl"; then I'm not clear why we only check for musl when setting the HOTSPOT_$1_LIBC variable src/hotspot/os/linux/os_linux.cpp line 624: > 622: // confstr() from musl libc returns EINVAL for > 623: // _CS_GNU_LIBC_VERSION and _CS_GNU_LIBPTHREAD_VERSION > 624: os::Linux::set_libc_version("unknown"); This should be "musl - unknown" as we don't know an exact version but we do know that it is musl. src/hotspot/os/linux/os_linux.cpp line 625: > 623: // _CS_GNU_LIBC_VERSION and _CS_GNU_LIBPTHREAD_VERSION > 624: os::Linux::set_libc_version("unknown"); > 625: os::Linux::set_libpthread_version("unknown"); This should be "musl - unknown" as we don't know an exact version but we do know that it is musl. src/hotspot/share/runtime/abstract_vm_version.cpp line 263: > 261: #define LIBC_STR "-" XSTR(LIBC) > 262: #else > 263: #define LIBC_STR "" Again I'm not clear why we do nothing in the non-musl case? Shouldn't we be reporting glibc or musl? src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c line 284: > 282: // To improve portability across platforms and avoid conflicts > 283: // between GNU and XSI versions of strerror_r, plain strerror is used. > 284: // It's safe because this code is not used in any multithreaded environment. I still question this assertion. The issue is not that the current code path that leads to strerror use may be executed concurrently but that any other strerror use could be concurrent with this one. I would consider this a "must fix" if not for the fact we already use strerror in the code and so this doesn't really change the exposure to the problem. test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c line 282: > 280: > 281: pthread_attr_init(&thread_attr); > 282: pthread_attr_setstacksize(&thread_attr, stack_size); Just a comment in response to the explanation as to why this change is needed. If the default thread stacksize under musl is insufficient to successfully attach such a thread to the VM then this will cause problems for applications that embed the VM directly (or which otherwise directly attach existing threads). test/hotspot/jtreg/runtime/TLS/exestack-tls.c line 60: > 58: } > 59: > 60: #if defined(__GLIBC) Why do we use this form here but at line 30 we have: #ifdef __GLIBC__ ? ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/49 From github.com+471021+marschall at openjdk.java.net Wed Sep 9 09:49:44 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Wed, 9 Sep 2020 09:49:44 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall 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: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/45/files - new: https://git.openjdk.java.net/jdk/pull/45/files/47328f4b..1c9dd9da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From philippe.marschall at gmail.com Wed Sep 9 09:45:37 2020 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Wed, 9 Sep 2020 11:45:37 +0200 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Mon, Sep 7, 2020 at 7:54 PM Alan Bateman wrote: > > On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > > > Hello, newbie here > > > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > > > - I tried to update the copyright year to 2020 in every file. > > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > > - All tier1 tests pass. > > - One jpackage/jlink tier2 test fails but I don't believe it is related. > > - Some tier3 Swing tests fail but I don't think they are related. > > This one probably needs discussion on hotspot-dev to get agreement on the rename/move. It might need coordination with > Graal. I sent out mails to hotspot-dev and graal-dev. > If the change does go ahead then please check if java.base's module-info.java still needs to export jdk.internal > to jdk.jfr, I suspect that qualified export can be removed. You're correct we can replace the jdk.internal export with the jdk.internal.vm.annotation export. I updated the PR accordingly. Cheers Philippe From sgehwolf at redhat.com Wed Sep 9 18:16:42 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Sep 2020 20:16:42 +0200 Subject: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal Message-ID: Hi, Please review this 8u (jdk8u/jdk8u-dev tree) fix for JDK-8252395 that I've pushed today. Thanks for Zhengyu Gu for noticing it. The pushed fix added the java.debuginfo and unpack.debuginfo make targets on the condition of ENABLE_DEBUG_SYMBOLS=true, which is insufficient. It needs another check on POST_STRIP_CMD which is set to non-empty for --with- native-debug-symbols={external,zipped}, and is indeed empty for --with- native-debug-symbols=internal. For the --with-native-debug-symbols=none case we have ENABLE_DEBUG_SYMBOLS=false. Bug: https://bugs.openjdk.java.net/browse/JDK-8252975 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252975/01/webrev/ Testing: Builds with --with-native-debug-symbols={none,internal,external,zipped} on Linux x86_64 OK? Thanks, Severin From zgu at redhat.com Wed Sep 9 18:26:12 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 9 Sep 2020 14:26:12 -0400 Subject: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal In-Reply-To: References: Message-ID: <693d409d-f304-9067-5211-121d6a0b283a@redhat.com> Verified, it fixed build. Looks good to me. Thanks for the quick fix. -Zhengyu On 9/9/20 2:16 PM, Severin Gehwolf wrote: > Hi, > > Please review this 8u (jdk8u/jdk8u-dev tree) fix for JDK-8252395 that > I've pushed today. Thanks for Zhengyu Gu for noticing it. The pushed > fix added the java.debuginfo and unpack.debuginfo make targets on the > condition of ENABLE_DEBUG_SYMBOLS=true, which is insufficient. It needs > another check on POST_STRIP_CMD which is set to non-empty for --with- > native-debug-symbols={external,zipped}, and is indeed empty for --with- > native-debug-symbols=internal. For the --with-native-debug-symbols=none > case we have ENABLE_DEBUG_SYMBOLS=false. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252975 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252975/01/webrev/ > > Testing: Builds with --with-native-debug-symbols={none,internal,external,zipped} on Linux x86_64 > > OK? > > Thanks, > Severin > From erikj at openjdk.java.net Wed Sep 9 22:57:48 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Sep 2020 22:57:48 GMT Subject: RFR: 8206311: Add docs-javase, docs-reference to CI build Message-ID: Reposting this review as PR. In order to regularly build the javase and reference docs images, I have made the following changes: 1. Introduced bundle targets for the javase and reference docs images. 2. To run this in CI without adding more unnecessary build time to the linux-x64 target (where the current docs are built), I created a new jib profile "docs". This will run in a separate task and will build all 3 docs targets. 3. To enable the docs targets to run standalone without having to build a full JDK, I had to tweak the "build-jdk" concept a bit, to allow it to also function when not cross compiling for certain parts of the build. Specifically the buildtools-modules can now be built by a "build-jdk" instead of the exploded image. 4. For symmetry, I renamed variables and targets involving docs images to always include one of "jdk", "javase" or "reference" in the name. See below for targets. The new top level targets are: docs-{jdk.javase,reference}-image: Aliases for the existing docs-{jdk,javase,reference} added for consistency. The old docs-image is now an alias for docs-jdk-image. all-docs-images: Builds all 3 of the above docs images. docs-{jdk,javase,reference}-bundles: Builds the bundles for each kind of docs image. The existing docs-bundles is now an alias for docs-jdk-bundles. all-docs-bundles: Builds all the docs bundles. ------------- Commit messages: - Add bundles targets for javase and reference docs Changes: https://git.openjdk.java.net/jdk/pull/99/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=99&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8206311 Stats: 142 lines in 7 files changed: 107 ins; 2 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/99.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/99/head:pull/99 PR: https://git.openjdk.java.net/jdk/pull/99 From alanb at openjdk.java.net Thu Sep 10 06:58:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 06:58:57 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall 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: > 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From mbeckwit at openjdk.java.net Thu Sep 10 07:26:58 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Thu, 10 Sep 2020 07:26:58 GMT Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC Message-ID: ZGC and ShenandoahGC are two low latency GCs in OpenJDK HotSpot. We will enable and run microbenchmarks and scaling tests for both. After enabling, I ran JTRegs, a few micros, and SPECJBB2015 (heap and multi-JVM) scaling tests for both the GCs. ------------- Commit messages: - JDK-8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC Changes: https://git.openjdk.java.net/jdk/pull/97/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=97&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252114 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/97.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/97/head:pull/97 PR: https://git.openjdk.java.net/jdk/pull/97 From shade at openjdk.java.net Thu Sep 10 07:26:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 10 Sep 2020 07:26:59 GMT Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 20:24:37 GMT, Monica Beckwith wrote: > ZGC and ShenandoahGC are two low latency GCs in OpenJDK HotSpot. We will enable and run microbenchmarks and scaling > tests for both. After enabling, I ran JTRegs, a few micros, and SPECJBB2015 (heap and multi-JVM) scaling tests for both > the GCs. I see the block that enables ZGC, where is the block that enables Shenandoah? Ah, Shenandoah does not filter for OS, so it is enabled for AArch64 already, right? make/autoconf/jvm-features.m4 line 398: > 396: AVAILABLE=false > 397: fi > 398: elif test "$OPENJDK_TARGET_CPU" = "aarch64"; then Should be "x$OPENJDK_TARGET_CPU" = "xaarch64"? ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/97 From mbeckwit at openjdk.java.net Thu Sep 10 07:27:00 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Thu, 10 Sep 2020 07:27:00 GMT Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 05:06:41 GMT, Aleksey Shipilev wrote: > I see the block that enables ZGC, where is the block that enables Shenandoah? I had a block for Shenandoah, but then I saw that someone had already modified/combined the Shenandoah to part to be enabled for all combos of aarch64: "# Check if the feature 'shenandoahgc' is available on this platform. # AC_DEFUN_ONCE([JVM_FEATURES_CHECK_SHENANDOAHGC], [ JVM_FEATURES_CHECK_AVAILABILITY(shenandoahgc, [ AC_MSG_CHECKING([if platform is supported by Shenandoah]) if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86" || \ test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then AC_MSG_RESULT([yes]) else AC_MSG_RESULT([no, $OPENJDK_TARGET_CPU]) AVAILABLE=false fi ]) ])" > Ah, Shenandoah does not filter for OS, so it is enabled for AArch64 already, right? +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/97 From sgehwolf at redhat.com Thu Sep 10 08:02:35 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 10 Sep 2020 10:02:35 +0200 Subject: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal In-Reply-To: <693d409d-f304-9067-5211-121d6a0b283a@redhat.com> References: <693d409d-f304-9067-5211-121d6a0b283a@redhat.com> Message-ID: On Wed, 2020-09-09 at 14:26 -0400, Zhengyu Gu wrote: > Verified, it fixed build. Looks good to me. > > Thanks for the quick fix. Thanks for the review! Cheers, Severin > -Zhengyu > > On 9/9/20 2:16 PM, Severin Gehwolf wrote: > > Hi, > > > > Please review this 8u (jdk8u/jdk8u-dev tree) fix for JDK-8252395 that > > I've pushed today. Thanks for Zhengyu Gu for noticing it. The pushed > > fix added the java.debuginfo and unpack.debuginfo make targets on the > > condition of ENABLE_DEBUG_SYMBOLS=true, which is insufficient. It needs > > another check on POST_STRIP_CMD which is set to non-empty for --with- > > native-debug-symbols={external,zipped}, and is indeed empty for --with- > > native-debug-symbols=internal. For the --with-native-debug-symbols=none > > case we have ENABLE_DEBUG_SYMBOLS=false. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252975 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252975/01/webrev/ > > > > Testing: Builds with --with-native-debug-symbols={none,internal,external,zipped} on Linux x86_64 > > > > OK? > > > > Thanks, > > Severin > > From david.holmes at oracle.com Thu Sep 10 08:24:34 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Sep 2020 18:24:34 +1000 Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC In-Reply-To: References: Message-ID: <0da1e4a8-3174-b09d-5932-087a59d75747@oracle.com> Hi Monica, On 10/09/2020 5:26 pm, Monica Beckwith wrote: > ZGC and ShenandoahGC are two low latency GCs in OpenJDK HotSpot. We will enable and run microbenchmarks and scaling > tests for both. After enabling, I ran JTRegs, a few micros, and SPECJBB2015 (heap and multi-JVM) scaling tests for both > the GCs. I'm not seeing any need to push this as a separate fix from the actual Windows-Aarch64 port. You're enabling something that can't be tested in mainline. Cheers, David > ------------- > > Commit messages: > - JDK-8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC > > Changes: https://git.openjdk.java.net/jdk/pull/97/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=97&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8252114 > Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jdk/pull/97.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/97/head:pull/97 > > PR: https://git.openjdk.java.net/jdk/pull/97 > From github.com+2210496+thatsIch at openjdk.java.net Thu Sep 10 08:52:25 2020 From: github.com+2210496+thatsIch at openjdk.java.net (thatsIch) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). @doom369 jcheck requires an associated issue ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:21 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:21 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() Message-ID: **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). ------------- Commit messages: - Merge branch 'master' of https://github.com/doom369/jdk into reaplce_equals_with_is_empty - revert change in classes that maintain jdk 1.4 compatibility - Improvement: replace all occurrences of the .equals("") usages with .isEmpty() Changes: https://git.openjdk.java.net/jdk/pull/29/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=29&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252999 Stats: 234 lines in 150 files changed: 0 ins; 0 del; 234 mod Patch: https://git.openjdk.java.net/jdk/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/29/head:pull/29 PR: https://git.openjdk.java.net/jdk/pull/29 From kcr at openjdk.java.net Thu Sep 10 08:52:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 07:57:48 GMT, Dmitriy Dumanskiy wrote: >> @doom369 jcheck requires an associated issue > > @mrserb hello. Thanks for the review. Any further actions required from me? Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you should expect a longer review process, since someone from each functional area will need to look at the changes in their area (like @mrserb started to do for the `2d` area). ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:25 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 18:08:15 GMT, thatsIch wrote: >> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found >> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). > > @doom369 jcheck requires an associated issue @mrserb hello. Thanks for the review. Any further actions required from me? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From serb at openjdk.java.net Thu Sep 10 08:52:29 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 10 Sep 2020 08:52:29 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). src/demo/share/java2d/J2DBench/src/j2dbench/tests/iio/InputImageTests.java line 187: > 185: String format = spi.getFormatNames()[0].toLowerCase(); > 186: String suffix = spi.getFileSuffixes()[0].toLowerCase(); > 187: if (suffix == null || suffix.equals("")) { This file intentionally maintains compatibility to jdk1.4, so equals("") should be used. src/demo/share/java2d/J2DBench/src/j2dbench/tests/iio/OutputImageTests.java line 146: > 144: String format = spi.getFormatNames()[0].toLowerCase(); > 145: String suffix = spi.getFileSuffixes()[0].toLowerCase(); > 146: if (suffix == null || suffix.equals("")) { This file intentionally maintains compatibility to jdk1.4, so equals("") should be used. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:26 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:26 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 20:21:44 GMT, Kevin Rushforth wrote: >> @mrserb hello. Thanks for the review. Any further actions required from me? > > Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a > Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement > request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once > you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing > "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you > should expect a longer review process, since someone from each functional area will need to look at the changes in > their area (like @mrserb started to do for the `2d` area). @kevinrushforth thanks. Done. Similar issues: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 could be joined somehow? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From adam.farley at uk.ibm.com Thu Sep 10 09:36:30 2020 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 10 Sep 2020 10:36:30 +0100 Subject: RFR: 8252998: ModuleWrapper.gmk doesn't consult include path Message-ID: Hi All, Requesting reviews and sponsor for the following change. A previous change (JDK-8244044) appears to prevent make from checking the include dirs for an included gmk file. This means that you can't override the included file using the include dirs, as was previously the case. This sounds like a bug, and should be fixed. Thoughts welcome. Bug: https://bugs.openjdk.java.net/browse/JDK-8252998 Webrev: http://cr.openjdk.java.net/~afarley/8252998/webrev/ Best Regards Adam Farley IBM Runtimes Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From adam.farley at uk.ibm.com Thu Sep 10 09:42:05 2020 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 10 Sep 2020 10:42:05 +0100 Subject: RFR: 8253000: Remove redundant MAKE_SUBDIR argument Message-ID: Hi All, Reviews and sponsor requested for the removal of the now-redundant MAKE_SUBDIR argument in DeclareRecipesForPhase's comment, along with its removal from anything that calls that macro. Bug: https://bugs.openjdk.java.net/browse/JDK-8253000 Webrev: http://cr.openjdk.java.net/~afarley/8253000/webrev/ Best Regards Adam Farley IBM Runtimes Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From alanb at openjdk.java.net Thu Sep 10 10:42:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 10:42:57 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy wrote: >> Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a >> Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement >> request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once >> you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing >> "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you >> should expect a longer review process, since someone from each functional area will need to look at the changes in >> their area (like @mrserb started to do for the `2d` area). > > @kevinrushforth thanks. Done. > > Similar issues: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 > > could be joined somehow? The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use JDK-8215014 rather than creating a new issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From Alan.Bateman at oracle.com Thu Sep 10 10:51:30 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Sep 2020 11:51:30 +0100 Subject: JDK-8252803: Add the /LARGEADDRESSAWARE flag when linking executables for Windows 32-bit. In-Reply-To: References: Message-ID: On 10/09/2020 10:44, Archana Nogriya wrote: > Hi, > > I am requesting a proposal for the contribution to OpenJDK. > I have created webrev with my changes. > Moving to build-dev as that is normally where the linker options are discussed. I don't know if there is a significant need for Windows 32-bit build these days but one thing to mention is that adding /LARGEADDRESSAWARE created compatibility concerns with JNI code in the past. I see Joe Darcy has linked to JDK-5061380 [1], there may be others. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-5061380 From dholmes at openjdk.java.net Thu Sep 10 11:24:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 11:24:10 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 10:40:15 GMT, Alan Bateman wrote: >> @kevinrushforth thanks. Done. >> >> Similar issues: >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 >> >> could be joined somehow? > > The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do > the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more > more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code > (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan > code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use > JDK-8215014 rather than creating a new issue. This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. Thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 12:07:57 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 12:07:57 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: >> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >> JDK-8215014 rather than creating a new issue. > > This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise > the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. > Thank you. I have in mind dozens of improvements all over the code like this one. I already did some further review and in most cases, those tiny changes go trough all codebase. I can create PR for every separate module, but in general, it would multiply x5 the number of PRs in total. If you think it's a better way to go, no problem, I can do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From kcr at openjdk.java.net Thu Sep 10 12:21:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 12:21:25 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: >> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >> JDK-8215014 rather than creating a new issue. > > This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise > the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. > Thank you. @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. Maybe @AlanBateman or @jddarcy can offer some advice? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From erik.joelsson at oracle.com Thu Sep 10 13:14:42 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 Sep 2020 06:14:42 -0700 Subject: RFR: 8252998: ModuleWrapper.gmk doesn't consult include path In-Reply-To: References: Message-ID: <937799d7-38d9-3760-caaa-ba03d25b01f0@oracle.com> Hello Adam, I agree with this change. However, since we moved to github and Skara last weekend, you need to post this as a PR. See instructions for setting up an OpenJDK workflow in the new Skara world here: https://wiki.openjdk.java.net/display/SKARA/Skara /Erik On 2020-09-10 02:36, Adam Farley8 wrote: > Hi All, > > Requesting reviews and sponsor for the following change. > > A previous change (JDK-8244044) appears to prevent make from checking the > include dirs for an included gmk file. > > This means that you can't override the included file using the include > dirs, as was previously the case. > > This sounds like a bug, and should be fixed. > > Thoughts welcome. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252998 > > Webrev: http://cr.openjdk.java.net/~afarley/8252998/webrev/ > > Best Regards > > Adam Farley > IBM Runtimes > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From erik.joelsson at oracle.com Thu Sep 10 13:15:06 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 Sep 2020 06:15:06 -0700 Subject: RFR: 8253000: Remove redundant MAKE_SUBDIR argument In-Reply-To: References: Message-ID: <062d110e-95ea-b120-eab9-aa01e1358afd@oracle.com> Hello Adam, This is a nice cleanup, but please repost as a PR. /Erik On 2020-09-10 02:42, Adam Farley8 wrote: > Hi All, > > Reviews and sponsor requested for the removal of the now-redundant > MAKE_SUBDIR argument in DeclareRecipesForPhase's comment, along with its > removal from anything that calls that macro. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8253000 > > Webrev: http://cr.openjdk.java.net/~afarley/8253000/webrev/ > > Best Regards > > Adam Farley > IBM Runtimes > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From dholmes at openjdk.java.net Thu Sep 10 13:56:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 13:56:10 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> Message-ID: On Thu, 10 Sep 2020 12:18:51 GMT, Kevin Rushforth wrote: >> This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise >> the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. >> Thank you. > > @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests > each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. > Maybe @AlanBateman or @jddarcy can offer some advice? 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will be delayed due to all of the mails being held up for moderator approval due to: " Too many recipients to the message" I have a longer email coming once it gets through the moderator approval delay. :( ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From david.holmes at oracle.com Thu Sep 10 13:49:24 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Sep 2020 23:49:24 +1000 Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On 10/09/2020 10:07 pm, Dmitriy Dumanskiy wrote: > On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: > >>> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >>> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >>> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >>> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >>> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >>> JDK-8215014 rather than creating a new issue. >> >> This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise >> the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. >> Thank you. > > I have in mind dozens of improvements all over the code like this one. I already did some further review and in most > cases, those tiny changes go trough all codebase. I can create PR for every separate module, but in general, it would > multiply x5 the number of PRs in total. If you think it's a better way to go, no problem, I can do that. Find a reasonable middle ground. You have around 14 mailing lists cc'd here, for changes on 150 files. It is very unlikely anyone will review all 150, and files in different areas are, by convention, reviewed by Reviewers for those areas. Even if people only look at a subset of files, communicating that to you effectively so you can figure out when all 150 have been reviewed, is not very practical. My initial breakdown would be: - build - desktop (awt/swing/2d) - serviceability/jmx (the SA and JVMTI changes) - security - core-libs Also note that while the original PR email went out to 14 lists, most people trying to reply-all won't be able to as they don't subscribe to all 14 lists, so the review threads will get very fragmented. Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/29 > From mbeckwit at openjdk.java.net Thu Sep 10 15:30:04 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Thu, 10 Sep 2020 15:30:04 GMT Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC [v2] In-Reply-To: References: Message-ID: > ZGC and ShenandoahGC are two low latency GCs in OpenJDK HotSpot. We will enable and run microbenchmarks and scaling > tests for both. After enabling, I ran JTRegs, a few micros, and SPECJBB2015 (heap and multi-JVM) scaling tests for both > the GCs. Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: x$OPENJDK_TARGET_CPU" = "xaarch64" Incorporating Aleksey's comments to incorporate 'x' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/97/files - new: https://git.openjdk.java.net/jdk/pull/97/files/10186339..49845fd9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=97&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=97&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/97.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/97/head:pull/97 PR: https://git.openjdk.java.net/jdk/pull/97 From mbeckwit at openjdk.java.net Thu Sep 10 15:30:09 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Thu, 10 Sep 2020 15:30:09 GMT Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC [v2] In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 05:09:25 GMT, Aleksey Shipilev wrote: >> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: >> >> x$OPENJDK_TARGET_CPU" = "xaarch64" >> >> Incorporating Aleksey's comments to incorporate 'x' > > make/autoconf/jvm-features.m4 line 398: > >> 396: AVAILABLE=false >> 397: fi >> 398: elif test "$OPENJDK_TARGET_CPU" = "aarch64"; then > > Should be "x$OPENJDK_TARGET_CPU" = "xaarch64"? added ------------- PR: https://git.openjdk.java.net/jdk/pull/97 From alanb at openjdk.java.net Thu Sep 10 15:53:05 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 15:53:05 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> Message-ID: <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote: >> @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests >> each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. >> Maybe @AlanBateman or @jddarcy can offer some advice? > > 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will > be delayed due to all of the mails being held up for moderator approval due to: > " Too many recipients to the message" > > I have a longer email coming once it gets through the moderator approval delay. :( Patches that do global replace are always awkward. In this case, there are 150 files changed and most seem to be tests or changes to tools used in the build (includes src/hotspot/share/prims/jvmtiEnvFill.java). If these are dropped from the patch then it leaves just 43 files, many of which are from 3rd party code that can also be dropped. This should reduce the patch down to a manageable 24 or so files that should be trivial to review. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From smonteith at openjdk.java.net Thu Sep 10 16:31:23 2020 From: smonteith at openjdk.java.net (Stuart Monteith) Date: Thu, 10 Sep 2020 16:31:23 GMT Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC [v2] In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 05:16:00 GMT, Monica Beckwith wrote: >> Ah, Shenandoah does not filter for OS, so it is enabled for AArch64 already, right? > >> Ah, Shenandoah does not filter for OS, so it is enabled for AArch64 already, right? > > +1 This looks good to me with Alexsey's changes applied. ------------- PR: https://git.openjdk.java.net/jdk/pull/97 From jvernee at openjdk.java.net Thu Sep 10 16:40:57 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Sep 2020 16:40:57 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> Message-ID: On Thu, 10 Sep 2020 15:50:39 GMT, Alan Bateman wrote: >> 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will >> be delayed due to all of the mails being held up for moderator approval due to: >> " Too many recipients to the message" >> >> I have a longer email coming once it gets through the moderator approval delay. :( > > Patches that do global replace are always awkward. In this case, there are 150 files changed and most seem to be tests > or changes to tools used in the build (includes src/hotspot/share/prims/jvmtiEnvFill.java). If these are dropped from > the patch then it leaves just 43 files, many of which are from 3rd party code that can also be dropped. This should > reduce the patch down to a manageable 24 or so files that should be trivial to review. Since one of the motivations for this change is micro benchmark performance, please add a benchmark to the JDKs micro benchmark suite as well. (see e.g. https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang). Also, what testing has been done for these changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From mbeckwit at openjdk.java.net Thu Sep 10 17:11:54 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Thu, 10 Sep 2020 17:11:54 GMT Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC [v2] In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 16:28:34 GMT, Stuart Monteith wrote: >>> Ah, Shenandoah does not filter for OS, so it is enabled for AArch64 already, right? >> >> +1 > > This looks good to me with Alexsey's changes applied. Ref: https://github.com/openjdk/jdk/pull/97#issuecomment-690077743 Hi David, Thanks. I wanted to start a conversation here as it does modify common code (the aarch64-linux combo check) and also wanted to highlight the difference between Shenandoah and ZGC checks. IMHO, Shenandoah checks are cleaner and if people agree, I would like to apply those to ZGC as well. (When that happens, it *will* be outside of the windows-aarch64 port and I will change the info in JBS accordingly) Please let me know what you think. ------------- PR: https://git.openjdk.java.net/jdk/pull/97 From psandoz at openjdk.java.net Thu Sep 10 18:02:26 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 10 Sep 2020 18:02:26 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall 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: > 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From jjg at openjdk.java.net Thu Sep 10 23:31:29 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 10 Sep 2020 23:31:29 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 12:04:48 GMT, Dmitriy Dumanskiy wrote: > I have in mind dozens of improvements all over the code like this one. That sounds scary. Broad updates like these cause unnecessary churn in the codebase, and can make merging and back porting harder. Changes should be discussed ahead of time with the appropriate teams. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From prr at openjdk.java.net Fri Sep 11 00:00:15 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 11 Sep 2020 00:00:15 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). 1) This is un-necessary churn. 2) I can't even be sure I am finding the ones in my area because there's so much here 3) The ones I can find have no need of whatever performance improvement this might bring. I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates you are making. ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/29 From david.holmes at oracle.com Fri Sep 11 01:03:10 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Sep 2020 11:03:10 +1000 Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC [v2] In-Reply-To: References: Message-ID: <6dcdeb24-8633-a3c1-48b7-6107942bba49@oracle.com> Hi Monica, On 11/09/2020 3:11 am, Monica Beckwith wrote: > Ref: https://github.com/openjdk/jdk/pull/97#issuecomment-690077743 > Hi David, > Thanks. I wanted to start a conversation here as it does modify common code (the aarch64-linux combo check) and also > wanted to highlight the difference between Shenandoah and ZGC checks. IMHO, Shenandoah checks are cleaner and if people > agree, I would like to apply those to ZGC as well. (When that happens, it *will* be outside of the windows-aarch64 port > and I will change the info in JBS accordingly) Please let me know what you think. I think you are going about this in a bit of a confusing way :) If you wanted to propose the ZGC feature check should be OS agnostic then you should have just proposed that rather than proposing a Windows-Aarch64 change that clearly belongs with the port work. You'll need to discuss the ZGC check with the ZGC folk on hotspot-gc-dev (now cc'd) but I'm pretty sure the OS check is deliberate, so that only those platforms known to actually work will be enabled. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/97 > From mbeckwit at openjdk.java.net Fri Sep 11 03:48:15 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Fri, 11 Sep 2020 03:48:15 GMT Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC [v2] In-Reply-To: References: Message-ID: <8sOw7jcJcZOrQmY3rjx5BYhT0GSJrUn1mq-v22QalLc=.5e479b5b-fed5-4937-87c4-da72ae227156@github.com> On Thu, 10 Sep 2020 17:09:00 GMT, Monica Beckwith wrote: >> This looks good to me with Alexsey's changes applied. > > Ref: https://github.com/openjdk/jdk/pull/97#issuecomment-690077743 > Hi David, > Thanks. I wanted to start a conversation here as it does modify common code (the aarch64-linux combo check) and also > wanted to highlight the difference between Shenandoah and ZGC checks. IMHO, Shenandoah checks are cleaner and if people > agree, I would like to apply those to ZGC as well. (When that happens, it *will* be outside of the windows-aarch64 port > and I will change the info in JBS accordingly) Please let me know what you think. Ref: https://github.com/openjdk/jdk/pull/97#issuecomment-690811308 I empathize with your comment, David. Here's a bit of a background for all - When I started the port, both ZGC, and Shenandoah had the "xlinux-aarch64" check whereas the "xx86" check was more elaborate for ZGC. At that time I chose the ZGC route for both the GCs and added separate checks for each OS. This is what the windows-aarch64 port has as well. (Since then Shenandoah has moved on to just checking the arch.) I already had a JBS entry, and the (partial) patch, I decided to use that for my first GitHub PR. and was hoping to start the conversation of the simpler route that Shenandoah took in the comments mentioning that as my preference and modify the JBS entry (and the patch) accordingly. Now coming back to this - @stooart-mon, do you think it is OK to just check for aarch64 (similar to Shenandoah)? @stefank what do you think of simplifying the x86 checks (similar to Shenandoah)? Thanks all. ------------- PR: https://git.openjdk.java.net/jdk/pull/97 From shade at openjdk.java.net Fri Sep 11 06:24:22 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 11 Sep 2020 06:24:22 GMT Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC [v2] In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 15:30:04 GMT, Monica Beckwith wrote: >> ZGC and ShenandoahGC are two low latency GCs in OpenJDK HotSpot. We will enable and run microbenchmarks and scaling >> tests for both. After enabling, I ran JTRegs, a few micros, and SPECJBB2015 (heap and multi-JVM) scaling tests for both >> the GCs. > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > x$OPENJDK_TARGET_CPU" = "xaarch64" > > Incorporating Aleksey's comments to incorporate 'x' The check looks fine now. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/97 From shade at openjdk.java.net Fri Sep 11 06:27:24 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 11 Sep 2020 06:27:24 GMT Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC [v2] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 06:21:46 GMT, Aleksey Shipilev wrote: >> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: >> >> x$OPENJDK_TARGET_CPU" = "xaarch64" >> >> Incorporating Aleksey's comments to incorporate 'x' > > The check looks fine now. > Ref: [#97 (comment)](https://github.com/openjdk/jdk/pull/97#issuecomment-690811308) > Now coming back to this - @stooart-mon, do you think it is OK to just check for aarch64 (similar to Shenandoah)? > @stefank what do you think of simplifying the x86 checks (similar to Shenandoah)? Thanks all. I believe keeping OS-specific checks for ZGC is better, as it reflects the reality of needing the OS-specific code there. We don't want to try and build on OS we know ZGC does not support (yet). Shenandoah does not have OS-specific code, only the arch-specific one, and so can live with OS checks only. ------------- PR: https://git.openjdk.java.net/jdk/pull/97 From stefank at openjdk.java.net Fri Sep 11 07:02:35 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 11 Sep 2020 07:02:35 GMT Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC [v2] In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 15:30:04 GMT, Monica Beckwith wrote: >> ZGC and ShenandoahGC are two low latency GCs in OpenJDK HotSpot. We will enable and run microbenchmarks and scaling >> tests for both. After enabling, I ran JTRegs, a few micros, and SPECJBB2015 (heap and multi-JVM) scaling tests for both >> the GCs. > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > x$OPENJDK_TARGET_CPU" = "xaarch64" > > Incorporating Aleksey's comments to incorporate 'x' Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/97 From avoitylov at openjdk.java.net Fri Sep 11 07:03:37 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 11 Sep 2020 07:03:37 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: Message-ID: > continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: JDK-8247589: Implementation of Alpine Linux/x64 Port ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/49/files - new: https://git.openjdk.java.net/jdk/pull/49/files/f61f546a..d5994cb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=00-01 Stats: 19 lines in 4 files changed: 7 ins; 4 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/49/head:pull/49 PR: https://git.openjdk.java.net/jdk/pull/49 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 11 07:18:17 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 11 Sep 2020 07:18:17 GMT Subject: Withdrawn: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 11 07:18:17 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 11 Sep 2020 07:18:17 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 23:57:38 GMT, Phil Race wrote: >> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found >> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). > > 1) This is un-necessary churn. > 2) I can't even be sure I am finding the ones in my area because there's so much here > 3) The ones I can find have no need of whatever performance improvement this might bring. > I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various > cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates > you are making. Ok, sorry for the distraction. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From avoitylov at openjdk.java.net Fri Sep 11 07:39:47 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 11 Sep 2020 07:39:47 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 23:44:58 GMT, David Holmes wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8247589: Implementation of Alpine Linux/x64 Port > > make/autoconf/platform.m4 line 536: > >> 534: AC_SUBST(HOTSPOT_$1_CPU_DEFINE) >> 535: >> 536: if test "x$OPENJDK_$1_LIBC" = "xmusl"; then > > I'm not clear why we only check for musl when setting the HOTSPOT_$1_LIBC variable this check is removed in the updated version. As a consequence, LIBC variable is added to the release file for all platforms, which is probably a good thing. > src/hotspot/os/linux/os_linux.cpp line 624: > >> 622: // confstr() from musl libc returns EINVAL for >> 623: // _CS_GNU_LIBC_VERSION and _CS_GNU_LIBPTHREAD_VERSION >> 624: os::Linux::set_libc_version("unknown"); > > This should be "musl - unknown" as we don't know an exact version but we do know that it is musl. Right, this should be more consistent with glibc which here returns name and version. Updated as suggested. > src/hotspot/os/linux/os_linux.cpp line 625: > >> 623: // _CS_GNU_LIBC_VERSION and _CS_GNU_LIBPTHREAD_VERSION >> 624: os::Linux::set_libc_version("unknown"); >> 625: os::Linux::set_libpthread_version("unknown"); > > This should be "musl - unknown" as we don't know an exact version but we do know that it is musl. The pthread version is also updated to "musl - unknown". Reason being, pthread functionality for musl is built into the library. > src/hotspot/share/runtime/abstract_vm_version.cpp line 263: > >> 261: #define LIBC_STR "-" XSTR(LIBC) >> 262: #else >> 263: #define LIBC_STR "" > > Again I'm not clear why we do nothing in the non-musl case? Shouldn't we be reporting glibc or musl? Unlike the case above, I think it's best to keep it as is. I'd expect there to be a bunch of scripts in the wild which parse it and may get broken when facing a triplet for existing platforms. > src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c line 284: > >> 282: // To improve portability across platforms and avoid conflicts >> 283: // between GNU and XSI versions of strerror_r, plain strerror is used. >> 284: // It's safe because this code is not used in any multithreaded environment. > > I still question this assertion. The issue is not that the current code path that leads to strerror use may be executed > concurrently but that any other strerror use could be concurrent with this one. I would consider this a "must fix" if > not for the fact we already use strerror in the code and so this doesn't really change the exposure to the problem. You are right! The updated version #ifdefs the XSI or GNU versions of strerror_r in this place. Note to self: file a bug to address the usage of strerror in other places, at least for HotSpot. > test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c line 282: > >> 280: >> 281: pthread_attr_init(&thread_attr); >> 282: pthread_attr_setstacksize(&thread_attr, stack_size); > > Just a comment in response to the explanation as to why this change is needed. If the default thread stacksize under > musl is insufficient to successfully attach such a thread to the VM then this will cause problems for applications that > embed the VM directly (or which otherwise directly attach existing threads). This fix https://git.musl-libc.org/cgit/musl/commit/src/aio/aio.c?id=1a6d6f131bd60ec2a858b34100049f0c042089f2 addresses the problem for recent versions of musl. The test passes on a recent Alpine Linux 3.11.6 (musl 1.1.24) and fails on Alpine Linux 3.8.2 (musl 1.1.19) without this test fix. There are still older versions of the library in the wild, hence the test fix. The mitigation for such users would be a distro upgrade. > test/hotspot/jtreg/runtime/TLS/exestack-tls.c line 60: > >> 58: } >> 59: >> 60: #if defined(__GLIBC) > > Why do we use this form here but at line 30 we have: > #ifdef __GLIBC__ > ? Fixed to be consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From stuart.monteith at arm.com Fri Sep 11 14:06:45 2020 From: stuart.monteith at arm.com (Stuart Monteith) Date: Fri, 11 Sep 2020 15:06:45 +0100 Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC [v2] In-Reply-To: <8sOw7jcJcZOrQmY3rjx5BYhT0GSJrUn1mq-v22QalLc=.5e479b5b-fed5-4937-87c4-da72ae227156@github.com> References: <8sOw7jcJcZOrQmY3rjx5BYhT0GSJrUn1mq-v22QalLc=.5e479b5b-fed5-4937-87c4-da72ae227156@github.com> Message-ID: <662dcb15-3685-3ce1-dbe8-3c6ab09d252f@arm.com> On 11/09/2020 04:48, Monica Beckwith wrote: > On Thu, 10 Sep 2020 17:09:00 GMT, Monica Beckwith wrote: > >>> This looks good to me with Alexsey's changes applied. >> >> Ref: https://github.com/openjdk/jdk/pull/97#issuecomment-690077743 >> Hi David, >> Thanks. I wanted to start a conversation here as it does modify common code (the aarch64-linux combo check) and also >> wanted to highlight the difference between Shenandoah and ZGC checks. IMHO, Shenandoah checks are cleaner and if people >> agree, I would like to apply those to ZGC as well. (When that happens, it *will* be outside of the windows-aarch64 port >> and I will change the info in JBS accordingly) Please let me know what you think. > > Ref: https://github.com/openjdk/jdk/pull/97#issuecomment-690811308 > I empathize with your comment, David. Here's a bit of a background for all - > When I started the port, both ZGC, and Shenandoah had the "xlinux-aarch64" check whereas the "xx86" check was more > elaborate for ZGC. At that time I chose the ZGC route for both the GCs and added separate checks for each OS. This is > what the windows-aarch64 port has as well. (Since then Shenandoah has moved on to just checking the arch.) I already > had a JBS entry, and the (partial) patch, I decided to use that for my first GitHub PR. and was hoping to start the > conversation of the simpler route that Shenandoah took in the comments mentioning that as my preference and modify the > JBS entry (and the patch) accordingly. > > Now coming back to this - @stooart-mon, do you think it is OK to just check for aarch64 (similar to Shenandoah)? > @stefank what do you think of simplifying the x86 checks (similar to Shenandoah)? Thanks all. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/97 > Hi Monica, I guess the choice is either to enable aarch64, and have the Mac port disable ZGC if necessary, or do what you have done here and just enable by by architecture and supported platform. If Anton is happy with the simple check for aarch64, then I'm happy. BR, Stuart From kcr at openjdk.java.net Fri Sep 11 14:35:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Sep 2020 14:35:23 GMT Subject: RFR: 8253031: git jcheck complains about invalid tags in jdk repo after fix for JDK-8252844 Message-ID: <7rFH9W5v_QDW4LHVi3w4NMy37ix8kNgZTWROPWah15E=.4a63e7e2-17c1-4acb-8e0d-99a4814c1d5a@github.com> In the fix for [JDK-8252844](https://bugs.openjdk.java.net/browse/JDK-8252844) the tags entry in `.jcheck/conf` was copied from the Skara Java code. The `` chars were escaped as `\` in the Java String so that it would contain ``. This additional level of escape is not needed in the `.jcheck/conf` file, and causes the regex to not be as intended. The fix is to replace `\` with `/` in the regex. ------------- Commit messages: - 8253031: git jcheck complains about invalid tags in jdk repo after fix for JDK-8252844 Changes: https://git.openjdk.java.net/jdk/pull/131/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=131&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253031 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/131.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/131/head:pull/131 PR: https://git.openjdk.java.net/jdk/pull/131 From ehelin at openjdk.java.net Fri Sep 11 14:46:15 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Fri, 11 Sep 2020 14:46:15 GMT Subject: RFR: 8253031: git jcheck complains about invalid tags in jdk repo after fix for JDK-8252844 In-Reply-To: <7rFH9W5v_QDW4LHVi3w4NMy37ix8kNgZTWROPWah15E=.4a63e7e2-17c1-4acb-8e0d-99a4814c1d5a@github.com> References: <7rFH9W5v_QDW4LHVi3w4NMy37ix8kNgZTWROPWah15E=.4a63e7e2-17c1-4acb-8e0d-99a4814c1d5a@github.com> Message-ID: On Fri, 11 Sep 2020 14:28:41 GMT, Kevin Rushforth wrote: > In the fix for [JDK-8252844](https://bugs.openjdk.java.net/browse/JDK-8252844) the tags entry in `.jcheck/conf` was > copied from the Skara Java code. The `` chars were escaped as `\` in the Java String so that it would contain ``. This > additional level of escape is not needed in the `.jcheck/conf` file, and causes the regex to not be as intended. The > fix is to replace `\` with `` in the regex. Looks good Kevin, thanks for fixing! ------------- Marked as reviewed by ehelin (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/131 From erikj at openjdk.java.net Fri Sep 11 14:57:21 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 11 Sep 2020 14:57:21 GMT Subject: RFR: 8253031: git jcheck complains about invalid tags in jdk repo after fix for JDK-8252844 In-Reply-To: <7rFH9W5v_QDW4LHVi3w4NMy37ix8kNgZTWROPWah15E=.4a63e7e2-17c1-4acb-8e0d-99a4814c1d5a@github.com> References: <7rFH9W5v_QDW4LHVi3w4NMy37ix8kNgZTWROPWah15E=.4a63e7e2-17c1-4acb-8e0d-99a4814c1d5a@github.com> Message-ID: On Fri, 11 Sep 2020 14:28:41 GMT, Kevin Rushforth wrote: > In the fix for [JDK-8252844](https://bugs.openjdk.java.net/browse/JDK-8252844) the tags entry in `.jcheck/conf` was > copied from the Skara Java code. The `` chars were escaped as `\` in the Java String so that it would contain ``. This > additional level of escape is not needed in the `.jcheck/conf` file, and causes the regex to not be as intended. The > fix is to replace `\` with `` in the regex. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/131 From kcr at openjdk.java.net Fri Sep 11 15:20:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Sep 2020 15:20:32 GMT Subject: Integrated: 8253031: git jcheck complains about invalid tags in jdk repo after fix for JDK-8252844 In-Reply-To: <7rFH9W5v_QDW4LHVi3w4NMy37ix8kNgZTWROPWah15E=.4a63e7e2-17c1-4acb-8e0d-99a4814c1d5a@github.com> References: <7rFH9W5v_QDW4LHVi3w4NMy37ix8kNgZTWROPWah15E=.4a63e7e2-17c1-4acb-8e0d-99a4814c1d5a@github.com> Message-ID: On Fri, 11 Sep 2020 14:28:41 GMT, Kevin Rushforth wrote: > In the fix for [JDK-8252844](https://bugs.openjdk.java.net/browse/JDK-8252844) the tags entry in `.jcheck/conf` was > copied from the Skara Java code. The `` chars were escaped as `\` in the Java String so that it would contain ``. This > additional level of escape is not needed in the `.jcheck/conf` file, and causes the regex to not be as intended. The > fix is to replace `\` with `` in the regex. This pull request has now been integrated. Changeset: 95251864 Author: Kevin Rushforth Committer: Erik Joelsson URL: https://git.openjdk.java.net/jdk/commit/95251864 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8253031: git jcheck complains about invalid tags in jdk repo after fix for JDK-8252844 Reviewed-by: ehelin, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/131 From wetmore at openjdk.java.net Fri Sep 11 15:20:36 2020 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 11 Sep 2020 15:20:36 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 07:15:26 GMT, Dmitriy Dumanskiy wrote: >> 1) This is un-necessary churn. >> 2) I can't even be sure I am finding the ones in my area because there's so much here >> 3) The ones I can find have no need of whatever performance improvement this might bring. >> I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various >> cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates >> you are making. > > Ok, sorry for the distraction. Our local Santuario maintainer says: In general, changes to Apache Santuario should also be made at Apache so we stay in sync. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From kvn at openjdk.java.net Fri Sep 11 21:57:54 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 11 Sep 2020 21:57:54 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> Message-ID: On Fri, 11 Sep 2020 21:53:12 GMT, Vladimir Kozlov wrote: >> Marked as reviewed by psandoz (Reviewer). > > You should consider upstreaming Graal changes (jdk.internal.vm.compiler) into https://github.com/oracle/graal > Otherwise next time we do "Update Graal" in JDK they will be overwritten. Changes look good. I ran hs-tier1 and hs-tier3 test jobs which run Graal tests and they passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From kvn at openjdk.java.net Fri Sep 11 21:57:54 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 11 Sep 2020 21:57:54 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> Message-ID: On Thu, 10 Sep 2020 17:59:54 GMT, Paul Sandoz wrote: >> Philippe Marschall 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. > > Marked as reviewed by psandoz (Reviewer). You should consider upstreaming Graal changes (jdk.internal.vm.compiler) into https://github.com/oracle/graal Otherwise next time we do "Update Graal" in JDK they will be overwritten. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From kvn at openjdk.java.net Sat Sep 12 00:21:29 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 12 Sep 2020 00:21:29 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall 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. Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From dholmes at openjdk.java.net Mon Sep 14 04:21:26 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Sep 2020 04:21:26 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 07:03:37 GMT, Aleksei Voitylov wrote: >> continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html >> >>> The download side of using JNI in these tests is that it complicates the >>> setup a bit for those that run jtreg directly and/or just build the JDK >>> and not the test libraries. You could reduce this burden a bit by >>> limiting the load library/isMusl check to Linux only, meaning isMusl >>> would not be called on other platforms. >>> >>> The alternative you suggest above might indeed be better. I assume you >>> don't mean splitting the tests but rather just adding a second @test >>> description so that the vm.musl case runs the test with a system >>> property that allows the test know the expected load library path behavior. >> >> I have updated the PR to split the two tests in multiple @test s. >> >>> The updated comment in java_md.c in this looks good. A minor comment on >>> Platform.isBusybox is Files.isSymbolicLink returning true implies that >>> the link exists so no need to check for exists too. Also the >>> if-then-else style for the new class in ProcessBuilder/Basic.java is >>> inconsistent with the rest of the test so it stands out. >> >> Thank you, these changes are done in the updated PR. >> >>> Given the repo transition this weekend then I assume you'll create a PR >>> for the final review at least. Also I see JEP 386 hasn't been targeted >>> yet but I assume Boris, as owner, will propose-to-target and wait for it >>> to be targeted before it is integrated. >> >> Yes. How can this be best accomplished with the new git workflow? >> - we can continue the review process till the end and I will request the integration to happen only after the JEP is >> targeted. I guess this step is now done by typing "slash integrate" in a comment. >> - we can pause the review process now until the JEP is targeted. >> >> In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8247589: Implementation of Alpine Linux/x64 Port Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From dholmes at openjdk.java.net Mon Sep 14 04:21:27 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Sep 2020 04:21:27 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: Message-ID: <6y6Cyk85aOiF6smCGSK5VH-rBadloV2gW8iVIW1e9BE=.47f56d70-2a7a-4951-a058-10add4118b31@github.com> On Wed, 9 Sep 2020 00:08:35 GMT, David Holmes wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8247589: Implementation of Alpine Linux/x64 Port > > Attempting to use the GitHub UI for further review. If this doesn't work out well I will revert to direct email. Updates look good. Nothing further from me. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From dholmes at openjdk.java.net Mon Sep 14 04:21:27 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Sep 2020 04:21:27 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 07:36:57 GMT, Aleksei Voitylov wrote: >> test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c line 282: >> >>> 280: >>> 281: pthread_attr_init(&thread_attr); >>> 282: pthread_attr_setstacksize(&thread_attr, stack_size); >> >> Just a comment in response to the explanation as to why this change is needed. If the default thread stacksize under >> musl is insufficient to successfully attach such a thread to the VM then this will cause problems for applications that >> embed the VM directly (or which otherwise directly attach existing threads). > > This fix https://git.musl-libc.org/cgit/musl/commit/src/aio/aio.c?id=1a6d6f131bd60ec2a858b34100049f0c042089f2 > addresses the problem for recent versions of musl. The test passes on a recent Alpine Linux 3.11.6 (musl 1.1.24) and > fails on Alpine Linux 3.8.2 (musl 1.1.19) without this test fix. There are still older versions of the library in the > wild, hence the test fix. The mitigation for such users would be a distro upgrade. Thanks for the additional info on this. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From avoitylov at openjdk.java.net Mon Sep 14 06:33:20 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Mon, 14 Sep 2020 06:33:20 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: Message-ID: <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com> On Mon, 14 Sep 2020 04:18:39 GMT, David Holmes wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8247589: Implementation of Alpine Linux/x64 Port > > Marked as reviewed by dholmes (Reviewer). thank you Alan, Erik, and David! When the JEP becomes Targeted, I'll use this PR to integrate the changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From darcy at openjdk.java.net Mon Sep 14 23:49:29 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Sep 2020 23:49:29 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM Message-ID: The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. ------------- Commit messages: - Update symbol generation to accomodate Git as the SCM Changes: https://git.openjdk.java.net/jdk/pull/161/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=161&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253034 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/161/head:pull/161 PR: https://git.openjdk.java.net/jdk/pull/161 From adityam at openjdk.java.net Tue Sep 15 01:22:13 2020 From: adityam at openjdk.java.net (Aditya Mandaleeka) Date: Tue, 15 Sep 2020 01:22:13 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 23:41:52 GMT, Joe Darcy wrote: > The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. make/scripts/generate-symbol-data.sh line 66: > 64: fi; > 65: > 66: if [ "`git status -s .`x" != "x" ] ; then Just a suggestion: perhaps you want to use the porcelain format here instead of short? https://git-scm.com/docs/git-status#Documentation/git-status.txt---porcelainltversiongt ------------- PR: https://git.openjdk.java.net/jdk/pull/161 From hannesw at openjdk.java.net Tue Sep 15 09:18:20 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 15 Sep 2020 09:18:20 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes Message-ID: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> This pull request is identical with the RFR previously sent for the Mercurial repository: https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html I'm copy-pasting the comments from the original RFR below. Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting code for setting up external links. The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for prereleases. Platform documentation URLs can be configured using the new --link-platform-properties option to provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on the new options. The feature can be disabled using the --no-platform-link option, generating the same output as previously. One problem I had to solve was how to handle the transition from prerelease versions to final releases, since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that switch via code change at a time shortly before release. The way it is done is that we determine if the current javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(), and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with source version 15 will generate links to the final release documentation) but I think this is acceptable. Another issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally there should be one test with a clear message. Because of this, when a release is encountered for which no element-list is available a warning is generated instead of an error, and the documentation is generated without platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new test to fail with a relatively clear message of what is wrong. *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we still need to maintain element-lists for older versions, so I?m not sure it?s worth it. For existing tests that check output affected by the new option I added the --no-platform-link option to disable the feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static release or source version, which we don?t want either). I updated the CSR to the new code. It also needs to be reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 Thanks, Hannes ------------- Commit messages: - 8216497: javadoc should auto-link to platform classes Changes: https://git.openjdk.java.net/jdk/pull/171/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=171&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8216497 Stats: 3230 lines in 53 files changed: 3220 ins; 4 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/171/head:pull/171 PR: https://git.openjdk.java.net/jdk/pull/171 From jlahoda at openjdk.java.net Tue Sep 15 11:32:50 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 15 Sep 2020 11:32:50 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes In-Reply-To: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: On Tue, 15 Sep 2020 09:10:54 GMT, Hannes Walln?fer wrote: > This pull request is identical with the RFR previously sent for the Mercurial repository: > > https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html > > I'm copy-pasting the comments from the original RFR below. > > Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting > code for setting up external links. > The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for > prereleases. Platform documentation URLs can be configured using the new --link-platform-properties option to > provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on > the new options. The feature can be disabled using the --no-platform-link option, generating the same output as > previously. One problem I had to solve was how to handle the transition from prerelease versions to final releases, > since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that > switch via code change at a time shortly before release. The way it is done is that we determine if the current > javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(), > and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This > means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with > source version 15 will generate links to the final release documentation) but I think this is acceptable. Another > issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to > pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally > there should be one test with a clear message. Because of this, when a release is encountered for which no > element-list is available a warning is generated instead of an error, and the documentation is generated without > platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new > test to fail with a relatively clear message of what is wrong. > *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we > still need to maintain element-lists for older versions, so I?m not sure it?s worth it. > > For existing tests that check output affected by the new option I added the --no-platform-link option to disable the > feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static > release or source version, which we don?t want either). I updated the CSR to the new code. It also needs to be > reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 > > Thanks, > Hannes I think it would be awesome if we could generate (most of) the {element,package}-list-VERSION.txt from the ct.sym historical data at build time. This would (hopefully) help with long-term maintenance. I've started to sketch that here: https://github.com/lahodaj/jdk/commit/36c1510587a4b050b148eda87ae7a7a89aff9690 Some comments on the attempt: -in this PR, there is package-list-9.txt - should it be element-list-9.txt, and should it contain module names (dtto element-list-10.txt)? -we may (for historical reasons) want to keep the lists for 7, 8, 9 and 10 (as the historical data in ct.sym do not exactly match what is in the package/element lists). It would be better to generate everything, but having a fixed list for some of the past versions would be better than having to create a new list for each new release. -the patch does not yet generate the list for the current release, but that should be doable. ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From jpai at openjdk.java.net Tue Sep 15 12:26:12 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 12:26:12 GMT Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v2] In-Reply-To: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> Message-ID: > Can I please get a review and a sponsor for this patch which fixes the issue reported in > https://bugs.openjdk.java.net/browse/JDK-8244706? > The commit here sets the `OS` header flag to `255` (which represents `unknown`) as noted in [1]. A new test has been > included in this commit to verify the change. Furthermore, this doesn't impact the `java.util.zip.GZIPInputStream` > since it ignores [2] this header value while reading the headers from the stream. [1] > https://tools.ietf.org/html/rfc1952#page-7 [2] > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#L173 Jaikiran Pai 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: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) Reviewed-By: ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/130/files - new: https://git.openjdk.java.net/jdk/pull/130/files/afad1261..159684de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=130&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=130&range=00-01 Stats: 5 lines in 2 files changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/130.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/130/head:pull/130 PR: https://git.openjdk.java.net/jdk/pull/130 From jpai at openjdk.java.net Tue Sep 15 12:31:15 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 12:31:15 GMT Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v3] In-Reply-To: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> Message-ID: > Can I please get a review and a sponsor for this patch which fixes the issue reported in > https://bugs.openjdk.java.net/browse/JDK-8244706? > The commit here sets the `OS` header flag to `255` (which represents `unknown`) as noted in [1]. A new test has been > included in this commit to verify the change. Furthermore, this doesn't impact the `java.util.zip.GZIPInputStream` > since it ignores [2] this header value while reading the headers from the stream. [1] > https://tools.ietf.org/html/rfc1952#page-7 [2] > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#L173 Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Improve the comment for the OS_UNKNOWN field ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/130/files - new: https://git.openjdk.java.net/jdk/pull/130/files/159684de..7679b119 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=130&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=130&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/130.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/130/head:pull/130 PR: https://git.openjdk.java.net/jdk/pull/130 From erikj at openjdk.java.net Tue Sep 15 12:57:17 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Sep 2020 12:57:17 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 23:41:52 GMT, Joe Darcy wrote: > The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/161 From hannesw at openjdk.java.net Tue Sep 15 12:58:44 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 15 Sep 2020 12:58:44 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes In-Reply-To: References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: On Tue, 15 Sep 2020 11:30:09 GMT, Jan Lahoda wrote: >> This pull request is identical with the RFR previously sent for the Mercurial repository: >> >> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html >> >> I'm copy-pasting the comments from the original RFR below. >> >> Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting >> code for setting up external links. >> The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for >> prereleases. Platform documentation URLs can be configured using the new --link-platform-properties option to >> provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on >> the new options. The feature can be disabled using the --no-platform-link option, generating the same output as >> previously. One problem I had to solve was how to handle the transition from prerelease versions to final releases, >> since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that >> switch via code change at a time shortly before release. The way it is done is that we determine if the current >> javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(), >> and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This >> means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with >> source version 15 will generate links to the final release documentation) but I think this is acceptable. Another >> issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to >> pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally >> there should be one test with a clear message. Because of this, when a release is encountered for which no >> element-list is available a warning is generated instead of an error, and the documentation is generated without >> platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new >> test to fail with a relatively clear message of what is wrong. >> *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we >> still need to maintain element-lists for older versions, so I?m not sure it?s worth it. >> >> For existing tests that check output affected by the new option I added the --no-platform-link option to disable the >> feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static >> release or source version, which we don?t want either). I updated the CSR to the new code. It also needs to be >> reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 >> >> Thanks, >> Hannes > > I think it would be awesome if we could generate (most of) the {element,package}-list-VERSION.txt from the ct.sym > historical data at build time. This would (hopefully) help with long-term maintenance. I've started to sketch that > here: https://github.com/lahodaj/jdk/commit/36c1510587a4b050b148eda87ae7a7a89aff9690 > Some comments on the attempt: > -in this PR, there is package-list-9.txt - should it be element-list-9.txt, and should it contain module names (dtto > element-list-10.txt)? > -we may (for historical reasons) want to keep the lists for 7, 8, 9 and 10 (as the historical data in ct.sym do not > exactly match what is in the package/element lists). It would be better to generate everything, but having a fixed list > for some of the past versions would be better than having to create a new list for each new release. > -the patch does not yet generate the list for the current release, but that should be doable. Thanks for the suggestions and help, Jan! > I think it would be awesome if we could generate (most of) the {element,package}-list-VERSION.txt from the ct.sym > historical data at build time. This would (hopefully) help with long-term maintenance. I've started to sketch that > here: [lahodaj at 36c1510](https://github.com/lahodaj/jdk/commit/36c1510587a4b050b148eda87ae7a7a89aff9690) I agree files should be generated dynamically. I knew about the sym files but wasn't sure how to go about it. Thanks a lot for stepping in and helping out, it's very much appreciated! > Some comments on the attempt: > -in this PR, there is package-list-9.txt - should it be element-list-9.txt, and should it contain module names (dtto > element-list-10.txt)? Javadoc in 9 still uses the old package-centric layout (package-list and no module names in URL paths). It only became fully module-aware in 10. > -we may (for historical reasons) want to keep the lists for 7, 8, 9 and 10 (as the historical data in ct.sym do not > exactly match what is in the package/element lists). It would be better to generate everything, but having a fixed list > for some of the past versions would be better than having to create a new list for each new release. > -the patch does not yet generate the list for the current release, but that should be doable. I definitely agree. I'll work on a new version that generates as much of the lists as possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From erikj at openjdk.java.net Tue Sep 15 12:58:44 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Sep 2020 12:58:44 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes In-Reply-To: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: <4CDMu2V_lHE_0xOp3zfR4An3GKV91vukCXMDq4AuO-k=.e6b96bf7-c4d1-4951-904c-dfb9521bbb71@github.com> On Tue, 15 Sep 2020 09:10:54 GMT, Hannes Walln?fer wrote: > This pull request is identical with the RFR previously sent for the Mercurial repository: > > https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html > > I'm copy-pasting the comments from the original RFR below. > > Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting > code for setting up external links. > The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for > prereleases. Platform documentation URLs can be configured using the new --link-platform-properties option to > provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on > the new options. The feature can be disabled using the --no-platform-link option, generating the same output as > previously. One problem I had to solve was how to handle the transition from prerelease versions to final releases, > since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that > switch via code change at a time shortly before release. The way it is done is that we determine if the current > javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(), > and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This > means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with > source version 15 will generate links to the final release documentation) but I think this is acceptable. Another > issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to > pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally > there should be one test with a clear message. Because of this, when a release is encountered for which no > element-list is available a warning is generated instead of an error, and the documentation is generated without > platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new > test to fail with a relatively clear message of what is wrong. > *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we > still need to maintain element-lists for older versions, so I?m not sure it?s worth it. > > For existing tests that check output affected by the new option I added the --no-platform-link option to disable the > feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static > release or source version, which we don?t want either). I updated the CSR to the new code. It also needs to be > reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 > > Thanks, > Hannes Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/171 From hannesw at openjdk.java.net Tue Sep 15 13:15:18 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 15 Sep 2020 13:15:18 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes In-Reply-To: <4CDMu2V_lHE_0xOp3zfR4An3GKV91vukCXMDq4AuO-k=.e6b96bf7-c4d1-4951-904c-dfb9521bbb71@github.com> References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> <4CDMu2V_lHE_0xOp3zfR4An3GKV91vukCXMDq4AuO-k=.e6b96bf7-c4d1-4951-904c-dfb9521bbb71@github.com> Message-ID: On Tue, 15 Sep 2020 12:56:13 GMT, Erik Joelsson wrote: >> This pull request is identical with the RFR previously sent for the Mercurial repository: >> >> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html >> >> I'm copy-pasting the comments from the original RFR below. >> >> Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting >> code for setting up external links. >> The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for >> prereleases. Platform documentation URLs can be configured using the new --link-platform-properties option to >> provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on >> the new options. The feature can be disabled using the --no-platform-link option, generating the same output as >> previously. One problem I had to solve was how to handle the transition from prerelease versions to final releases, >> since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that >> switch via code change at a time shortly before release. The way it is done is that we determine if the current >> javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(), >> and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This >> means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with >> source version 15 will generate links to the final release documentation) but I think this is acceptable. Another >> issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to >> pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally >> there should be one test with a clear message. Because of this, when a release is encountered for which no >> element-list is available a warning is generated instead of an error, and the documentation is generated without >> platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new >> test to fail with a relatively clear message of what is wrong. >> *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we >> still need to maintain element-lists for older versions, so I?m not sure it?s worth it. >> >> For existing tests that check output affected by the new option I added the --no-platform-link option to disable the >> feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static >> release or source version, which we don?t want either). I updated the CSR to the new code. It also needs to be >> reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 >> >> Thanks, >> Hannes > > Build changes look good. Converted to draft as @lahodaj has offered to enhance the feature as described in the comments above. ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From ehelin at openjdk.java.net Tue Sep 15 13:48:07 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Tue, 15 Sep 2020 13:48:07 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 01:19:32 GMT, Aditya Mandaleeka wrote: >> The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. > > make/scripts/generate-symbol-data.sh line 66: > >> 64: fi; >> 65: >> 66: if [ "`git status -s .`x" != "x" ] ; then > > Just a suggestion: perhaps you want to use the porcelain format here instead of short? > https://git-scm.com/docs/git-status#Documentation/git-status.txt---porcelainltversiongt I agree with @adityamandaleeka, please use `git status --porcelain=v1`. See the git status [documentation](https://git-scm.com/docs/git-status#_porcelain_format_version_1) for the specification for the output. ------------- PR: https://git.openjdk.java.net/jdk/pull/161 From rkennke at openjdk.java.net Tue Sep 15 15:54:34 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 15 Sep 2020 15:54:34 GMT Subject: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC [v2] In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 15:30:04 GMT, Monica Beckwith wrote: >> ZGC and ShenandoahGC are two low latency GCs in OpenJDK HotSpot. We will enable and run microbenchmarks and scaling >> tests for both. After enabling, I ran JTRegs, a few micros, and SPECJBB2015 (heap and multi-JVM) scaling tests for both >> the GCs. > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > x$OPENJDK_TARGET_CPU" = "xaarch64" > > Incorporating Aleksey's comments to incorporate 'x' Looks good to me. Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/97 From minqi at openjdk.java.net Tue Sep 15 19:15:50 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 15 Sep 2020 19:15:50 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive Message-ID: This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses function. Tests: tier1-4 ------------- Commit messages: - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - Merge remote-tracking branch 'upstream/master' into jdk-8247536 - Merge remote-tracking branch 'upstream/master' into jdk-8247536 - Merge remote-tracking branch 'origin/jdk-8252689' - 8252689: Classes are loaded from jrt:/java.base even when CDS is used - 8252689: Classes are loaded from jrt:/java.base even when CDS is used - 8252689: Classes are loaded from jrt:/java.base even when CDS is used Changes: https://git.openjdk.java.net/jdk/pull/193/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247536 Stats: 368 lines in 18 files changed: 344 ins; 13 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From darcy at openjdk.java.net Tue Sep 15 20:10:42 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Sep 2020 20:10:42 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 13:45:40 GMT, Erik Helin wrote: >> make/scripts/generate-symbol-data.sh line 66: >> >>> 64: fi; >>> 65: >>> 66: if [ "`git status -s .`x" != "x" ] ; then >> >> Just a suggestion: perhaps you want to use the porcelain format here instead of short? >> https://git-scm.com/docs/git-status#Documentation/git-status.txt---porcelainltversiongt > > I agree with @adityamandaleeka, please use `git status --porcelain=v1`. See the git status > [documentation](https://git-scm.com/docs/git-status#_porcelain_format_version_1) for the specification for the output. @adityamandaleeka and @edvbld, thanks for the suggestion; I'll update the patch accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/161 From darcy at openjdk.java.net Tue Sep 15 20:21:07 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Sep 2020 20:21:07 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM [v2] In-Reply-To: References: Message-ID: > The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/161/files - new: https://git.openjdk.java.net/jdk/pull/161/files/2910def1..c577063c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=161&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=161&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/161/head:pull/161 PR: https://git.openjdk.java.net/jdk/pull/161 From adityam at openjdk.java.net Tue Sep 15 20:21:07 2020 From: adityam at openjdk.java.net (Aditya Mandaleeka) Date: Tue, 15 Sep 2020 20:21:07 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 20:18:31 GMT, Joe Darcy wrote: >> The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback Marked as reviewed by adityam (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/161 From darcy at openjdk.java.net Tue Sep 15 20:44:52 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Sep 2020 20:44:52 GMT Subject: Integrated: 8253034: Update symbol generation to accomodate Git as the SCM In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 23:41:52 GMT, Joe Darcy wrote: > The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. This pull request has now been integrated. Changeset: fc36328d Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/fc36328d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8253034: Update symbol generation to accomodate Git as the SCM Reviewed-by: erikj, adityam ------------- PR: https://git.openjdk.java.net/jdk/pull/161 From yumin.qi at oracle.com Tue Sep 15 20:45:24 2020 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 15 Sep 2020 13:45:24 -0700 Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive Message-ID: <503de1cc-5513-68ad-80a9-cc8e12d59abb@oracle.com> HI, all ? Please review changes for? 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive. ? What happened: ? I pushed with commit comment: ??? 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive ? When created pullrequest, the title is jdk 8247536, I did not pay attention to it, thought it will be filled correct. But it wasn't. The jcheck failed on checking the title, after I modified the title to correct form, there are no emails sent out, so I send here the link, please review via this link: ? https://github.com/openjdk/jdk/pull/193/files ? Thanks ? Yumin From kcr at openjdk.java.net Tue Sep 15 22:27:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Sep 2020 22:27:23 GMT Subject: RFR: 8253206: Enforce whitespace checking for additional source files Message-ID: This adds the following extensions to the list of source files that git jcheck will check for whitespace errors: .cc, .hh, .m, .mm All files with the above extensions are now white-space clean after the fix for [JDK-8240487](https://bugs.openjdk.java.net/browse/JDK-8240487). This will help them stay that way. I just integrated a similar fix to `jfx` (with a few more source extensions that aren't relevant for the JDK) in [JDK-8240499](https://bugs.openjdk.java.net/browse/JDK-8240499). ------------- Commit messages: - 8253206: Enforce whitespace checking for additional source files Changes: https://git.openjdk.java.net/jdk/pull/195/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=195&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253206 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/195.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/195/head:pull/195 PR: https://git.openjdk.java.net/jdk/pull/195 From mandy.chung at oracle.com Tue Sep 15 23:04:40 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Sep 2020 16:04:40 -0700 Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive In-Reply-To: References: Message-ID: <7047f476-0635-58f2-fc0f-163e69f56ac4@oracle.com> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java 367 /** 368 * called from vm to generate MethodHandle holder classes 369 * @return @code { Object[] } if holder classes can be generated. 370 * @param lines the output lines from @code { VM.cdsTraceResolve } 371 */ @code {....} is wrong syntax. It should be {@code ....} 372 static Object[] cdsGenerateHolderClasses(String[] lines) { this can be made private as it's invoked by VM only. Can you move it to the end of the file. 373 try { 374 Map result = generateHolderClasses(Arrays.stream(lines)); 375 if (result == null) { 376 return null; 377 } generateHolderClasses should never return null and so line 371-377 can be dropped. ? I also suggest to add in the generateHolderClasses method to add Objects.requireNonNull(traces). 379???????????? Object[] ret_array = new Object[size * 2]; Rename `ret_array` to retArray to follow the naming convention using camel case. src/java.base/share/classes/jdk/internal/misc/VM.java 457 isDumpLoadedClassListSetAndOpen = isDumpLoadedClassListSetAndOpen0(); This should be cached in the caller who checks if -XX:+DumpLoadedClassList instead of every VM initialization. Since there are many CDS-related methods, I think it's time to introduce a new CDS class for these methods to reside (maybe jdk.internal.vm.CDS?). I suggest to add CDS:logTraceResolve(String line) method that will check if isDumpLoadedClassListSetAndOpen is true, then call the native cdsTraceResolve (or whatever name). This way, GenerateJLIClassesHelper can simply call CDS::logTraceResolve. 493 * Output to DumpLoadedClassList, format is simimar to LF_RESOLVE s/simimar/similar 494 * @see InvokerBytecodeGenerator 495 * @param line the line to output. @see is typically placed after @param. Should it say @see java.lang.invoke.GenerateJLIClassesHelper::traceLambdaForm instead of InvokerBytecodeGenerator? Mandy On 9/15/20 12:15 PM, Yumin Qi wrote: > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. > > Tests: tier1-4 > > ------------- > > Commit messages: > - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive > - Merge remote-tracking branch 'upstream/master' into jdk-8247536 > - Merge remote-tracking branch 'upstream/master' into jdk-8247536 > - Merge remote-tracking branch 'origin/jdk-8252689' > - 8252689: Classes are loaded from jrt:/java.base even when CDS is used > - 8252689: Classes are loaded from jrt:/java.base even when CDS is used > - 8252689: Classes are loaded from jrt:/java.base even when CDS is used > > Changes: https://git.openjdk.java.net/jdk/pull/193/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8247536 > Stats: 368 lines in 18 files changed: 344 ins; 13 del; 11 mod > Patch: https://git.openjdk.java.net/jdk/pull/193.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 > > PR: https://git.openjdk.java.net/jdk/pull/193 From prr at openjdk.java.net Tue Sep 15 23:09:21 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 15 Sep 2020 23:09:21 GMT Subject: RFR: 8253206: Enforce whitespace checking for additional source files In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 22:18:09 GMT, Kevin Rushforth wrote: > This adds the following extensions to the list of source files that git jcheck will check for whitespace errors: > > .cc, .hh, .m, .mm > > All files with the above extensions are now white-space clean after the fix for > [JDK-8240487](https://bugs.openjdk.java.net/browse/JDK-8240487). This will help them stay that way. > I just integrated a similar fix to `jfx` (with a few more source extensions that aren't relevant for the JDK) in > [JDK-8240499](https://bugs.openjdk.java.net/browse/JDK-8240499). Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/195 From iignatyev at openjdk.java.net Wed Sep 16 00:27:17 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 16 Sep 2020 00:27:17 GMT Subject: RFR: 8253207: enable problemlists jcheck's check Message-ID: problemlists[[1]] check verifies that there are no problem-list entries w/ the bug-id used in the commit message. [1]: https://github.com/openjdk/skara/pull/518 ------------- Commit messages: - 8253207: enable problemlists jcheck's check Changes: https://git.openjdk.java.net/jdk/pull/196/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=196&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253207 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/196.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/196/head:pull/196 PR: https://git.openjdk.java.net/jdk/pull/196 From erikj at openjdk.java.net Wed Sep 16 13:09:32 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 16 Sep 2020 13:09:32 GMT Subject: RFR: 8253206: Enforce whitespace checking for additional source files In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 22:18:09 GMT, Kevin Rushforth wrote: > This adds the following extensions to the list of source files that git jcheck will check for whitespace errors: > > .cc, .hh, .m, .mm > > All files with the above extensions are now white-space clean after the fix for > [JDK-8240487](https://bugs.openjdk.java.net/browse/JDK-8240487). This will help them stay that way. > I just integrated a similar fix to `jfx` (with a few more source extensions that aren't relevant for the JDK) in > [JDK-8240499](https://bugs.openjdk.java.net/browse/JDK-8240499). Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/195 From erikj at openjdk.java.net Wed Sep 16 13:11:12 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 16 Sep 2020 13:11:12 GMT Subject: RFR: 8253207: enable problemlists jcheck's check In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 00:15:54 GMT, Igor Ignatyev wrote: > problemlists[[1]] check verifies that there are no problem-list entries w/ the bug-id used in the commit message. > > [1]: https://github.com/openjdk/skara/pull/518 Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/196 From jdv at openjdk.java.net Wed Sep 16 14:05:18 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Wed, 16 Sep 2020 14:05:18 GMT Subject: RFR: 8253206: Enforce whitespace checking for additional source files In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 22:18:09 GMT, Kevin Rushforth wrote: > This adds the following extensions to the list of source files that git jcheck will check for whitespace errors: > > .cc, .hh, .m, .mm > > All files with the above extensions are now white-space clean after the fix for > [JDK-8240487](https://bugs.openjdk.java.net/browse/JDK-8240487). This will help them stay that way. > I just integrated a similar fix to `jfx` (with a few more source extensions that aren't relevant for the JDK) in > [JDK-8240499](https://bugs.openjdk.java.net/browse/JDK-8240499). Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/195 From kcr at openjdk.java.net Wed Sep 16 14:05:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Sep 2020 14:05:18 GMT Subject: Integrated: 8253206: Enforce whitespace checking for additional source files In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 22:18:09 GMT, Kevin Rushforth wrote: > This adds the following extensions to the list of source files that git jcheck will check for whitespace errors: > > .cc, .hh, .m, .mm > > All files with the above extensions are now white-space clean after the fix for > [JDK-8240487](https://bugs.openjdk.java.net/browse/JDK-8240487). This will help them stay that way. > I just integrated a similar fix to `jfx` (with a few more source extensions that aren't relevant for the JDK) in > [JDK-8240499](https://bugs.openjdk.java.net/browse/JDK-8240499). This pull request has now been integrated. Changeset: 10867134 Author: Kevin Rushforth Committer: Jayathirth D V URL: https://git.openjdk.java.net/jdk/commit/10867134 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8253206: Enforce whitespace checking for additional source files Reviewed-by: prr, erikj, jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/195 From github.com+53073448+junyzheng at openjdk.java.net Wed Sep 16 17:08:35 2020 From: github.com+53073448+junyzheng at openjdk.java.net (Junyuan Zheng) Date: Wed, 16 Sep 2020 17:08:35 GMT Subject: RFR: 8253253: Binutils tar ball extension update to gz Message-ID: Our infra team found this error when building DevKit with GCC 4.9.2. The binutils version is 2.25, and an *.xz doesn't exist on https://ftp.gnu.org/pub/gnu/binutils. Hence, we would like to submit a PR to update *.xz to *.gz. We have confirmed that *.gz exists for all binutil version. ------------- Commit messages: - Fix linux GCC 4.9.2 devkit binutils url error Changes: https://git.openjdk.java.net/jdk/pull/162/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=162&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253253 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/162.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/162/head:pull/162 PR: https://git.openjdk.java.net/jdk/pull/162 From erikj at openjdk.java.net Wed Sep 16 17:22:44 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 16 Sep 2020 17:22:44 GMT Subject: RFR: 8253253: Binutils tar ball extension update to gz In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 04:54:04 GMT, Junyuan Zheng wrote: > Our infra team found this error when building DevKit with GCC 4.9.2. The binutils version is 2.25, and an *.xz doesn't > exist on https://ftp.gnu.org/pub/gnu/binutils. Hence, we would like to submit a PR to update *.xz to *.gz. > We have confirmed that *.gz exists for all binutil version. Marked as reviewed by erikj (Reviewer). The change is ok, but why would you need such an old devkit? We build with gcc 9.2 and are in the process of upgrading to 10.2. We have been lax with removing old configs for devkit generation. ------------- PR: https://git.openjdk.java.net/jdk/pull/162 From iignatyev at openjdk.java.net Wed Sep 16 17:23:39 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 16 Sep 2020 17:23:39 GMT Subject: RFR: 8253207: enable problemlists jcheck's check In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 13:08:17 GMT, Erik Joelsson wrote: >> problemlists[[1]] check verifies that there are no problem-list entries w/ the bug-id used in the commit message. >> >> [1]: https://github.com/openjdk/skara/pull/518 > > Marked as reviewed by erikj (Reviewer). thanks for your review, Erik. ------------- PR: https://git.openjdk.java.net/jdk/pull/196 From iignatyev at openjdk.java.net Wed Sep 16 17:23:40 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 16 Sep 2020 17:23:40 GMT Subject: Integrated: 8253207: enable problemlists jcheck's check In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 00:15:54 GMT, Igor Ignatyev wrote: > problemlists[[1]] check verifies that there are no problem-list entries w/ the bug-id used in the commit message. > > [1]: https://github.com/openjdk/skara/pull/518 This pull request has now been integrated. Changeset: d38c97dd Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/d38c97dd Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod 8253207: enable problemlists jcheck's check Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/196 From github.com+53073448+junyzheng at openjdk.java.net Wed Sep 16 17:35:22 2020 From: github.com+53073448+junyzheng at openjdk.java.net (Junyuan Zheng) Date: Wed, 16 Sep 2020 17:35:22 GMT Subject: RFR: 8253253: Binutils tar ball extension update to gz In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 17:20:18 GMT, Erik Joelsson wrote: >> Our infra team found this error when building DevKit with GCC 4.9.2. The binutils version is 2.25, and an *.xz doesn't >> exist on https://ftp.gnu.org/pub/gnu/binutils. Hence, we would like to submit a PR to update *.xz to *.gz. >> We have confirmed that *.gz exists for all binutil version. > > Marked as reviewed by erikj (Reviewer). We only use the GCC 4.9.2 for jdk8u. The openjdk/jdk repository's devkit contains all devkits that support older jdk. So we can just use this file to build all the devkits instead of pulling devkits from jdk8u and jdk11u. I also notice newer code always contains devkit from older code. jdk contains (gcc 9, 7, 8 4), jdk11u contains (gcc 7, 4), and jdk8u contains (gcc 4). But I will abandon this PR and change our workflow if outdated devkit will be eventually removed from openjdk/jdk repository. ------------- PR: https://git.openjdk.java.net/jdk/pull/162 From erikj at openjdk.java.net Wed Sep 16 17:53:49 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 16 Sep 2020 17:53:49 GMT Subject: RFR: 8253253: Binutils tar ball extension update to gz In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 17:32:22 GMT, Junyuan Zheng wrote: >> Marked as reviewed by erikj (Reviewer). > > We only use the GCC 4.9.2 for jdk8u. The openjdk/jdk repository's devkit contains all devkits that support older jdk. > So we can just use this file to build all the devkits instead of pulling devkits from jdk8u and jdk11u. I also notice > newer code always contains devkit from older code. jdk contains (gcc 9, 7, 8 4), jdk11u contains (gcc 7, 4), and jdk8u > contains (gcc 4). But I will abandon this PR and change our workflow if outdated devkit will be eventually removed from > openjdk/jdk repository. Ah, I see. I would say that the intention is not to keep the latest mainline devkit generation scripts updated to support all older update releases, but I can see how it could look that way given how we have so far not really deleted older configs. ------------- PR: https://git.openjdk.java.net/jdk/pull/162 From iklam at openjdk.java.net Wed Sep 16 19:08:27 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 16 Sep 2020 19:08:27 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 18:57:55 GMT, Yumin Qi wrote: > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Changes requested by iklam (Reviewer). src/hotspot/share/classfile/lambdaFormInvokers.cpp line 51: > 49: #include "runtime/os.hpp" > 50: #include "runtime/signature.hpp" > 51: Are all these header files needed? E.g., typeArrayKlass.hpp doesn't seem to be needed. src/hotspot/share/classfile/lambdaFormInvokers.cpp line 121: > 119: log_info(cds)("Class %s not present, skip", name); > 120: return; > 121: } Since the classlist can be generated by the user, it may cause the assert at line 115 to fail. For example, no java.lang.invoke.*$Holder classes are used by HelloWorld: $ java -verbose -Xshare:off -cp . HelloWorld | grep Holder [0.030s][info][class,load] java.util.KeyValueHolder source: jrt:/java.base [0.080s][info][class,load] java.security.SecureClassLoader$DebugHolder source: jrt:/java.base $ But it's possible for the user to generate a classlist using HelloWorld, and then manually add LF_RESOLVE lines into the classlist. So I think line 114 should be changed to a regular lookup (the symbol is created if it doesn't exist), and line 115 should be removed. Also, we should add some test cases for invalid LF_RESOLVE input. You can see examples in [appcds/customLoader/ClassListFormatA.java](https://github.com/openjdk/jdk/blob/d250f9e08c4a0c047cd3e619918c116f568e31d4/test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatA.java#L51). Since the new tests aren't related to custom loader, we should probably move [appcds/customLoader/ClassListFormatBase.java](https://github.com/openjdk/jdk/blob/d250f9e08c4a0c047cd3e619918c116f568e31d4/test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatBase.java#L30) under appcds/, and add a new file like appcds/ClassListFormat.java src/hotspot/share/classfile/lambdaFormInvokers.cpp line 158: > 156: // find_class assert on SystemDictionary_lock or safepoint > 157: MutexLocker lock(SystemDictionary_lock); > 158: InstanceKlass* old = SystemDictionary::find_class(class_name, cld); There's no need to call `find_class` here, since it will return the same class as `klass` on line 117. src/hotspot/share/classfile/lambdaFormInvokers.hpp line 27: > 25: #ifndef SHARE_MEMORY_LAMBDAFORMINVOKERS_HPP > 26: #define SHARE_MEMORY_LAMBDAFORMINVOKERS_HPP > 27: #include "memory/allocation.hpp" For the AllStatic base class, you should use memory/allStatic.hpp instead. src/hotspot/share/classfile/systemDictionary.cpp line 1875: > 1873: VerifyDuringStartup || > 1874: VerifyAfterGC || > 1875: DumpSharedSpaces, "too expensive"); This may not be needed if you remove the find_class() call from LambdaFormInvokers::regenerate_holder_classes? src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 67: > 65: if (VM.isDumpLoadedClassListSetAndOpen) { > 66: VM.cdsTraceResolve(traceLF); > 67: } GenerateJLIClassesHelper shouldn't need to know why the trace is needed. Also, "cdsTraceResolve" is too generic. I think it's better to have if (TRACE_RESOLVE || VM.CDS_TRACE_JLINV_RESOLVE) { ... VM.cdsTraceJLINVResolve(traceLF); The acronym JLINV is used in [methodHandles.cpp](https://github.com/openjdk/jdk/blob/ce93cbce77e1f4baa52676826c8ae27d474360b6/src/hotspot/share/prims/methodHandles.cpp#L1524) src/java.base/share/classes/jdk/internal/misc/VM.java line 490: > 488: */ > 489: public static boolean isDumpLoadedClassListSetAndOpen; > 490: private static native boolean isDumpLoadedClassListSetAndOpen0(); I would suggest to rename to `isDumpingLoadedClassList` ------------- PR: https://git.openjdk.java.net/jdk/pull/193 From minqi at openjdk.java.net Thu Sep 17 01:16:45 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 17 Sep 2020 01:16:45 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 19:05:56 GMT, Ioi Lam wrote: >> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous >> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the >> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses >> function. Tests: tier1-4 > > Changes requested by iklam (Reviewer). > _Mailing list message from [Mandy Chung](mailto:mandy.chung at oracle.com) on > [build-dev](mailto:build-dev at openjdk.java.net):_ > src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java > 367 /** 368 * called from vm to generate MethodHandle holder classes 369 > * @return @code { Object[] } if holder classes can be generated. 370 * > @param lines the output lines from @code { VM.cdsTraceResolve } 371 */ > @code {....} is wrong syntax. It should be {@code ....} 372 static > Object[] cdsGenerateHolderClasses(String[] lines) { this can be made > private as it's invoked by VM only. Can you move it to the end of the Will change access to 'private' > file. 373 try { 374 Map result = > generateHolderClasses(Arrays.stream(lines)); 375 if (result == null) { > 376 return null; 377 } > > generateHolderClasses should never return null and so line 371-377 can > be dropped. ? I also suggest to add in the generateHolderClasses method > to add Objects.requireNonNull(traces). > Will drop the check and add Objects.requireNonNull(traces). > 379???????????? Object[] ret_array = new Object[size * 2]; > > Rename `ret_array` to retArray to follow the naming convention using camel case. > > src/java.base/share/classes/jdk/internal/misc/VM.java > 457 isDumpLoadedClassListSetAndOpen = isDumpLoadedClassListSetAndOpen0(); > > This should be cached in the caller who checks if -XX:+DumpLoadedClassList > instead of every VM initialization. > > Since there are many CDS-related methods, I think it's time to introduce > a new CDS class for these methods to reside (maybe jdk.internal.vm.CDS?). > > I suggest to add CDS:logTraceResolve(String line) method that > will check if isDumpLoadedClassListSetAndOpen is true, then call the > native cdsTraceResolve (or whatever name). This way, > GenerateJLIClassesHelper can simply call CDS::logTraceResolve. > Created a separate issue https://bugs.openjdk.java.net/browse/JDK-8253208 to move CDS method to CDS.java All CDS related code will be added to CDS.java > 493 * Output to DumpLoadedClassList, format is simimar to LF_RESOLVE > > s/simimar/similar > > 494 * @see InvokerBytecodeGenerator > 495 * @param line the line to output. > > @see is typically placed after @param. > > Should it say @see java.lang.invoke.GenerateJLIClassesHelper::traceLambdaForm > instead of InvokerBytecodeGenerator? > Right, will change that to the suggestion. > Mandy > > On 9/15/20 12:15 PM, Yumin Qi wrote: ------------- PR: https://git.openjdk.java.net/jdk/pull/193 From github.com+53073448+junyzheng at openjdk.java.net Thu Sep 17 18:00:19 2020 From: github.com+53073448+junyzheng at openjdk.java.net (Junyuan Zheng) Date: Thu, 17 Sep 2020 18:00:19 GMT Subject: RFR: 8253253: Binutils tar ball extension update to gz In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 17:50:41 GMT, Erik Joelsson wrote: >> We only use the GCC 4.9.2 for jdk8u. The openjdk/jdk repository's devkit contains all devkits that support older jdk. >> So we can just use this file to build all the devkits instead of pulling devkits from jdk8u and jdk11u. I also notice >> newer code always contains devkit from older code. jdk contains (gcc 9, 7, 8 4), jdk11u contains (gcc 7, 4), and jdk8u >> contains (gcc 4). But I will abandon this PR and change our workflow if outdated devkit will be eventually removed from >> openjdk/jdk repository. > > Ah, I see. I would say that the intention is not to keep the latest mainline devkit generation scripts updated to > support all older update releases, but I can see how it could look that way given how we have so far not really deleted > older configs. I will check in this code just in case people are going to use this script to generate GCC 4.9.2 devkit. ------------- PR: https://git.openjdk.java.net/jdk/pull/162 From smarks at openjdk.java.net Fri Sep 18 02:50:45 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 18 Sep 2020 02:50:45 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 15:17:58 GMT, Bradford Wetmore wrote: >> Ok, sorry for the distraction. > > Our local Santuario maintainer says: > > In general, changes to Apache Santuario should also be made at Apache so we stay in sync. Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made earlier in this PR, > I have in mind dozens of improvements all over the code like this one. It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... so we don't want to update this code even though it's IN the JDK. Those kind of constraints generally don't apply to code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is definitely the case for tools like javac, but I think it might also apply to some things in base.) Anyway, if you'd like to pursue some of these improvements, drop a note to core-libs-dev at openjdk and we can talk about it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From gnu.andrew at redhat.com Fri Sep 18 05:40:22 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 18 Sep 2020 06:40:22 +0100 Subject: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal In-Reply-To: References: Message-ID: <20200918054022.GA353844@stopbrexit> On 20:16 Wed 09 Sep , Severin Gehwolf wrote: > Hi, > > Please review this 8u (jdk8u/jdk8u-dev tree) fix for JDK-8252395 that > I've pushed today. Thanks for Zhengyu Gu for noticing it. The pushed > fix added the java.debuginfo and unpack.debuginfo make targets on the > condition of ENABLE_DEBUG_SYMBOLS=true, which is insufficient. It needs > another check on POST_STRIP_CMD which is set to non-empty for --with- > native-debug-symbols={external,zipped}, and is indeed empty for --with- > native-debug-symbols=internal. For the --with-native-debug-symbols=none > case we have ENABLE_DEBUG_SYMBOLS=false. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252975 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252975/01/webrev/ > > Testing: Builds with --with-native-debug-symbols={none,internal,external,zipped} on Linux x86_64 > > OK? > > Thanks, > Severin > Build is still broken for me with this patch: /usr/bin/cp /home/ahughes/builder/8u-dev/jdk/objs/java_objs/java.diz /home/ahughes/builder/8u-dev/jdk/bin/java.diz /usr/bin/cp: cannot stat '/home/ahughes/builder/8u-dev/jdk/objs/java_objs/java.diz': No such file or directory where --with-native-debug-symbols is not set (pre-JDK-8207324) The use of these two conditionals seems odd to me. What we want to know is whether zipped debuginfo is in use. This is not the same as debug symbols in general being enabled. Also, DEBUGINFO_EXT is only being set when ZIP_DEBUGINFO_FILES is true! POST_STRIP_CMD seems to only be used in image creation, so I don't think checking this is appropriate either. Instead, we should mirror what is done in make/common/NativeCompilation.gmk when creating the .diz files: -ifeq ($(ENABLE_DEBUG_SYMBOLS), true) - ifneq ($(POST_STRIP_CMD), ) +ifeq ($(ZIP_DEBUGINFO_FILES), true) + ifneq ($(STRIP_POLICY), no_strip) The second check is necessary because ZIP_DEBUGINFO_FILES is set by default, and so may be true even if STRIP_POLICY has been set to no_strip. The attached patch fixed the build for me. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 -------------- next part -------------- diff --git a/make/CompileLaunchers.gmk b/make/CompileLaunchers.gmk --- a/make/CompileLaunchers.gmk +++ b/make/CompileLaunchers.gmk @@ -247,8 +247,8 @@ $(CP) $(JDK_OUTPUTDIR)/objs/java_objs$(OUTPUT_SUBDIR)/java$(DEBUGINFO_EXT) $@ BUILD_LAUNCHERS += $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/java$(EXE_SUFFIX) -ifeq ($(ENABLE_DEBUG_SYMBOLS), true) - ifneq ($(POST_STRIP_CMD), ) +ifeq ($(ZIP_DEBUGINFO_FILES), true) + ifneq ($(STRIP_POLICY), no_strip) BUILD_LAUNCHERS += $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/java$(DEBUGINFO_EXT) endif endif @@ -557,8 +557,8 @@ $(call install-file) BUILD_LAUNCHERS += $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/unpack200$(EXE_SUFFIX) -ifeq ($(ENABLE_DEBUG_SYMBOLS), true) - ifneq ($(POST_STRIP_CMD), ) +ifeq ($(ZIP_DEBUGINFO_FILES), true) + ifneq ($(STRIP_POLICY), no_strip) BUILD_LAUNCHERS += $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/unpack200$(DEBUGINFO_EXT) endif endif From mbaesken at openjdk.java.net Fri Sep 18 08:29:22 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 18 Sep 2020 08:29:22 GMT Subject: RFR: JDK-8253239: Disable VS warning C4307 Message-ID: hello, this fixes the build when using VS2017. VS2019 does not have the issue as far as I know. failure was > ./test/hotspot/gtest/utilities/test_align.cpp(96): error C2220: warning treated as error - no 'object' file generated > ./test/hotspot/gtest/utilities/test_align.cpp(156): note: see reference to function template instantiation 'void > static_test_alignments(void)' being compiled with > [ > T=int64_t, > A=uint8_t > ] > ./test/hotspot/gtest/utilities/test_align.cpp(162): note: see reference to function template instantiation 'void > test_alignments(void)' being compiled ./test/hotspot/gtest/utilities/test_align.cpp(96): warning > C4307: '+': integral constant overflow > > This might be related to an issue fixed at least in some versions of VS2019 , that is discussed here : https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html https://bugs.openjdk.java.net/browse/JDK-8253239 ------------- Commit messages: - JDK-8253239 Changes: https://git.openjdk.java.net/jdk/pull/237/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=237&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253239 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/237.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/237/head:pull/237 PR: https://git.openjdk.java.net/jdk/pull/237 From shade at openjdk.java.net Fri Sep 18 09:02:05 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 09:02:05 GMT Subject: RFR: JDK-8253239: Disable VS warning C4307 In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 08:22:56 GMT, Matthias Baesken wrote: > hello, this fixes the build when using VS2017. VS2019 does not have the issue as far as I know. > failure was > >> ./test/hotspot/gtest/utilities/test_align.cpp(96): error C2220: warning treated as error - no 'object' file generated >> ./test/hotspot/gtest/utilities/test_align.cpp(156): note: see reference to function template instantiation 'void >> static_test_alignments(void)' being compiled with >> [ >> T=int64_t, >> A=uint8_t >> ] >> ./test/hotspot/gtest/utilities/test_align.cpp(162): note: see reference to function template instantiation 'void >> test_alignments(void)' being compiled ./test/hotspot/gtest/utilities/test_align.cpp(96): warning >> C4307: '+': integral constant overflow >> >> > > This might be related to an issue fixed at least in some versions of VS2019 , that is discussed here : > > https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html > > https://bugs.openjdk.java.net/browse/JDK-8253239 make/autoconf/flags-cflags.m4 line 138: > 136: DISABLED_WARNINGS="4800" > 137: if test "x$TOOLCHAIN_VERSION" = x2017; then > 138: DISABLED_WARNINGS+=" 4307" Seems like this file uses 2 spaces as indenting, 4 spaces are used here. ------------- PR: https://git.openjdk.java.net/jdk/pull/237 From sgehwolf at redhat.com Fri Sep 18 09:22:10 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 18 Sep 2020 11:22:10 +0200 Subject: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal In-Reply-To: <20200918054022.GA353844@stopbrexit> References: <20200918054022.GA353844@stopbrexit> Message-ID: Hi Andrew, On Fri, 2020-09-18 at 06:40 +0100, Andrew Hughes wrote: > On 20:16 Wed 09 Sep , Severin Gehwolf wrote: > > Hi, > > > > Please review this 8u (jdk8u/jdk8u-dev tree) fix for JDK-8252395 that > > I've pushed today. Thanks for Zhengyu Gu for noticing it. The pushed > > fix added the java.debuginfo and unpack.debuginfo make targets on the > > condition of ENABLE_DEBUG_SYMBOLS=true, which is insufficient. It needs > > another check on POST_STRIP_CMD which is set to non-empty for --with- > > native-debug-symbols={external,zipped}, and is indeed empty for --with- > > native-debug-symbols=internal. For the --with-native-debug-symbols=none > > case we have ENABLE_DEBUG_SYMBOLS=false. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252975 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252975/01/webrev/ > > > > Testing: Builds with --with-native-debug-symbols={none,internal,external,zipped} on Linux x86_64 > > > > OK? > > > > Thanks, > > Severin > > > > Build is still broken for me with this patch: > > /usr/bin/cp /home/ahughes/builder/8u-dev/jdk/objs/java_objs/java.diz /home/ahughes/builder/8u-dev/jdk/bin/java.diz > /usr/bin/cp: cannot stat '/home/ahughes/builder/8u-dev/jdk/objs/java_objs/java.diz': No such file or directory > > where --with-native-debug-symbols is not set (pre-JDK-8207324) Hmm, I'm not sure how you are building. I've checked builds with: $ bash configure \ --with-boot-jdk="/some/boot/jdk" \ --with-extra-cflags=-Wno-error \ --disable-zip-debug-info $ make images and $ bash configure \ --with-boot-jdk="/some/boot/jdk" \ --with-extra-cflags=-Wno-error $ make images and $ bash configure \ --with-boot-jdk="/some/boot/jdk" \ --with-extra-cflags=-Wno-error \ --disable-debug-symbols $ make images All seem to work fine for me. Are you sure you are not setting POST_STRIP_CMD or the like explicitly somewhere else. Please post the exact configure/make invocations you are using. FWIW, that bug you've referenced seems wrong: 8207324: aarch64 jtreg: assert in TestOptionsWithRanges.jtr You probably meant JDK-8036003: 8036003: Add --with-native-debug-symbols=[none|internal|external|zipped] > The use of these two conditionals seems odd to me. What we want to know > is whether zipped debuginfo is in use. No. We want to know whether or not external debug symbols (zipped or otherwise) are in use. > This is not the same as debug symbols > in general being enabled. Yes. Correctly so. > Also, DEBUGINFO_EXT is only being set when > ZIP_DEBUGINFO_FILES is true! How so? ifeq ($(ZIP_DEBUGINFO_FILES), true) DEBUGINFO_EXT := .diz else ifeq ($(OPENJDK_TARGET_OS), macosx) DEBUGINFO_EXT := .dSYM else ifeq ($(OPENJDK_TARGET_OS), windows) DEBUGINFO_EXT := .pdb else DEBUGINFO_EXT := .debuginfo endif On Linux with --with-native-debug-symbols=external this ends up with: DEBUGINFO_EXT := .debuginfo > POST_STRIP_CMD seems to only be used in image creation, so I don't > think checking this is appropriate either. Seems debatable. > Instead, we should mirror what is done in make/common/NativeCompilation.gmk when > creating the .diz files: > > -ifeq ($(ENABLE_DEBUG_SYMBOLS), true) > - ifneq ($(POST_STRIP_CMD), ) > +ifeq ($(ZIP_DEBUGINFO_FILES), true) > + ifneq ($(STRIP_POLICY), no_strip) > > The second check is necessary because ZIP_DEBUGINFO_FILES is set by default, > and so may be true even if STRIP_POLICY has been set to no_strip. Your patch won't work for --with-native-debug-symbols=external. In that case no *.debuginfo files for the java and unpack200 launchers would be created. With your patch: $ find build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/ | grep -E 'java\.debuginfo|unpack200\.debuginfo' Expected: $ find build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/ | grep -E 'java\.debuginfo|unpack200\.debuginfo' build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java.debuginfo build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/unpack200.debuginfo > The attached patch fixed the build for me. Sorry, I don't seem to be able to reproduce your build failure. Thanks, Severin From mbaesken at openjdk.java.net Fri Sep 18 10:05:10 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 18 Sep 2020 10:05:10 GMT Subject: RFR: JDK-8253239: Disable VS warning C4307 [v2] In-Reply-To: References: Message-ID: > hello, this fixes the build when using VS2017. VS2019 does not have the issue as far as I know. > failure was > >> ./test/hotspot/gtest/utilities/test_align.cpp(96): error C2220: warning treated as error - no 'object' file generated >> ./test/hotspot/gtest/utilities/test_align.cpp(156): note: see reference to function template instantiation 'void >> static_test_alignments(void)' being compiled with >> [ >> T=int64_t, >> A=uint8_t >> ] >> ./test/hotspot/gtest/utilities/test_align.cpp(162): note: see reference to function template instantiation 'void >> test_alignments(void)' being compiled ./test/hotspot/gtest/utilities/test_align.cpp(96): warning >> C4307: '+': integral constant overflow >> >> > > This might be related to an issue fixed at least in some versions of VS2019 , that is discussed here : > > https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html > > https://bugs.openjdk.java.net/browse/JDK-8253239 Matthias Baesken 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: JDK-8253239 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/237/files - new: https://git.openjdk.java.net/jdk/pull/237/files/0d1d38b3..4e82edcb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=237&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=237&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/237.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/237/head:pull/237 PR: https://git.openjdk.java.net/jdk/pull/237 From shade at openjdk.java.net Fri Sep 18 10:05:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 10:05:10 GMT Subject: RFR: JDK-8253239: Disable VS warning C4307 [v2] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 10:00:55 GMT, Matthias Baesken wrote: >> hello, this fixes the build when using VS2017. VS2019 does not have the issue as far as I know. >> failure was >> >>> ./test/hotspot/gtest/utilities/test_align.cpp(96): error C2220: warning treated as error - no 'object' file generated >>> ./test/hotspot/gtest/utilities/test_align.cpp(156): note: see reference to function template instantiation 'void >>> static_test_alignments(void)' being compiled with >>> [ >>> T=int64_t, >>> A=uint8_t >>> ] >>> ./test/hotspot/gtest/utilities/test_align.cpp(162): note: see reference to function template instantiation 'void >>> test_alignments(void)' being compiled ./test/hotspot/gtest/utilities/test_align.cpp(96): warning >>> C4307: '+': integral constant overflow >>> >>> >> >> This might be related to an issue fixed at least in some versions of VS2019 , that is discussed here : >> >> https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html >> >> https://bugs.openjdk.java.net/browse/JDK-8253239 > > Matthias Baesken 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: > JDK-8253239 This looks fine to me, but build maintainers should approve. ------------- PR: https://git.openjdk.java.net/jdk/pull/237 From mbaesken at openjdk.java.net Fri Sep 18 10:05:11 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 18 Sep 2020 10:05:11 GMT Subject: RFR: JDK-8253239: Disable VS warning C4307 [v2] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 08:57:36 GMT, Aleksey Shipilev wrote: >> Matthias Baesken 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: >> JDK-8253239 > > make/autoconf/flags-cflags.m4 line 138: > >> 136: DISABLED_WARNINGS="4800" >> 137: if test "x$TOOLCHAIN_VERSION" = x2017; then >> 138: DISABLED_WARNINGS+=" 4307" > > Seems like this file uses 2 spaces as indenting, 4 spaces are used here. You Are right, I adjusted the indenting to 2 sapces and did a git commit --amend and repushed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/237 From mbeckwit at openjdk.java.net Fri Sep 18 10:14:22 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Fri, 18 Sep 2020 10:14:22 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support Message-ID: This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html Changes since then: * We've improved the write barrier as suggested by Andrew [1] * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but will be required for the upcoming macOS+Aarch64 [2] port as well. * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the Windows-specific CPU feature detection on top of it. [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html [2] https://openjdk.java.net/jeps/8251280 ------------- Commit messages: - 8248787: G1: Workaround MSVC bug - 8248670: Windows: Exception handling support on AArch64 - 8248660: AArch64: Make _clear_cache and _nop portable - 8248659: AArch64: Extend CPU Feature detection - 8248656: Add Windows AArch64 platform support code - 8248498: Add build system support for Windows AArch64 - 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ - 8248663: AArch64: Avoid existing macros/keywords of MSVC - 8248676: AArch64: Add workaround for LITable constructor - 8248500: AArch64: Remove the r18 dependency on Windows AArch64 (regenerate tests) - ... and 3 more: https://git.openjdk.java.net/jdk/compare/68da63dc...26e4af3a Changes: https://git.openjdk.java.net/jdk/pull/212/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248238 Stats: 4230 lines in 69 files changed: 2406 ins; 273 del; 1551 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From avoitylov at openjdk.java.net Fri Sep 18 10:59:21 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 18 Sep 2020 10:59:21 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com> References: <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com> Message-ID: On Mon, 14 Sep 2020 06:30:50 GMT, Aleksei Voitylov wrote: >> Marked as reviewed by dholmes (Reviewer). > > thank you Alan, Erik, and David! When the JEP becomes Targeted, I'll use this PR to integrate the changes. I added the contributors that could be found in the portola project commits. If anyone knows some other contributors I missed, I'll be happy to stand corrected. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 18 11:07:46 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 18 Sep 2020 11:07:46 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: <668fR1wEZWaC0TDCyRIeOZ4AddXZXnKQhyHQdXtOab8=.6cb419cb-632b-4524-980e-18a6e06958e8@github.com> On Fri, 18 Sep 2020 02:48:15 GMT, Stuart Marks wrote: >> Our local Santuario maintainer says: >> >> In general, changes to Apache Santuario should also be made at Apache so we stay in sync. > > Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made > earlier in this PR, >> I have in mind dozens of improvements all over the code like this one. > > It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and > sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source > bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... > so we don't want to update this code even though it's IN the JDK. Those kind of constraints generally don't apply to > code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything > outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and > sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. > There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some > code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is > definitely the case for tools like javac, but I think it might also apply to some things in base.) Anyway, if you'd > like to pursue some of these improvements, drop a note to core-libs-dev at openjdk and we can talk about it. Thanks. @stuart-marks thanks. Sure, I understand that maintaining OpenJDK is not a simple task. I thought as change is super simple without any side effects it can go through. But I was wrong. That's fine. I'll focus on `java.base` when I have some free time. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From afarley at openjdk.java.net Fri Sep 18 11:44:30 2020 From: afarley at openjdk.java.net (Adam Farley) Date: Fri, 18 Sep 2020 11:44:30 GMT Subject: RFR: 8253000: Remove redundant MAKE_SUBDIR argument Message-ID: <9Gb2JqpxNcge35zEW2bPIxiRvI5xcgCR9kYn7MIbjyg=.585c314b-a824-431e-ab45-767c4f3ef0b7@github.com> As part of JDK-8244044, MAKE_SUBDIR is no longer used in DeclareRecipesForPhase inside MakeSupport.gmk. Therefore, it seems sensible to modify the instances where this is passed to DeclareRecipesForPhase, and to remove references to it from the associated MakeSupport.gmk comment. Bug: https://bugs.openjdk.java.net/browse/JDK-8253000 ------------- Commit messages: - 8253000: Remove redundant MAKE_SUBDIR argument Changes: https://git.openjdk.java.net/jdk/pull/249/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=249&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253000 Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/249.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/249/head:pull/249 PR: https://git.openjdk.java.net/jdk/pull/249 From afarley at openjdk.java.net Fri Sep 18 12:15:07 2020 From: afarley at openjdk.java.net (Adam Farley) Date: Fri, 18 Sep 2020 12:15:07 GMT Subject: RFR: 8252998: ModuleWrapper.gmk doesn't consult include path Message-ID: A change made to ModuleWrapper.gmk as part of JDK-8244044 means that an included makefile is found in the current directory, so Make doesn't check the include dirs for overriding gmk files. Recommend a minor, partial reversion of this changeset to ensure any override files are included instead. Bug: https://bugs.openjdk.java.net/browse/JDK-8252998 ------------- Commit messages: - 8252998: ModuleWrapper.gmk doesn't consult include path Changes: https://git.openjdk.java.net/jdk/pull/250/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=250&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252998 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/250.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/250/head:pull/250 PR: https://git.openjdk.java.net/jdk/pull/250 From erikj at openjdk.java.net Fri Sep 18 12:45:22 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 12:45:22 GMT Subject: RFR: 8253000: Remove redundant MAKE_SUBDIR argument In-Reply-To: <9Gb2JqpxNcge35zEW2bPIxiRvI5xcgCR9kYn7MIbjyg=.585c314b-a824-431e-ab45-767c4f3ef0b7@github.com> References: <9Gb2JqpxNcge35zEW2bPIxiRvI5xcgCR9kYn7MIbjyg=.585c314b-a824-431e-ab45-767c4f3ef0b7@github.com> Message-ID: On Fri, 18 Sep 2020 11:37:06 GMT, Adam Farley wrote: > As part of JDK-8244044, MAKE_SUBDIR is no longer used in DeclareRecipesForPhase inside MakeSupport.gmk. > > Therefore, it seems sensible to modify the instances where this is passed to DeclareRecipesForPhase, and to remove > references to it from the associated MakeSupport.gmk comment. > Bug: https://bugs.openjdk.java.net/browse/JDK-8253000 Looks good, thanks for cleaning this up! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/249 From erikj at openjdk.java.net Fri Sep 18 12:46:55 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 12:46:55 GMT Subject: RFR: 8252998: ModuleWrapper.gmk doesn't consult include path In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 12:07:45 GMT, Adam Farley wrote: > A change made to ModuleWrapper.gmk as part of JDK-8244044 means that an included makefile is found in the current > directory, so Make doesn't check the include dirs for overriding gmk files. > Recommend a minor, partial reversion of this changeset to ensure any override files are included instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252998 Looks good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/250 From erikj at openjdk.java.net Fri Sep 18 13:02:18 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 13:02:18 GMT Subject: RFR: JDK-8253239: Disable VS warning C4307 [v2] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 10:00:55 GMT, Aleksey Shipilev wrote: >> Matthias Baesken 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: >> JDK-8253239 > > This looks fine to me, but build maintainers should approve. I left a suggestion for a comment. You should be able to just accept it if you are happy with it. If you would rather write something yourself, I recommend committing without --amend. The Skara bot will automatically squash all your changes before merging this to the main repo. ------------- PR: https://git.openjdk.java.net/jdk/pull/237 From erikj at openjdk.java.net Fri Sep 18 13:02:19 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 13:02:19 GMT Subject: RFR: JDK-8253239: Disable VS warning C4307 [v2] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 10:05:10 GMT, Matthias Baesken wrote: >> hello, this fixes the build when using VS2017. VS2019 does not have the issue as far as I know. >> failure was >> >>> ./test/hotspot/gtest/utilities/test_align.cpp(96): error C2220: warning treated as error - no 'object' file generated >>> ./test/hotspot/gtest/utilities/test_align.cpp(156): note: see reference to function template instantiation 'void >>> static_test_alignments(void)' being compiled with >>> [ >>> T=int64_t, >>> A=uint8_t >>> ] >>> ./test/hotspot/gtest/utilities/test_align.cpp(162): note: see reference to function template instantiation 'void >>> test_alignments(void)' being compiled ./test/hotspot/gtest/utilities/test_align.cpp(96): warning >>> C4307: '+': integral constant overflow >>> >>> >> >> This might be related to an issue fixed at least in some versions of VS2019 , that is discussed here : >> >> https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html >> >> https://bugs.openjdk.java.net/browse/JDK-8253239 > > Matthias Baesken 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: > JDK-8253239 make/autoconf/flags-cflags.m4 line 137: > 135: WARNINGS_ENABLE_ALL="-W3" > 136: DISABLED_WARNINGS="4800" > 137: if test "x$TOOLCHAIN_VERSION" = x2017; then I would like a comment here explaining why we need to disable this warning, since it's caused by a faulty behavior in the compiler. make/autoconf/flags-cflags.m4 line 138: > 136: DISABLED_WARNINGS="4800" > 137: if test "x$TOOLCHAIN_VERSION" = x2017; then > 138: DISABLED_WARNINGS+=" 4307" Suggestion: # VS2017 incorrectly triggers this warning for constexpr DISABLED_WARNINGS+=" 4307" ------------- PR: https://git.openjdk.java.net/jdk/pull/237 From erikj at openjdk.java.net Fri Sep 18 13:35:34 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 13:35:34 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith wrote: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Build changes look good to me. I will take this branch for a spin. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From mbaesken at openjdk.java.net Fri Sep 18 13:58:57 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 18 Sep 2020 13:58:57 GMT Subject: RFR: JDK-8253239: Disable VS warning C4307 [v3] In-Reply-To: References: Message-ID: <0C1DUqGtgKh_-LtVqtvUYOIu9gKL8PdfWAojjpwyqzY=.5c87fa56-d6f9-4dfd-a51a-e59834b28d75@github.com> > hello, this fixes the build when using VS2017. VS2019 does not have the issue as far as I know. > failure was > >> ./test/hotspot/gtest/utilities/test_align.cpp(96): error C2220: warning treated as error - no 'object' file generated >> ./test/hotspot/gtest/utilities/test_align.cpp(156): note: see reference to function template instantiation 'void >> static_test_alignments(void)' being compiled with >> [ >> T=int64_t, >> A=uint8_t >> ] >> ./test/hotspot/gtest/utilities/test_align.cpp(162): note: see reference to function template instantiation 'void >> test_alignments(void)' being compiled ./test/hotspot/gtest/utilities/test_align.cpp(96): warning >> C4307: '+': integral constant overflow >> >> > > This might be related to an issue fixed at least in some versions of VS2019 , that is discussed here : > > https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html > > https://bugs.openjdk.java.net/browse/JDK-8253239 Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: JDK-8253239: Disable VS warning C4307 Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/237/files - new: https://git.openjdk.java.net/jdk/pull/237/files/4e82edcb..af48bb31 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=237&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=237&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/237.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/237/head:pull/237 PR: https://git.openjdk.java.net/jdk/pull/237 From mdoerr at openjdk.java.net Fri Sep 18 14:09:55 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 18 Sep 2020 14:09:55 GMT Subject: RFR: JDK-8253239: Disable VS warning C4307 [v3] In-Reply-To: <0C1DUqGtgKh_-LtVqtvUYOIu9gKL8PdfWAojjpwyqzY=.5c87fa56-d6f9-4dfd-a51a-e59834b28d75@github.com> References: <0C1DUqGtgKh_-LtVqtvUYOIu9gKL8PdfWAojjpwyqzY=.5c87fa56-d6f9-4dfd-a51a-e59834b28d75@github.com> Message-ID: On Fri, 18 Sep 2020 13:58:57 GMT, Matthias Baesken wrote: >> hello, this fixes the build when using VS2017. VS2019 does not have the issue as far as I know. >> failure was >> >>> ./test/hotspot/gtest/utilities/test_align.cpp(96): error C2220: warning treated as error - no 'object' file generated >>> ./test/hotspot/gtest/utilities/test_align.cpp(156): note: see reference to function template instantiation 'void >>> static_test_alignments(void)' being compiled with >>> [ >>> T=int64_t, >>> A=uint8_t >>> ] >>> ./test/hotspot/gtest/utilities/test_align.cpp(162): note: see reference to function template instantiation 'void >>> test_alignments(void)' being compiled ./test/hotspot/gtest/utilities/test_align.cpp(96): warning >>> C4307: '+': integral constant overflow >>> >>> >> >> This might be related to an issue fixed at least in some versions of VS2019 , that is discussed here : >> >> https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html >> >> https://bugs.openjdk.java.net/browse/JDK-8253239 > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8253239: Disable VS warning C4307 > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> Marked as reviewed by mdoerr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/237 From erikj at openjdk.java.net Fri Sep 18 14:09:55 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 14:09:55 GMT Subject: RFR: JDK-8253239: Disable VS warning C4307 [v3] In-Reply-To: <0C1DUqGtgKh_-LtVqtvUYOIu9gKL8PdfWAojjpwyqzY=.5c87fa56-d6f9-4dfd-a51a-e59834b28d75@github.com> References: <0C1DUqGtgKh_-LtVqtvUYOIu9gKL8PdfWAojjpwyqzY=.5c87fa56-d6f9-4dfd-a51a-e59834b28d75@github.com> Message-ID: On Fri, 18 Sep 2020 13:58:57 GMT, Matthias Baesken wrote: >> hello, this fixes the build when using VS2017. VS2019 does not have the issue as far as I know. >> failure was >> >>> ./test/hotspot/gtest/utilities/test_align.cpp(96): error C2220: warning treated as error - no 'object' file generated >>> ./test/hotspot/gtest/utilities/test_align.cpp(156): note: see reference to function template instantiation 'void >>> static_test_alignments(void)' being compiled with >>> [ >>> T=int64_t, >>> A=uint8_t >>> ] >>> ./test/hotspot/gtest/utilities/test_align.cpp(162): note: see reference to function template instantiation 'void >>> test_alignments(void)' being compiled ./test/hotspot/gtest/utilities/test_align.cpp(96): warning >>> C4307: '+': integral constant overflow >>> >>> >> >> This might be related to an issue fixed at least in some versions of VS2019 , that is discussed here : >> >> https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html >> >> https://bugs.openjdk.java.net/browse/JDK-8253239 > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8253239: Disable VS warning C4307 > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/237 From mbaesken at openjdk.java.net Fri Sep 18 14:09:56 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 18 Sep 2020 14:09:56 GMT Subject: Integrated: JDK-8253239: Disable VS warning C4307 In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 08:22:56 GMT, Matthias Baesken wrote: > hello, this fixes the build when using VS2017. VS2019 does not have the issue as far as I know. > failure was > >> ./test/hotspot/gtest/utilities/test_align.cpp(96): error C2220: warning treated as error - no 'object' file generated >> ./test/hotspot/gtest/utilities/test_align.cpp(156): note: see reference to function template instantiation 'void >> static_test_alignments(void)' being compiled with >> [ >> T=int64_t, >> A=uint8_t >> ] >> ./test/hotspot/gtest/utilities/test_align.cpp(162): note: see reference to function template instantiation 'void >> test_alignments(void)' being compiled ./test/hotspot/gtest/utilities/test_align.cpp(96): warning >> C4307: '+': integral constant overflow >> >> > > This might be related to an issue fixed at least in some versions of VS2019 , that is discussed here : > > https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html > > https://bugs.openjdk.java.net/browse/JDK-8253239 This pull request has now been integrated. Changeset: 52c28b86 Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/52c28b86 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod 8253239: Disable VS warning C4307 Reviewed-by: mdoerr, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/237 From erikj at openjdk.java.net Fri Sep 18 15:37:26 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 15:37:26 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 13:33:07 GMT, Erik Joelsson wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Build changes look good to me. I will take this branch for a spin. Our linux-aarch64 build fails with this: cc: error: unrecognized command line option '-std=c++14' when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing, and if so, how are you addressing it? ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Fri Sep 18 18:41:13 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Fri, 18 Sep 2020 18:41:13 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com> On Fri, 18 Sep 2020 15:34:26 GMT, Erik Joelsson wrote: >> Build changes look good to me. I will take this branch for a spin. > > Our linux-aarch64 build fails with this: > cc: error: unrecognized command line option '-std=c++14' > when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch > > I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing, > and if so, how are you addressing it? Hey @erikj79, thank you so much for giving it a try! > Our linux-aarch64 build fails with this: > cc: error: unrecognized command line option '-std=c++14' > when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch Hmm, that's interesting. What environment is that exactly? What `configure` line are you using there? We have tested on such a system: $ cat /etc/issue Ubuntu 19.10 \n \l $ bash configure --with-boot-jdk=/home/beurba/work/jdk-16+13 --with-jtreg $ make clean CONF=linux-aarch64-server-release $ make images JOBS=255 LOG=info CONF=linux-aarch64-server-release $ ./build/linux-aarch64-server-release/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep aarch64 java.home = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk os.arch = aarch64 sun.boot.library.path = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk/lib -------------------------------------------------------- > I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing, > and if so, how are you addressing it? Yes. As far as I understand, the problem is that `fixpath.exe` isn't built properly when doing cross-compiling on Windows targets (as it hasn't been a thing so far). We use a workaround internally https://gist.github.com/lewurm/c099a4b5fcd8a182510cbdeebcb41f77 , but a proper solution is under discussion on build-dev: https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027872.html ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From erikj at openjdk.java.net Fri Sep 18 20:37:45 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 20:37:45 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith wrote: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 make/autoconf/toolchain.m4 line 902: > 900: BUILD_DEVKIT_TOOLCHAIN_PATH="$BUILD_DEVKIT_ROOT/bin" > 901: fi > 902: UTIL_PREPEND_TO_PATH([PATH],$BUILD_DEVKIT_TOOLCHAIN_PATH) Here is a problem. In our linux cross compile build, we rely on the PATH being completely overwritten with the paths from the devkit here. Otherwise the UTIL_REQUIRE_PROGS may find /usr/bin/cc before $BUILD_DEVKIT_TOOLCHAIN_PATH/gcc. This is the reason my linux-aarch64 (cross compile) build failed. The system installed cc was too old to recognize the -stdc=c++14 argument. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From erikj at openjdk.java.net Fri Sep 18 20:37:45 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 20:37:45 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 20:32:36 GMT, Erik Joelsson wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > make/autoconf/toolchain.m4 line 902: > >> 900: BUILD_DEVKIT_TOOLCHAIN_PATH="$BUILD_DEVKIT_ROOT/bin" >> 901: fi >> 902: UTIL_PREPEND_TO_PATH([PATH],$BUILD_DEVKIT_TOOLCHAIN_PATH) > > Here is a problem. In our linux cross compile build, we rely on the PATH being completely overwritten with the paths > from the devkit here. Otherwise the UTIL_REQUIRE_PROGS may find /usr/bin/cc before $BUILD_DEVKIT_TOOLCHAIN_PATH/gcc. > This is the reason my linux-aarch64 (cross compile) build failed. The system installed cc was too old to recognize > the -stdc=c++14 argument. I assume you need the rest of the PATH on Windows. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From aph at redhat.com Sat Sep 19 09:27:36 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 19 Sep 2020 10:27:36 +0100 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: On 18/09/2020 11:14, Monica Beckwith wrote: > This is a continuation of > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] It's still wrong, I'm afraid. This is not a full barrier: +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_acq_rel); it is only StoreStore|LoadStore|LoadLoad, but you need StoreLoad as well. It might well be that you get the same DMB ISH instruction, but unless you use a StoreLoad barrier here it's theoretically possible for a compiler to reorder accesses so that a processor sees its own stores before other processors do. (And it's confusing for the reader too.) Use: +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_seq_cst); See here: https://en.cppreference.com/w/cpp/atomic/memory_order memory_order_seq_cst "...plus a single total order exists in which all threads observe all modifications in the same order (see Sequentially-consistent ordering below)" -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sat Sep 19 10:21:05 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 19 Sep 2020 11:21:05 +0100 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: On 18/09/2020 11:14, Monica Beckwith wrote: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html The diffs in assembler_aarch64.cpp are mostly spurious. Please try this. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- diff --git a/src/hotspot/cpu/aarch64/aarch64-asmtest.py b/src/hotspot/cpu/aarch64/aarch64-asmtest.py index f5a5c6b5aee..43bac8e8142 100644 --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py @@ -12,8 +12,11 @@ class Operand(object): class Register(Operand): def generate(self): - self.number = random.randint(0, 30) - return self + while True: + self.number = random.randint(0, 30) + # r18 is used for TLS on Windows ABI. + if self.number != 18: + return self def astr(self, prefix): return prefix + str(self.number) @@ -36,8 +39,10 @@ class GeneralRegister(Register): class GeneralRegisterOrZr(Register): def generate(self): - self.number = random.randint(0, 31) - return self + while True: + self.number = random.randint(0, 31) + if self.number != 18: + return self def astr(self, prefix = ""): if (self.number == 31): @@ -53,8 +58,10 @@ class GeneralRegisterOrZr(Register): class GeneralRegisterOrSp(Register): def generate(self): - self.number = random.randint(0, 31) - return self + while True: + self.number = random.randint(0, 31) + if self.number != 18: + return self def astr(self, prefix = ""): if (self.number == 31): @@ -1331,7 +1338,7 @@ generate(SpecialCases, [["ccmn", "__ ccmn(zr, zr, 3u, Assembler::LE);", ["st1w", "__ sve_st1w(z0, __ S, p1, Address(r0, 7));", "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"], ["st1b", "__ sve_st1b(z0, __ B, p2, Address(sp, r1));", "st1b\t{z0.b}, p2, [sp, x1]"], ["st1h", "__ sve_st1h(z0, __ H, p3, Address(sp, r8));", "st1h\t{z0.h}, p3, [sp, x8, LSL #1]"], - ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r18));", "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"], + ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r17));", "st1d\t{z0.d}, p4, [x0, x17, LSL #3]"], ["ldr", "__ sve_ldr(z0, Address(sp));", "ldr\tz0, [sp]"], ["ldr", "__ sve_ldr(z31, Address(sp, -256));", "ldr\tz31, [sp, #-256, MUL VL]"], ["str", "__ sve_str(z8, Address(r8, 255));", "str\tz8, [x8, #255, MUL VL]"], From github.com+53073448+junyzheng at openjdk.java.net Mon Sep 21 05:59:50 2020 From: github.com+53073448+junyzheng at openjdk.java.net (Junyuan Zheng) Date: Mon, 21 Sep 2020 05:59:50 GMT Subject: Integrated: 8253253: Binutils tar ball extension update to gz In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 04:54:04 GMT, Junyuan Zheng wrote: > Our infra team found this error when building DevKit with GCC 4.9.2. The binutils version is 2.25, and an *.xz doesn't > exist on https://ftp.gnu.org/pub/gnu/binutils. Hence, we would like to submit a PR to update *.xz to *.gz. > We have confirmed that *.gz exists for all binutil version. This pull request has now been integrated. Changeset: fdce055a Author: Junyuan Zheng <53073448+junyzheng at users.noreply.github.com> Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/fdce055a Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8253253: Binutils tar ball extension update to gz Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/162 From mbeckwit at openjdk.java.net Mon Sep 21 07:14:52 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 21 Sep 2020 07:14:52 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2] In-Reply-To: References: Message-ID: <9ex1cWVOzjYIl9WtLrMt_hGrAQDKPNu5afUME7dfM9o=.e5cee81f-4bd6-4896-bd90-f713585bff37@github.com> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith 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 six new commits since the last revision: - 8248787: G1: Workaround MSVC bug Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248670: Windows: Exception handling support on AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248660: AArch64: Make _clear_cache and _nop portable Summary: __builtin___clear_cache, etc. Contributed-by: mbeckwit, luhenry, burban - 8248659: AArch64: Extend CPU Feature detection Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248656: Add Windows AArch64 platform support code Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248498: Add build system support for Windows AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/26e4af3a..5f9b0d35 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Mon Sep 21 07:14:52 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 21 Sep 2020 07:14:52 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 20:34:55 GMT, Erik Joelsson wrote: > I assume you need the rest of the PATH on Windows. Doesn't look like it actually. I've reverted it, thanks for catching it. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Mon Sep 21 08:18:21 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 21 Sep 2020 08:18:21 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2] In-Reply-To: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com> References: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com> Message-ID: On Fri, 18 Sep 2020 18:38:34 GMT, Bernhard Urban-Forster wrote: >> Our linux-aarch64 build fails with this: >> cc: error: unrecognized command line option '-std=c++14' >> when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch >> >> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing, >> and if so, how are you addressing it? > > Hey @erikj79, thank you so much for giving it a try! > >> Our linux-aarch64 build fails with this: >> cc: error: unrecognized command line option '-std=c++14' >> when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch > > Hmm, that's interesting. What environment is that exactly? What `configure` line are you using there? We have tested on > such a system: $ cat /etc/issue > Ubuntu 19.10 \n \l > $ bash configure --with-boot-jdk=/home/beurba/work/jdk-16+13 --with-jtreg > $ make clean CONF=linux-aarch64-server-release > $ make images JOBS=255 LOG=info CONF=linux-aarch64-server-release > $ ./build/linux-aarch64-server-release/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep aarch64 > java.home = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk > os.arch = aarch64 > sun.boot.library.path = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk/lib > -------------------------------------------------------- >> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing, >> and if so, how are you addressing it? > > Yes. As far as I understand, the problem is that `fixpath.exe` isn't built properly when doing cross-compiling on > Windows targets (as it hasn't been a thing so far). We use a workaround internally > https://gist.github.com/lewurm/c099a4b5fcd8a182510cbdeebcb41f77 , but a proper solution is under discussion on > build-dev: https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027872.html > _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ > > On 18/09/2020 11:14, Monica Beckwith wrote: > > > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > The diffs in assembler_aarch64.cpp are mostly spurious. Please try this. Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part would look indeed nicer with that: https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ): --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py @@ -13,6 +13,8 @@ class Register(Operand): def generate(self): self.number = random.randint(0, 30) + if self.number == 18: + self.number = 17 return self def astr(self, prefix): @@ -37,6 +39,8 @@ class GeneralRegisterOrZr(Register): def generate(self): self.number = random.randint(0, 31) + if self.number == 18: + self.number = 16 return self def astr(self, prefix = ""): @@ -54,6 +58,8 @@ class GeneralRegisterOrZr(Register): class GeneralRegisterOrSp(Register): def generate(self): self.number = random.randint(0, 31) + if self.number == 18: + self.number = 15 return self def astr(self, prefix = ""): @@ -1331,7 +1337,7 @@ generate(SpecialCases, [["ccmn", "__ ccmn(zr, zr, 3u, Assembler::LE);", ["st1w", "__ sve_st1w(z0, __ S, p1, Address(r0, 7));", "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"], ["st1b", "__ sve_st1b(z0, __ B, p2, Address(sp, r1));", "st1b\t{z0.b}, p2, [sp, x1]"], ["st1h", "__ sve_st1h(z0, __ H, p3, Address(sp, r8));", "st1h\t{z0.h}, p3, [sp, x8, LSL #1]"], - ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r18));", "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"], + ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r17));", "st1d\t{z0.d}, p4, [x0, x17, LSL #3]"], ["ldr", "__ sve_ldr(z0, Address(sp));", "ldr\tz0, [sp]"], ["ldr", "__ sve_ldr(z31, Address(sp, -256));", "ldr\tz31, [sp, #-256, MUL VL]"], ["str", "__ sve_str(z8, Address(r8, 255));", "str\tz8, [x8, #255, MUL VL]"], ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From aph at redhat.com Mon Sep 21 09:30:18 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 21 Sep 2020 10:30:18 +0100 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2] In-Reply-To: References: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com> Message-ID: On 21/09/2020 09:18, Bernhard Urban-Forster wrote: > Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the > retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part > would look indeed nicer with that: https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ): > > --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py > +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py > @@ -13,6 +13,8 @@ class Register(Operand): > > def generate(self): > self.number = random.randint(0, 30) > + if self.number == 18: > + self.number = 17 Yes, better. Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hannesw at openjdk.java.net Mon Sep 21 10:47:40 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 21 Sep 2020 10:47:40 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v2] In-Reply-To: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: > This pull request is identical with the RFR previously sent for the Mercurial repository: > > https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html > > I'm copy-pasting the comments from the original RFR below. > > Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting > code for setting up external links. > The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for > prereleases. Platform documentation URLs can be configured using the new --link-platform-properties option to > provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on > the new options. The feature can be disabled using the --no-platform-link option, generating the same output as > previously. One problem I had to solve was how to handle the transition from prerelease versions to final releases, > since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that > switch via code change at a time shortly before release. The way it is done is that we determine if the current > javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(), > and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This > means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with > source version 15 will generate links to the final release documentation) but I think this is acceptable. Another > issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to > pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally > there should be one test with a clear message. Because of this, when a release is encountered for which no > element-list is available a warning is generated instead of an error, and the documentation is generated without > platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new > test to fail with a relatively clear message of what is wrong. > *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we > still need to maintain element-lists for older versions, so I?m not sure it?s worth it. > > For existing tests that check output affected by the new option I added the --no-platform-link option to disable the > feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static > release or source version, which we don?t want either). I updated the CSR to the new code. It also needs to be > reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 > > Thanks, > Hannes Hannes Walln?fer has updated the pull request incrementally with three additional commits since the last revision: - Merge pull request #1 from lahodaj/JDK-8216497 Automatically generate the elements-list data from the ct.sym for releases 11+, including the current release under development - Generating current release list for javadoc; using hardcoded lists for versions < 11 - Attempting to (mostly) generate the javadoc release manifests from ct.sym historical data. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/171/files - new: https://git.openjdk.java.net/jdk/pull/171/files/2aed84f8..6d659ae3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=171&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=171&range=00-01 Stats: 2007 lines in 9 files changed: 308 ins; 1698 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/171/head:pull/171 PR: https://git.openjdk.java.net/jdk/pull/171 From rwestberg at openjdk.java.net Mon Sep 21 13:51:21 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Mon, 21 Sep 2020 13:51:21 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions Message-ID: A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open source repositories. I've incorporated the feedback into an updated version that I believe is ready to be integrated. If this is integrated into the `master` branch, future branches created and updated in personal forks will build and run the basic tier 1 tests as described in this configuration, on Linux, Windows and macOS (all on x64). It's of course possible for any contributor to opt out fully or partially of these automatic runs in a few different ways. To opt out completely, a contributor can simply disable GitHub Actions on their personal fork, and no further jobs will be executed. Another option is to add a repository secret [4] with the name `JDK_SUBMIT_FILTER` set to any value. If this is set, only branches prefixed with `submit/` will be subject to automatic build and test. This can also be further refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a value such as `Linux x64, Windows x64` to limit automatic build and test to these two platforms. It will still be possible to run the tests on any branch and/or platform by manually triggering the workflow. To see what this looks like in practice, an example run can be found here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is currently a failing test on Windows which is tracked by JDK-8249095, which should probably be resolved before this change is integrated). Best regards, Robin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] https://github.com/features/actions [3] https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits [4] https://docs.github.com/en/actions/reference/encrypted-secrets ------------- Commit messages: - Updates after initial preview - Initial version Changes: https://git.openjdk.java.net/jdk/pull/284/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253424 Stats: 739 lines in 1 file changed: 739 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/284/head:pull/284 PR: https://git.openjdk.java.net/jdk/pull/284 From erikj at openjdk.java.net Mon Sep 21 14:01:56 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 21 Sep 2020 14:01:56 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 13:32:09 GMT, Robin Westberg wrote: > A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests > for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open > source repositories. I've incorporated the feedback into an updated version that I believe is ready to be integrated. > If this is integrated into the `master` branch, future branches created and updated in personal forks will build and > run the basic tier 1 tests as described in this configuration, on Linux, Windows and macOS (all on x64). It's of course > possible for any contributor to opt out fully or partially of these automatic runs in a few different ways. To opt out > completely, a contributor can simply disable GitHub Actions on their personal fork, and no further jobs will be > executed. Another option is to add a repository secret [4] with the name `JDK_SUBMIT_FILTER` set to any value. If this > is set, only branches prefixed with `submit/` will be subject to automatic build and test. This can also be further > refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a value such as `Linux x64, Windows x64` to > limit automatic build and test to these two platforms. It will still be possible to run the tests on any branch and/or > platform by manually triggering the workflow. To see what this looks like in practice, an example run can be found > here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is currently a failing test on Windows > which is tracked by JDK-8249095, which should probably be resolved before this change is integrated). Best regards, > Robin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits [4] > https://docs.github.com/en/actions/reference/encrypted-secrets Is there any way to derive the version strings for dependencies from a different source? Once pushed, this file will require updating whenever the bootjdk, jtreg version or gtest version is updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/284 From mbeckwit at openjdk.java.net Mon Sep 21 14:55:26 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 21 Sep 2020 14:55:26 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3] In-Reply-To: References: Message-ID: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith 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 11 new commits since the last revision: - 8248787: G1: Workaround MSVC bug Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248670: Windows: Exception handling support on AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248660: AArch64: Make _clear_cache and _nop portable Summary: __builtin___clear_cache, etc. Contributed-by: mbeckwit, luhenry, burban - 8248659: AArch64: Extend CPU Feature detection Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248656: Add Windows AArch64 platform support code Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248498: Add build system support for Windows AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248663: AArch64: Avoid existing macros/keywords of MSVC Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248676: AArch64: Add workaround for LITable constructor Reviewed-by: aph Contributed-by: mbeckwit, luhenry, burban - 8248500: AArch64: Remove the r18 dependency on Windows AArch64 (regenerate tests) Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - ... and 1 more: https://git.openjdk.java.net/jdk/compare/5f9b0d35...3881b12d ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/5f9b0d35..3881b12d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=01-02 Stats: 1366 lines in 2 files changed: 6 ins; 4 del; 1356 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Mon Sep 21 14:55:27 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 21 Sep 2020 14:55:27 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3] In-Reply-To: References: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com> Message-ID: On Mon, 21 Sep 2020 08:15:20 GMT, Bernhard Urban-Forster wrote: >> Hey @erikj79, thank you so much for giving it a try! >> >>> Our linux-aarch64 build fails with this: >>> cc: error: unrecognized command line option '-std=c++14' >>> when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch >> >> Hmm, that's interesting. What environment is that exactly? What `configure` line are you using there? We have tested on >> such a system: $ cat /etc/issue >> Ubuntu 19.10 \n \l >> $ bash configure --with-boot-jdk=/home/beurba/work/jdk-16+13 --with-jtreg >> $ make clean CONF=linux-aarch64-server-release >> $ make images JOBS=255 LOG=info CONF=linux-aarch64-server-release >> $ ./build/linux-aarch64-server-release/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep aarch64 >> java.home = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk >> os.arch = aarch64 >> sun.boot.library.path = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk/lib >> -------------------------------------------------------- >>> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing, >>> and if so, how are you addressing it? >> >> Yes. As far as I understand, the problem is that `fixpath.exe` isn't built properly when doing cross-compiling on >> Windows targets (as it hasn't been a thing so far). We use a workaround internally >> https://gist.github.com/lewurm/c099a4b5fcd8a182510cbdeebcb41f77 , but a proper solution is under discussion on >> build-dev: https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027872.html > >> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >> >> On 18/09/2020 11:14, Monica Beckwith wrote: >> >> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> The diffs in assembler_aarch64.cpp are mostly spurious. Please try this. > > > Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the > retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part > would look indeed nicer with that: https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ): > --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py > +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py > @@ -13,6 +13,8 @@ class Register(Operand): > > def generate(self): > self.number = random.randint(0, 30) > + if self.number == 18: > + self.number = 17 > return self > > def astr(self, prefix): > @@ -37,6 +39,8 @@ class GeneralRegisterOrZr(Register): > > def generate(self): > self.number = random.randint(0, 31) > + if self.number == 18: > + self.number = 16 > return self > > def astr(self, prefix = ""): > @@ -54,6 +58,8 @@ class GeneralRegisterOrZr(Register): > class GeneralRegisterOrSp(Register): > def generate(self): > self.number = random.randint(0, 31) > + if self.number == 18: > + self.number = 15 > return self > > def astr(self, prefix = ""): > @@ -1331,7 +1337,7 @@ generate(SpecialCases, [["ccmn", "__ ccmn(zr, zr, 3u, Assembler::LE);", > ["st1w", "__ sve_st1w(z0, __ S, p1, Address(r0, 7));", "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"], > ["st1b", "__ sve_st1b(z0, __ B, p2, Address(sp, r1));", "st1b\t{z0.b}, p2, [sp, x1]"], > ["st1h", "__ sve_st1h(z0, __ H, p3, Address(sp, r8));", "st1h\t{z0.h}, p3, [sp, x8, LSL #1]"], > - ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r18));", "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"], > + ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r17));", "st1d\t{z0.d}, p4, [x0, x17, > LSL #3]"], > ["ldr", "__ sve_ldr(z0, Address(sp));", "ldr\tz0, [sp]"], > ["ldr", "__ sve_ldr(z31, Address(sp, -256));", "ldr\tz31, [sp, #-256, MUL VL]"], > ["str", "__ sve_str(z8, Address(r8, 255));", "str\tz8, [x8, #255, MUL VL]"], > _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ > > On 21/09/2020 09:18, Bernhard Urban-Forster wrote: > > > Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the > > retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part > > would look indeed nicer with that: https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ): > > [...] > > Yes, better. Thanks. Great, I've updated the PR. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From rwestberg at openjdk.java.net Mon Sep 21 15:33:15 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Mon, 21 Sep 2020 15:33:15 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions In-Reply-To: References: Message-ID: <2gwNsqQ3OJqaTKD66CfHrVWFbDVxxcLEvM3oMOPejOo=.5bad0484-7502-422b-8e4b-6e970959584a@github.com> On Mon, 21 Sep 2020 13:59:06 GMT, Erik Joelsson wrote: >> A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests >> for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open >> source repositories. I've incorporated the feedback into an updated version that I believe is ready to be integrated. >> If this is integrated into the `master` branch, future branches created and updated in personal forks will build and >> run the basic tier 1 tests as described in this configuration, on Linux, Windows and macOS (all on x64). It's of course >> possible for any contributor to opt out fully or partially of these automatic runs in a few different ways. To opt out >> completely, a contributor can simply disable GitHub Actions on their personal fork, and no further jobs will be >> executed. Another option is to add a repository secret [4] with the name `JDK_SUBMIT_FILTER` set to any value. If this >> is set, only branches prefixed with `submit/` will be subject to automatic build and test. This can also be further >> refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a value such as `Linux x64, Windows x64` to >> limit automatic build and test to these two platforms. It will still be possible to run the tests on any branch and/or >> platform by manually triggering the workflow. To see what this looks like in practice, an example run can be found >> here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is currently a failing test on Windows >> which is tracked by JDK-8249095, which should probably be resolved before this change is integrated). Best regards, >> Robin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] >> https://github.com/features/actions [3] >> https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits [4] >> https://docs.github.com/en/actions/reference/encrypted-secrets > > Is there any way to derive the version strings for dependencies from a different source? Once pushed, this file will > require updating whenever the bootjdk, jtreg version or gtest version is updated. Certainly, the prerequisites step can checkout additional repositories and run shell commands to extract variables to be used for later steps. Do we have any suitable source for these versions? We'll also need download links for the different flavors of the bootjdk (and ideally the sha256 hash, although the verification step could perhaps be skipped). ------------- PR: https://git.openjdk.java.net/jdk/pull/284 From sgehwolf at openjdk.java.net Mon Sep 21 16:48:11 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 21 Sep 2020 16:48:11 GMT Subject: RFR: 8252998: ModuleWrapper.gmk doesn't consult include path In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 12:44:13 GMT, Erik Joelsson wrote: >> A change made to ModuleWrapper.gmk as part of JDK-8244044 means that an included makefile is found in the current >> directory, so Make doesn't check the include dirs for overriding gmk files. >> Recommend a minor, partial reversion of this changeset to ensure any override files are included instead. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8252998 > > Looks good. @adamfarley Please see https://github.com/openjdk/jdk/pull/250#issuecomment-694845694 for getting this integrated. For non-committers it's `/integrate` and then `/sponsor` by somebody with commit rights. ------------- PR: https://git.openjdk.java.net/jdk/pull/250 From erikj at openjdk.java.net Mon Sep 21 17:25:26 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 21 Sep 2020 17:25:26 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions In-Reply-To: <2gwNsqQ3OJqaTKD66CfHrVWFbDVxxcLEvM3oMOPejOo=.5bad0484-7502-422b-8e4b-6e970959584a@github.com> References: <2gwNsqQ3OJqaTKD66CfHrVWFbDVxxcLEvM3oMOPejOo=.5bad0484-7502-422b-8e4b-6e970959584a@github.com> Message-ID: <1BduorxiB-c33s_OlKgtJulsazxapxCj2kqGhAj1UiA=.9c618556-fb24-4236-aefe-bf37d5a4a4b4@github.com> On Mon, 21 Sep 2020 15:30:41 GMT, Robin Westberg wrote: >> Is there any way to derive the version strings for dependencies from a different source? Once pushed, this file will >> require updating whenever the bootjdk, jtreg version or gtest version is updated. > > Certainly, the prerequisites step can checkout additional repositories and run shell commands to extract variables to > be used for later steps. Do we have any suitable source for these versions? We'll also need download links for the > different flavors of the bootjdk (and ideally the sha256 hash, although the verification step could perhaps be skipped). We don't have a good source currently no, but something to keep in mind. Ideally we would want to create a common source for both jib-profiles.js and the gitactions to read from. I would prefer something that can be read both as a properties file and sourced as a shell script, much like the version-numbers file currently is. That could be done as a separate change though. ------------- PR: https://git.openjdk.java.net/jdk/pull/284 From minqi at openjdk.java.net Mon Sep 21 18:17:55 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 21 Sep 2020 18:17:55 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: > With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: 8253208: Move CDS related code to a separate class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/261/files - new: https://git.openjdk.java.net/jdk/pull/261/files/b9789c8b..c01deec7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=00-01 Stats: 27 lines in 7 files changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/261/head:pull/261 PR: https://git.openjdk.java.net/jdk/pull/261 From minqi at openjdk.java.net Mon Sep 21 18:25:55 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 21 Sep 2020 18:25:55 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: <7rL3zSJi28q_2LUdGaxlpMg8b2fFh1IHNF07U3uaaeU=.b4a7e852-9c61-43bf-aadf-30b5d5d6af32@github.com> On Sun, 20 Sep 2020 06:10:53 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> 8253208: Move CDS related code to a separate class > > src/java.base/share/native/libjava/CDS.c line 49: > >> 47: JNIEXPORT jboolean JNICALL >> 48: Java_jdk_internal_misc_CDS_isCDSDumpingEnabled(JNIEnv *env, jclass jcls) { >> 49: return JVM_IsCDSDumpingEnabled(env); > > Maybe: return JVM_IsCDSDynamicDumpingEnabled(env) updated with comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From mchung at openjdk.java.net Mon Sep 21 19:00:33 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 21 Sep 2020 19:00:33 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8253208: Move CDS related code to a separate class This patch looks okay. Please add the javadoc for `CDS::getRandomSeedForDumping` and `CDS::defineArchiveModules` for completeness. ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From erikj at openjdk.java.net Mon Sep 21 19:07:13 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 21 Sep 2020 19:07:13 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: <65z5iR9UPXmBfCEVJkOgnegcyctdCIOZJ_tMl0bEdAI=.0457ea07-f4ff-48e4-b793-2e8011ee1a45@github.com> On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8253208: Move CDS related code to a separate class Build changes look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From iklam at openjdk.java.net Mon Sep 21 21:57:01 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 21 Sep 2020 21:57:01 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8253208: Move CDS related code to a separate class Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From minqi at openjdk.java.net Mon Sep 21 22:24:15 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 21 Sep 2020 22:24:15 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v3] In-Reply-To: References: Message-ID: <7yHEh89XlpTGoXfHw85_SVEKEBM0t03tQlkZ7tKm4P0=.399d9d6c-c375-4892-a92c-3cd6806e51d6@github.com> > With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: 8253208: Move CDS related code to a separate class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/261/files - new: https://git.openjdk.java.net/jdk/pull/261/files/c01deec7..953b6bac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=01-02 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/261/head:pull/261 PR: https://git.openjdk.java.net/jdk/pull/261 From ascarpino at openjdk.java.net Mon Sep 21 23:14:18 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 21 Sep 2020 23:14:18 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves Message-ID: This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 ------------- Commit messages: - 8235710: Remove the legacy elliptic curves Changes: https://git.openjdk.java.net/jdk/pull/289/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=289&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8235710 Stats: 20143 lines in 75 files changed: 25 ins; 20038 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/289/head:pull/289 PR: https://git.openjdk.java.net/jdk/pull/289 From erikj at openjdk.java.net Mon Sep 21 23:52:50 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 21 Sep 2020 23:52:50 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 21:10:58 GMT, Anthony Scarpino wrote: > This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The > SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will > remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, > sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, > X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 > prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 make/autoconf/jdk-options.m4 line 234: > 232: # Enable or disable the elliptic curve crypto implementation > 233: # > 234: AC_DEFUN_ONCE([JDKOPT_DETECT_INTREE_EC], There should be a call to this macro from either configure.ac or this file that also needs to be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From ascarpino at openjdk.java.net Tue Sep 22 00:18:07 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 22 Sep 2020 00:18:07 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: > This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The > SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will > remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, > sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, > X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 > prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: remove JDKOPT_DETECT_INTREE_EC from configure.ac ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/289/files - new: https://git.openjdk.java.net/jdk/pull/289/files/47eee3f4..8a04ce7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=289&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=289&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/289/head:pull/289 PR: https://git.openjdk.java.net/jdk/pull/289 From ascarpino at openjdk.java.net Tue Sep 22 00:18:08 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 22 Sep 2020 00:18:08 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 23:50:07 GMT, Erik Joelsson wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> remove JDKOPT_DETECT_INTREE_EC from configure.ac > > make/autoconf/jdk-options.m4 line 234: > >> 232: # Enable or disable the elliptic curve crypto implementation >> 233: # >> 234: AC_DEFUN_ONCE([JDKOPT_DETECT_INTREE_EC], > > There should be a call to this macro from either configure.ac or this file that also needs to be removed. found it in configure.ac and removed ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From xuelei at openjdk.java.net Tue Sep 22 01:31:08 2020 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 22 Sep 2020 01:31:08 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > remove JDKOPT_DETECT_INTREE_EC from configure.ac Looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/289 From github.com+471021+marschall at openjdk.java.net Tue Sep 22 05:26:31 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Tue, 22 Sep 2020 05:26:31 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v3] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=02 Stats: 748 lines in 64 files changed: 149 ins; 149 del; 450 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From mbeckwit at openjdk.java.net Tue Sep 22 07:13:50 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Tue, 22 Sep 2020 07:13:50 GMT Subject: Integrated: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC In-Reply-To: References: Message-ID: <_v8F-ZrZsrhdY1v8fkPZkP-7v6ZuAeW6ThLBMpk5CSc=.e9cd6c80-d027-4ba3-9524-9abc63789172@github.com> On Wed, 9 Sep 2020 20:24:37 GMT, Monica Beckwith wrote: > ZGC and ShenandoahGC are two low latency GCs in OpenJDK HotSpot. We will enable and run microbenchmarks and scaling > tests for both. After enabling, I ran JTRegs, a few micros, and SPECJBB2015 (heap and multi-JVM) scaling tests for both > the GCs. This pull request has now been integrated. Changeset: 96f722cf Author: Monica Beckwith Committer: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/96f722cf Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC Reviewed-by: shade, stefank, rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/97 From egahlin at openjdk.java.net Tue Sep 22 08:45:52 2020 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 22 Sep 2020 08:45:52 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Sat, 12 Sep 2020 00:19:00 GMT, Vladimir Kozlov wrote: >> Philippe Marschall 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: >> 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate > > Marked as reviewed by kvn (Reviewer). Have you run the JFR tests in test/jdk/jdk/jfr? ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From erikj at openjdk.java.net Tue Sep 22 13:23:40 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Sep 2020 13:23:40 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > remove JDKOPT_DETECT_INTREE_EC from configure.ac Build changes look good. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From rwestberg at openjdk.java.net Tue Sep 22 13:39:24 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Tue, 22 Sep 2020 13:39:24 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions In-Reply-To: <1BduorxiB-c33s_OlKgtJulsazxapxCj2kqGhAj1UiA=.9c618556-fb24-4236-aefe-bf37d5a4a4b4@github.com> References: <2gwNsqQ3OJqaTKD66CfHrVWFbDVxxcLEvM3oMOPejOo=.5bad0484-7502-422b-8e4b-6e970959584a@github.com> <1BduorxiB-c33s_OlKgtJulsazxapxCj2kqGhAj1UiA=.9c618556-fb24-4236-aefe-bf37d5a4a4b4@github.com> Message-ID: On Mon, 21 Sep 2020 17:22:57 GMT, Erik Joelsson wrote: >> Certainly, the prerequisites step can checkout additional repositories and run shell commands to extract variables to >> be used for later steps. Do we have any suitable source for these versions? We'll also need download links for the >> different flavors of the bootjdk (and ideally the sha256 hash, although the verification step could perhaps be skipped). > > We don't have a good source currently no, but something to keep in mind. Ideally we would want to create a common > source for both jib-profiles.js and the gitactions to read from. I would prefer something that can be read both as a > properties file and sourced as a shell script, much like the version-numbers file currently is. That could be done as a > separate change though. Sure, should not be that hard to parse something similar. The GitHub actions will probably need it in JSON format at some point, but nothing a little `sed -e '1i {' -e 's/#.*//g' -e 's/"//g' -e 's/(.*)=(.*)/"\1": "\2",/g' -e '$s/,\s{0,}$/}/'` won't solve. Any suggestion for the location and name of such a file? I'm thinking it would contain entries like this: BOOT_JDK_VERSION="14.0.2" JTREG_VERSION="jtreg5.1-b01" GTEST_VERSION="release-1.8.1" LINUX_X64_BOOT_JDK_FILENAME="openjdk-14.0.2_linux-x64_bin.tar.gz" LINUX_X64_BOOT_JDK_URL="https://download.java.net/java/GA/jdk14.0.2/205943a0976c4ed48cb16f1043c5c647/12/GPL/openjdk-14.0.2_linux-x64_bin.tar.gz" LINUX_X64_BOOT_JDK_SHA256="91310200f072045dc6cef2c8c23e7e6387b37c46e9de49623ce0fa461a24623d" ------------- PR: https://git.openjdk.java.net/jdk/pull/284 From erikj at openjdk.java.net Tue Sep 22 14:08:37 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Sep 2020 14:08:37 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions In-Reply-To: References: <2gwNsqQ3OJqaTKD66CfHrVWFbDVxxcLEvM3oMOPejOo=.5bad0484-7502-422b-8e4b-6e970959584a@github.com> <1BduorxiB-c33s_OlKgtJulsazxapxCj2kqGhAj1UiA=.9c618556-fb24-4236-aefe-bf37d5a4a4b4@github.com> Message-ID: On Tue, 22 Sep 2020 13:36:58 GMT, Robin Westberg wrote: >> We don't have a good source currently no, but something to keep in mind. Ideally we would want to create a common >> source for both jib-profiles.js and the gitactions to read from. I would prefer something that can be read both as a >> properties file and sourced as a shell script, much like the version-numbers file currently is. That could be done as a >> separate change though. > > Sure, should not be that hard to parse something similar. The GitHub actions will probably need it in JSON format at > some point, but nothing a little `sed -e '1i {' -e 's/#.*//g' -e 's/"//g' -e 's/(.*)=(.*)/"\1": "\2",/g' -e > '$s/,\s{0,}$/}/'` won't solve. Any suggestion for the location and name of such a file? I'm thinking it would contain > entries like this: BOOT_JDK_VERSION="14.0.2" JTREG_VERSION="jtreg5.1-b01" > GTEST_VERSION="release-1.8.1" > LINUX_X64_BOOT_JDK_FILENAME="openjdk-14.0.2_linux-x64_bin.tar.gz" > LINUX_X64_BOOT_JDK_URL="https://download.java.net/java/GA/jdk14.0.2/205943a0976c4ed48cb16f1043c5c647/12/GPL/openjdk-14.0.2_linux-x64_bin.tar.gz" > LINUX_X64_BOOT_JDK_SHA256="91310200f072045dc6cef2c8c23e7e6387b37c46e9de49623ce0fa461a24623d" The other primary consumer of this is make/conf/jib-profiles.js. The make/conf dir would make sense to me. The challenge here is creating a set of variables that are suitable enough for both config files to consume. For BootJDK, we never bothered with bumping the version for updates, and I very much doubt we will do that in the future for github actions, so a plain major version 14, and soon 15, would be preferred from my point of view. This is however not enough for jib-profiles.js (yet) so we can't really share bootjdk config for now anyway. For jtreg, we specify 5.1 and b01 as two separate metadata values. For gtest we specify the version as 1.8.1. ------------- PR: https://git.openjdk.java.net/jdk/pull/284 From mullan at openjdk.java.net Tue Sep 22 14:08:44 2020 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 22 Sep 2020 14:08:44 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: <8nr0RrYr-7cnjo4sSs9BpMWPCfFptjBDVu56hoDxl0U=.d5addb7e-5646-4f58-a5e7-29eda6cae1fc@github.com> On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > remove JDKOPT_DETECT_INTREE_EC from configure.ac throw new IllegalStateException( new InvalidAlgorithmParameterException( "Curve not supported: Private: " + ((privNC != null) ? privNC.toString() : " unknown") + ", PublicKey:" + ((pubNC != null) ? pubNC.toString() : " unknown"))); src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java line 180: > 178: ((privNC != null) ? privNC.toString() : " unknown") + > 179: ", PublicKey:" + > 180: ((pubNC != null) ? pubNC.toString() : " unknown"))); Spacing issues: "PublicKey:" should be "PublicKey: " and " unknown" should be "unknown". ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From mchung at openjdk.java.net Tue Sep 22 16:03:07 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Sep 2020 16:03:07 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v3] In-Reply-To: <7yHEh89XlpTGoXfHw85_SVEKEBM0t03tQlkZ7tKm4P0=.399d9d6c-c375-4892-a92c-3cd6806e51d6@github.com> References: <7yHEh89XlpTGoXfHw85_SVEKEBM0t03tQlkZ7tKm4P0=.399d9d6c-c375-4892-a92c-3cd6806e51d6@github.com> Message-ID: <8hwfOa6oYGE3dZPVcdltbIO_lVzRHFeztiTrFAFaIr0=.f4082018-d17a-40ee-94f7-14fef9872579@github.com> On Mon, 21 Sep 2020 22:24:15 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8253208: Move CDS related code to a separate class Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From minqi at openjdk.java.net Tue Sep 22 16:14:40 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 22 Sep 2020 16:14:40 GMT Subject: Integrated: 8253208: Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 23:47:56 GMT, Yumin Qi wrote: > With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 This pull request has now been integrated. Changeset: c1df13b8 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/c1df13b8 Stats: 218 lines in 23 files changed: 53 ins; 119 del; 46 mod 8253208: Move CDS related code to a separate class Reviewed-by: mchung, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From erikj at openjdk.java.net Tue Sep 22 17:02:59 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Sep 2020 17:02:59 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 07:10:47 GMT, Bernhard Urban-Forster wrote: >> I assume you need the rest of the PATH on Windows. > >> I assume you need the rest of the PATH on Windows. > > Doesn't look like it actually. I've reverted it, thanks for catching it. Thanks, I tried the updated patch and it works now. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From jjg at openjdk.java.net Tue Sep 22 17:37:03 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 22 Sep 2020 17:37:03 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v2] In-Reply-To: References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: On Mon, 21 Sep 2020 10:47:40 GMT, Hannes Walln?fer wrote: >> This pull request is identical with the RFR previously sent for the Mercurial repository: >> >> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html >> >> I'm copy-pasting the comments from the original RFR below. >> >> Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting >> code for setting up external links. >> The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for >> prereleases. Platform documentation URLs can be configured using the new --link-platform-properties option to >> provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on >> the new options. The feature can be disabled using the --no-platform-link option, generating the same output as >> previously. One problem I had to solve was how to handle the transition from prerelease versions to final releases, >> since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that >> switch via code change at a time shortly before release. The way it is done is that we determine if the current >> javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(), >> and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This >> means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with >> source version 15 will generate links to the final release documentation) but I think this is acceptable. Another >> issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to >> pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally >> there should be one test with a clear message. Because of this, when a release is encountered for which no >> element-list is available a warning is generated instead of an error, and the documentation is generated without >> platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new >> test to fail with a relatively clear message of what is wrong. >> *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we >> still need to maintain element-lists for older versions, so I?m not sure it?s worth it. >> >> For existing tests that check output affected by the new option I added the --no-platform-link option to disable the >> feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static >> release or source version, which we don?t want either). I updated the CSR to the new code. It also needs to be >> reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 >> >> Thanks, >> Hannes > > Hannes Walln?fer has updated the pull request incrementally with three additional commits since the last revision: > > - Merge pull request #1 from lahodaj/JDK-8216497 > > Automatically generate the elements-list data from the ct.sym for releases 11+, including the current release under > development > - Generating current release list for javadoc; using hardcoded lists for versions < 11 > - Attempting to (mostly) generate the javadoc release manifests from ct.sym historical data. Generally excellent. Some feedback inline. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 350: > 348: > 349: doclet.usage.excludedocfilessubdir.parameters=\ > 350: :.. 3 dots for ellipsis? 2 dots is "parent directory" src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 384: > 382: > 383: doclet.usage.no-platform-link.description=\ > 384: Do not generate links to platform documentation Suggest: Do not generate links to the platform documentation src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java line 194: > 192: > 193: /** > 194: * Argument for command-line option {@code --no-platform-link}. minor: would "--no-platform-links" (plural) be a better name for the option? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java line 435: > 433: }, > 434: > 435: new Option(resources, "--no-platform-link") { Repeating preceding comment: would `--no-platform-links` (plural) be a better name? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 236: > 234: * @param linkPlatformProperties path or URL to properties file containing > 235: * platform documentation URLs, or null > 236: * @param reporter The {@code DocErrorReporter} used to report errors. (pedantic) param descriptions are typically phrases (no initial capital, no trailing period) In this case, your two `@param` descriptions are inconsistent src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 323: > 321: props.load(inputStream); > 322: } > 323: url = props.getProperty("doclet.platform.docs." + version); Similar to other file-or-url arguments: good! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 340: > 338: private int getSourceVersionNumber() { > 339: SourceVersion sourceVersion = configuration.docEnv.getSourceVersion(); > 340: // TODO it would be nice if this was provided by SourceVersion File an RFE for `SourceVersion` test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java line 49: > 47: javadoc("-d", "out-1", > 48: "-sourcepath", testSrc, > 49: "--no-platform-link", I see lots of instances of `no-platform-link` in this and subsequent tests. `JavadocTester` does have the concept of default options, although that may be more for the behavior after executing javadoc and not for the options given to javadoc itself. Is it worth supporting default javadoc options, since that the default can be disabled for specific tests? ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From jjg at openjdk.java.net Tue Sep 22 17:37:03 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 22 Sep 2020 17:37:03 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v2] In-Reply-To: References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: On Tue, 22 Sep 2020 17:24:19 GMT, Jonathan Gibbons wrote: >> Hannes Walln?fer has updated the pull request incrementally with three additional commits since the last revision: >> >> - Merge pull request #1 from lahodaj/JDK-8216497 >> >> Automatically generate the elements-list data from the ct.sym for releases 11+, including the current release under >> development >> - Generating current release list for javadoc; using hardcoded lists for versions < 11 >> - Attempting to (mostly) generate the javadoc release manifests from ct.sym historical data. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 323: > >> 321: props.load(inputStream); >> 322: } >> 323: url = props.getProperty("doclet.platform.docs." + version); > > Similar to other file-or-url arguments: good! As a possibly-later cleanup, should we have a single utility method somewhere (in this class) to open a stream on a file-or-url? ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From mbeckwit at openjdk.java.net Tue Sep 22 18:38:11 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Tue, 22 Sep 2020 18:38:11 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v4] In-Reply-To: References: Message-ID: <9AWXqWBreFSnBvXc9kzj0R7RIIRjmdg3nDz859KKD5Q=.df3d538f-a8d7-4e22-8d8c-76371172f75d@github.com> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - 8248787: G1: Workaround MSVC bug Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248670: Windows: Exception handling support on AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248660: AArch64: Make _clear_cache and _nop portable Summary: __builtin___clear_cache, etc. Contributed-by: mbeckwit, luhenry, burban - 8248659: AArch64: Extend CPU Feature detection Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248656: Add Windows AArch64 platform support code Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248498: Add build system support for Windows AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248663: AArch64: Avoid existing macros/keywords of MSVC Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248676: AArch64: Add workaround for LITable constructor Reviewed-by: aph Contributed-by: mbeckwit, luhenry, burban - 8248500: AArch64: Remove the r18 dependency on Windows AArch64 (regenerate tests) Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - ... and 3 more: https://git.openjdk.java.net/jdk/compare/7b860120...50ab8edf ------------- Changes: https://git.openjdk.java.net/jdk/pull/212/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=03 Stats: 2970 lines in 69 files changed: 2407 ins; 275 del; 288 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From gnu.andrew at redhat.com Wed Sep 23 03:39:09 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Sep 2020 04:39:09 +0100 Subject: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal In-Reply-To: References: <20200918054022.GA353844@stopbrexit> Message-ID: <20200923033909.GC577314@stopbrexit> On 11:22 Fri 18 Sep , Severin Gehwolf wrote: > Hi Andrew, > > > Build is still broken for me with this patch: > > > > /usr/bin/cp /home/ahughes/builder/8u-dev/jdk/objs/java_objs/java.diz /home/ahughes/builder/8u-dev/jdk/bin/java.diz > > /usr/bin/cp: cannot stat '/home/ahughes/builder/8u-dev/jdk/objs/java_objs/java.diz': No such file or directory > > > > where --with-native-debug-symbols is not set (pre-JDK-8207324) > > Hmm, I'm not sure how you are building. I've checked builds with: > > $ bash configure \ > --with-boot-jdk="/some/boot/jdk" \ > --with-extra-cflags=-Wno-error \ > --disable-zip-debug-info > $ make images > > and > > $ bash configure \ > --with-boot-jdk="/some/boot/jdk" \ > --with-extra-cflags=-Wno-error > $ make images > > and > > $ bash configure \ > --with-boot-jdk="/some/boot/jdk" \ > --with-extra-cflags=-Wno-error \ > --disable-debug-symbols > $ make images > > All seem to work fine for me. Are you sure you are not > setting POST_STRIP_CMD or the like explicitly somewhere else. Please > post the exact configure/make invocations you are using. > > FWIW, that bug you've referenced seems wrong: > 8207324: aarch64 jtreg: assert in TestOptionsWithRanges.jtr > > You probably meant JDK-8036003: > 8036003: Add --with-native-debug-symbols=[none|internal|external|zipped] No, JDK-8207234 (must have flipped the digits) as referenced in common/autoconf/jdk-options.m4. This is building with: $ make [...] STRIP_POLICY=no_strip > > > The use of these two conditionals seems odd to me. What we want to know > > is whether zipped debuginfo is in use. > > No. We want to know whether or not external debug symbols (zipped or > otherwise) are in use. > > > This is not the same as debug symbols > > in general being enabled. > > Yes. Correctly so. > > > Also, DEBUGINFO_EXT is only being set when > > ZIP_DEBUGINFO_FILES is true! > > How so? > > ifeq ($(ZIP_DEBUGINFO_FILES), true) > DEBUGINFO_EXT := .diz > else ifeq ($(OPENJDK_TARGET_OS), macosx) > DEBUGINFO_EXT := .dSYM > else ifeq ($(OPENJDK_TARGET_OS), windows) > DEBUGINFO_EXT := .pdb > else > DEBUGINFO_EXT := .debuginfo > endif > > On Linux with --with-native-debug-symbols=external this ends up with: > > DEBUGINFO_EXT := .debuginfo > Right, I misread this. Sorry for the confusion. It was late, and what should have been a simple merge led to an unexpected build failure from this. > > POST_STRIP_CMD seems to only be used in image creation, so I don't > > think checking this is appropriate either. > > Seems debatable. > I don't see how... $ grep -r 'POST_STRIP_CMD' make jdk/make/ jdk/make/Images.gmk:ifneq ($(POST_STRIP_CMD), ) jdk/make/Images.gmk: $(POST_STRIP_CMD) $< That's the only instance, other than in your patch. $ grep -r 'STRIP_POLICY' make jdk/make/ make/common/NativeCompilation.gmk: ifeq ($$($1_STRIP_POLICY),) make/common/NativeCompilation.gmk: $1_STRIP_POLICY:=$$(STRIP_POLICY) make/common/NativeCompilation.gmk: ifneq ($$($1_STRIP_POLICY), no_strip) make/common/NativeCompilation.gmk: ifneq ($$($1_STRIP_POLICY), no_strip) make/common/NativeCompilation.gmk: ifneq ($$($1_STRIP_POLICY), no_strip) make/common/NativeCompilation.gmk: ifneq ($$($1_STRIP_POLICY), no_strip) make/common/NativeCompilation.gmk: ifneq ($$($1_STRIP_POLICY), no_strip) TL;DR: we need a check on STRIP_POLICY in the conditional. It doesn't really matter whether this is in addition to POST_STRIP_CMD or not, but it's needed as STRIP_POLICY=no_strip alone worked before and now it doesn't. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From github.com+471021+marschall at openjdk.java.net Wed Sep 23 04:03:05 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Wed, 23 Sep 2020 04:03:05 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v4] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=03 Stats: 753 lines in 65 files changed: 153 ins; 149 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From dholmes at openjdk.java.net Wed Sep 23 05:13:17 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Sep 2020 05:13:17 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Tue, 22 Sep 2020 08:43:04 GMT, Erik Gahlin wrote: >> Marked as reviewed by kvn (Reviewer). > > Have you run the JFR tests in test/jdk/jdk/jfr? @marschall Please do not force-push anything as it breaks the commit history in the PR and renders previous reviews/comments obsolete. There is no way for the reviewers to see what changed between the commit they reviewed and the commit now in the PR. To update to latest changes you should have just merged your branch with your (up-to-date) local master, committed that merge in your local branch and then pushed that commit to your Personal Fork. The skara tooling will flatten the series of commits in a PR into one single well-formed commit that is pushed to the master branch of the repo. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From zuismanm at gmail.com Wed Sep 23 10:29:37 2020 From: zuismanm at gmail.com (Moshe Zuisman) Date: Wed, 23 Sep 2020 13:29:37 +0300 Subject: How can I know which vulnerabilities (CVEs) are fixed in specific tag of open JDK? Message-ID: Hi. I have the following problem. We provide OpenJDK binary distro with our product. With the current version we provided JDK8u-b222 Customer comes with a list of CVEs and asks if they are fixed in distro, we provided with our product. For example he asks about cve-2014-3566, jre-vuln-cve-2017-3241(it is only a part of the full list he asks about). In the release note of b222 ( https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009840.html) I do not see any info about fixed CVEs. Is there any way I figure out what is a full list of CVEs - fixed in specific, or opposite - can I somehow know if some specific CVE fixed in some build? From Alan.Bateman at oracle.com Wed Sep 23 10:38:32 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Sep 2020 11:38:32 +0100 Subject: How can I know which vulnerabilities (CVEs) are fixed in specific tag of open JDK? In-Reply-To: References: Message-ID: On 23/09/2020 11:29, Moshe Zuisman wrote: > Hi. > I have the following problem. We provide OpenJDK binary distro with our > product. > With the current version we provided JDK8u-b222 > Customer comes with a list of CVEs and asks if they are fixed in distro, we > provided with our product. > For example he asks about cve-2014-3566, jre-vuln-cve-2017-3241(it is only > a part of the full list he asks about). > In the release note of b222 ( > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009840.html) I > do not see any info about fixed CVEs. > Is there any way I figure out what is a full list of CVEs - fixed in > specific, or opposite - can I somehow know if some specific CVE fixed in > some build? Advisories are posted to the vuln-announce mailing list and also linked from the advisories page [1]. -Alan [1] https://openjdk.java.net/groups/vulnerability/advisories/ From hannesw at openjdk.java.net Wed Sep 23 11:06:50 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 23 Sep 2020 11:06:50 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v2] In-Reply-To: References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: On Tue, 22 Sep 2020 17:30:19 GMT, Jonathan Gibbons wrote: >> Hannes Walln?fer has updated the pull request incrementally with three additional commits since the last revision: >> >> - Merge pull request #1 from lahodaj/JDK-8216497 >> >> Automatically generate the elements-list data from the ct.sym for releases 11+, including the current release under >> development >> - Generating current release list for javadoc; using hardcoded lists for versions < 11 >> - Attempting to (mostly) generate the javadoc release manifests from ct.sym historical data. > > test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java line 49: > >> 47: javadoc("-d", "out-1", >> 48: "-sourcepath", testSrc, >> 49: "--no-platform-link", > > I see lots of instances of `no-platform-link` in this and subsequent tests. `JavadocTester` does have the concept of > default options, although that may be more for the behavior after executing javadoc and not for the options given to > javadoc itself. Is it worth supporting default javadoc options, since that the default can be disabled for specific > tests? I can't really find how `JavadocTester` uses or supports default options. My concern with this would be that it would make JavadocTester less transparent and intuitive to use, as you'd have to be aware what the default options are. ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From zuismanm at gmail.com Wed Sep 23 11:35:53 2020 From: zuismanm at gmail.com (Moshe Zuisman) Date: Wed, 23 Sep 2020 14:35:53 +0300 Subject: How can I know which vulnerabilities (CVEs) are fixed in specific tag of open JDK? In-Reply-To: References: Message-ID: Thanks! But the problem here is that this list includes only vulnerabilities, dated by 2019-2020. Vulnerabilities we (our customer) are interested in - are of 2014-2015. ??, 23 ????. 2020 ?. ? 13:38, Alan Bateman : > On 23/09/2020 11:29, Moshe Zuisman wrote: > > Hi. > > I have the following problem. We provide OpenJDK binary distro with our > > product. > > With the current version we provided JDK8u-b222 > > Customer comes with a list of CVEs and asks if they are fixed in distro, > we > > provided with our product. > > For example he asks about cve-2014-3566, jre-vuln-cve-2017-3241(it is > only > > a part of the full list he asks about). > > In the release note of b222 ( > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009840.html) > I > > do not see any info about fixed CVEs. > > Is there any way I figure out what is a full list of CVEs - fixed in > > specific, or opposite - can I somehow know if some specific CVE fixed in > > some build? > Advisories are posted to the vuln-announce mailing list and also linked > from the advisories page [1]. > > -Alan > > [1] https://openjdk.java.net/groups/vulnerability/advisories/ > From mbeckwit at openjdk.java.net Wed Sep 23 13:23:43 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Wed, 23 Sep 2020 13:23:43 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5] In-Reply-To: References: Message-ID: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: Update orderAccess_windows_aarch64.hpp changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/50ab8edf..4da7b89e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From mbeckwit at openjdk.java.net Wed Sep 23 13:23:43 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Wed, 23 Sep 2020 13:23:43 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5] In-Reply-To: References: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com> Message-ID: On Mon, 21 Sep 2020 14:47:15 GMT, Bernhard Urban-Forster wrote: >>> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >>> >>> On 18/09/2020 11:14, Monica Beckwith wrote: >>> >>> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >>> >>> The diffs in assembler_aarch64.cpp are mostly spurious. Please try this. >> >> >> Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the >> retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part >> would look indeed nicer with that: https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ): >> --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py >> +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py >> @@ -13,6 +13,8 @@ class Register(Operand): >> >> def generate(self): >> self.number = random.randint(0, 30) >> + if self.number == 18: >> + self.number = 17 >> return self >> >> def astr(self, prefix): >> @@ -37,6 +39,8 @@ class GeneralRegisterOrZr(Register): >> >> def generate(self): >> self.number = random.randint(0, 31) >> + if self.number == 18: >> + self.number = 16 >> return self >> >> def astr(self, prefix = ""): >> @@ -54,6 +58,8 @@ class GeneralRegisterOrZr(Register): >> class GeneralRegisterOrSp(Register): >> def generate(self): >> self.number = random.randint(0, 31) >> + if self.number == 18: >> + self.number = 15 >> return self >> >> def astr(self, prefix = ""): >> @@ -1331,7 +1337,7 @@ generate(SpecialCases, [["ccmn", "__ ccmn(zr, zr, 3u, Assembler::LE);", >> ["st1w", "__ sve_st1w(z0, __ S, p1, Address(r0, 7));", "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"], >> ["st1b", "__ sve_st1b(z0, __ B, p2, Address(sp, r1));", "st1b\t{z0.b}, p2, [sp, x1]"], >> ["st1h", "__ sve_st1h(z0, __ H, p3, Address(sp, r8));", "st1h\t{z0.h}, p3, [sp, x8, LSL #1]"], >> - ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r18));", "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"], >> + ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r17));", "st1d\t{z0.d}, p4, [x0, x17, >> LSL #3]"], >> ["ldr", "__ sve_ldr(z0, Address(sp));", "ldr\tz0, [sp]"], >> ["ldr", "__ sve_ldr(z31, Address(sp, -256));", "ldr\tz31, [sp, #-256, MUL VL]"], >> ["str", "__ sve_str(z8, Address(r8, 255));", "str\tz8, [x8, #255, MUL VL]"], > >> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >> >> On 21/09/2020 09:18, Bernhard Urban-Forster wrote: >> >> > Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the >> > retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part >> > would look indeed nicer with that: https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ): >> > [...] >> >> Yes, better. Thanks. > > Great, I've updated the PR. Thank you! Thanks, Andrew for catching that. I have made the needful changes. -Monica > _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ > > On 18/09/2020 11:14, Monica Beckwith wrote: > > > This is a continuation of > > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > > * We've improved the write barrier as suggested by Andrew [1] > > It's still wrong, I'm afraid. This is not a full barrier: > > +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_acq_rel); > > it is only StoreStore|LoadStore|LoadLoad, but you need StoreLoad as > well. It might well be that you get the same DMB ISH instruction, but > unless you use a StoreLoad barrier here it's theoretically possible > for a compiler to reorder accesses so that a processor sees its own > stores before other processors do. (And it's confusing for the reader > too.) > > Use: > > +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_seq_cst); > > See here: > > https://en.cppreference.com/w/cpp/atomic/memory_order > > memory_order_seq_cst "...plus a single total order exists in which all > threads observe all modifications in the same order (see > Sequentially-consistent ordering below)" > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From rwestberg at openjdk.java.net Wed Sep 23 13:49:49 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Wed, 23 Sep 2020 13:49:49 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v2] In-Reply-To: References: Message-ID: > A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests > for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open > source repositories. I've incorporated the feedback into an updated version that I believe is ready to be integrated. > If this is integrated into the `master` branch, future branches created and updated in personal forks will build and > run the basic tier 1 tests as described in this configuration, on Linux, Windows and macOS (all on x64). It's of course > possible for any contributor to opt out fully or partially of these automatic runs in a few different ways. To opt out > completely, a contributor can simply disable GitHub Actions on their personal fork, and no further jobs will be > executed. Another option is to add a repository secret [4] with the name `JDK_SUBMIT_FILTER` set to any value. If this > is set, only branches prefixed with `submit/` will be subject to automatic build and test. This can also be further > refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a value such as `Linux x64, Windows x64` to > limit automatic build and test to these two platforms. It will still be possible to run the tests on any branch and/or > platform by manually triggering the workflow. To see what this looks like in practice, an example run can be found > here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is currently a failing test on Windows > which is tracked by JDK-8249095, which should probably be resolved before this change is integrated). Best regards, > Robin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits [4] > https://docs.github.com/en/actions/reference/encrypted-secrets Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: Extract all hardcoded versions to a separate configuration file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/284/files - new: https://git.openjdk.java.net/jdk/pull/284/files/4074e334..7f260ede Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=00-01 Stats: 170 lines in 2 files changed: 102 ins; 5 del; 63 mod Patch: https://git.openjdk.java.net/jdk/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/284/head:pull/284 PR: https://git.openjdk.java.net/jdk/pull/284 From rwestberg at openjdk.java.net Wed Sep 23 13:49:50 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Wed, 23 Sep 2020 13:49:50 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions In-Reply-To: References: <2gwNsqQ3OJqaTKD66CfHrVWFbDVxxcLEvM3oMOPejOo=.5bad0484-7502-422b-8e4b-6e970959584a@github.com> <1BduorxiB-c33s_OlKgtJulsazxapxCj2kqGhAj1UiA=.9c618556-fb24-4236-aefe-bf37d5a4a4b4@github.com> Message-ID: On Tue, 22 Sep 2020 14:05:42 GMT, Erik Joelsson wrote: >> Sure, should not be that hard to parse something similar. The GitHub actions will probably need it in JSON format at >> some point, but nothing a little `sed -e '1i {' -e 's/#.*//g' -e 's/"//g' -e 's/(.*)=(.*)/"\1": "\2",/g' -e >> '$s/,\s{0,}$/}/'` won't solve. Any suggestion for the location and name of such a file? I'm thinking it would contain >> entries like this: BOOT_JDK_VERSION="14.0.2" JTREG_VERSION="jtreg5.1-b01" >> GTEST_VERSION="release-1.8.1" >> LINUX_X64_BOOT_JDK_FILENAME="openjdk-14.0.2_linux-x64_bin.tar.gz" >> LINUX_X64_BOOT_JDK_URL="https://download.java.net/java/GA/jdk14.0.2/205943a0976c4ed48cb16f1043c5c647/12/GPL/openjdk-14.0.2_linux-x64_bin.tar.gz" >> LINUX_X64_BOOT_JDK_SHA256="91310200f072045dc6cef2c8c23e7e6387b37c46e9de49623ce0fa461a24623d" > > The other primary consumer of this is make/conf/jib-profiles.js. The make/conf dir would make sense to me. > > The challenge here is creating a set of variables that are suitable enough for both config files to consume. For > BootJDK, we never bothered with bumping the version for updates, and I very much doubt we will do that in the future > for github actions, so a plain major version 14, and soon 15, would be preferred from my point of view. This is however > not enough for jib-profiles.js (yet) so we can't really share bootjdk config for now anyway. For jtreg, we specify 5.1 > and b01 as two separate metadata values. For gtest we specify the version as 1.8.1. I added `make/conf/test-dependencies` with version numbers specified on the format that `jib-profiles.js` would expect. Actually using them from that file as well could perhaps be a separate task though. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/284 From hannesw at openjdk.java.net Wed Sep 23 14:20:12 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 23 Sep 2020 14:20:12 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v3] In-Reply-To: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: <1KT8mUPZcjXK-MHKDlrStvUvwJFt36fi4zq_HFwZQQc=.676ec735-6d55-4440-b040-8cdbe3fc0d4d@github.com> > This pull request is identical with the RFR previously sent for the Mercurial repository: > > https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html > > I'm copy-pasting the comments from the original RFR below. > > Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting > code for setting up external links. > The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for > prereleases. Platform documentation URLs can be configured using the new --link-platform-properties option to > provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on > the new options. The feature can be disabled using the --no-platform-link option, generating the same output as > previously. One problem I had to solve was how to handle the transition from prerelease versions to final releases, > since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that > switch via code change at a time shortly before release. The way it is done is that we determine if the current > javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(), > and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This > means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with > source version 15 will generate links to the final release documentation) but I think this is acceptable. Another > issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to > pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally > there should be one test with a clear message. Because of this, when a release is encountered for which no > element-list is available a warning is generated instead of an error, and the documentation is generated without > platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new > test to fail with a relatively clear message of what is wrong. > *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we > still need to maintain element-lists for older versions, so I?m not sure it?s worth it. > > For existing tests that check output affected by the new option I added the --no-platform-link option to disable the > feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static > release or source version, which we don?t want either). I updated the CSR to the new code. It also needs to be > reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 > > Thanks, > Hannes Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Rename --no-platform-link option plus minor cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/171/files - new: https://git.openjdk.java.net/jdk/pull/171/files/6d659ae3..6009dd70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=171&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=171&range=01-02 Stats: 73 lines in 38 files changed: 0 ins; 0 del; 73 mod Patch: https://git.openjdk.java.net/jdk/pull/171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/171/head:pull/171 PR: https://git.openjdk.java.net/jdk/pull/171 From valeriep at openjdk.java.net Wed Sep 23 17:09:51 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 23 Sep 2020 17:09:51 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > remove JDKOPT_DETECT_INTREE_EC from configure.ac src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java line 219: > 217: > 218: Collection supportedCurves; > 219: supportedCurves = CurveDB.getSupportedCurves(); Shouldn't the supportedCurves be the hardcoded 3 curves? ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From erikj at openjdk.java.net Wed Sep 23 17:27:09 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 23 Sep 2020 17:27:09 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions In-Reply-To: References: <2gwNsqQ3OJqaTKD66CfHrVWFbDVxxcLEvM3oMOPejOo=.5bad0484-7502-422b-8e4b-6e970959584a@github.com> <1BduorxiB-c33s_OlKgtJulsazxapxCj2kqGhAj1UiA=.9c618556-fb24-4236-aefe-bf37d5a4a4b4@github.com> Message-ID: On Wed, 23 Sep 2020 13:46:50 GMT, Robin Westberg wrote: >> The other primary consumer of this is make/conf/jib-profiles.js. The make/conf dir would make sense to me. >> >> The challenge here is creating a set of variables that are suitable enough for both config files to consume. For >> BootJDK, we never bothered with bumping the version for updates, and I very much doubt we will do that in the future >> for github actions, so a plain major version 14, and soon 15, would be preferred from my point of view. This is however >> not enough for jib-profiles.js (yet) so we can't really share bootjdk config for now anyway. For jtreg, we specify 5.1 >> and b01 as two separate metadata values. For gtest we specify the version as 1.8.1. > > I added `make/conf/test-dependencies` with version numbers specified on the format that `jib-profiles.js` would expect. > Actually using them from that file as well could perhaps be a separate task though. :) The version-numbers file (which is also a shared properties style file) is not using quotes for values, which is fine as long as there are no spaces. I believe if you read it as a properties file, you need to strip the quotes if you have them. I prefer if version-numbers and test-dependencies using the same format. Otherwise this looks good to me! ------------- PR: https://git.openjdk.java.net/jdk/pull/284 From jjg at openjdk.java.net Wed Sep 23 17:57:04 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 23 Sep 2020 17:57:04 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v3] In-Reply-To: <1KT8mUPZcjXK-MHKDlrStvUvwJFt36fi4zq_HFwZQQc=.676ec735-6d55-4440-b040-8cdbe3fc0d4d@github.com> References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> <1KT8mUPZcjXK-MHKDlrStvUvwJFt36fi4zq_HFwZQQc=.676ec735-6d55-4440-b040-8cdbe3fc0d4d@github.com> Message-ID: On Wed, 23 Sep 2020 14:20:12 GMT, Hannes Walln?fer wrote: >> This pull request is identical with the RFR previously sent for the Mercurial repository: >> >> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html >> >> I'm copy-pasting the comments from the original RFR below. >> >> Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting >> code for setting up external links. >> The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for >> prereleases. Platform documentation URLs can be configured using the new --link-platform-properties option to >> provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on >> the new options. The feature can be disabled using the --no-platform-link option, generating the same output as >> previously. One problem I had to solve was how to handle the transition from prerelease versions to final releases, >> since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that >> switch via code change at a time shortly before release. The way it is done is that we determine if the current >> javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(), >> and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This >> means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with >> source version 15 will generate links to the final release documentation) but I think this is acceptable. Another >> issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to >> pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally >> there should be one test with a clear message. Because of this, when a release is encountered for which no >> element-list is available a warning is generated instead of an error, and the documentation is generated without >> platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new >> test to fail with a relatively clear message of what is wrong. >> *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we >> still need to maintain element-lists for older versions, so I?m not sure it?s worth it. >> >> For existing tests that check output affected by the new option I added the --no-platform-link option to disable the >> feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static >> release or source version, which we don?t want either). I updated the CSR to the new code. It also needs to be >> reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 >> >> Thanks, >> Hannes > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Rename --no-platform-link option plus minor cleanup I agree with the judgement call to _not_ introduce default javadoc options. It was just a suggestion to consider, and I agree it would make the calls less intuitively obvious, for the short term gain of editing fewer tests here. It also helped to realize that the support default platform links does _not_ involve any network access. FWIW, the precedent in JavadocTester that I was referrng to is `setAutomaticCheckLinks`, `setAutomaticCheckAccessibility`, but those are about default actions after javadoc has been run, and not about default methods. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/171 From rwestberg at openjdk.java.net Wed Sep 23 17:58:22 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Wed, 23 Sep 2020 17:58:22 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v3] In-Reply-To: References: Message-ID: > A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests > for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open > source repositories. I've incorporated the feedback into an updated version that I believe is ready to be integrated. > If this is integrated into the `master` branch, future branches created and updated in personal forks will build and > run the basic tier 1 tests as described in this configuration, on Linux, Windows and macOS (all on x64). It's of course > possible for any contributor to opt out fully or partially of these automatic runs in a few different ways. To opt out > completely, a contributor can simply disable GitHub Actions on their personal fork, and no further jobs will be > executed. Another option is to add a repository secret [4] with the name `JDK_SUBMIT_FILTER` set to any value. If this > is set, only branches prefixed with `submit/` will be subject to automatic build and test. This can also be further > refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a value such as `Linux x64, Windows x64` to > limit automatic build and test to these two platforms. It will still be possible to run the tests on any branch and/or > platform by manually triggering the workflow. To see what this looks like in practice, an example run can be found > here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is currently a failing test on Windows > which is tracked by JDK-8249095, which should probably be resolved before this change is integrated). Best regards, > Robin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits [4] > https://docs.github.com/en/actions/reference/encrypted-secrets Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary quoting from the test-dependencies file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/284/files - new: https://git.openjdk.java.net/jdk/pull/284/files/7f260ede..496d896c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=01-02 Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/284/head:pull/284 PR: https://git.openjdk.java.net/jdk/pull/284 From rwestberg at openjdk.java.net Wed Sep 23 17:58:22 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Wed, 23 Sep 2020 17:58:22 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions In-Reply-To: References: <2gwNsqQ3OJqaTKD66CfHrVWFbDVxxcLEvM3oMOPejOo=.5bad0484-7502-422b-8e4b-6e970959584a@github.com> <1BduorxiB-c33s_OlKgtJulsazxapxCj2kqGhAj1UiA=.9c618556-fb24-4236-aefe-bf37d5a4a4b4@github.com> Message-ID: <29PQR9-EihUS6UB23xC4IPyIOjkAKo0UuDWgfbw0fN8=.e478235a-81e3-48c1-a291-5f82f1917c32@github.com> On Wed, 23 Sep 2020 17:24:39 GMT, Erik Joelsson wrote: >> I added `make/conf/test-dependencies` with version numbers specified on the format that `jib-profiles.js` would expect. >> Actually using them from that file as well could perhaps be a separate task though. :) > > The version-numbers file (which is also a shared properties style file) is not using quotes for values, which is fine > as long as there are no spaces. I believe if you read it as a properties file, you need to strip the quotes if you have > them. I prefer if version-numbers and test-dependencies using the same format. Otherwise this looks good to me! Sounds reasonable, didn't notice that discrepancy! Fixed in the latest commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/284 From github.com+471021+marschall at openjdk.java.net Wed Sep 23 18:41:06 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Wed, 23 Sep 2020 18:41:06 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=04 Stats: 749 lines in 65 files changed: 149 ins; 149 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From kvn at openjdk.java.net Wed Sep 23 18:55:29 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 23 Sep 2020 18:55:29 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 23 Sep 2020 18:41:06 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains one commit: > 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Update seems fine. Thanks for JFR testing and fixing. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/45 From minqi at openjdk.java.net Wed Sep 23 19:22:06 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 23 Sep 2020 19:22:06 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 19:01:18 GMT, Ioi Lam wrote: >> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous >> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the >> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses >> function. Tests: tier1-4 > > src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 67: > >> 65: if (VM.isDumpLoadedClassListSetAndOpen) { >> 66: VM.cdsTraceResolve(traceLF); >> 67: } > > GenerateJLIClassesHelper shouldn't need to know why the trace is needed. Also, "cdsTraceResolve" is too generic. > > I think it's better to have > if (TRACE_RESOLVE || VM.CDS_TRACE_JLINV_RESOLVE) { > ... > VM.cdsTraceJLINVResolve(traceLF); > > The acronym JLINV is used in > [methodHandles.cpp](https://github.com/openjdk/jdk/blob/ce93cbce77e1f4baa52676826c8ae27d474360b6/src/hotspot/share/prims/methodHandles.cpp#L1524) With CDS related code moved to CDS.java, I think we should keep TRACE_RESOLVE here. A new name like suggested by Mandy, logTraceResolve in CDS.java > src/java.base/share/classes/jdk/internal/misc/VM.java line 490: > >> 488: */ >> 489: public static boolean isDumpLoadedClassListSetAndOpen; >> 490: private static native boolean isDumpLoadedClassListSetAndOpen0(); > > I would suggest to rename to `isDumpingLoadedClassList` Will change. ------------- PR: https://git.openjdk.java.net/jdk/pull/193 From egahlin at openjdk.java.net Wed Sep 23 20:05:14 2020 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 23 Sep 2020 20:05:14 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 23 Sep 2020 18:41:06 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains one commit: > 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From ascarpino at openjdk.java.net Wed Sep 23 22:27:34 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 23 Sep 2020 22:27:34 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: <8nr0RrYr-7cnjo4sSs9BpMWPCfFptjBDVu56hoDxl0U=.d5addb7e-5646-4f58-a5e7-29eda6cae1fc@github.com> References: <8nr0RrYr-7cnjo4sSs9BpMWPCfFptjBDVu56hoDxl0U=.d5addb7e-5646-4f58-a5e7-29eda6cae1fc@github.com> Message-ID: On Tue, 22 Sep 2020 13:53:12 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> remove JDKOPT_DETECT_INTREE_EC from configure.ac > > src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java line 180: > >> 178: ((privNC != null) ? privNC.toString() : " unknown") + >> 179: ", PublicKey:" + >> 180: ((pubNC != null) ? pubNC.toString() : " unknown"))); > > Spacing issues: "PublicKey:" should be "PublicKey: " and " unknown" should be "unknown". After considering the keys closer, I don't need to specify the key anymore. PrivateKey and PublicKey were removed ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From ascarpino at openjdk.java.net Wed Sep 23 22:27:34 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 23 Sep 2020 22:27:34 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 17:07:21 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> remove JDKOPT_DETECT_INTREE_EC from configure.ac > > src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java line 219: > >> 217: >> 218: Collection supportedCurves; >> 219: supportedCurves = CurveDB.getSupportedCurves(); > > Shouldn't the supportedCurves be the hardcoded 3 curves? Ah yes. Thanks for seeing that. ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From mikael at openjdk.java.net Wed Sep 23 22:40:01 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 23 Sep 2020 22:40:01 GMT Subject: RFR: 8248984: Bump minimum boot jdk to JDK 15 Message-ID: JDK 15 is now GA. The minimum boot JDK version for mainline/JDK 16 should be bumped to this version. Testing: tier1-5 passed with a slightly earlier version of this change. Re-running tier1 now for good luck. ------------- Commit messages: - 8248984: Bump minimum boot jdk to JDK 15 Changes: https://git.openjdk.java.net/jdk/pull/326/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=326&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248984 Stats: 18 lines in 2 files changed: 0 ins; 13 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/326/head:pull/326 PR: https://git.openjdk.java.net/jdk/pull/326 From darcy at openjdk.java.net Wed Sep 23 22:45:13 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 23 Sep 2020 22:45:13 GMT Subject: RFR: 8248984: Bump minimum boot jdk to JDK 15 In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 22:32:37 GMT, Mikael Vidstedt wrote: > JDK 15 is now GA. The minimum boot JDK version for mainline/JDK 16 should be bumped to this version. > > Testing: tier1-5 passed with a slightly earlier version of this change. Re-running tier1 now for good luck. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/326 From erikj at openjdk.java.net Wed Sep 23 22:50:46 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 23 Sep 2020 22:50:46 GMT Subject: RFR: 8248984: Bump minimum boot jdk to JDK 15 In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 22:32:37 GMT, Mikael Vidstedt wrote: > JDK 15 is now GA. The minimum boot JDK version for mainline/JDK 16 should be bumped to this version. > > Testing: tier1-5 passed with a slightly earlier version of this change. Re-running tier1 now for good luck. @rwestberg Note that you will need to update your actions patch if this goes in first. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/326 From kvn at openjdk.java.net Wed Sep 23 22:50:52 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 23 Sep 2020 22:50:52 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 23 Sep 2020 20:02:45 GMT, Erik Gahlin wrote: >> Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains one commit: >> 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate > > Marked as reviewed by egahlin (Reviewer). @marschall I will sponsor it after you integrate the latest update. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From minqi at openjdk.java.net Wed Sep 23 23:20:11 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 23 Sep 2020 23:20:11 GMT Subject: RFR: 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class Message-ID: This patch is a REDO for JDK-8253208 which was backed out since it caused runtime/cds/DeterministicDump.java failed, see JDK-8253495. Since the failure is another issue and only triggered by this patch, the test case now is put on ProblemList.txt. The real root cause for the failure is detailed in JDK-8253495. When JDK-8253208 was backed out, CDS.java remained without removed from that patch (see JDK-8253495 subtask), so this patch does not include CDS.java (this is why you will see CDS.c without CDS.java in this patch). Tests tier1-4 passed. ------------- Commit messages: - 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class Changes: https://git.openjdk.java.net/jdk/pull/327/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=327&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253500 Stats: 156 lines in 22 files changed: 57 ins; 53 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/327.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/327/head:pull/327 PR: https://git.openjdk.java.net/jdk/pull/327 From ascarpino at openjdk.java.net Wed Sep 23 23:38:03 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 23 Sep 2020 23:38:03 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v3] In-Reply-To: References: Message-ID: > This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The > SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will > remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, > sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, > X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 > prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: change exception for ec keyagreement fix supportedcurves in SunEC ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/289/files - new: https://git.openjdk.java.net/jdk/pull/289/files/8a04ce7a..1f9820ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=289&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=289&range=01-02 Stats: 20 lines in 3 files changed: 4 ins; 10 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/289/head:pull/289 PR: https://git.openjdk.java.net/jdk/pull/289 From mchung at openjdk.java.net Thu Sep 24 00:20:24 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 24 Sep 2020 00:20:24 GMT Subject: RFR: 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 23:05:59 GMT, Yumin Qi wrote: > This patch is a REDO for JDK-8253208 which was backed out since it caused runtime/cds/DeterministicDump.java failed, > see JDK-8253495. Since the failure is another issue and only triggered by this patch, the test case now is put on > ProblemList.txt. The real root cause for the failure is detailed in JDK-8253495. When JDK-8253208 was backed out, > CDS.java remained without removed from that patch (see JDK-8253495 subtask), so this patch does not include CDS.java > (this is why you will see CDS.c without CDS.java in this patch). Tests tier1-4 passed. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/327 From iklam at openjdk.java.net Thu Sep 24 02:03:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 24 Sep 2020 02:03:57 GMT Subject: RFR: 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 23:05:59 GMT, Yumin Qi wrote: > This patch is a REDO for JDK-8253208 which was backed out since it caused runtime/cds/DeterministicDump.java failed, > see JDK-8253495. Since the failure is another issue and only triggered by this patch, the test case now is put on > ProblemList.txt. The real root cause for the failure is detailed in JDK-8253495. When JDK-8253208 was backed out, > CDS.java remained without removed from that patch (see JDK-8253495 subtask), so this patch does not include CDS.java > (this is why you will see CDS.c without CDS.java in this patch). Tests tier1-4 passed. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/327 From dholmes at openjdk.java.net Thu Sep 24 05:00:16 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 24 Sep 2020 05:00:16 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 13:23:43 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > Update orderAccess_windows_aarch64.hpp > > changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided I've mainly looked at the non-Aarch64 specific changes. A couple of minor comments below. src/hotspot/os/windows/os_windows.cpp line 2546: > 2544: > 2545: #ifdef _M_ARM64 > 2546: // Unsafe memory access I'm not at all clear why this unsafe memory access handling is for Aarch64 only? src/hotspot/share/runtime/stubRoutines.cpp line 397: > 395: // test safefetch routines > 396: // Not on Windows 32bit until 8074860 is fixed > 397: #if ! (defined(_WIN32) && defined(_M_IX86)) && !defined(_M_ARM64) The comment needs updating to refer to Aarch64. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/212 From dholmes at openjdk.java.net Thu Sep 24 05:03:34 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 24 Sep 2020 05:03:34 GMT Subject: RFR: 8248984: Bump minimum boot jdk to JDK 15 In-Reply-To: References: Message-ID: <6TcVZjgo9FoccXHI59ck5lrA6nDr7IudBmfFgFbdSJ0=.178a3c35-77ce-4159-8254-3370074c807a@github.com> On Wed, 23 Sep 2020 22:32:37 GMT, Mikael Vidstedt wrote: > JDK 15 is now GA. The minimum boot JDK version for mainline/JDK 16 should be bumped to this version. > > Testing: tier1-5 passed with a slightly earlier version of this change. Re-running tier1 now for good luck. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/326 From dholmes at openjdk.java.net Thu Sep 24 05:14:47 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 24 Sep 2020 05:14:47 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5] In-Reply-To: References: Message-ID: <4-nb0OwmjwH4FpKoNor3BGZmsAKouFjMJpJ8uN62Y_s=.7de01521-af13-4ce1-ace9-80f4ef2a6d4f@github.com> On Thu, 24 Sep 2020 04:57:39 GMT, David Holmes wrote: >> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: >> >> Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided > > I've mainly looked at the non-Aarch64 specific changes. A couple of minor comments below. @mo-beck This PR should not be associated with any JBS issues which are targeted at repo-aarch64-port. All such issues should have been closed by now when the associated code was pushed to aarch64-port repo. That was the whole point of creating separate issues so that they could be tracked in the porting repo. Now that all of that work should be complete the only issue that should remain open in relation to the Windows-Aarch64 port is JDK-8248238. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From rwestberg at openjdk.java.net Thu Sep 24 09:10:04 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Thu, 24 Sep 2020 09:10:04 GMT Subject: RFR: 8248984: Bump minimum boot jdk to JDK 15 In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 22:47:47 GMT, Erik Joelsson wrote: >> JDK 15 is now GA. The minimum boot JDK version for mainline/JDK 16 should be bumped to this version. >> >> Testing: tier1-5 passed with a slightly earlier version of this change. Re-running tier1 now for good luck. > > @rwestberg Note that you will need to update your actions patch if this goes in first. @erikj79 Thanks for the heads-up, I've updated #284 to use 15 now. ------------- PR: https://git.openjdk.java.net/jdk/pull/326 From rwestberg at openjdk.java.net Thu Sep 24 09:14:30 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Thu, 24 Sep 2020 09:14:30 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v4] In-Reply-To: References: Message-ID: > A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests > for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open > source repositories. I've incorporated the feedback into an updated version that I believe is ready to be integrated. > If this is integrated into the `master` branch, future branches created and updated in personal forks will build and > run the basic tier 1 tests as described in this configuration, on Linux, Windows and macOS (all on x64). It's of course > possible for any contributor to opt out fully or partially of these automatic runs in a few different ways. To opt out > completely, a contributor can simply disable GitHub Actions on their personal fork, and no further jobs will be > executed. Another option is to add a repository secret [4] with the name `JDK_SUBMIT_FILTER` set to any value. If this > is set, only branches prefixed with `submit/` will be subject to automatic build and test. This can also be further > refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a value such as `Linux x64, Windows x64` to > limit automatic build and test to these two platforms. It will still be possible to run the tests on any branch and/or > platform by manually triggering the workflow. To see what this looks like in practice, an example run can be found > here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is currently a failing test on Windows > which is tracked by JDK-8249095, which should probably be resolved before this change is integrated). Best regards, > Robin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits [4] > https://docs.github.com/en/actions/reference/encrypted-secrets Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: Update boot JDK to 15 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/284/files - new: https://git.openjdk.java.net/jdk/pull/284/files/496d896c..de5074fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=02-03 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/284/head:pull/284 PR: https://git.openjdk.java.net/jdk/pull/284 From mbeckwit at openjdk.java.net Thu Sep 24 14:04:22 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Thu, 24 Sep 2020 14:04:22 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6] In-Reply-To: References: Message-ID: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith 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 17 additional commits since the last revision: - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc - cleanup for 8253457: Remove unimplemented register stack functions - Merge remote-tracking branch 'upstream/master' into jdk-windows - Update orderAccess_windows_aarch64.hpp changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided - 8248787: G1: Workaround MSVC bug Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248670: Windows: Exception handling support on AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248660: AArch64: Make _clear_cache and _nop portable Summary: __builtin___clear_cache, etc. Contributed-by: mbeckwit, luhenry, burban - 8248659: AArch64: Extend CPU Feature detection Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248656: Add Windows AArch64 platform support code Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248498: Add build system support for Windows AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - ... and 7 more: https://git.openjdk.java.net/jdk/compare/6cee388c...2b662010 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/4da7b89e..2b662010 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=04-05 Stats: 1938 lines in 234 files changed: 652 ins; 841 del; 445 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From mbeckwit at openjdk.java.net Thu Sep 24 15:15:45 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Thu, 24 Sep 2020 15:15:45 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7] In-Reply-To: References: Message-ID: <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request incrementally with two additional commits since the last revision: - os_windows: remove duplicated UMA handling - test_safefetch{32,N} works fine on win+aarch64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/2b662010..68f61d60 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=05-06 Stats: 22 lines in 2 files changed: 0 ins; 21 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Thu Sep 24 15:15:47 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Thu, 24 Sep 2020 15:15:47 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 04:45:16 GMT, David Holmes wrote: >> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: >> >> Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided > > src/hotspot/os/windows/os_windows.cpp line 2546: > >> 2544: >> 2545: #ifdef _M_ARM64 >> 2546: // Unsafe memory access > > I'm not at all clear why this unsafe memory access handling is for Aarch64 only? Hum, this was already part of [JDK-8250810](https://github.com/openjdk/jdk/commit/a4eaf9536c272862b5ec856bf263679be09bddc9) / [JDK-8248817](https://github.com/openjdk/jdk/commit/257809d7440e87ac595d03b6c9a98d8f457f314c) (see a couple lines below in this PR) without the `ifdef` for Aarch64, but I messed up rebasing on top of it. I removed it now, thanks for catching! ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Thu Sep 24 15:19:13 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Thu, 24 Sep 2020 15:19:13 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 04:52:22 GMT, David Holmes wrote: >> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: >> >> Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided > > src/hotspot/share/runtime/stubRoutines.cpp line 397: > >> 395: // test safefetch routines >> 396: // Not on Windows 32bit until 8074860 is fixed >> 397: #if ! (defined(_WIN32) && defined(_M_IX86)) && !defined(_M_ARM64) > > The comment needs updating to refer to Aarch64. This is actually not needed anymore, as it does work just fine on Windows+Aarch64. Presumably we have added it in the early days of the port when we haven't figured out exception handling quite yet. Thanks for catching David. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From erikj at openjdk.java.net Thu Sep 24 15:25:17 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 24 Sep 2020 15:25:17 GMT Subject: RFR: 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 23:05:59 GMT, Yumin Qi wrote: > This patch is a REDO for JDK-8253208 which was backed out since it caused runtime/cds/DeterministicDump.java failed, > see JDK-8253495. Since the failure is another issue and only triggered by this patch, the test case now is put on > ProblemList.txt. The real root cause for the failure is detailed in JDK-8253495. When JDK-8253208 was backed out, > CDS.java remained without removed from that patch (see JDK-8253495 subtask), so this patch does not include CDS.java > (this is why you will see CDS.c without CDS.java in this patch). Tests tier1-4 passed. Build changes ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/327 From minqi at openjdk.java.net Thu Sep 24 15:30:52 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 24 Sep 2020 15:30:52 GMT Subject: Integrated: 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 23:05:59 GMT, Yumin Qi wrote: > This patch is a REDO for JDK-8253208 which was backed out since it caused runtime/cds/DeterministicDump.java failed, > see JDK-8253495. Since the failure is another issue and only triggered by this patch, the test case now is put on > ProblemList.txt. The real root cause for the failure is detailed in JDK-8253495. When JDK-8253208 was backed out, > CDS.java remained without removed from that patch (see JDK-8253495 subtask), so this patch does not include CDS.java > (this is why you will see CDS.c without CDS.java in this patch). Tests tier1-4 passed. This pull request has now been integrated. Changeset: 89c5e49b Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/89c5e49b Stats: 156 lines in 22 files changed: 57 ins; 53 del; 46 mod 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class Reviewed-by: mchung, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/327 From cjplummer at openjdk.java.net Thu Sep 24 15:47:05 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 24 Sep 2020 15:47:05 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6] In-Reply-To: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com> References: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com> Message-ID: <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> On Thu, 24 Sep 2020 14:04:22 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith 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 17 additional commits since > the last revision: > - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc > - cleanup for 8253457: Remove unimplemented register stack functions > - Merge remote-tracking branch 'upstream/master' into jdk-windows > - Update orderAccess_windows_aarch64.hpp > > changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided > - 8248787: G1: Workaround MSVC bug > Reviewed-by: > Contributed-by: mbeckwit, luhenry, burban > - 8248670: Windows: Exception handling support on AArch64 > Reviewed-by: > Contributed-by: mbeckwit, luhenry, burban > - 8248660: AArch64: Make _clear_cache and _nop portable > Summary: __builtin___clear_cache, etc. > Contributed-by: mbeckwit, luhenry, burban > - 8248659: AArch64: Extend CPU Feature detection > Reviewed-by: > Contributed-by: mbeckwit, luhenry, burban > - 8248656: Add Windows AArch64 platform support code > Reviewed-by: > Contributed-by: mbeckwit, luhenry, burban > - 8248498: Add build system support for Windows AArch64 > Reviewed-by: > Contributed-by: mbeckwit, luhenry, burban > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/ddd43bee...2b662010 I looked at changes to existing SA files. These changes look fine. I did not look at the new aarch64 SA files other than the copyright section. I assume they are clones of the x64 versions with some symbolic renaming. If there is any more than that and you'd like me to have a look, let me know. As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of other non-SA files that are new and also have the same copyright issue. I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs a copyright date update. ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/212 From erikj at openjdk.java.net Thu Sep 24 20:31:49 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 24 Sep 2020 20:31:49 GMT Subject: RFR: 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle Message-ID: Oracle is changing the minor version of Visual Studio used for building the JDK on Windows. This patch updates the jib profiles configuration to point to the new devkit. ------------- Commit messages: - Bump VS version in jib-profiles Changes: https://git.openjdk.java.net/jdk/pull/346/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=346&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253615 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/346/head:pull/346 PR: https://git.openjdk.java.net/jdk/pull/346 From weijun at openjdk.java.net Thu Sep 24 20:44:56 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 24 Sep 2020 20:44:56 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v3] In-Reply-To: References: Message-ID: <-ljn2FU7DqIvcoKq3qO-yYHZNEU9rqJek3S4z8Ha7sQ=.c9175e31-2b48-432f-912e-2367079a92df@github.com> On Wed, 23 Sep 2020 23:38:03 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > change exception for ec keyagreement > fix supportedcurves in SunEC src/java.base/share/conf/security/java.security line 636: > 634: # > 635: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \ > 636: RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 `jdk.disabled.namedCurves` still exists. If someone decides to add a curve there, shouldn't it be also disabled here? ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From ascarpino at openjdk.java.net Thu Sep 24 21:19:05 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 24 Sep 2020 21:19:05 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v3] In-Reply-To: <-ljn2FU7DqIvcoKq3qO-yYHZNEU9rqJek3S4z8Ha7sQ=.c9175e31-2b48-432f-912e-2367079a92df@github.com> References: <-ljn2FU7DqIvcoKq3qO-yYHZNEU9rqJek3S4z8Ha7sQ=.c9175e31-2b48-432f-912e-2367079a92df@github.com> Message-ID: <4NaHde8FhqOKFtSMByp6WSZuB0xEM1i4COfU2w-NdCM=.15c29dce-df92-486c-a567-c7b764b1fe63@github.com> On Thu, 24 Sep 2020 19:48:45 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> change exception for ec keyagreement >> fix supportedcurves in SunEC > > src/java.base/share/conf/security/java.security line 636: > >> 634: # >> 635: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \ >> 636: RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 > > `jdk.disabled.namedCurves` still exists. If someone decides to add a curve there, shouldn't it be also disabled here? jdk.disabled.namedCurves is commented out and I don't think it's good for every operation disabled algorithms call to check an empty property. The description for the disabledAlgorithm properties say you have to use "include", so I don't think it is necessary to we keep it active.. ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From mikael at openjdk.java.net Thu Sep 24 21:36:39 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 24 Sep 2020 21:36:39 GMT Subject: RFR: 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 20:25:27 GMT, Erik Joelsson wrote: > Oracle is changing the minor version of Visual Studio used for building the JDK on Windows. This patch updates the jib > profiles configuration to point to the new devkit. Do you want to update doc/building.{md,html} to reflect the change at Oracle as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/346 From phh at openjdk.java.net Thu Sep 24 21:36:59 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Thu, 24 Sep 2020 21:36:59 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Message-ID: Please review this small patch to enable the OSX build using Xcode 12.0. Thanks, Paul ------------- Commit messages: - JDK-8253375 Changes: https://git.openjdk.java.net/jdk/pull/348/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=348&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253375 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/348/head:pull/348 PR: https://git.openjdk.java.net/jdk/pull/348 From mikael at openjdk.java.net Thu Sep 24 21:37:52 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 24 Sep 2020 21:37:52 GMT Subject: RFR: 8253616: Change to GCC 10.2 for building on Linux at Oracle Message-ID: <2r194Vqgwk25o-n7CKoaAxekOvL5sGWvede_Te7j91E=.24ab36fc-1fe7-4318-95d9-e165b7cd3be3@github.com> Please review this change which updates the defaults in the linux devkit creator, the doc/building.md file, and the JIB (Oracle) configuration to gcc 10.2. ------------- Commit messages: - 8253616: Change to GCC 10.2 for building on Linux at Oracle Changes: https://git.openjdk.java.net/jdk/pull/349/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=349&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253616 Stats: 33 lines in 4 files changed: 20 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/349/head:pull/349 PR: https://git.openjdk.java.net/jdk/pull/349 From weijun at openjdk.java.net Thu Sep 24 21:40:07 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 24 Sep 2020 21:40:07 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v3] In-Reply-To: <4NaHde8FhqOKFtSMByp6WSZuB0xEM1i4COfU2w-NdCM=.15c29dce-df92-486c-a567-c7b764b1fe63@github.com> References: <-ljn2FU7DqIvcoKq3qO-yYHZNEU9rqJek3S4z8Ha7sQ=.c9175e31-2b48-432f-912e-2367079a92df@github.com> <4NaHde8FhqOKFtSMByp6WSZuB0xEM1i4COfU2w-NdCM=.15c29dce-df92-486c-a567-c7b764b1fe63@github.com> Message-ID: <0fVNVOSd-7OZnI9Pj_CxoIcGT2Guv47FXy2N6cQDNmg=.e035384e-66d0-4b18-b9dd-3c5146e2b000@github.com> On Thu, 24 Sep 2020 21:15:34 GMT, Anthony Scarpino wrote: >> src/java.base/share/conf/security/java.security line 636: >> >>> 634: # >>> 635: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \ >>> 636: RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 >> >> `jdk.disabled.namedCurves` still exists. If someone decides to add a curve there, shouldn't it be also disabled here? > > jdk.disabled.namedCurves is commented out and I don't think it's good for every operation disabled algorithms call to > check an empty property. The description for the disabledAlgorithm properties say you have to use "include", so I > don't think it is necessary to we keep it active.. I just think this is an unnecessary behavior change. After all, the purpose of `jdk.disabled.namedCurves` is to be included in other disabledAlgorithms properties. No strong opinion on this. Please decide yourself. ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From prr at openjdk.java.net Thu Sep 24 21:51:19 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 24 Sep 2020 21:51:19 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul The awt change looks fine although it would be nice if you could paste the compiler error message into the bug report, since I'd like to see the compiler's reason why this is ambiguous today and not before - assuming that is the issue. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From ascarpino at openjdk.java.net Thu Sep 24 21:52:53 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 24 Sep 2020 21:52:53 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v3] In-Reply-To: <0fVNVOSd-7OZnI9Pj_CxoIcGT2Guv47FXy2N6cQDNmg=.e035384e-66d0-4b18-b9dd-3c5146e2b000@github.com> References: <-ljn2FU7DqIvcoKq3qO-yYHZNEU9rqJek3S4z8Ha7sQ=.c9175e31-2b48-432f-912e-2367079a92df@github.com> <4NaHde8FhqOKFtSMByp6WSZuB0xEM1i4COfU2w-NdCM=.15c29dce-df92-486c-a567-c7b764b1fe63@github.com> <0fVNVOSd-7OZnI9Pj_CxoIcGT2Guv47FXy2N6cQDNmg=.e035384e-66d0-4b18-b9dd-3c5146e2b000@github.com> Message-ID: On Thu, 24 Sep 2020 21:37:14 GMT, Weijun Wang wrote: >> jdk.disabled.namedCurves is commented out and I don't think it's good for every operation disabled algorithms call to >> check an empty property. The description for the disabledAlgorithm properties say you have to use "include", so I >> don't think it is necessary to we keep it active.. > > I just think this is an unnecessary behavior change. After all, the purpose of `jdk.disabled.namedCurves` is to be > included in other disabledAlgorithms properties. > No strong opinion on this. Please decide yourself. I understand what you are saying. The property only existed because there were so many curves that would have overwhelmed the disabledAlgorithms. I also don't like making this a permanent addition to the disabledAlgorithm properties. It's possible we may remove the property in the future as it's likely unnecessary going forward. ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From mbeckwit at openjdk.java.net Thu Sep 24 22:04:56 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Thu, 24 Sep 2020 22:04:56 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6] In-Reply-To: <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> References: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com> <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> Message-ID: <5ZsmSA9duJz5k77S_uvs3cJWDiQAv9ZkB6Nj1mede14=.27ded45d-7093-4151-ac83-7baf1b5ae3d4@github.com> On Thu, 24 Sep 2020 15:43:10 GMT, Chris Plummer wrote: >> Monica Beckwith 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 17 additional commits since >> the last revision: >> - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc >> - cleanup for 8253457: Remove unimplemented register stack functions >> - Merge remote-tracking branch 'upstream/master' into jdk-windows >> - Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided >> - 8248787: G1: Workaround MSVC bug >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248670: Windows: Exception handling support on AArch64 >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248660: AArch64: Make _clear_cache and _nop portable >> Summary: __builtin___clear_cache, etc. >> Contributed-by: mbeckwit, luhenry, burban >> - 8248659: AArch64: Extend CPU Feature detection >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248656: Add Windows AArch64 platform support code >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248498: Add build system support for Windows AArch64 >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - ... and 7 more: https://git.openjdk.java.net/jdk/compare/6fea1339...2b662010 > > I looked at changes to existing SA files. These changes look fine. > > I did not look at the new aarch64 SA files other than the copyright section. I assume they are clones of the x64 > versions with some symbolic renaming. If there is any more than that and you'd like me to have a look, let me know. > As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of > other non-SA files that are new and also have the same copyright issue. > I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs > a copyright date update. @dholmes-ora, makes sense. I will do the needful. Thanks. > @mo-beck This PR should not be associated with any JBS issues which are targeted at repo-aarch64-port. All such issues > should have been closed by now when the associated code was pushed to aarch64-port repo. That was the whole point of > creating separate issues so that they could be tracked in the porting repo. Now that all of that work should be > complete the only issue that should remain open in relation to the Windows-Aarch64 port is JDK-8248238. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From erikj at openjdk.java.net Thu Sep 24 22:24:23 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 24 Sep 2020 22:24:23 GMT Subject: RFR: 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle [v2] In-Reply-To: References: Message-ID: > Oracle is changing the minor version of Visual Studio used for building the JDK on Windows. This patch updates the jib > profiles configuration to point to the new devkit. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Update build docs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/346/files - new: https://git.openjdk.java.net/jdk/pull/346/files/e77d322b..759c8070 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=346&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=346&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/346/head:pull/346 PR: https://git.openjdk.java.net/jdk/pull/346 From mikael at openjdk.java.net Thu Sep 24 22:24:23 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 24 Sep 2020 22:24:23 GMT Subject: RFR: 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle [v2] In-Reply-To: References: Message-ID: <9XxuOsQyRsIEHIDI9PM0Zhi6BF2b92QdsT0jXPizGOo=.0f78c65c-7c62-4376-a2b4-3adf6b8fbdf9@github.com> On Thu, 24 Sep 2020 22:20:47 GMT, Erik Joelsson wrote: >> Oracle is changing the minor version of Visual Studio used for building the JDK on Windows. This patch updates the jib >> profiles configuration to point to the new devkit. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Update build docs Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/346 From erikj at openjdk.java.net Thu Sep 24 22:25:38 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 24 Sep 2020 22:25:38 GMT Subject: RFR: 8253616: Change to GCC 10.2 for building on Linux at Oracle In-Reply-To: <2r194Vqgwk25o-n7CKoaAxekOvL5sGWvede_Te7j91E=.24ab36fc-1fe7-4318-95d9-e165b7cd3be3@github.com> References: <2r194Vqgwk25o-n7CKoaAxekOvL5sGWvede_Te7j91E=.24ab36fc-1fe7-4318-95d9-e165b7cd3be3@github.com> Message-ID: On Thu, 24 Sep 2020 21:31:49 GMT, Mikael Vidstedt wrote: > Please review this change which updates the defaults in the linux devkit creator, the doc/building.md file, and the JIB > (Oracle) configuration to gcc 10.2. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/349 From erikj at openjdk.java.net Thu Sep 24 22:33:37 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 24 Sep 2020 22:33:37 GMT Subject: Integrated: 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 20:25:27 GMT, Erik Joelsson wrote: > Oracle is changing the minor version of Visual Studio used for building the JDK on Windows. This patch updates the jib > profiles configuration to point to the new devkit. This pull request has now been integrated. Changeset: 24a42489 Author: Erik Joelsson URL: https://git.openjdk.java.net/jdk/commit/24a42489 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/346 From david.holmes at oracle.com Fri Sep 25 01:34:10 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Sep 2020 11:34:10 +1000 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6] In-Reply-To: <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> References: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com> <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> Message-ID: <14d09119-7802-bc97-7547-626edee9c959@oracle.com> Hi Chris, Monica, On 25/09/2020 1:47 am, Chris Plummer wrote: > As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of > other non-SA files that are new and also have the same copyright issue. If a file was created completely from scratch then it should just have the Microsoft copyright notice. However, if it was copied from an existing file and modified, then the existing file's copyright should be included and a Microsoft one added if the changes are significant. But IANAL. :) Cheers, David > I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs > a copyright date update. > > ------------- > > Changes requested by cjplummer (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/212 > From dholmes at openjdk.java.net Fri Sep 25 02:26:32 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 25 Sep 2020 02:26:32 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <5q0sckv5JjyV1HNZMX1f1eG2dwCjfLTejO8pfH7tS5s=.f1a8c3d5-a436-41bd-9d9f-68f0103539a1@github.com> On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul Changes requested by dholmes (Reviewer). src/hotspot/share/runtime/sharedRuntime.cpp line 2851: > 2849: if (buf != NULL) { > 2850: CodeBuffer buffer(buf); > 2851: short locs_buf[80]; This code is just weird. Why is the buf array not declared to be the desired type? If the compiler rejects double because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ? ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From ascarpino at openjdk.java.net Fri Sep 25 02:42:57 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 25 Sep 2020 02:42:57 GMT Subject: Integrated: 8235710: Remove the legacy elliptic curves In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 21:10:58 GMT, Anthony Scarpino wrote: > This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The > SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will > remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, > sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, > X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 > prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 This pull request has now been integrated. Changeset: 0b83fc01 Author: Anthony Scarpino URL: https://git.openjdk.java.net/jdk/commit/0b83fc01 Stats: 20155 lines in 77 files changed: 28 ins; 20048 del; 79 mod 8235710: Remove the legacy elliptic curves Reviewed-by: xuelei, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From kbarrett at openjdk.java.net Fri Sep 25 05:49:08 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 25 Sep 2020 05:49:08 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul No, don't do this. In the original, double is used to obtain the desired alignmnent. Changing the element type to short reduces the alignment requirement for the variable. initialize_shared_locs will then adjust the alignment, potentially shrinking the effective array size. So this is a real change that I think shouldn't be made. I think changing the declaration for locs_buf to any of the following gives equivalent behavior to the current code. I don't know whether any of them will trigger the new clang warning though. I don't have access to that version right now, and the documentation for the warning is useless (like so much of clang's warning options documentation). (1) alignas(double) char locs_buf[20 * sizeof(double)]; (but alignas is not yet in the "permitted features" list in the Style Guide: https://bugs.openjdk.java.net/browse/JDK-8252584) (2) union { char locs_buf[20 * sizeof(double)]; double align; }; (3) std::aligned_storage_t<20 * sizeof(double)> locs_buf; and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf and #include This has the benefit of being explicit that we're just stack allocating a block of storage. I'll make a wild guess that (1) and (2) will still warn, though char arrays are somewhat special in the language so maybe they won't. I'm pretty sure (3) should do the trick. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From kbarrett at openjdk.java.net Fri Sep 25 06:09:10 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 25 Sep 2020 06:09:10 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: > 127: NSColor* result = nil; > 128: > 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : > java_awt_SystemColor_NUM_COLORS)) { This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues related to the compiler upgrade. Someone might want to backport just this fix, for example. ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Fri Sep 25 06:12:27 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 25 Sep 2020 02:12:27 -0400 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <26D262B7-A73B-450D-8789-16F33B950379@oracle.com> > On Sep 25, 2020, at 1:49 AM, Kim Barrett wrote: > > On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul [I tried submitting this comment through the github UI and somehow managed to lose all the context in the process. In case it?s not (eventually) obvious, this is about the change to src/hotspot/share/runtime/sharedRuntime.cpp. Still figuring out github?] > No, don't do this. In the original, double is used to obtain the desired > alignmnent. Changing the element type to short reduces the alignment > requirement for the variable. initialize_shared_locs will then adjust the > alignment, potentially shrinking the effective array size. So this is a > real change that I think shouldn't be made. > > I think changing the declaration for locs_buf to any of the following gives > equivalent behavior to the current code. I don't know whether any of them > will trigger the new clang warning though. I don't have access to that > version right now, and the documentation for the warning is useless (like so > much of clang's warning options documentation). > > (1) alignas(double) char locs_buf[20 * sizeof(double)]; > (but alignas is not yet in the "permitted features" list in the Style Guide: > https://bugs.openjdk.java.net/browse/JDK-8252584) > > (2) union { char locs_buf[20 * sizeof(double)]; double align; }; > > (3) std::aligned_storage_t<20 * sizeof(double)> locs_buf; > and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf > and #include > This has the benefit of being explicit that we're just stack allocating a > block of storage. > > I'll make a wild guess that (1) and (2) will still warn, though char arrays > are somewhat special in the language so maybe they won't. I'm pretty sure > (3) should do the trick. > > ------------- > > Changes requested by kbarrett (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/348 From ngasson at openjdk.java.net Fri Sep 25 07:53:59 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 25 Sep 2020 07:53:59 GMT Subject: RFR: 8253624: gtest fails when run from make with read-only source directory Message-ID: In an out-of-tree build where the source code is in a read-only location several gtests such as LogFileOutput.invalid_file_test_vm will fail because they write files to the current working directory. [ RUN ] LogFileOutput.invalid_file_test_vm # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/logTestUtils.inline.hpp:65 assert failed: failed to create directory tmplogdir # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/mnt/nicgas01-pc/jdk/test/hotspot/gtest/logging/logTestUtils.inline.hpp:65), pid=51470, tid=51470 # assert(!failed) failed: failed to create directory tmplogdir Run the gtest launcher with the working directory set to the test support directory which we know is writable. ------------- Commit messages: - 8253624: gtest fails when run from make with read-only source directory Changes: https://git.openjdk.java.net/jdk/pull/354/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=354&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253624 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/354.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/354/head:pull/354 PR: https://git.openjdk.java.net/jdk/pull/354 From kim.barrett at oracle.com Fri Sep 25 08:00:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 25 Sep 2020 04:00:48 -0400 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <0CC7FB67-55D9-4E7F-9B45-BA7FD6E3BE43@oracle.com> > On Sep 25, 2020, at 1:49 AM, Kim Barrett wrote: > > On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > [?] > > I think changing the declaration for locs_buf to any of the following gives > equivalent behavior to the current code. [?] > > [?] Another variant that probably avoids both the warning and avoids any C++14 features: (4) union { char data[20 * sizeof(double)]; double align; } locs_buf; and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf. > ------------- > > Changes requested by kbarrett (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/348 From lucy at openjdk.java.net Fri Sep 25 10:22:08 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Fri, 25 Sep 2020 10:22:08 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 05:46:08 GMT, Kim Barrett wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > No, don't do this. In the original, double is used to obtain the desired > alignmnent. Changing the element type to short reduces the alignment > requirement for the variable. initialize_shared_locs will then adjust the > alignment, potentially shrinking the effective array size. So this is a > real change that I think shouldn't be made. > > I think changing the declaration for locs_buf to any of the following gives > equivalent behavior to the current code. I don't know whether any of them > will trigger the new clang warning though. I don't have access to that > version right now, and the documentation for the warning is useless (like so > much of clang's warning options documentation). > > (1) alignas(double) char locs_buf[20 * sizeof(double)]; > (but alignas is not yet in the "permitted features" list in the Style Guide: > https://bugs.openjdk.java.net/browse/JDK-8252584) > > (2) union { char locs_buf[20 * sizeof(double)]; double align; }; > > (3) std::aligned_storage_t<20 * sizeof(double)> locs_buf; > and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf > and #include > This has the benefit of being explicit that we're just stack allocating a > block of storage. > > I'll make a wild guess that (1) and (2) will still warn, though char arrays > are somewhat special in the language so maybe they won't. I'm pretty sure > (3) should do the trick. I checked Kim Barrett's proposals (1) and (2) on my machine (MacOS 10.15, Xcode 12.0). Both proposals make the warning go away. Another note, actually, it's more like a question: Has anyone had an eye on what happens in initialize_shared_locs(relocInfo* buf, int length)? To my understanding, "buf", which is passed in as "locs_buf", is stored into CodeBuffer fields. Is that a good idea? "locs_buf" points into the stack. This pointer becomes invalid at the end of the "locs_buf" scope. Did I get something wrong here? ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From zuismanm at gmail.com Fri Sep 25 10:23:11 2020 From: zuismanm at gmail.com (Moshe Zuisman) Date: Fri, 25 Sep 2020 13:23:11 +0300 Subject: cve-2014-3566 cve-2014-6593 in OPEN JDK 8 Message-ID: Hi. I am trying to figure out if cve-2014-3566 cve-2014-6593 nad if yes - starting from which build. Alan Bateman pointed me to https://openjdk.java.net/groups/vulnerability/advisories/. But it contains only a list of fixed vulnerabilities, that were reported at 2019-2020 years. I have found at https://linux.oracle.com/errata/ELSA-2015-0069.html that Open JDK 8 for Oracle Linux 6 already contained fix for cve-2014-3566 for example. But - is there some way, I can be sure that this was included in the general code base of Open JDK(and not some special branch - ORACLE manages for their systems), and starting from which build this fix was included? From kim.barrett at oracle.com Fri Sep 25 10:37:08 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 25 Sep 2020 06:37:08 -0400 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <7298FBE4-01E9-4857-B213-B2A7F0A41621@oracle.com> > On Sep 25, 2020, at 6:22 AM, Lutz Schmidt wrote: > > On Fri, 25 Sep 2020 05:46:08 GMT, Kim Barrett wrote: > > Another note, actually, it's more like a question: > Has anyone had an eye on what happens in initialize_shared_locs(relocInfo* buf, int length)? To my understanding, > "buf", which is passed in as "locs_buf", is stored into CodeBuffer fields. Is that a good idea? "locs_buf" points into > the stack. This pointer becomes invalid at the end of the "locs_buf" scope. Did I get something wrong here? It?s ?odd? but I think it?s more or less okay. Here and in other uses we seem to be allocating dynamically scoped storage for temporary use by the CodeBuffer. I think a more normal formulation might be to allocate the buffer, then pass it to the CodeBuffer constructor as a non-transfer of ownership. But I haven?t looked at all the places where this is used, and that?s perhaps out of scope for the problem at hand. > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From david.holmes at oracle.com Fri Sep 25 10:56:39 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Sep 2020 20:56:39 +1000 Subject: cve-2014-3566 cve-2014-6593 in OPEN JDK 8 In-Reply-To: References: Message-ID: Hi Moshe, On 25/09/2020 8:23 pm, Moshe Zuisman wrote: > Hi. > I am trying to figure out if cve-2014-3566 cve-2014-6593 nad if yes - > starting from which build. This is not something that build-dev can help you with. The best people to contact for this would be the Vulnerability group that Alan referred to. There is historical information available for Oracle JDK [1] but I don't know how to map that to OpenJDK for certain. Cheers, David ----- [1] To go that far back you'd need to check: https://www.oracle.com/security-alerts/public-vuln-to-advisory-mapping.html for the CVE and find the corresponding CPU link. E.g. for cve-2014-3566 it is: https://www.oracle.com/security-alerts/cpujul2017.html which applies to Oracle Java SE, versions 6u151, 7u141, 8u131. (I'm not sure whether than means it is fixed in 8u131 or whether 8u131 is still affected and the fix is in the next CPU release.) > Alan Bateman pointed me to > https://openjdk.java.net/groups/vulnerability/advisories/. But it contains > only a list of fixed vulnerabilities, that were reported at 2019-2020 years. > I have found at https://linux.oracle.com/errata/ELSA-2015-0069.html > that Open JDK 8 for Oracle Linux 6 already contained fix for cve-2014-3566 > for example. > But - is there some way, I can be sure that this was included in the > general code base of Open JDK(and not some special branch - ORACLE manages > for their systems), and starting from which build this fix was included? > From zuismanm at gmail.com Fri Sep 25 12:28:28 2020 From: zuismanm at gmail.com (Moshe Zuisman) Date: Fri, 25 Sep 2020 15:28:28 +0300 Subject: cve-2014-3566 cve-2014-6593 in OPEN JDK 8 In-Reply-To: References: Message-ID: Hi David. Do this Vulnerability group have some their own forum, mail list or other place - they can be contacted? ??, 25 ????. 2020 ?. ? 13:58, David Holmes : > Hi Moshe, > > On 25/09/2020 8:23 pm, Moshe Zuisman wrote: > > Hi. > > I am trying to figure out if cve-2014-3566 cve-2014-6593 nad if yes - > > starting from which build. > > This is not something that build-dev can help you with. > > The best people to contact for this would be the Vulnerability group > that Alan referred to. > > There is historical information available for Oracle JDK [1] but I don't > know how to map that to OpenJDK for certain. > > Cheers, > David > ----- > > [1] To go that far back you'd need to check: > > https://www.oracle.com/security-alerts/public-vuln-to-advisory-mapping.html > > for the CVE and find the corresponding CPU link. E.g. for cve-2014-3566 > it is: > > https://www.oracle.com/security-alerts/cpujul2017.html > > which applies to Oracle Java SE, versions 6u151, 7u141, 8u131. (I'm not > sure whether than means it is fixed in 8u131 or whether 8u131 is still > affected and the fix is in the next CPU release.) > > > Alan Bateman pointed me to > > https://openjdk.java.net/groups/vulnerability/advisories/. But it > contains > > only a list of fixed vulnerabilities, that were reported at 2019-2020 > years. > > I have found at https://linux.oracle.com/errata/ELSA-2015-0069.html > > that Open JDK 8 for Oracle Linux 6 already contained fix for > cve-2014-3566 > > for example. > > But - is there some way, I can be sure that this was included in the > > general code base of Open JDK(and not some special branch - ORACLE > manages > > for their systems), and starting from which build this fix was included? > > > From aph at openjdk.java.net Fri Sep 25 12:47:47 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 25 Sep 2020 12:47:47 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7] In-Reply-To: <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com> References: <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com> Message-ID: On Thu, 24 Sep 2020 15:15:45 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request incrementally with two additional commits since the last revision: > > - os_windows: remove duplicated UMA handling > - test_safefetch{32,N} works fine on win+aarch64 Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From rwestberg at openjdk.java.net Fri Sep 25 13:10:01 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Fri, 25 Sep 2020 13:10:01 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v5] In-Reply-To: References: Message-ID: > A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests > for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open > source repositories. I've incorporated the feedback into an updated version that I believe is ready to be integrated. > If this is integrated into the `master` branch, future branches created and updated in personal forks will build and > run the basic tier 1 tests as described in this configuration, on Linux, Windows and macOS (all on x64). It's of course > possible for any contributor to opt out fully or partially of these automatic runs in a few different ways. To opt out > completely, a contributor can simply disable GitHub Actions on their personal fork, and no further jobs will be > executed. Another option is to add a repository secret [4] with the name `JDK_SUBMIT_FILTER` set to any value. If this > is set, only branches prefixed with `submit/` will be subject to automatic build and test. This can also be further > refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a value such as `Linux x64, Windows x64` to > limit automatic build and test to these two platforms. It will still be possible to run the tests on any branch and/or > platform by manually triggering the workflow. To see what this looks like in practice, an example run can be found > here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is currently a failing test on Windows > which is tracked by JDK-8249095, which should probably be resolved before this change is integrated). Best regards, > Robin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits [4] > https://docs.github.com/en/actions/reference/encrypted-secrets Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: Avoid persisting transient artifacts, combine all test results into a final bundle ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/284/files - new: https://git.openjdk.java.net/jdk/pull/284/files/de5074fe..441a18b7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=03-04 Stats: 92 lines in 1 file changed: 64 ins; 6 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/284/head:pull/284 PR: https://git.openjdk.java.net/jdk/pull/284 From rwestberg at openjdk.java.net Fri Sep 25 13:15:13 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Fri, 25 Sep 2020 13:15:13 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions In-Reply-To: <29PQR9-EihUS6UB23xC4IPyIOjkAKo0UuDWgfbw0fN8=.e478235a-81e3-48c1-a291-5f82f1917c32@github.com> References: <2gwNsqQ3OJqaTKD66CfHrVWFbDVxxcLEvM3oMOPejOo=.5bad0484-7502-422b-8e4b-6e970959584a@github.com> <1BduorxiB-c33s_OlKgtJulsazxapxCj2kqGhAj1UiA=.9c618556-fb24-4236-aefe-bf37d5a4a4b4@github.com> <29PQR9-EihUS6UB23xC4IPyIOjkAKo0UuDWgfbw0fN8=.e478235a-81e3-48c1-a291-5f82f1917c32@github.com> Message-ID: On Wed, 23 Sep 2020 17:55:23 GMT, Robin Westberg wrote: >> The version-numbers file (which is also a shared properties style file) is not using quotes for values, which is fine >> as long as there are no spaces. I believe if you read it as a properties file, you need to strip the quotes if you have >> them. I prefer if version-numbers and test-dependencies using the same format. Otherwise this looks good to me! > > Sounds reasonable, didn't notice that discrepancy! Fixed in the latest commit. After some feedback on the jdk-dev mailing list (thanks @jaikiran!) I took a second look at removing artifacts that are only created for passing between the build and test steps. Turns out that there is an API for this (it's still in preview, but seems to work fine) that can be used for this. When this API is finalized we can update that part, but it's not a deal-breaker even if it should change, as the test runs will still complete successfully. With this API available, it's also possible to publish a single artifact containing all test results, regardless of outcome. ------------- PR: https://git.openjdk.java.net/jdk/pull/284 From erikj at openjdk.java.net Fri Sep 25 13:39:51 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 25 Sep 2020 13:39:51 GMT Subject: RFR: 8253624: gtest fails when run from make with read-only source directory In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 07:45:34 GMT, Nick Gasson wrote: > In an out-of-tree build where the source code is in a read-only location > several gtests such as LogFileOutput.invalid_file_test_vm will fail > because they write files to the current working directory. > > [ RUN ] LogFileOutput.invalid_file_test_vm > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/logTestUtils.inline.hpp:65 > assert failed: failed to create directory tmplogdir > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/mnt/nicgas01-pc/jdk/test/hotspot/gtest/logging/logTestUtils.inline.hpp:65), pid=51470, tid=51470 > # assert(!failed) failed: failed to create directory tmplogdir > > Run the gtest launcher with the working directory set to the test > support directory which we know is writable. That's a nice fix, thanks! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/354 From erikj at openjdk.java.net Fri Sep 25 13:53:33 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 25 Sep 2020 13:53:33 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v5] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 13:10:01 GMT, Robin Westberg wrote: >> A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests >> for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open >> source repositories. I've incorporated the feedback into an updated version that I believe is ready to be integrated. >> If this is integrated into the `master` branch, future branches created and updated in personal forks will build and >> run the basic tier 1 tests as described in this configuration, on Linux, Windows and macOS (all on x64). It's of course >> possible for any contributor to opt out fully or partially of these automatic runs in a few different ways. To opt out >> completely, a contributor can simply disable GitHub Actions on their personal fork, and no further jobs will be >> executed. Another option is to add a repository secret [4] with the name `JDK_SUBMIT_FILTER` set to any value. If this >> is set, only branches prefixed with `submit/` will be subject to automatic build and test. This can also be further >> refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a value such as `Linux x64, Windows x64` to >> limit automatic build and test to these two platforms. It will still be possible to run the tests on any branch and/or >> platform by manually triggering the workflow. To see what this looks like in practice, an example run can be found >> here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is currently a failing test on Windows >> which is tracked by JDK-8249095, which should probably be resolved before this change is integrated). Best regards, >> Robin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] >> https://github.com/features/actions [3] >> https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits [4] >> https://docs.github.com/en/actions/reference/encrypted-secrets > > Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: > > Avoid persisting transient artifacts, combine all test results into a final bundle Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/284 From ehelin at openjdk.java.net Fri Sep 25 13:53:32 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Fri, 25 Sep 2020 13:53:32 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v5] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 13:10:01 GMT, Robin Westberg wrote: >> A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests >> for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open >> source repositories. I've incorporated the feedback into an updated version that I believe is ready to be integrated. >> If this is integrated into the `master` branch, future branches created and updated in personal forks will build and >> run the basic tier 1 tests as described in this configuration, on Linux, Windows and macOS (all on x64). It's of course >> possible for any contributor to opt out fully or partially of these automatic runs in a few different ways. To opt out >> completely, a contributor can simply disable GitHub Actions on their personal fork, and no further jobs will be >> executed. Another option is to add a repository secret [4] with the name `JDK_SUBMIT_FILTER` set to any value. If this >> is set, only branches prefixed with `submit/` will be subject to automatic build and test. This can also be further >> refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a value such as `Linux x64, Windows x64` to >> limit automatic build and test to these two platforms. It will still be possible to run the tests on any branch and/or >> platform by manually triggering the workflow. To see what this looks like in practice, an example run can be found >> here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is currently a failing test on Windows >> which is tracked by JDK-8249095, which should probably be resolved before this change is integrated). Best regards, >> Robin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] >> https://github.com/features/actions [3] >> https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits [4] >> https://docs.github.com/en/actions/reference/encrypted-secrets > > Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: > > Avoid persisting transient artifacts, combine all test results into a final bundle Looks good to me, awesome work @rwestberg! ------------- Marked as reviewed by ehelin (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/284 From david.holmes at oracle.com Fri Sep 25 14:13:06 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Sep 2020 00:13:06 +1000 Subject: cve-2014-3566 cve-2014-6593 in OPEN JDK 8 In-Reply-To: References: Message-ID: <63142641-ca33-8ed5-6da6-9c8bbb2c5c2e@oracle.com> On 25/09/2020 10:28 pm, Moshe Zuisman wrote: > Hi David. Do this Vulnerability group have some their own forum, mail > list or other place - they can be contacted? I assumed they did have but it seems not :( https://openjdk.java.net/groups/vulnerability/ The only mailing list they have that you can post to is for vulnerability reports. I suspect you have to pick an OpenJDK distributor and then ask them about this, rather than trying to find out generically what "version of OpenJDK" contains a given fix. I'm pretty sure that we don't record CVE details when such fixes get integrated. David ----- > ??, 25 ????. 2020 ?. ? 13:58, David Holmes >: > > Hi Moshe, > > On 25/09/2020 8:23 pm, Moshe Zuisman wrote: > > Hi. > > I am trying to figure out if cve-2014-3566 cve-2014-6593 nad if yes - > > starting from which build. > > This is not something that build-dev can help you with. > > The best people to contact for this would be the Vulnerability group > that Alan referred to. > > There is historical information available for Oracle JDK [1] but I > don't > know how to map that to OpenJDK for certain. > > Cheers, > David > ----- > > [1] To go that far back you'd need to check: > > https://www.oracle.com/security-alerts/public-vuln-to-advisory-mapping.html > > for the CVE and find the corresponding CPU link. E.g. for cve-2014-3566 > it is: > > https://www.oracle.com/security-alerts/cpujul2017.html > > which applies to Oracle Java SE, versions 6u151, 7u141, 8u131. (I'm not > sure whether than means it is fixed in 8u131 or whether 8u131 is still > affected and the fix is in the next CPU release.) > > > Alan Bateman pointed me to > > https://openjdk.java.net/groups/vulnerability/advisories/. But it > contains > > only a list of fixed vulnerabilities, that were reported at > 2019-2020 years. > > I have found at https://linux.oracle.com/errata/ELSA-2015-0069.html > > that Open JDK 8 for Oracle Linux 6 already contained fix for > cve-2014-3566 > > for example. > > But - is there some way, I can be sure that this was included in the > > general code base of Open JDK(and not some special branch - > ORACLE manages > > for their systems), and starting from which build this fix was > included? > > > From erikj at openjdk.java.net Fri Sep 25 20:44:19 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 25 Sep 2020 20:44:19 GMT Subject: RFR: 8253660: Need better error report when artifact resolution fails in AotCompiler.java Message-ID: In AotCompiler.java, if artifact resolution fails, we have no way of diagnosing the error. This patch improves the default toString() of ArtifactResolverException to automatically include the toString() method of the root cause. It also adds stack trace printing specifically in AotCompiler.java. I also found a similar issue in PKCS11Test, and fixed it by adding the ArtifactResolverException there as cause for the RuntimeException being thrown. This causes the stack trace to be printed on failure. I looked through all other uses of ArtifactResolver, but they are handling the exception in a way that already prints the stack trace. ------------- Commit messages: - Add cause to RuntimeException in PKCS11Test - Include root cause message in ArtifactResolverException by default. Print stack trace in AotCotCompiler. Changes: https://git.openjdk.java.net/jdk/pull/368/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=368&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253660 Stats: 14 lines in 3 files changed: 13 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/368/head:pull/368 PR: https://git.openjdk.java.net/jdk/pull/368 From minqi at openjdk.java.net Fri Sep 25 21:08:07 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 25 Sep 2020 21:08:07 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v2] In-Reply-To: References: Message-ID: > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - Merge branch 'master' into jdk-8247536 - Merge branch 'master' of https://github.com/openjdk/jdk - Merge branch 'master' of https://github.com/openjdk/jdk - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - Merge remote-tracking branch 'upstream/master' into jdk-8247536 - Merge remote-tracking branch 'upstream/master' into jdk-8247536 - Merge remote-tracking branch 'origin/jdk-8252689' - 8252689: Classes are loaded from jrt:/java.base even when CDS is used - 8252689: Classes are loaded from jrt:/java.base even when CDS is used - ... and 1 more: https://git.openjdk.java.net/jdk/compare/8b85c3a6...f45f364d ------------- Changes: https://git.openjdk.java.net/jdk/pull/193/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=01 Stats: 425 lines in 19 files changed: 399 ins; 13 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From minqi at openjdk.java.net Fri Sep 25 21:19:39 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 25 Sep 2020 21:19:39 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v3] In-Reply-To: References: Message-ID: > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/193/files - new: https://git.openjdk.java.net/jdk/pull/193/files/f45f364d..b1955272 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=01-02 Stats: 88 lines in 15 files changed: 57 ins; 15 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From minqi at openjdk.java.net Fri Sep 25 21:41:22 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 25 Sep 2020 21:41:22 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v4] In-Reply-To: References: Message-ID: > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/193/files - new: https://git.openjdk.java.net/jdk/pull/193/files/b1955272..4148e7d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From minqi at openjdk.java.net Fri Sep 25 21:58:36 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 25 Sep 2020 21:58:36 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v5] In-Reply-To: References: Message-ID: <58G1o_bRoZOc9vFivWYgPj1xaCL1G3UaR5a0BtEuGx8=.afcd2c71-72d1-47ad-8b4f-4faff40a231d@github.com> > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' of https://git.openjdk.java.net/jdk into jdk-8247536 - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - Merge branch 'master' into jdk-8247536 - Merge branch 'master' of https://github.com/openjdk/jdk - Merge branch 'master' of https://github.com/openjdk/jdk - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - Merge remote-tracking branch 'upstream/master' into jdk-8247536 - Merge remote-tracking branch 'upstream/master' into jdk-8247536 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/b159e4ed...01b229cc ------------- Changes: https://git.openjdk.java.net/jdk/pull/193/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=04 Stats: 464 lines in 21 files changed: 440 ins; 13 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From iklam at openjdk.java.net Fri Sep 25 21:58:38 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 25 Sep 2020 21:58:38 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v3] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 21:19:39 GMT, Yumin Qi wrote: >> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous >> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the >> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses >> function. Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive Changes requested by iklam (Reviewer). test/hotspot/jtreg/runtime/cds/appcds/DumpClassListWithLF.java line 32: > 30: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds > 31: * @compile ClassListFormatBase.java test-classes/Hello.java > 32: * @run driver DumpClassListWithLF The `@compile` line can be removed to speed up the test execution. You can add this: @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds/test-classes and also change the code below appJar, classlist( - "Hello", + Hello.class.getName(), (There's no need for `/test/hotspot/jtreg/runtime/cds/appcds` in `@library` because that's the current directory of this test). test/hotspot/jtreg/runtime/cds/appcds/DumpClassListWithLF.java line 53: > 51: "Hello", > 52: "@lambda-form-invoker [LF_RESOLVE] java.lang.invoke.DirectMethodHandle$Holder invokeStatic L7_L > (success)", 53: "@lambda-form-invoker [LF_RESOLVE] java.lang.invoke.DirectMethodHandle$Holder > invokeStatic LL_I (success)"), I think the `(success)` part should not be included in the classlist. The classlist is the public interface. It should be concise and include only the necessary information. @lambda-form-invoker [LF_RESOLVE] java.lang.invoke.DirectMethodHandle$Holder invokeStatic L7_L @lambda-form-invoker [LF_RESOLVE] java.lang.invoke.DirectMethodHandle$Holder invokeStatic LL_I test/hotspot/jtreg/runtime/cds/appcds/customLoader/ProhibitedPackageNamesTest.java line 31: > 29: * @requires vm.cds.custom.loaders > 30: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds > 31: * @compile ../ClassListFormatBase.java ../test-classes/Hello.java test-classes/InProhibitedPkg.java Similar comment for avoiding `@compile`. `@compile` has been mis-used by older CDS tests. We should avoid using it, and should remove it when we are touching the old tests. src/hotspot/share/classfile/systemDictionary.cpp line 1864: > 1862: > 1863: // Used for assertions and verification, also used from LambdaFormInvokers::reload_class > 1864: // to get original class which has already been loaded. Is the above comment change still needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/193 From rwestberg at openjdk.java.net Sat Sep 26 15:35:55 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Sat, 26 Sep 2020 15:35:55 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v6] In-Reply-To: References: Message-ID: > A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests > for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open > source repositories. I've incorporated the feedback into an updated version that I believe is ready to be integrated. > If this is integrated into the `master` branch, future branches created and updated in personal forks will build and > run the basic tier 1 tests as described in this configuration, on Linux, Windows and macOS (all on x64). It's of course > possible for any contributor to opt out fully or partially of these automatic runs in a few different ways. To opt out > completely, a contributor can simply disable GitHub Actions on their personal fork, and no further jobs will be > executed. Another option is to add a repository secret [4] with the name `JDK_SUBMIT_FILTER` set to any value. If this > is set, only branches prefixed with `submit/` will be subject to automatic build and test. This can also be further > refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a value such as `Linux x64, Windows x64` to > limit automatic build and test to these two platforms. It will still be possible to run the tests on any branch and/or > platform by manually triggering the workflow. To see what this looks like in practice, an example run can be found > here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is currently a failing test on Windows > which is tracked by JDK-8249095, which should probably be resolved before this change is integrated). Best regards, > Robin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits [4] > https://docs.github.com/en/actions/reference/encrypted-secrets Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: Ensure that test logs are always collected, regardless of test job outcome ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/284/files - new: https://git.openjdk.java.net/jdk/pull/284/files/441a18b7..22336eba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=04-05 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/284/head:pull/284 PR: https://git.openjdk.java.net/jdk/pull/284 From zuismanm at gmail.com Sat Sep 26 18:51:27 2020 From: zuismanm at gmail.com (Moshe Zuisman) Date: Sat, 26 Sep 2020 21:51:27 +0300 Subject: build-dev Digest, Vol 161, Issue 61 In-Reply-To: References: Message-ID: >Date: Sat, 26 Sep 2020 00:13:06 +1000 > > From: David Holmes > > To: Moshe Zuisman > > Cc: build-dev at openjdk.java.net > > Subject: Re: cve-2014-3566 cve-2014-6593 in OPEN JDK 8 > > Message-ID: <63142641-ca33-8ed5-6da6-9c8bbb2c5c2e at oracle.com> > > Content-Type: text/plain; charset=utf-8; format=flowed > > > On 25/09/2020 10:28 pm, Moshe Zuisman wrote: > > > Hi David. Do this Vulnerability group have some their own forum, mail > > > list or other place - they can be contacted? > > > I assumed they did have but it seems not :( > > > https://openjdk.java.net/groups/vulnerability/ > > > > The only mailing list they have that you can post to is for > > vulnerability reports. > > > I suspect you have to pick an OpenJDK distributor and then ask them > > about this, rather than trying to find out generically what "version of > > OpenJDK" contains a given fix. I'm pretty sure that we don't record CVE > > details when such fixes get integrated. > > > David > > ----- > > Hi David. Thanks for your help! From github.com+471021+marschall at openjdk.java.net Sun Sep 27 19:03:44 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Sun, 27 Sep 2020 19:03:44 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v6] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall 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-8138732 - 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=05 Stats: 749 lines in 65 files changed: 149 ins; 149 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From ngasson at openjdk.java.net Mon Sep 28 01:57:22 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 28 Sep 2020 01:57:22 GMT Subject: Integrated: 8253624: gtest fails when run from make with read-only source directory In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 07:45:34 GMT, Nick Gasson wrote: > In an out-of-tree build where the source code is in a read-only location > several gtests such as LogFileOutput.invalid_file_test_vm will fail > because they write files to the current working directory. > > [ RUN ] LogFileOutput.invalid_file_test_vm > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/logTestUtils.inline.hpp:65 > assert failed: failed to create directory tmplogdir > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/mnt/nicgas01-pc/jdk/test/hotspot/gtest/logging/logTestUtils.inline.hpp:65), pid=51470, tid=51470 > # assert(!failed) failed: failed to create directory tmplogdir > > Run the gtest launcher with the working directory set to the test > support directory which we know is writable. This pull request has now been integrated. Changeset: f014854a Author: Nick Gasson URL: https://git.openjdk.java.net/jdk/commit/f014854a Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8253624: gtest fails when run from make with read-only source directory Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/354 From rwestberg at openjdk.java.net Mon Sep 28 06:54:21 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Mon, 28 Sep 2020 06:54:21 GMT Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v7] In-Reply-To: References: Message-ID: > A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests > for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open > source repositories. I've incorporated the feedback into an updated version that I believe is ready to be integrated. > If this is integrated into the `master` branch, future branches created and updated in personal forks will build and > run the basic tier 1 tests as described in this configuration, on Linux, Windows and macOS (all on x64). It's of course > possible for any contributor to opt out fully or partially of these automatic runs in a few different ways. To opt out > completely, a contributor can simply disable GitHub Actions on their personal fork, and no further jobs will be > executed. Another option is to add a repository secret [4] with the name `JDK_SUBMIT_FILTER` set to any value. If this > is set, only branches prefixed with `submit/` will be subject to automatic build and test. This can also be further > refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a value such as `Linux x64, Windows x64` to > limit automatic build and test to these two platforms. It will still be possible to run the tests on any branch and/or > platform by manually triggering the workflow. To see what this looks like in practice, an example run can be found > here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is currently a failing test on Windows > which is tracked by JDK-8249095, which should probably be resolved before this change is integrated). Best regards, > Robin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits [4] > https://docs.github.com/en/actions/reference/encrypted-secrets Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: Final optimization ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/284/files - new: https://git.openjdk.java.net/jdk/pull/284/files/22336eba..c7830155 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=284&range=05-06 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/284/head:pull/284 PR: https://git.openjdk.java.net/jdk/pull/284 From rwestberg at openjdk.java.net Mon Sep 28 09:39:52 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Mon, 28 Sep 2020 09:39:52 GMT Subject: Integrated: 8253424: Add support for running pre-submit testing using GitHub Actions In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 13:32:09 GMT, Robin Westberg wrote: > A few days ago I posted an initial version of the necessary configuration required to run pre-submit build and tests > for JDK main-line contributions using GitHub Actions [2] and the free tier [3] available to everyone working with open > source repositories. I've incorporated the feedback into an updated version that I believe is ready to be integrated. > If this is integrated into the `master` branch, future branches created and updated in personal forks will build and > run the basic tier 1 tests as described in this configuration, on Linux, Windows and macOS (all on x64). It's of course > possible for any contributor to opt out fully or partially of these automatic runs in a few different ways. To opt out > completely, a contributor can simply disable GitHub Actions on their personal fork, and no further jobs will be > executed. Another option is to add a repository secret [4] with the name `JDK_SUBMIT_FILTER` set to any value. If this > is set, only branches prefixed with `submit/` will be subject to automatic build and test. This can also be further > refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a value such as `Linux x64, Windows x64` to > limit automatic build and test to these two platforms. It will still be possible to run the tests on any branch and/or > platform by manually triggering the workflow. To see what this looks like in practice, an example run can be found > here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that there is currently a failing test on Windows > which is tracked by JDK-8249095, which should probably be resolved before this change is integrated). Best regards, > Robin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits [4] > https://docs.github.com/en/actions/reference/encrypted-secrets This pull request has now been integrated. Changeset: 840aa2b7 Author: Robin Westberg URL: https://git.openjdk.java.net/jdk/commit/840aa2b7 Stats: 904 lines in 2 files changed: 904 ins; 0 del; 0 mod 8253424: Add support for running pre-submit testing using GitHub Actions Reviewed-by: ehelin, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/284 From magnus.ihse.bursie at oracle.com Mon Sep 28 12:14:59 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 28 Sep 2020 14:14:59 +0200 Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions In-Reply-To: References: <2gwNsqQ3OJqaTKD66CfHrVWFbDVxxcLEvM3oMOPejOo=.5bad0484-7502-422b-8e4b-6e970959584a@github.com> <1BduorxiB-c33s_OlKgtJulsazxapxCj2kqGhAj1UiA=.9c618556-fb24-4236-aefe-bf37d5a4a4b4@github.com> Message-ID: On 2020-09-23 19:27, Erik Joelsson wrote: > The version-numbers file (which is also a shared properties style file) is not using quotes for values, which is fine > as long as there are no spaces. I believe if you read it as a properties file, you need to strip the quotes if you have > them. I prefer if version-numbers and test-dependencies using the same format. I've been away for a while, but now I'm back -- with a royal backlog. :) On a related note, I *really* think we should move the version-numbers file to make/conf. I think I even have an open bug on that somewhere. The move itself is trivial, but the consequences needs to be checked carefully. I'm happy that you put the new test-dependencies file in make/conf, though! /Magnus From mbeckwit at openjdk.java.net Mon Sep 28 13:13:43 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 28 Sep 2020 13:13:43 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v8] In-Reply-To: References: Message-ID: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith 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 22 additional commits since the last revision: - Fix graal codestyle - Reduce includes - Merge remote-tracking branch 'upstream/master' into jdk-windows - os_windows: remove duplicated UMA handling - test_safefetch{32,N} works fine on win+aarch64 - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc - cleanup for 8253457: Remove unimplemented register stack functions - Merge remote-tracking branch 'upstream/master' into jdk-windows - Update orderAccess_windows_aarch64.hpp changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided - 8248787: G1: Workaround MSVC bug Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - ... and 12 more: https://git.openjdk.java.net/jdk/compare/4dd32e55...275a0b7f ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/68f61d60..275a0b7f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=06-07 Stats: 25771 lines in 386 files changed: 3908 ins; 20954 del; 909 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Mon Sep 28 13:49:07 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 28 Sep 2020 13:49:07 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6] In-Reply-To: <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> References: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com> <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> Message-ID: On Thu, 24 Sep 2020 15:43:10 GMT, Chris Plummer wrote: >> Monica Beckwith 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 17 additional commits since >> the last revision: >> - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc >> - cleanup for 8253457: Remove unimplemented register stack functions >> - Merge remote-tracking branch 'upstream/master' into jdk-windows >> - Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided >> - 8248787: G1: Workaround MSVC bug >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248670: Windows: Exception handling support on AArch64 >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248660: AArch64: Make _clear_cache and _nop portable >> Summary: __builtin___clear_cache, etc. >> Contributed-by: mbeckwit, luhenry, burban >> - 8248659: AArch64: Extend CPU Feature detection >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248656: Add Windows AArch64 platform support code >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248498: Add build system support for Windows AArch64 >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - ... and 7 more: https://git.openjdk.java.net/jdk/compare/451890eb...2b662010 > > I looked at changes to existing SA files. These changes look fine. > > I did not look at the new aarch64 SA files other than the copyright section. I assume they are clones of the x64 > versions with some symbolic renaming. If there is any more than that and you'd like me to have a look, let me know. > As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of > other non-SA files that are new and also have the same copyright issue. > I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs > a copyright date update. @plummercj thank you for your feedback. I've updated the copyright in mentioned files. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From mbeckwit at openjdk.java.net Mon Sep 28 13:48:59 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 28 Sep 2020 13:48:59 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v9] In-Reply-To: References: Message-ID: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: SA: update copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/275a0b7f..23b209db Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=07-08 Stats: 5 lines in 5 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From mbeckwit at openjdk.java.net Mon Sep 28 14:07:16 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 28 Sep 2020 14:07:16 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: References: Message-ID: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge remote-tracking branch 'upstream/master' into jdk-windows - SA: update copyright - Fix graal codestyle - Reduce includes - Merge remote-tracking branch 'upstream/master' into jdk-windows - os_windows: remove duplicated UMA handling - test_safefetch{32,N} works fine on win+aarch64 - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc - cleanup for 8253457: Remove unimplemented register stack functions - Merge remote-tracking branch 'upstream/master' into jdk-windows - ... and 14 more: https://git.openjdk.java.net/jdk/compare/ec9bee68...a7cdaad6 ------------- Changes: https://git.openjdk.java.net/jdk/pull/212/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=09 Stats: 2566 lines in 62 files changed: 2208 ins; 126 del; 232 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From mikael at openjdk.java.net Mon Sep 28 15:59:43 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Mon, 28 Sep 2020 15:59:43 GMT Subject: RFR: 8253616: Change to GCC 10.2 for building on Linux at Oracle [v2] In-Reply-To: <2r194Vqgwk25o-n7CKoaAxekOvL5sGWvede_Te7j91E=.24ab36fc-1fe7-4318-95d9-e165b7cd3be3@github.com> References: <2r194Vqgwk25o-n7CKoaAxekOvL5sGWvede_Te7j91E=.24ab36fc-1fe7-4318-95d9-e165b7cd3be3@github.com> Message-ID: > Please review this change which updates the defaults in the linux devkit creator, the doc/building.md file, and the JIB > (Oracle) configuration to gcc 10.2. Mikael Vidstedt 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 - 8253616: Change to GCC 10.2 for building on Linux at Oracle ------------- Changes: https://git.openjdk.java.net/jdk/pull/349/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=349&range=01 Stats: 33 lines in 4 files changed: 20 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/349/head:pull/349 PR: https://git.openjdk.java.net/jdk/pull/349 From minqi at openjdk.java.net Mon Sep 28 17:36:52 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 28 Sep 2020 17:36:52 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v6] In-Reply-To: References: Message-ID: <-yguNGytFoC5nivpKCYn3IKzCPlRSb-vRyw12Rn0r5c=.29825818-7b48-4eff-9cfb-2bea3abe8f16@github.com> > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - In case of exception happens during reloading class, CHECK will return without free the allocated buffer for class bytes so moved the buffer allocation and freeing to caller. Also removed test 6 since there is not guarantee that we can give a signature which will always fail. Additional changes to GenerateJLIClassesHelper according to review suggestion. - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536 - Merge branch 'master' of https://git.openjdk.java.net/jdk into jdk-8247536 - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - Merge branch 'master' into jdk-8247536 - Merge branch 'master' of https://github.com/openjdk/jdk - Merge branch 'master' of https://github.com/openjdk/jdk - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - ... and 6 more: https://git.openjdk.java.net/jdk/compare/1ae6b533...9ab52116 ------------- Changes: https://git.openjdk.java.net/jdk/pull/193/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=05 Stats: 457 lines in 21 files changed: 433 ins; 13 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From vkempik at openjdk.java.net Mon Sep 28 17:41:43 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 28 Sep 2020 17:41:43 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> Message-ID: On Mon, 28 Sep 2020 14:07:16 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 24 commits: > - Merge remote-tracking branch 'upstream/master' into jdk-windows > - SA: update copyright > - Fix graal codestyle > - Reduce includes > - Merge remote-tracking branch 'upstream/master' into jdk-windows > - os_windows: remove duplicated UMA handling > - test_safefetch{32,N} works fine on win+aarch64 > - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc > - cleanup for 8253457: Remove unimplemented register stack functions > - Merge remote-tracking branch 'upstream/master' into jdk-windows > - ... and 14 more: https://git.openjdk.java.net/jdk/compare/ec9bee68...a7cdaad6 src/hotspot/cpu/aarch64/register_aarch64.cpp line 44: > 42: "rscratch1", "rscratch2", > 43: "r10", "r11", "r12", "r13", "r14", "r15", "r16", > 44: "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19", For me this line doesn't look good in case of expanding this functionality to macos-aarch64 as it's just the name of register and it's r18 on every platform except WIN64 and has nothing to do with reserving r18. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From minqi at openjdk.java.net Mon Sep 28 17:42:42 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 28 Sep 2020 17:42:42 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v3] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 21:45:13 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive > > test/hotspot/jtreg/runtime/cds/appcds/DumpClassListWithLF.java line 32: > >> 30: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds >> 31: * @compile ClassListFormatBase.java test-classes/Hello.java >> 32: * @run driver DumpClassListWithLF > > The `@compile` line can be removed to speed up the test execution. You can add this: > > @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds/test-classes > > and also change the code below > > appJar, classlist( > - "Hello", > + Hello.class.getName(), > > (There's no need for `/test/hotspot/jtreg/runtime/cds/appcds` in `@library` because that's the current directory of > this test). I tried using @library and passed local tests, but it failed mach5 for complaining no file Hello.class found from path. ------------- PR: https://git.openjdk.java.net/jdk/pull/193 From mikael at openjdk.java.net Mon Sep 28 18:34:36 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Mon, 28 Sep 2020 18:34:36 GMT Subject: Integrated: 8253616: Change to GCC 10.2 for building on Linux at Oracle In-Reply-To: <2r194Vqgwk25o-n7CKoaAxekOvL5sGWvede_Te7j91E=.24ab36fc-1fe7-4318-95d9-e165b7cd3be3@github.com> References: <2r194Vqgwk25o-n7CKoaAxekOvL5sGWvede_Te7j91E=.24ab36fc-1fe7-4318-95d9-e165b7cd3be3@github.com> Message-ID: On Thu, 24 Sep 2020 21:31:49 GMT, Mikael Vidstedt wrote: > Please review this change which updates the defaults in the linux devkit creator, the doc/building.md file, and the JIB > (Oracle) configuration to gcc 10.2. This pull request has now been integrated. Changeset: d25b03e9 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/d25b03e9 Stats: 33 lines in 4 files changed: 20 ins; 0 del; 13 mod 8253616: Change to GCC 10.2 for building on Linux at Oracle Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/349 From github.com+471021+marschall at openjdk.java.net Mon Sep 28 19:10:41 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Mon, 28 Sep 2020 19:10:41 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 23 Sep 2020 22:47:47 GMT, Vladimir Kozlov wrote: >> Marked as reviewed by egahlin (Reviewer). > > @marschall I will sponsor it after you integrate the latest update. @vnkozlov done, I hope I now made it correctly with a merge commit for the latest merge conflict ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From burban at openjdk.java.net Mon Sep 28 19:12:24 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 28 Sep 2020 19:12:24 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> Message-ID: On Mon, 28 Sep 2020 17:37:32 GMT, Vladimir Kempik wrote: >> Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains 24 commits: >> - Merge remote-tracking branch 'upstream/master' into jdk-windows >> - SA: update copyright >> - Fix graal codestyle >> - Reduce includes >> - Merge remote-tracking branch 'upstream/master' into jdk-windows >> - os_windows: remove duplicated UMA handling >> - test_safefetch{32,N} works fine on win+aarch64 >> - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc >> - cleanup for 8253457: Remove unimplemented register stack functions >> - Merge remote-tracking branch 'upstream/master' into jdk-windows >> - ... and 14 more: https://git.openjdk.java.net/jdk/compare/ec9bee68...a7cdaad6 > > src/hotspot/cpu/aarch64/register_aarch64.cpp line 44: > >> 42: "rscratch1", "rscratch2", >> 43: "r10", "r11", "r12", "r13", "r14", "r15", "r16", >> 44: "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19", > > For me this line doesn't look good in case of expanding this functionality to macos-aarch64 > as it's just the name of register and it's r18 on every platform except WIN64 and has nothing to do with reserving r18. The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS: Suggestion: "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", Are you suggesting it should rather be something like this eventually? Suggestion: "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From vkempik at openjdk.java.net Mon Sep 28 19:33:11 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 28 Sep 2020 19:33:11 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> Message-ID: On Mon, 28 Sep 2020 19:09:17 GMT, Bernhard Urban-Forster wrote: >> src/hotspot/cpu/aarch64/register_aarch64.cpp line 44: >> >>> 42: "rscratch1", "rscratch2", >>> 43: "r10", "r11", "r12", "r13", "r14", "r15", "r16", >>> 44: "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19", >> >> For me this line doesn't look good in case of expanding this functionality to macos-aarch64 >> as it's just the name of register and it's r18 on every platform except WIN64 and has nothing to do with reserving r18. > > The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for > macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS: > Suggestion: > "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", > Are you suggesting it should rather be something like this eventually? > Suggestion: > > "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", this looks better I think, if it's done right from beginning, we won't have to modify it later. The Question is, can we do it ahead of JEP-391 ? If we can't then maybe better to leave it this way for now: WIN64_ONLY("rtls") NOT_WIN64("r18") as r18 is supposed to be reserved register on aarch64, linux is just an exception where it's allowed. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Mon Sep 28 19:40:49 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 28 Sep 2020 19:40:49 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> Message-ID: <9cbO1bZWUEMui6WWZKjYKrvGhvNXgCLdm3C3NInY07k=.5a5ff95b-5c3b-467e-b2d4-04ef075f3f58@github.com> On Mon, 28 Sep 2020 19:28:10 GMT, Vladimir Kempik wrote: >> The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for >> macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS: >> Suggestion: >> "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", >> Are you suggesting it should rather be something like this eventually? >> Suggestion: >> >> "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", > > this looks better I think, if it's done right from beginning, we won't have to modify it later. > The Question is, can we do it ahead of JEP-391 ? > If we can't then maybe better to leave it this way for now: > WIN64_ONLY("rtls") NOT_WIN64("r18") > > as r18 is supposed to be reserved register on aarch64, linux is just an exception where it's allowed. Let us go with the following in this PR as that's the extend of this PR: Suggestion: "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls"), "r19", We can update it accordingly in a PR for JEP-391. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From vkempik at openjdk.java.net Mon Sep 28 19:44:33 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 28 Sep 2020 19:44:33 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: <9cbO1bZWUEMui6WWZKjYKrvGhvNXgCLdm3C3NInY07k=.5a5ff95b-5c3b-467e-b2d4-04ef075f3f58@github.com> References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> <9cbO1bZWUEMui6WWZKjYKrvGhvNXgCLdm3C3NInY07k=.5a5ff95b-5c3b-467e-b2d4-04ef075f3f58@github.com> Message-ID: On Mon, 28 Sep 2020 19:38:15 GMT, Bernhard Urban-Forster wrote: >> this looks better I think, if it's done right from beginning, we won't have to modify it later. >> The Question is, can we do it ahead of JEP-391 ? >> If we can't then maybe better to leave it this way for now: >> WIN64_ONLY("rtls") NOT_WIN64("r18") >> >> as r18 is supposed to be reserved register on aarch64, linux is just an exception where it's allowed. > > Let us go with the following in this PR as that's the extend of this PR: > Suggestion: > > "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls"), "r19", > We can update it accordingly in a PR for JEP-391. Ok, Great. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From mbeckwit at openjdk.java.net Mon Sep 28 19:53:37 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 28 Sep 2020 19:53:37 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v11] In-Reply-To: References: Message-ID: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: r18 only on Linux ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/a7cdaad6..398d7645 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From mikael at openjdk.java.net Mon Sep 28 21:25:15 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Mon, 28 Sep 2020 21:25:15 GMT Subject: Integrated: 8248984: Bump minimum boot jdk to JDK 15 In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 22:32:37 GMT, Mikael Vidstedt wrote: > JDK 15 is now GA. The minimum boot JDK version for mainline/JDK 16 should be bumped to this version. > > Testing: tier1-5 passed with a slightly earlier version of this change. Re-running tier1 now for good luck. This pull request has now been integrated. Changeset: 527b0e44 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/527b0e44 Stats: 18 lines in 2 files changed: 0 ins; 13 del; 5 mod 8248984: Bump minimum boot jdk to JDK 15 Reviewed-by: darcy, erikj, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/326 From dholmes at openjdk.java.net Tue Sep 29 06:57:02 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 29 Sep 2020 06:57:02 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v11] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 19:53:37 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > r18 only on Linux Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From mbaesken at openjdk.java.net Tue Sep 29 07:14:29 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 29 Sep 2020 07:14:29 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: > >> 127: NSColor* result = nil; >> 128: >> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >> java_awt_SystemColor_NUM_COLORS)) { > > This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just > has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues > related to the compiler upgrade. Someone might want to backport just this fix, for example. Hello Kim, Paul - so should we open a separate bug for the src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for the useAppleColor check in CSystemColors.m ? ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From mbaesken at openjdk.java.net Tue Sep 29 07:59:05 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 29 Sep 2020 07:59:05 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: <5q0sckv5JjyV1HNZMX1f1eG2dwCjfLTejO8pfH7tS5s=.f1a8c3d5-a436-41bd-9d9f-68f0103539a1@github.com> References: <5q0sckv5JjyV1HNZMX1f1eG2dwCjfLTejO8pfH7tS5s=.f1a8c3d5-a436-41bd-9d9f-68f0103539a1@github.com> Message-ID: On Fri, 25 Sep 2020 02:23:07 GMT, David Holmes wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > src/hotspot/share/runtime/sharedRuntime.cpp line 2851: > >> 2849: if (buf != NULL) { >> 2850: CodeBuffer buffer(buf); >> 2851: short locs_buf[80]; > > This code is just weird. Why is the locs_buf array not declared to be the desired type? If the compiler rejects double > because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or > int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ? Currently we have in the existing code various kind of buffers passed into initialize_shared_locs that compile nicely on all supported compilers and on Xcode 12 as well ,see c1_Compilation.cpp 326 char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size); 327 code->insts()->initialize_shared_locs((relocInfo*)locs_buffer, sharedRuntime.cpp 2681 CodeBuffer buffer(buf); 2682 short buffer_locs[20]; 2683 buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, 2684 sizeof(buffer_locs)/sizeof(relocInfo)); So probably using short would be consistent to what we do already in the coding at another place (looking into relocInfo it would be probably better to use unsigned short or to typedef unsigned short in the relocInfo class and use the typedef). ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From aph at redhat.com Tue Sep 29 09:24:35 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Sep 2020 10:24:35 +0100 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> Message-ID: <2f5093a5-2e1b-6ce9-3fc9-2c036261218f@redhat.com> On 28/09/2020 20:12, Bernhard Urban-Forster wrote: > The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for > macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS: > Suggestion: > > "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", > Are you suggesting it should rather be something like this eventually? > Suggestion: > > "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", This wrong. We can't use the register in Linux only, except in Linux-specific code of which there is almost none. It should be called r18_tls everywhere, as discussed. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Sep 29 09:26:31 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Sep 2020 10:26:31 +0100 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> Message-ID: On 28/09/2020 20:12, Bernhard Urban-Forster wrote: > The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for > macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS: > Suggestion: > > "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", > Are you suggesting it should rather be something like this eventually? > Suggestion: > > "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", This is wrong. We can't use the register in Linux either, except in Linux-specific code of which there is almost none. It's also a pointless complication. r18 should be called r18_tls everywhere, as discussed. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ihse at openjdk.java.net Tue Sep 29 11:16:06 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 29 Sep 2020 11:16:06 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v11] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 19:53:37 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > r18 only on Linux Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/212 From kim.barrett at oracle.com Tue Sep 29 11:22:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 07:22:48 -0400 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <751EE42A-4A0F-45EB-88EA-FD7A2B068CD2@oracle.com> > On Sep 29, 2020, at 3:14 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: >> >>> 127: NSColor* result = nil; >>> 128: >>> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >>> java_awt_SystemColor_NUM_COLORS)) { >> >> This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just >> has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues >> related to the compiler upgrade. Someone might want to backport just this fix, for example. > > Hello Kim, Paul - so should we open a separate bug for the > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just > uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for > the useAppleColor check in CSystemColors.m ? I think so. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Tue Sep 29 12:02:11 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 08:02:11 -0400 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: <5q0sckv5JjyV1HNZMX1f1eG2dwCjfLTejO8pfH7tS5s=.f1a8c3d5-a436-41bd-9d9f-68f0103539a1@github.com> Message-ID: <20D716A9-C5BC-47A3-ADB4-CBA732A94DF6@oracle.com> > On Sep 29, 2020, at 3:59 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 02:23:07 GMT, David Holmes wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/hotspot/share/runtime/sharedRuntime.cpp line 2851: >> >>> 2849: if (buf != NULL) { >>> 2850: CodeBuffer buffer(buf); >>> 2851: short locs_buf[80]; >> >> This code is just weird. Why is the locs_buf array not declared to be the desired type? If the compiler rejects double >> because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or >> int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ? > > Currently we have in the existing code various kind of buffers passed into initialize_shared_locs that compile nicely > on all supported compilers and on Xcode 12 as well ,see > > c1_Compilation.cpp > > 326 char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size); > 327 code->insts()->initialize_shared_locs((relocInfo*)locs_buffer, > > sharedRuntime.cpp > > 2681 CodeBuffer buffer(buf); > 2682 short buffer_locs[20]; > 2683 buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, > 2684 sizeof(buffer_locs)/sizeof(relocInfo)); > > So probably using short would be consistent to what we do already in the coding at another place (looking into > relocInfo it would be probably better to use unsigned short or to typedef unsigned short in the relocInfo class > and use the typedef). That?s *not* consistent, because of buffer alignment. The call to NEW_RESOURCE_ARRAY is going to return a pointer to memory that is 2*word aligned. (Interesting, possibly a 32/64 bit ?bug? here.) The existing code in sharedRuntime.cpp is allocating double-aligned. iniitalize_shared_locs wants a HeapWordSize-aligned buffer, and adjusts the pointer it uses accordingly. (I think with existing code it could just make the alignment of the buffer a precondition, but I haven?t looked at all callers.) Changing the declaration in sharedRuntime.cpp to short[] reduces the alignment requirement for the array, possibly requiring alignment adjustment (and hence size reduction) by initialize_shared_locs. Since initialize_shared_locs specifically adjusts the alignment, some downstream use of the buffer probably actually cares. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From hohensee at amazon.com Tue Sep 29 13:46:27 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 29 Sep 2020 13:46:27 +0000 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Message-ID: <8D7E0A19-32C7-47CC-890D-1670A5A02D5E@amazon.com> Hi, Matthias, Kim. No problem opening a separate issue to fix CSystemColors.m. Thanks, Paul ?On 9/29/20, 4:23 AM, "hotspot-dev on behalf of Kim Barrett" wrote: > On Sep 29, 2020, at 3:14 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: >> >>> 127: NSColor* result = nil; >>> 128: >>> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >>> java_awt_SystemColor_NUM_COLORS)) { >> >> This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just >> has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues >> related to the compiler upgrade. Someone might want to backport just this fix, for example. > > Hello Kim, Paul - so should we open a separate bug for the > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just > uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for > the useAppleColor check in CSystemColors.m ? I think so. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From mbeckwit at openjdk.java.net Tue Sep 29 14:08:49 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Tue, 29 Sep 2020 14:08:49 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12] In-Reply-To: References: Message-ID: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: change string representation for r18 to "r18_tls" on every platform ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/398d7645..15466ab2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Tue Sep 29 14:08:50 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Tue, 29 Sep 2020 14:08:50 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7] In-Reply-To: References: <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com> Message-ID: On Fri, 25 Sep 2020 12:44:37 GMT, Andrew Haley wrote: >> Monica Beckwith has updated the pull request incrementally with two additional commits since the last revision: >> >> - os_windows: remove duplicated UMA handling >> - test_safefetch{32,N} works fine on win+aarch64 > > Marked as reviewed by aph (Reviewer). @theRealAph okay, I've changed the string representation of `r18` to `"r18_tls"` on every platform. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From mbaesken at openjdk.java.net Tue Sep 29 14:09:25 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 29 Sep 2020 14:09:25 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 07:11:34 GMT, Matthias Baesken wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: >> >>> 127: NSColor* result = nil; >>> 128: >>> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >>> java_awt_SystemColor_NUM_COLORS)) { >> >> This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just >> has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues >> related to the compiler upgrade. Someone might want to backport just this fix, for example. > > Hello Kim, Paul - so should we open a separate bug for the > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just > uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for > the useAppleColor check in CSystemColors.m ? I created https://bugs.openjdk.java.net/browse/JDK-8253791 8253791: Issue with useAppleColor check in CSystemColors.m for this issue (Kim and Paul are fine to have a separate JBS issue for this) ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From hohensee at amazon.com Tue Sep 29 14:18:18 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 29 Sep 2020 14:18:18 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Message-ID: Thanks for the reviews/discussion, and apologies for the delayed reply: I've been OOTO. Kim is correct, initialize_shared_locs specifically adjusts the alignment of its buffer argument, which is why short works. char would work as well, but short happens to be the size of a relocInfo. Maybe the author of the other use in sharedRuntime.cpp at line 2682 used short to remind of that. Code that calls initialize_shared_locs is inconsistent even within itself. E.g., in c1_Compilation.cpp, we have int locs_buffer_size = 20 * (relocInfo::length_limit + sizeof(relocInfo)); char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size); code->insts()->initialize_shared_locs((relocInfo*)locs_buffer, locs_buffer_size / sizeof(relocInfo)); relocInfo::length_limit is a count of shorts, while sizeof(relocInfo) is a count of chars. The units aren?t the same but are added together as if they were. relocInfo::length_limit is supposed to be the maximum size of a compressed relocation record, so why add sizeof(relocInfo)? And then in sharedRuntime.cpp, we have two places. The first: short buffer_locs[20]; buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, sizeof(buffer_locs)/sizeof(relocInfo)); relocInfo::length_limit is 15 on a 64-bit machine, so with a buffer of 20 shorts, alignment in initialize_shared_locs might take up to of 3 more, which is uncomfortably close to 20 afaic. And, if you add sizeof(relocInfo) as happens in c1_Compilation.cpp, you're bang on at 20. The unstated assumption seems to be that only a single relocation record will be needed. The second: double locs_buf[20]; buffer.insts()->initialize_shared_locs((relocInfo*)locs_buf, sizeof(locs_buf) / sizeof(relocInfo)); This at allocates a buffer that will hold 5 compressed relocation records with 10 bytes left over, and guarantees 8 byte alignment. Perhaps when it was written, initialize_shared_locs didn't align its buffer argument address. And, there's that sizeof(relocInfo) padding again: 2 extra bytes per relocation record. Anyway, I just wanted to make the compiler warning go away, not figure out why the code is the way it is. Matthias and Kim would like to separate out the CSystemColors.m patch into a separate bug, which is fine by me (see separate email). So, for the sharedRuntime patch, would it be ok to just use short locs_buf[84]; to account for possible alignment in initialize_shared_locs? I'm using 84 because 80 is exactly 5 records plus 5 sizeof(relocInfo)s, allowing for alignment adds 3, and rounding the total array size up to a multiple of 8 adds 1. Thanks, Paul ?On 9/29/20, 5:03 AM, "2d-dev on behalf of Kim Barrett" <2d-dev-retn at openjdk.java.net on behalf of kim.barrett at oracle.com> wrote: > On Sep 29, 2020, at 3:59 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 02:23:07 GMT, David Holmes wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/hotspot/share/runtime/sharedRuntime.cpp line 2851: >> >>> 2849: if (buf != NULL) { >>> 2850: CodeBuffer buffer(buf); >>> 2851: short locs_buf[80]; >> >> This code is just weird. Why is the locs_buf array not declared to be the desired type? If the compiler rejects double >> because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or >> int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ? > > Currently we have in the existing code various kind of buffers passed into initialize_shared_locs that compile nicely > on all supported compilers and on Xcode 12 as well ,see > > c1_Compilation.cpp > > 326 char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size); > 327 code->insts()->initialize_shared_locs((relocInfo*)locs_buffer, > > sharedRuntime.cpp > > 2681 CodeBuffer buffer(buf); > 2682 short buffer_locs[20]; > 2683 buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, > 2684 sizeof(buffer_locs)/sizeof(relocInfo)); > > So probably using short would be consistent to what we do already in the coding at another place (looking into > relocInfo it would be probably better to use unsigned short or to typedef unsigned short in the relocInfo class > and use the typedef). That?s *not* consistent, because of buffer alignment. The call to NEW_RESOURCE_ARRAY is going to return a pointer to memory that is 2*word aligned. (Interesting, possibly a 32/64 bit ?bug? here.) The existing code in sharedRuntime.cpp is allocating double-aligned. iniitalize_shared_locs wants a HeapWordSize-aligned buffer, and adjusts the pointer it uses accordingly. (I think with existing code it could just make the alignment of the buffer a precondition, but I haven?t looked at all callers.) Changing the declaration in sharedRuntime.cpp to short[] reduces the alignment requirement for the array, possibly requiring alignment adjustment (and hence size reduction) by initialize_shared_locs. Since initialize_shared_locs specifically adjusts the alignment, some downstream use of the buffer probably actually cares. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From matthias.baesken at sap.com Tue Sep 29 14:41:59 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 29 Sep 2020 14:41:59 +0000 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: <8D7E0A19-32C7-47CC-890D-1670A5A02D5E@amazon.com> References: <8D7E0A19-32C7-47CC-890D-1670A5A02D5E@amazon.com> Message-ID: > Hi, Matthias, Kim. No problem opening a separate issue to fix CSystemColors.m. Hi Paul, did that : https://bugs.openjdk.java.net/browse/JDK-8253791 https://github.com/openjdk/jdk/pull/403 Best regards, Matthias -----Original Message----- From: Hohensee, Paul Sent: Dienstag, 29. September 2020 15:46 To: Kim Barrett ; Matthias Baesken Cc: 2d-dev at openjdk.java.net; awt-dev at openjdk.java.net; build-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: RE: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Hi, Matthias, Kim. No problem opening a separate issue to fix CSystemColors.m. Thanks, Paul ?On 9/29/20, 4:23 AM, "hotspot-dev on behalf of Kim Barrett" wrote: > On Sep 29, 2020, at 3:14 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: >> >>> 127: NSColor* result = nil; >>> 128: >>> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >>> java_awt_SystemColor_NUM_COLORS)) { >> >> This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just >> has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues >> related to the compiler upgrade. Someone might want to backport just this fix, for example. > > Hello Kim, Paul - so should we open a separate bug for the > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just > uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for > the useAppleColor check in CSystemColors.m ? I think so. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Tue Sep 29 16:32:27 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 12:32:27 -0400 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <0CA82EAC-9A42-411F-8761-6D9D4F85101E@oracle.com> > On Sep 29, 2020, at 10:18 AM, Hohensee, Paul wrote: > Code that calls initialize_shared_locs is inconsistent even within itself. E.g., in c1_Compilation.cpp, we have Agreed there seems to be a bit of a mess around that function. > Anyway, I just wanted to make the compiler warning go away, not figure out why the code is the way it is. Matthias and Kim would like to separate out the CSystemColors.m patch into a separate bug, which is fine by me (see separate email). > > So, for the sharedRuntime patch, would it be ok to just use > > short locs_buf[84]; > > to account for possible alignment in initialize_shared_locs? I'm using 84 because 80 is exactly 5 records plus 5 sizeof(relocInfo)s, allowing for alignment adds 3, and rounding the total array size up to a multiple of 8 adds 1. Your analysis looks plausible. But consider instead struct { double data[20]; } locs_buf; and change next line to use &locs_buf This doesn't change the size or alignment from pre-existing code. I can't test whether this will suppress the warning, but I'm guessing it will. And the rest of below is off if that?s wrong. Changing the size and type and worrying about alignment changes seems beyond what's needed "to make the compiler warning go away, not figure out why the code is the way it is.? I dislike making weird changes to suppress compiler warnings, but changing the type and size seems more weird to me here. I mean, 84 looks like a number pulled out of a hat, unless you are going to add a bunch of commentary that probably really belongs in a bug report to look at this stuff more carefully. And file an RFE to look at initialize_shared_locs and its callers more carefully. From phh at openjdk.java.net Tue Sep 29 19:33:48 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Tue, 29 Sep 2020 19:33:48 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul Paul Hohensee 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: - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch - Merge branch 'master' into JDK-8253375 - JDK-8253375 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/348/files - new: https://git.openjdk.java.net/jdk/pull/348/files/5db5edc2..cb08da07 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=348&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=348&range=00-01 Stats: 27610 lines in 391 files changed: 4691 ins; 21610 del; 1309 mod Patch: https://git.openjdk.java.net/jdk/pull/348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/348/head:pull/348 PR: https://git.openjdk.java.net/jdk/pull/348 From kbarrett at openjdk.java.net Tue Sep 29 19:39:03 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 29 Sep 2020 19:39:03 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee 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: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From lucy at openjdk.java.net Tue Sep 29 20:05:34 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 29 Sep 2020 20:05:34 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee 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: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 The proposed (updated) change does _NOT_ compile on my machine (MacOS 10.15.6, Xcode 12.0): sharedRuntime.cpp:2860:46: error: cannot cast from type 'struct (anonymous struct at sharedRuntime.cpp:2859:7)' to pointer type 'relocInfo *' You will have to use a union (option (2) as proposed by Kim Barrett far above. I proved that variant compiles on my machine. ------------- Changes requested by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From cjplummer at openjdk.java.net Tue Sep 29 20:11:19 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 29 Sep 2020 20:11:19 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7] In-Reply-To: References: <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com> Message-ID: On Tue, 29 Sep 2020 14:03:57 GMT, Bernhard Urban-Forster wrote: >> Marked as reviewed by aph (Reviewer). > > @theRealAph okay, I've changed the string representation of `r18` to `"r18_tls"` on every platform. > @plummercj thank you for your feedback. I've updated the copyright in mentioned files. Changes look good. Thanks. I'm marking as "reviewed" for serviceability changes and copyrights. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From cjplummer at openjdk.java.net Tue Sep 29 20:16:24 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 29 Sep 2020 20:16:24 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:08:49 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > change string representation for r18 to "r18_tls" on every platform Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From kim.barrett at oracle.com Tue Sep 29 20:53:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 16:53:48 -0400 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: > On Sep 29, 2020, at 4:05 PM, Lutz Schmidt wrote: > > On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> Paul Hohensee 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: >> - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch >> - Merge branch 'master' into JDK-8253375 >> - JDK-8253375 > > The proposed (updated) change does _NOT_ compile on my machine (MacOS 10.15.6, Xcode 12.0): > > sharedRuntime.cpp:2860:46: error: cannot cast from type 'struct (anonymous struct at sharedRuntime.cpp:2859:7)' to > pointer type 'relocInfo *? Did you use the change from the PR, or apply it manually. That looks like the error one would get if only the type of locs_buf were changed, without changing to take the address in the reference. That is, without changing `(relocInfo*)locs_buf` to `(relocInfo*)&locs_buf`. That second change is in the PR. > You will have to use a union (option (2) as proposed by Kim Barrett far above. I proved that variant compiles on my > machine. > > ------------- > > Changes requested by lucy (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/348 From psandoz at openjdk.java.net Tue Sep 29 21:51:36 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 29 Sep 2020 21:51:36 GMT Subject: RFR: 8223347: Integration of Vector API (Incubator) Message-ID: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the title): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code has changed, except for that related to merging. ------------- Commit messages: - Fix permissions - Fix permissions - Merge master - Vector API new files - Integration of Vector API (Incubator) Changes: https://git.openjdk.java.net/jdk/pull/367/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=367&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223347 Stats: 295107 lines in 336 files changed: 292957 ins; 1062 del; 1088 mod Patch: https://git.openjdk.java.net/jdk/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/367/head:pull/367 PR: https://git.openjdk.java.net/jdk/pull/367 From erikj at openjdk.java.net Tue Sep 29 22:02:39 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 29 Sep 2020 22:02:39 GMT Subject: RFR: 8223347: Integration of Vector API (Incubator) In-Reply-To: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com> References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com> Message-ID: On Fri, 25 Sep 2020 20:14:29 GMT, Paul Sandoz wrote: > This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was > used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the > title): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html > > If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a > pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code > has changed, except for that related to merging. Build changes look ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/367 From hohensee at amazon.com Tue Sep 29 22:14:27 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 29 Sep 2020 22:14:27 +0000 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] Message-ID: <398178BA-0420-4ED1-9B70-7FBC3336638D@amazon.com> Hmm. I'm running Xcode 12.0.1 on 10.15.6 and don't see it. Are you sure you have the '&' in front of locs_buf? I.e., buffer.insts()->initialize_shared_locs((relocInfo*)&locs_buf, sizeof(locs_buf) / sizeof(relocInfo)); ^ Thanks, Paul ?On 9/29/20, 1:07 PM, "build-dev on behalf of Lutz Schmidt" wrote: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee 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: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 The proposed (updated) change does _NOT_ compile on my machine (MacOS 10.15.6, Xcode 12.0): sharedRuntime.cpp:2860:46: error: cannot cast from type 'struct (anonymous struct at sharedRuntime.cpp:2859:7)' to pointer type 'relocInfo *' You will have to use a union (option (2) as proposed by Kim Barrett far above. I proved that variant compiles on my machine. ------------- Changes requested by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From dholmes at openjdk.java.net Wed Sep 30 00:43:13 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 30 Sep 2020 00:43:13 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:08:49 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > change string representation for r18 to "r18_tls" on every platform Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From jiefu at openjdk.java.net Wed Sep 30 03:36:11 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 30 Sep 2020 03:36:11 GMT Subject: RFR: 8223347: Integration of Vector API (Incubator) In-Reply-To: References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com> Message-ID: <-JIanIoqecCK7WfRPElGiS9Gora2wP3NfpGZ3hNL_Hg=.2ccfa0e9-33c6-430b-9303-66829e97e6ff@github.com> On Tue, 29 Sep 2020 22:00:04 GMT, Erik Joelsson wrote: >> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was >> used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the >> title): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html >> >> If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a >> pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code >> has changed, except for that related to merging. > > Build changes look ok. Hi @PaulSandoz , This integration seems to miss https://github.com/openjdk/panama-vector/pull/1, which had fixed crashes on AVX512 machines. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/367 From minqi at openjdk.java.net Wed Sep 30 04:59:20 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 30 Sep 2020 04:59:20 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v7] In-Reply-To: References: Message-ID: > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Remove trailing word of line which is not used in holder class regeneration. There is a trailing LF (Line Feed) so trim white spaces from both front and end of the line or it will fail method type validation. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/193/files - new: https://git.openjdk.java.net/jdk/pull/193/files/9ab52116..9b0f523b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=05-06 Stats: 22 lines in 2 files changed: 10 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From lucy at openjdk.java.net Wed Sep 30 05:54:42 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 30 Sep 2020 05:54:42 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee 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: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 I just copied the declaration and oversaw that tiny little '&'. With it, sharedRuntime.cpp compiles fine. Sorry for not being careful enough. Reviewed. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From hohensee at amazon.com Wed Sep 30 12:15:07 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 30 Sep 2020 12:15:07 +0000 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] Message-ID: <364A2F2E-E8C9-4A83-94EF-D067280FE037@amazon.com> Thanks, Lutz! ?On 9/29/20, 10:56 PM, "build-dev on behalf of Lutz Schmidt" wrote: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee 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: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 I just copied the declaration and oversaw that tiny little '&'. With it, sharedRuntime.cpp compiles fine. Sorry for not being careful enough. Reviewed. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From phh at openjdk.java.net Wed Sep 30 12:19:01 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Wed, 30 Sep 2020 12:19:01 GMT Subject: Integrated: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <-aDiMyf9VRdCWuDRYzuFLBKq2amMJspLw7Cnqt1hhTg=.404ceda1-f8a3-4b99-9a38-269da1939573@github.com> On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul This pull request has now been integrated. Changeset: f80a6066 Author: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/f80a6066 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8253375: OSX build fails with Xcode 12.0 (12A7209) Replace double array with short array in AdapterHandlerLibrary::create_native_wrapper, add parens around ?: in CSystemColors:getColor Reviewed-by: prr, kbarrett, lucy ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From rwestberg at openjdk.java.net Wed Sep 30 17:05:00 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Wed, 30 Sep 2020 17:05:00 GMT Subject: RFR: 8253865: Pre-submit testing using GitHub Actions does not detect failures reliably Message-ID: The pre-submit test definitions utilizing GitHub Actions can sometimes report success even when there are failing tests. The failure detection depended on make returning a non-zero exit code on failures, which doesn't seem to work. To properly determine test outcome we should check the "test-summary.txt" result file for the string "TEST SUCCESS". If it isn't found, the tests must have failed. This change also includes a reliability improvement. Here's an example of a run with the updated test definitions: https://github.com/rwestberg/jdk/actions/runs/280529475 Note! There is a failure now properly detected in langtools/tier1 on Windows (tools/javac/launcher/SourceLauncherTest.java) which is tracked by https://bugs.openjdk.java.net/browse/JDK-8249095 - could be of interest to either fix or ProblemList that one before integrating this change. ------------- Commit messages: - Retry artifact downloading on failure - Check results and show comprehensive list of failing tests (if any) Changes: https://git.openjdk.java.net/jdk/pull/437/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=437&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253865 Stats: 108 lines in 1 file changed: 108 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/437.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/437/head:pull/437 PR: https://git.openjdk.java.net/jdk/pull/437 From hohensee at amazon.com Wed Sep 30 17:28:26 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 30 Sep 2020 17:28:26 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Message-ID: <68FA0B26-8DB3-4F08-9F76-87DD570FDF28@amazon.com> I filed https://bugs.openjdk.java.net/browse/JDK-8253868: CodeSection::initialize_shared_locs buffer argument types and sizes are opaque Paul ?On 9/29/20, 9:35 AM, "Kim Barrett" wrote: > On Sep 29, 2020, at 10:18 AM, Hohensee, Paul wrote: > Code that calls initialize_shared_locs is inconsistent even within itself. E.g., in c1_Compilation.cpp, we have Agreed there seems to be a bit of a mess around that function. > Anyway, I just wanted to make the compiler warning go away, not figure out why the code is the way it is. Matthias and Kim would like to separate out the CSystemColors.m patch into a separate bug, which is fine by me (see separate email). > > So, for the sharedRuntime patch, would it be ok to just use > > short locs_buf[84]; > > to account for possible alignment in initialize_shared_locs? I'm using 84 because 80 is exactly 5 records plus 5 sizeof(relocInfo)s, allowing for alignment adds 3, and rounding the total array size up to a multiple of 8 adds 1. Your analysis looks plausible. But consider instead struct { double data[20]; } locs_buf; and change next line to use &locs_buf This doesn't change the size or alignment from pre-existing code. I can't test whether this will suppress the warning, but I'm guessing it will. And the rest of below is off if that?s wrong. Changing the size and type and worrying about alignment changes seems beyond what's needed "to make the compiler warning go away, not figure out why the code is the way it is.? I dislike making weird changes to suppress compiler warnings, but changing the type and size seems more weird to me here. I mean, 84 looks like a number pulled out of a hat, unless you are going to add a bunch of commentary that probably really belongs in a bug report to look at this stuff more carefully. And file an RFE to look at initialize_shared_locs and its callers more carefully. From psandoz at openjdk.java.net Wed Sep 30 18:22:31 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 30 Sep 2020 18:22:31 GMT Subject: RFR: 8223347: Integration of Vector API (Incubator) In-Reply-To: <-JIanIoqecCK7WfRPElGiS9Gora2wP3NfpGZ3hNL_Hg=.2ccfa0e9-33c6-430b-9303-66829e97e6ff@github.com> References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com> <-JIanIoqecCK7WfRPElGiS9Gora2wP3NfpGZ3hNL_Hg=.2ccfa0e9-33c6-430b-9303-66829e97e6ff@github.com> Message-ID: On Wed, 30 Sep 2020 03:33:38 GMT, Jie Fu wrote: >> Build changes look ok. > > Hi @PaulSandoz , > > This integration seems to miss https://github.com/openjdk/panama-vector/pull/1, which had fixed crashes on AVX512 > machines. > Thanks. @DamonFool we can follow up later for that fix (and others in `vectorIntrinsics`), after this PR integrates. I don't want to perturb the code that has already been reviewed, which requires yet more additional review. ------------- PR: https://git.openjdk.java.net/jdk/pull/367 From kvn at openjdk.java.net Wed Sep 30 20:05:42 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 30 Sep 2020 20:05:42 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Mon, 28 Sep 2020 19:08:04 GMT, Philippe Marschall wrote: >> @marschall I will sponsor it after you integrate the latest update. > > @vnkozlov done, I hope I now made it correctly with a merge commit for the latest merge conflict hs-tier1, hs-tier3-graal testing passed ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From github.com+471021+marschall at openjdk.java.net Wed Sep 30 20:07:31 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Wed, 30 Sep 2020 20:07:31 GMT Subject: Integrated: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. This pull request has now been integrated. Changeset: 2a406f3c Author: Philippe Marschall Committer: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/2a406f3c Stats: 749 lines in 65 files changed: 149 ins; 149 del; 451 mod 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package Reviewed-by: dholmes, alanb, psandoz, kvn, egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From kustos at gmx.net Wed Sep 23 18:40:22 2020 From: kustos at gmx.net (Philippe Marschall) Date: Wed, 23 Sep 2020 20:40:22 +0200 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On 22.09.20 10:45, Erik Gahlin wrote: > On Sat, 12 Sep 2020 00:19:00 GMT, Vladimir Kozlov wrote: > >>> Philippe Marschall 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: >>> 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate >> >> Marked as reviewed by kvn (Reviewer). > > Have you run the JFR tests in test/jdk/jdk/jfr? I initially did not but now I have. jdk.jfr.event.runtime.TestModuleEvents was failing, I have updated it to what makes sense to me. Cheers Philippe From kustos at gmx.net Wed Sep 23 18:42:59 2020 From: kustos at gmx.net (Philippe Marschall) Date: Wed, 23 Sep 2020 20:42:59 +0200 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On 23.09.20 07:13, David Holmes wrote: > On Tue, 22 Sep 2020 08:43:04 GMT, Erik Gahlin wrote: > >>> Marked as reviewed by kvn (Reviewer). >> >> Have you run the JFR tests in test/jdk/jdk/jfr? > > @marschall Please do not force-push anything as it breaks the commit history in the PR and renders previous > reviews/comments obsolete. There is no way for the reviewers to see what changed between the commit they reviewed and > the commit now in the PR. > > To update to latest changes you should have just merged your branch with your (up-to-date) local master, committed that > merge in your local branch and then pushed that commit to your Personal Fork. The skara tooling will flatten the series > of commits in a PR into one single well-formed commit that is pushed to the master branch of the repo. My apologies, I was not aware of this, I won't make this mistake in the future again. I don't assume there is a way to fix this now. Philippe