From cjashfor at linux.ibm.com Tue Sep 1 00:17:08 2020 From: cjashfor at linux.ibm.com (Corey Ashford) Date: Mon, 31 Aug 2020 17:17:08 -0700 Subject: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: <11ca749f-3015-c004-aa6b-3194e1dfe4eb@linux.ibm.com> Message-ID: <5ac1ac19-af1c-4ee6-b478-873031710081@linux.ibm.com> On 8/27/20 8:07 AM, Doerr, Martin wrote: >>> I will use __attribute__ ((align(16))) instead of __vector, and make >> them arrays of 16 unsigned char. > Maybe __vectors works as expected, too, now. Whatever we use, I'd appreciate to double-check the alignment e.g. by using gdb. > I don't remember what we had tried and why it didn't work as desired. I just now tried on gcc-7.5.0, declaring a __vector at 1, 2, 3, 8, 9, and 15 byte offsets in a struct, trying to force a misalignment, but the compiler realigned all of them on 16-byte boundaries. If someone decides to make the intrinsic work on AIX (big endian), and compiles with 7.3.1, I don't know what will happen w.r.t. alignment, so to be on the safe side, I will make the declarations 16-byte unsigned char arrays with an align attribute. Looking a bit deeper, I see that the __vector type comes out of the C preprocessor as: __attribute__((altivec(vector__))). It's part of the compiler's basic set of predefined macros, and can be seen using this command: % gcc -dM -E - < /dev/null | grep __vector #define __vector __attribute__((altivec(vector__))) Some information here: https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Type-Attributes.html I don't know if this is helpful or not, but it might answer part of your question about the meaning of __vector. Regards, - Corey From aph at redhat.com Tue Sep 1 07:52:03 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 1 Sep 2020 08:52:03 +0100 Subject: [aarch64-port-dev ] RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: <1729f1b1-056d-76c9-c820-d38bd6c1235d@redhat.com> Message-ID: On 31/08/2020 10:46, Yangfei (Felix) wrote: > >> -----Original Message----- >> From: Andrew Haley [mailto:aph at redhat.com] >> Sent: Monday, August 31, 2020 4:41 PM >> On 31/08/2020 07:50, Yangfei (Felix) wrote: >>> >> >> This looks like a direct copy of the sha3-cecore.S file.You'll need Linaro to >> contribute it. I don't imagine they'll have any problem with that: they are >> OCA signatories > >> Also, given that we've got the assembly source file, why not just copy that >> into OpenJDK? I can't see the point rewriting it into the HotSpot assembler. > > Actually, we referenced the existing intrinsics implementation and > took a similar way. It looks strange to have one intrinsic that goes > differently. And we won't be able to emit this code on demand if we > go that different way. Some cpu does not support these special sha3 > instructions and thus does need this code at all. I think that's > one advantage of using a stub. OK. But you'll still need Linaro to contribute it to OpenJDK. We could ask Stuart to help with that. -- 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 eric.c.liu at arm.com Tue Sep 1 08:01:22 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Tue, 1 Sep 2020 08:01:22 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: Hi all, Please review this simple change to fix some compile warnings. The newer gcc (gcc-8 or higher) would warn for calls to bounded string manipulation functions such as 'strncpy' that may either truncate the copied string or leave the destination unchanged. This patch fixed stringop-truncation warnings reported by gcc, some of them only appear when compiled with "--enable-asan". [TESTS] Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. No new failure found. http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8252407 Thanks, Eric From daniel.fuchs at oracle.com Tue Sep 1 09:18:26 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Sep 2020 10:18:26 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: <3cab30a7-0b1e-15ef-9237-4083fe271a4c@oracle.com> Hi Eric, The changes to NetworkInterface.c look good to me. best regards, -- daniel On 01/09/2020 09:01, Eric Liu wrote: > Hi all, > > Please review this simple change to fix some compile warnings. > > The newer gcc (gcc-8 or higher) would warn for calls to bounded string > manipulation functions such as 'strncpy' that may either truncate the > copied string or leave the destination unchanged. > > This patch fixed stringop-truncation warnings reported by gcc, some of > them only appear when compiled with "--enable-asan". > > [TESTS] > Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. > No new failure found. > > http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8252407 > > Thanks, > Eric > From kim.barrett at oracle.com Tue Sep 1 09:46:26 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Sep 2020 05:46:26 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> > On Sep 1, 2020, at 4:01 AM, Eric Liu wrote: > > Hi all, > > Please review this simple change to fix some compile warnings. > > The newer gcc (gcc-8 or higher) would warn for calls to bounded string > manipulation functions such as 'strncpy' that may either truncate the > copied string or leave the destination unchanged. > > This patch fixed stringop-truncation warnings reported by gcc, some of > them only appear when compiled with "--enable-asan". > > [TESTS] > Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. > No new failure found. > > http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8252407 > > Thanks, > Eric I really hate -Wstringop-truncation. It's been a constant source of churn for us ever since it appeared. The changes being made to getIndex and getFlags (NetworkInterface.c) are modifying lines that were changed very recently to deal with such warnings from gcc10. I'm worried that these new changes will re-trigger warnings from gcc10 (though this change isn't a revert; the gcc10 warning was justifiable). I think it should be okay, but there?s some risk here. Changes look good, subject to that caveat. I think these changes conform better to the documented description of the warning than did the recent NetworkInterface.c change mentioned above, so I?m hopeful that we?re not in a warning cycle here. But it would be good to have someone test these changes against gcc10.x. From kim.barrett at oracle.com Tue Sep 1 09:53:28 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Sep 2020 05:53:28 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <444A171B-076F-402C-A601-2C66203A1DE0@oracle.com> > On Sep 1, 2020, at 5:46 AM, Kim Barrett wrote: > >> On Sep 1, 2020, at 4:01 AM, Eric Liu wrote: >> >> Hi all, >> >> Please review this simple change to fix some compile warnings. >> >> The newer gcc (gcc-8 or higher) would warn for calls to bounded string >> manipulation functions such as 'strncpy' that may either truncate the >> copied string or leave the destination unchanged. >> >> This patch fixed stringop-truncation warnings reported by gcc, some of >> them only appear when compiled with "--enable-asan". >> >> [TESTS] >> Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. >> No new failure found. >> >> http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8252407 >> >> Thanks, >> Eric > > I really hate -Wstringop-truncation. It's been a constant source of churn > for us ever since it appeared. The changes being made to getIndex and > getFlags (NetworkInterface.c) are modifying lines that were changed very > recently to deal with such warnings from gcc10. I'm worried that these new > changes will re-trigger warnings from gcc10 (though this change isn't a > revert; the gcc10 warning was justifiable). I think it should be okay, but > there?s some risk here. > > Changes look good, subject to that caveat. Apparently I forgot about the discussion of the casted enum, so belay that. > I think these changes conform > better to the documented description of the warning than did the recent > NetworkInterface.c change mentioned above, so I?m hopeful that we?re not > in a warning cycle here. But it would be good to have someone test these > changes against gcc10.x. From felix.yang at huawei.com Tue Sep 1 10:53:12 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 1 Sep 2020 10:53:12 +0000 Subject: [aarch64-port-dev ] RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: <1729f1b1-056d-76c9-c820-d38bd6c1235d@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Tuesday, September 1, 2020 3:52 PM > To: Yangfei (Felix) ; hotspot-compiler- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net; Stuart Monteith > > Subject: Re: [aarch64-port-dev ] RFR: 8252204: AArch64: Implement SHA3 > accelerator/intrinsic > > On 31/08/2020 10:46, Yangfei (Felix) wrote: > > > >> -----Original Message----- > >> From: Andrew Haley [mailto:aph at redhat.com] > >> Sent: Monday, August 31, 2020 4:41 PM On 31/08/2020 07:50, Yangfei > >> (Felix) wrote: > >>> > >> > >> This looks like a direct copy of the sha3-cecore.S file.You'll need > >> Linaro to contribute it. I don't imagine they'll have any problem > >> with that: they are OCA signatories > > > >> Also, given that we've got the assembly source file, why not just > >> copy that into OpenJDK? I can't see the point rewriting it into the HotSpot > assembler. > > > > Actually, we referenced the existing intrinsics implementation and > > took a similar way. It looks strange to have one intrinsic that goes > > differently. And we won't be able to emit this code on demand if we > > go that different way. Some cpu does not support these special sha3 > > instructions and thus does need this code at all. I think that's one > > advantage of using a stub. > > OK. But you'll still need Linaro to contribute it to OpenJDK. We could ask > Stuart to help with that. Sure, I am happy if the original author of the assembly code or someone else from Linaro could help here. I wasn't aware there was such an requirement here given that assembly code is licensed under GPL. Should we separate the patch into two parts: changes for the shared code part and the aarch64 port-specific changes? Thanks, Felix 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 daniel.fuchs at oracle.com Tue Sep 1 11:59:17 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Sep 2020 12:59:17 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: Hi Eric, Kim, On 01/09/2020 10:46, Kim Barrett wrote: > he changes being made to getIndex and > getFlags (NetworkInterface.c) are modifying lines that were changed very > recently to deal with such warnings from gcc10. I'm worried that these new > changes will re-trigger warnings from gcc10 (though this change isn't a > revert; the gcc10 warning was justifiable). I think it should be okay, but > there?s some risk here. Thanks for reminding me of these changes. Indeed, the changes proposed to NetworkInteface.c - though not incorrect - may well re-trigger this gcc10 warning [1]. So now I don't think this should go through unless it's verified that it doesn't cause further issues down the road. [1] https://bugs.openjdk.java.net/browse/JDK-8250863 best regards, -- daniel 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 evan.whelan at oracle.com Tue Sep 1 13:14:21 2020 From: evan.whelan at oracle.com (Evan Whelan) Date: Tue, 1 Sep 2020 06:14:21 -0700 (PDT) Subject: RFR: JDK-8248772: Extra comma in documentation of Thread#interrupt() Message-ID: <19824149-b926-4cf9-828e-f65aed5319d4@default> Hi all, This RFR is for a small change to fix a grammatical error in Thread#interrupt() docs. JBS Link: https://bugs.openjdk.java.net/browse/JDK-8248772 Patch seen below. --- old/open/src/java.base/share/classes/java/lang/Thread.java 2020-09-01 13:00:37.913711118 +0000 +++ new/open/src/java.base/share/classes/java/lang/Thread.java 2020-09-01 13:00:37.653697905 +0000 @@ -952,7 +952,7 @@ * Object#wait() wait()}, {@link Object#wait(long) wait(long)}, or {@link * Object#wait(long, int) wait(long, int)} methods of the {@link Object} * class, or of the {@link #join()}, {@link #join(long)}, {@link - * #join(long, int)}, {@link #sleep(long)}, or {@link #sleep(long, int)}, + * #join(long, int)}, {@link #sleep(long)}, or {@link #sleep(long, int)} * methods of this class, then its interrupt status will be cleared and it * will receive an {@link InterruptedException}. * Thanks in advance, Evan Whelan 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 Roger.Riggs at oracle.com Tue Sep 1 13:30:44 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 1 Sep 2020 09:30:44 -0400 Subject: RFR: JDK-8248772: Extra comma in documentation of Thread#interrupt() In-Reply-To: <19824149-b926-4cf9-828e-f65aed5319d4@default> References: <19824149-b926-4cf9-828e-f65aed5319d4@default> Message-ID: <589fc2f3-4d15-a077-94d6-eea478198b60@oracle.com> Hi Evan, Looks fine. Thanks, Roger On 9/1/20 9:14 AM, Evan Whelan wrote: > Hi all, > > > > This RFR is for a small change to fix a grammatical error in Thread#interrupt() docs. > > > > JBS Link: https://bugs.openjdk.java.net/browse/JDK-8248772 > > Patch seen below. > > > > --- old/open/src/java.base/share/classes/java/lang/Thread.java 2020-09-01 13:00:37.913711118 +0000 > > +++ new/open/src/java.base/share/classes/java/lang/Thread.java 2020-09-01 13:00:37.653697905 +0000 > > @@ -952,7 +952,7 @@ > > * Object#wait() wait()}, {@link Object#wait(long) wait(long)}, or {@link > > * Object#wait(long, int) wait(long, int)} methods of the {@link Object} > > * class, or of the {@link #join()}, {@link #join(long)}, {@link > > - * #join(long, int)}, {@link #sleep(long)}, or {@link #sleep(long, int)}, > > + * #join(long, int)}, {@link #sleep(long)}, or {@link #sleep(long, int)} > > * methods of this class, then its interrupt status will be cleared and it > > * will receive an {@link InterruptedException}. > > * > > Thanks in advance, > > Evan Whelan From eric.c.liu at arm.com Tue Sep 1 13:59:32 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Tue, 1 Sep 2020 13:59:32 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com>, Message-ID: Hi Daniel, Kim, Thanks for your review. > Kim Barrett on Tue Sep 1 09:46:26 UTC 2020 > > Changes look good, subject to that caveat. I think these changes conform > better to the documented description of the warning than did the recent > NetworkInterface.c change mentioned above, so I?m hopeful that we?re not > in a warning cycle here. But it would be good to have someone test these > changes against gcc10.x. I just tested this patch by GCC (10.1.0) and it would really re-trigger those warnings :( I have not noticed the history before, but it's really hard to imagine that GCC would have different behaviors. >Daniel Fuchs on Tue Sep 1 11:59:17 UTC 2020 > > Thanks for reminding me of these changes. > Indeed, the changes proposed to NetworkInteface.c - though > not incorrect - may well re-trigger this gcc10 warning [1]. > So now I don't think this should go through unless it's verified > that it doesn't cause further issues down the road. Do you think it's a good idea to suppress those warnings by pragma? As we already know the code are actually correct, and that would make GCC happy both for 9 and 10. Thanks, Eric From mik3hall at gmail.com Tue Sep 1 14:23:26 2020 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 1 Sep 2020 09:23:26 -0500 Subject: jpackage: support for environment variables in --java-options In-Reply-To: References: Message-ID: > On Sep 1, 2020, at 2:07 AM, Serban Iordache wrote: > > Not sure if it was clear from my previous messages, but what I am asking for is that the environment variables are expanded with the values they have on the user's machine (not on the machine where jpackage has been executed). It might be better at this point for the developers to respond. However, I believe on probably all platforms these options are included in a .cfg file that is bundled with the application. It is set at build time and not in anyway dynamic at runtime. Unless maybe you had some pre-launch process that modified that .cfg file? On OS X I believe true application environment variables can be set in the Info.plist file, LSEnvironment entries if I remember correctly. A fork of the javapackager tool previously used in association with JavaFX was recently.mentioned on that list (JavaFX). I saw it included support for the PATH environment variable. On OS X using LSEnvironment as mentioned. I didn?t see this on the jpackage ?help and wondered if any such support was currently included in jpackage. It is a valid point I was overlooking that some of this might be user dependent and changes to PATH or other environment variables might not be valid for all users unless care was taken. Again, difficult to take care with everything set at build time. From aph at redhat.com Tue Sep 1 14:44:07 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 1 Sep 2020 15:44:07 +0100 Subject: [aarch64-port-dev ] RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: <1729f1b1-056d-76c9-c820-d38bd6c1235d@redhat.com> Message-ID: <95965aeb-9d97-3b27-e684-967b6155eb34@redhat.com> On 01/09/2020 11:53, Yangfei (Felix) wrote: > Sure, I am happy if the original author of the assembly code or someone else from Linaro could help here. > I wasn't aware there was such an requirement here given that assembly code is licensed under GPL. There sure is. All code must be contributed by its owner and put on the cr.openjdk site. Especially GPL code. > Should we separate the patch into two parts: changes for the shared code part and the aarch64 port-specific changes? I think not. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mik3hall at gmail.com Tue Sep 1 15:05:09 2020 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 1 Sep 2020 10:05:09 -0500 Subject: jpackage: support for environment variables in --java-options In-Reply-To: References: Message-ID: <05DE6736-C407-4CC4-A104-34C1D3023CE8@gmail.com> > On Sep 1, 2020, at 9:23 AM, Michael Hall wrote: > > > >> On Sep 1, 2020, at 2:07 AM, Serban Iordache wrote: >> >> Not sure if it was clear from my previous messages, but what I am asking for is that the environment variables are expanded with the values they have on the user's machine (not on the machine where jpackage has been executed). > > It might be better at this point for the developers to respond. > > However, I believe on probably all platforms these options are included in a .cfg file that is bundled with the application. It is set at build time and not in anyway dynamic at runtime. Unless maybe you had some pre-launch process that modified that .cfg file? > > On OS X I believe true application environment variables can be set in the Info.plist file, LSEnvironment entries if I remember correctly. A fork of the javapackager tool previously used in association with JavaFX was recently.mentioned on that list (JavaFX). I saw it included support for the PATH environment variable. On OS X using LSEnvironment as mentioned. I didn?t see this on the jpackage ?help and wondered if any such support was currently included in jpackage. > > It is a valid point I was overlooking that some of this might be user dependent and changes to PATH or other environment variables might not be valid for all users unless care was taken. Again, difficult to take care with everything set at build time. Of course there is the code that reads the .cfg file. Thinking about it that could possibly be modified to resolve some dynamic variable type settings as it reads it. From andy.herrick at oracle.com Tue Sep 1 15:30:46 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 1 Sep 2020 11:30:46 -0400 Subject: jpackage: support for environment variables in --java-options In-Reply-To: References: Message-ID: I have been following this discussion , and feel it is worth pursuing. Currently , the values of --arguments and --java-options are pre-processed at launch time by expanding the values of $APPDIR, $ROOTDIR, and $BINDIR to values determined by the native launchers. If we can do so without breaking existing functionality we should also expand? environment variables to their values at launch time. example:? "--java-options \$USER_JAVA_OPTIONS", "--java-options -Dfoo=\$USER_BAR_VALUE",? "--arguments \$USER_MYAPP_ARGS" Developer would have to make sure that the resulting java options or app arguments make sense both with and without the corresponding environment variable set.? jpackage could make sure that an empty option or argument did not cause a problem (as in first and third example above when there is no corresponding env setting). /Andy On 9/1/2020 10:23 AM, Michael Hall wrote: > >> On Sep 1, 2020, at 2:07 AM, Serban Iordache wrote: >> >> Not sure if it was clear from my previous messages, but what I am asking for is that the environment variables are expanded with the values they have on the user's machine (not on the machine where jpackage has been executed). > It might be better at this point for the developers to respond. > > However, I believe on probably all platforms these options are included in a .cfg file that is bundled with the application. It is set at build time and not in anyway dynamic at runtime. Unless maybe you had some pre-launch process that modified that .cfg file? > > On OS X I believe true application environment variables can be set in the Info.plist file, LSEnvironment entries if I remember correctly. A fork of the javapackager tool previously used in association with JavaFX was recently.mentioned on that list (JavaFX). I saw it included support for the PATH environment variable. On OS X using LSEnvironment as mentioned. I didn?t see this on the jpackage ?help and wondered if any such support was currently included in jpackage. > > It is a valid point I was overlooking that some of this might be user dependent and changes to PATH or other environment variables might not be valid for all users unless care was taken. Again, difficult to take care with everything set at build time. > > > > > From mik3hall at gmail.com Tue Sep 1 15:54:16 2020 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 1 Sep 2020 10:54:16 -0500 Subject: jpackage: support for environment variables in --java-options In-Reply-To: References: Message-ID: > On Sep 1, 2020, at 10:30 AM, Andy Herrick wrote: > > I have been following this discussion , and feel it is worth pursuing. > > Currently , the values of --arguments and --java-options are pre-processed at launch time by expanding the values of $APPDIR, $ROOTDIR, and $BINDIR to values determined by the native launchers. > > If we can do so without breaking existing functionality we should also expand environment variables to their values at launch time. > > example: "--java-options \$USER_JAVA_OPTIONS", "--java-options -Dfoo=\$USER_BAR_VALUE", "--arguments \$USER_MYAPP_ARGS" > > Developer would have to make sure that the resulting java options or app arguments make sense both with and without the corresponding environment variable set. jpackage could make sure that an empty option or argument did not cause a problem (as in first and third example above when there is no corresponding env setting). Actually I think about Serban?s original idea. Which seems would be workable in a lot of cases. Unless you actually need it to be an environment variable. From vipinsharma85 at gmail.com Tue Sep 1 16:12:41 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Tue, 1 Sep 2020 21:42:41 +0530 Subject: RFR 8252538: Replace @exception with @throws java.rmi package Message-ID: Hi, Please review and sponsor the fix for replacing @exception with @throws in java.rmi package. Issue: https://bugs.openjdk.java.net/browse/JDK-8252538 Webrev: https://cr.openjdk.java.net/~vsharma/8252538/webrev.01/ Regards, Vipin From sean.coffey at oracle.com Tue Sep 1 16:25:51 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 1 Sep 2020 17:25:51 +0100 Subject: RFR: 8249694 - [TestBug] java/lang/StringBuffer/HugeCapacity.java and j/l/StringBuilder/HugeCapacity.java tests shouldn't be @ignore-d In-Reply-To: References: Message-ID: <5a0ea05b-24b7-d0f7-600b-8724db3a15a0@oracle.com> Wouldn't you require the sun.arch.data.model == "64" jtreg config in these tests also ? regards, Sean. On 28/08/2020 19:13, Fernando Guallini wrote: > > > > > > > > Hi, > > May I please get reviews and a sponsor for this trivial change: > > webrev: http://cr.openjdk.java.net/~fguallini/8249694/webrev.00/ > Testbug: https://bugs.openjdk.java.net/browse/JDK-8249694 > > Tests do not need to have ?@ignore' because with @requires os.maxMemory is enough to ensure they will not be executed if memory requirements are not satisfied. They run in Mach5 with no issues. > > Thanks > > -Fernando From ian.graves at oracle.com Tue Sep 1 16:52:25 2020 From: ian.graves at oracle.com (Ian Graves) Date: Tue, 1 Sep 2020 11:52:25 -0500 Subject: [RFR] Docfix for Unsafe RE Fence Methods (remake from [PATCH]) Message-ID: <07CAF7E8-73E5-43DB-8334-0091E55F60F8@oracle.com> All, Per an earlier discussion submitted with a patch but without a JBS entry (my fault!). This is an RFR to update the docs in Unsafe for some of the fence methods to better reflect the current state of affairs in the file. Updating the verbiage to make it less opinionated per some previous comments (thanks, Hans!). JBS Link: https://bugs.openjdk.java.net/browse/JDK-8252529 Patch follows my signature. Thanks! Ian diff -r 3e9d813ff918 src/java.base/share/classes/jdk/internal/misc/Unsafe.java --- a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java Thu Aug 27 20:20:39 2020 +0200 +++ b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java Tue Sep 01 11:44:42 2020 -0500 @@ -3412,9 +3412,8 @@ * Corresponds to C11 atomic_thread_fence(memory_order_acquire) * (an "acquire fence"). * - * A pure LoadLoad fence is not provided, since the addition of LoadStore - * is almost always desired, and most current hardware instructions that - * provide a LoadLoad barrier also provide a LoadStore barrier for free. + * Provides a LoadLoad barrier followed by a LoadStore barrier. + * * @since 1.8 */ @HotSpotIntrinsicCandidate @@ -3427,9 +3426,9 @@ * Corresponds to C11 atomic_thread_fence(memory_order_release) * (a "release fence"). * - * A pure StoreStore fence is not provided, since the addition of LoadStore - * is almost always desired, and most current hardware instructions that - * provide a StoreStore barrier also provide a LoadStore barrier for free. + * Provides a StoreStore barrier followed by a LoadStore barrier. + * + * * @since 1.8 */ @HotSpotIntrinsicCandidate @@ -3450,6 +3449,10 @@ /** * Ensures that loads before the fence will not be reordered with * loads after the fence. + * + * This method is operationally equivalent to {@link #loadFence()}. + * + * @since 9 */ public final void loadLoadFence() { loadFence(); @@ -3458,6 +3461,10 @@ /** * Ensures that stores before the fence will not be reordered with * stores after the fence. + * + * This method is operationally equivalent to {@link #storeFence()}. + * + * @since 9 */ public final void storeStoreFence() { storeFence(); From Roger.Riggs at oracle.com Tue Sep 1 17:12:03 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 1 Sep 2020 13:12:03 -0400 Subject: RFR 8252538: Replace @exception with @throws java.rmi package In-Reply-To: References: Message-ID: <3e68fe1f-be94-8549-bc89-eb148ac3864c@oracle.com> Hi Vipin, Looks fine. Though I would also correct the indentation and join source lines in a few cases. MasrshalledObject.java.? Continuation lines should be indented. Lines 110 and 164, 166. Naming.java: Join line 110, 137, 162, 191: "appropriately... formatted URL" Thanks, Roger > Hi, > > Please review and sponsor the fix for replacing @exception with @throws in > java.rmi package. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8252538 > Webrev: https://cr.openjdk.java.net/~vsharma/8252538/webrev.01/ > > > Regards, > Vipin From paul.sandoz at oracle.com Tue Sep 1 18:13:11 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Sep 2020 11:13:11 -0700 Subject: [RFR] Docfix for Unsafe RE Fence Methods (remake from [PATCH]) In-Reply-To: <07CAF7E8-73E5-43DB-8334-0091E55F60F8@oracle.com> References: <07CAF7E8-73E5-43DB-8334-0091E55F60F8@oracle.com> Message-ID: <69A81071-780E-40BF-9655-52445E94ABD4@oracle.com> If memory serves me correctly we added these methods for completeness when doing VarHandles, but we deferred any intrinsic work (do it when really needed). This looks good to me. Minor tweak. I would recommend using an @implNote to be clear this not permanent behavior and could change e.g.: * @implNote * This implementation is operationally equivalent to {@link #loadFence()} No need for another review, just send me the patch. I can sponsor it for you. Paul. > On Sep 1, 2020, at 9:52 AM, Ian Graves wrote: > > All, > > Per an earlier discussion submitted with a patch but without a JBS entry (my fault!). > > This is an RFR to update the docs in Unsafe for some of the fence methods to better reflect the current state of affairs in the file. Updating the verbiage to make it less opinionated per some previous comments (thanks, Hans!). > > JBS Link: https://bugs.openjdk.java.net/browse/JDK-8252529 > > Patch follows my signature. > > Thanks! > > Ian > > > diff -r 3e9d813ff918 src/java.base/share/classes/jdk/internal/misc/Unsafe.java > --- a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java Thu Aug 27 20:20:39 2020 +0200 > +++ b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java Tue Sep 01 11:44:42 2020 -0500 > @@ -3412,9 +3412,8 @@ > * Corresponds to C11 atomic_thread_fence(memory_order_acquire) > * (an "acquire fence"). > * > - * A pure LoadLoad fence is not provided, since the addition of LoadStore > - * is almost always desired, and most current hardware instructions that > - * provide a LoadLoad barrier also provide a LoadStore barrier for free. > + * Provides a LoadLoad barrier followed by a LoadStore barrier. > + * > * @since 1.8 > */ > @HotSpotIntrinsicCandidate > @@ -3427,9 +3426,9 @@ > * Corresponds to C11 atomic_thread_fence(memory_order_release) > * (a "release fence"). > * > - * A pure StoreStore fence is not provided, since the addition of LoadStore > - * is almost always desired, and most current hardware instructions that > - * provide a StoreStore barrier also provide a LoadStore barrier for free. > + * Provides a StoreStore barrier followed by a LoadStore barrier. > + * > + * > * @since 1.8 > */ > @HotSpotIntrinsicCandidate > @@ -3450,6 +3449,10 @@ > /** > * Ensures that loads before the fence will not be reordered with > * loads after the fence. > + * > + * This method is operationally equivalent to {@link #loadFence()}. > + * > + * @since 9 > */ > public final void loadLoadFence() { > loadFence(); > @@ -3458,6 +3461,10 @@ > /** > * Ensures that stores before the fence will not be reordered with > * stores after the fence. > + * > + * This method is operationally equivalent to {@link #storeFence()}. > + * > + * @since 9 > */ > public final void storeStoreFence() { > storeFence(); From andy.herrick at oracle.com Tue Sep 1 18:18:41 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 1 Sep 2020 14:18:41 -0400 Subject: jpackage: support for environment variables in --java-options In-Reply-To: References: Message-ID: <5ccb9820-3349-352d-6bcf-062ac494b12f@oracle.com> On 9/1/2020 11:54 AM, Michael Hall wrote: > >> On Sep 1, 2020, at 10:30 AM, Andy Herrick wrote: >> >> I have been following this discussion , and feel it is worth pursuing. >> >> Currently , the values of --arguments and --java-options are pre-processed at launch time by expanding the values of $APPDIR, $ROOTDIR, and $BINDIR to values determined by the native launchers. >> >> If we can do so without breaking existing functionality we should also expand environment variables to their values at launch time. >> >> example: "--java-options \$USER_JAVA_OPTIONS", "--java-options -Dfoo=\$USER_BAR_VALUE", "--arguments \$USER_MYAPP_ARGS" >> >> Developer would have to make sure that the resulting java options or app arguments make sense both with and without the corresponding environment variable set. jpackage could make sure that an empty option or argument did not cause a problem (as in first and third example above when there is no corresponding env setting). > Actually I think about Serban?s original idea. Which seems would be workable in a lot of cases. Unless you actually need it to be an environment variable. I think Serban's original request was just this, to allow arbitrary environment variables: > Is there a way to pass values from environment variables when using > --java-options? > > It would be nice to be able to write something like this: > --java-options "-DmyAppData=$HOME/.myData" > > (Instead of using the $ sign, another notation may be more appropriate, in > order to not conflict with macros such as $APPDIR or $ROOTDIR.) Although I don't think there is a problem conflicting with the existing macros for $ROOTDIR, $APPDIR, or $BINDIR, we may need something more exclusive that "$XXXX" since dollar sign may be a legitimate character in an existing argument or vm option ("-DPRICE=$10.50") or ("-DCURRENCY_TAG=$") anyway, wouldn't this go a long way to alleviating the concerns of JDK-8250950 ? /Andy From huizhe.wang at oracle.com Tue Sep 1 21:12:47 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 1 Sep 2020 14:12:47 -0700 Subject: RFR [16/java.xml] 8252354 : Properties :: storeToXML method does not throw ClassCastException when supplied non strings. Message-ID: Please review a fix to report CCE when keys or values are not Strings as specified. JBS: https://bugs.openjdk.java.net/browse/JDK-8252354 webrev: http://cr.openjdk.java.net/~joehw/jdk16/8252354/webrev/ Thanks, Joe From mik3hall at gmail.com Tue Sep 1 21:22:00 2020 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 1 Sep 2020 16:22:00 -0500 Subject: jpackage: support for environment variables in --java-options In-Reply-To: <5ccb9820-3349-352d-6bcf-062ac494b12f@oracle.com> References: <5ccb9820-3349-352d-6bcf-062ac494b12f@oracle.com> Message-ID: > >> Is there a way to pass values from environment variables when using >> --java-options? >> >> It would be nice to be able to write something like this: >> --java-options "-DmyAppData=$HOME/.myData" >> >> (Instead of using the $ sign, another notation may be more appropriate, in >> order to not conflict with macros such as $APPDIR or $ROOTDIR.) > Although I don't think there is a problem conflicting with the existing macros for $ROOTDIR, $APPDIR, or $BINDIR, we may need something more exclusive that "$XXXX" since dollar sign may be a legitimate character in an existing argument or vm option ("-DPRICE=$10.50") or ("-DCURRENCY_TAG=$") > > anyway, wouldn't this go a long way to alleviating the concerns of JDK-8250950 ? > > If I follow the referenced issue, after a quick browse, it wants to satisfy the need for different user memory specifications. It proposes doing this with a standalone configuration file that could override the one jpackage uses. So could be used for more general overrides. You are now thinking environment variables could provide the override without the need for a second user/developer configuration file? I am not sure that works. Actually, I don?t think the environment variable settings would be very useful on OS X at all after considering this issue. On OS X applications get a default set of environment variables not dependent on user ones. Looking like this from an application of mine? exec env TMPDIR=/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/ __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0y for HOME=/Users/mjh SHELL=/bin/bash Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.sZlyFCZcWZ/Render SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.f11OdXASJN/Listeners PATH=/usr/bin:/bin:/usr/sbin:/sbin LOGNAME=mjh DISPLAY=/private/tmp/com.apple.launchd.rN2uW3mk7s/org.macosforge.xquartz:0 XPC_SERVICE_NAME=us.hall.FastRGraalHP.35068 USER=mjh XPC_FLAGS=0x0 My own settings from Terminal (.bash_profile) are more involved say for the PATH variable? env | grep PATH PATH=/Users/mjh/anaconda3/bin:/Users/mjh/anaconda3/condabin:/opt/ooRexx/bin:/usr/local/Cellar/watchman/4.9.0_3/bin:/Users/mjh/management/spark-2.4.3-bin-hadoop2.7/bin:/Users/mjh/management/apache-maven-3.6.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin ... So I?m not sure passing things to the application at launch time by environment variable would work? At least OS X. If as I think the issue indicated you wanted a cross-platform solution. 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 naoto.sato at oracle.com Tue Sep 1 22:11:43 2020 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 1 Sep 2020 15:11:43 -0700 Subject: RFR [16/java.xml] 8252354 : Properties :: storeToXML method does not throw ClassCastException when supplied non strings. In-Reply-To: References: Message-ID: <6daa644c-cc05-d320-6127-ca70f100818e@oracle.com> Hi Joe, Looks good to me. The test can declare @Test(expected = CCE.class) to eliminate storeToXML(), but I am ok with either way. Naoto On 9/1/20 2:12 PM, Joe Wang wrote: > Please review a fix to report CCE when keys or values are not Strings as > specified. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8252354 > > webrev: http://cr.openjdk.java.net/~joehw/jdk16/8252354/webrev/ > > Thanks, > Joe From Lance.Andersen at oracle.com Tue Sep 1 22:16:47 2020 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Tue, 1 Sep 2020 18:16:47 -0400 Subject: RFR [16/java.xml] 8252354 : Properties :: storeToXML method does not throw ClassCastException when supplied non strings. In-Reply-To: References: Message-ID: <2354BEA3-DC01-48C1-9C1A-FE425FA17494@oracle.com> Hi Joe Looks fine to me -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com > On Sep 1, 2020, at 5:12 PM, Joe Wang wrote: > > ?Please review a fix to report CCE when keys or values are not Strings as specified. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8252354 > > webrev: http://cr.openjdk.java.net/~joehw/jdk16/8252354/webrev/ > > Thanks, > Joe From swpalmer at gmail.com Tue Sep 1 22:45:44 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 1 Sep 2020 18:45:44 -0400 Subject: jpackage: support for environment variables in --java-options In-Reply-To: References: Message-ID: <02E3F745-BF17-4F4D-BD84-B840329B0AE6@gmail.com> > On Sep 1, 2020, at 5:22 PM, Michael Hall wrote: > > ? >> >> >>> Is there a way to pass values from environment variables when using >>> --java-options? >>> >>> It would be nice to be able to write something like this: >>> --java-options "-DmyAppData=$HOME/.myData" >>> >>> (Instead of using the $ sign, another notation may be more appropriate, in >>> order to not conflict with macros such as $APPDIR or $ROOTDIR.) >> Although I don't think there is a problem conflicting with the existing macros for $ROOTDIR, $APPDIR, or $BINDIR, we may need something more exclusive that "$XXXX" since dollar sign may be a legitimate character in an existing argument or vm option ("-DPRICE=$10.50") or ("-DCURRENCY_TAG=$") >> >> anyway, wouldn't this go a long way to alleviating the concerns of JDK-8250950 ? >> >> > If I follow the referenced issue, after a quick browse, it wants to satisfy the need for different user memory specifications. It proposes doing this with a standalone configuration file that could override the one jpackage uses. So could be used for more general overrides. > You are now thinking environment variables could provide the override without the need for a second user/developer configuration file? > I am not sure that works. Actually, I don?t think the environment variable settings would be very useful on OS X at all after considering this issue. > On OS X applications get a default set of environment variables not dependent on user ones. > Looking like this from an application of mine? > > exec env > TMPDIR=/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/ > __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0y for > HOME=/Users/mjh > SHELL=/bin/bash > Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.sZlyFCZcWZ/Render > SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.f11OdXASJN/Listeners > PATH=/usr/bin:/bin:/usr/sbin:/sbin > LOGNAME=mjh > DISPLAY=/private/tmp/com.apple.launchd.rN2uW3mk7s/org.macosforge.xquartz:0 > XPC_SERVICE_NAME=us.hall.FastRGraalHP.35068 > USER=mjh > XPC_FLAGS=0x0 > > My own settings from Terminal (.bash_profile) are more involved say for the PATH variable? > > env | grep PATH > PATH=/Users/mjh/anaconda3/bin:/Users/mjh/anaconda3/condabin:/opt/ooRexx/bin:/usr/local/Cellar/watchman/4.9.0_3/bin:/Users/mjh/management/spark-2.4.3-bin-hadoop2.7/bin:/Users/mjh/management/apache-maven-3.6.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin > ... > > So I?m not sure passing things to the application at launch time by environment variable would work? At least OS X. If as I think the issue indicated you wanted a cross-platform solution. On macOS you need to set the variables differently, but I think it can still work. The variables known to your shell are not the same as those known to LaunchServices. For those use the launchctl command to set them. Scott From mik3hall at gmail.com Tue Sep 1 23:08:09 2020 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 1 Sep 2020 18:08:09 -0500 Subject: jpackage: support for environment variables in --java-options In-Reply-To: <02E3F745-BF17-4F4D-BD84-B840329B0AE6@gmail.com> References: <02E3F745-BF17-4F4D-BD84-B840329B0AE6@gmail.com> Message-ID: <2DA6F91C-22E7-4BE7-9B48-0B26D9541FB0@gmail.com> > > On macOS you need to set the variables differently, but I think it can still work. The variables known to your shell are not the same as those known to LaunchServices. For those use the launchctl command to set them. > I?m not that familiar with launchctl. Is this something the application user is expected to do? What experience I have had with applications and environment variables involved adding the entries to Info.plist. Making the environment variables normally available to the application as environment variables. My question is if there is or will be any kind of OS X support for this in jpackage? LSEnvironment settings in the Info.plist file. e.g. the following was what was recently mentioned on the javafx list? https://github.com/fvarrui/JavaPackager envPath Defines PATH environment variable in GNU/Linux and Mac OS X startup scripts. Otherwise, this seems to be getting a little confusing, for me anyhow, as to what you?re trying to do and when. Are you trying to use environment variables at build time to replace variables that will be resolved in the config file. Which seemed to be what Serban was asking. Or did I misunderstand that and Serban actually wants settings that will be resolved at application launch? Or do you want to use them at application launch time as some kind of mechanism to override config file settings there like jdk memory settings? Which seems to what the jdk issue concerned. My question seems simpler. I will let others resolve other environment variable usage at build or launch time. I am interested in runtime. From magnus.ihse.bursie at oracle.com Wed Sep 2 06:39:47 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 Sep 2020 08:39:47 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> On 2020-09-01 11:46, Kim Barrett wrote: >> On Sep 1, 2020, at 4:01 AM, Eric Liu wrote: >> >> Hi all, >> >> Please review this simple change to fix some compile warnings. >> >> The newer gcc (gcc-8 or higher) would warn for calls to bounded string >> manipulation functions such as 'strncpy' that may either truncate the >> copied string or leave the destination unchanged. >> >> This patch fixed stringop-truncation warnings reported by gcc, some of >> them only appear when compiled with "--enable-asan". >> >> [TESTS] >> Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. >> No new failure found. >> >> http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8252407 >> >> Thanks, >> Eric > I really hate -Wstringop-truncation. It's been a constant source of churn > for us ever since it appeared. The changes being made to getIndex and > getFlags (NetworkInterface.c) are modifying lines that were changed very > recently to deal with such warnings from gcc10. I'm worried that these new > changes will re-trigger warnings from gcc10 (though this change isn't a > revert; the gcc10 warning was justifiable). I think it should be okay, but > there?s some risk here. Maybe we should have a common library for all native code where we supply our own string operation functions? It will then be much easier to make sure the implementation passes different compiler versions, and that we provide sane semantics (which isn't really the? case with the original C library functions; hence all this warning churning). There have been other problem areas before, where a common library (static or dynamic) would have helped. Perhaps it's time to go ahead and create one... /Magnus > > Changes look good, subject to that caveat. I think these changes conform > better to the documented description of the warning than did the recent > NetworkInterface.c change mentioned above, so I?m hopeful that we?re not > in a warning cycle here. But it would be good to have someone test these > changes against gcc10.x. > > From fweimer at redhat.com Wed Sep 2 07:19:52 2020 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 02 Sep 2020 09:19:52 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> (Magnus Ihse Bursie's message of "Wed, 2 Sep 2020 08:39:47 +0200") References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> Message-ID: <87tuwgodbb.fsf@oldenburg2.str.redhat.com> * Magnus Ihse Bursie: > Maybe we should have a common library for all native code where we > supply our own string operation functions? It will then be much easier > to make sure the implementation passes different compiler versions, > and that we provide sane semantics (which isn't really the? case with > the original C library functions; hence all this warning churning). When I looked at this (sorry that I never sent a patch), pretty much all uses of strncpy were actually bugs: The code should check the actual string length using strlen, report an error if it would be truncated, and then use memcpy with the length already computed, plus one. In other words, the strncpy warnings are correct, and there is only churn in the sense that GCC gets smarter at discovering bugs. At least one of the bugs was in theory user-visible: the network interface code would return data for an interface that does not actually exist on the system. Thanks, Florian From kim.barrett at oracle.com Wed Sep 2 07:50:38 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Sep 2020 03:50:38 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> Message-ID: > On Sep 2, 2020, at 2:39 AM, Magnus Ihse Bursie wrote: > > On 2020-09-01 11:46, Kim Barrett wrote: >> I really hate -Wstringop-truncation. It's been a constant source of churn >> for us ever since it appeared. The changes being made to getIndex and >> getFlags (NetworkInterface.c) are modifying lines that were changed very >> recently to deal with such warnings from gcc10. I'm worried that these new >> changes will re-trigger warnings from gcc10 (though this change isn't a >> revert; the gcc10 warning was justifiable). I think it should be okay, but >> there?s some risk here. > Maybe we should have a common library for all native code where we supply our own string operation functions? It will then be much easier to make sure the implementation passes different compiler versions, and that we provide sane semantics (which isn't really the case with the original C library functions; hence all this warning churning). For the recurring problems with strncpy, there?s already this: https://bugs.openjdk.java.net/browse/JDK-8232187 Nobody?s picked it up yet. From kim.barrett at oracle.com Wed Sep 2 07:56:06 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Sep 2020 03:56:06 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87tuwgodbb.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> Message-ID: <89A572A7-E2EE-4A26-A907-C5D59FDBDFCA@oracle.com> > On Sep 2, 2020, at 3:19 AM, Florian Weimer wrote: > > * Magnus Ihse Bursie: > >> Maybe we should have a common library for all native code where we >> supply our own string operation functions? It will then be much easier >> to make sure the implementation passes different compiler versions, >> and that we provide sane semantics (which isn't really the case with >> the original C library functions; hence all this warning churning). > > When I looked at this (sorry that I never sent a patch), pretty much all > uses of strncpy were actually bugs: The code should check the actual > string length using strlen, report an error if it would be truncated, > and then use memcpy with the length already computed, plus one. > > In other words, the strncpy warnings are correct, and there is only > churn in the sense that GCC gets smarter at discovering bugs. Having been involved in reviews of a lot of these warnings, I think that?s seriously overstating the cases where there have been actual bugs. There have been some actual bugs found, but there have been a lot of definite false positives. Particularly from -Wstringop-truncation. From daniel.fuchs at oracle.com Wed Sep 2 09:26:29 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Sep 2020 10:26:29 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87tuwgodbb.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> Message-ID: Hi, On 02/09/2020 08:19, Florian Weimer wrote: > At least one of the bugs was in theory user-visible: the network > interface code would return data for an interface that does not actually > exist on the system. WRT NetworkInterface.c, I might support using `strnlen` to check the length before hand, if that solves both cases (gcc8 and gcc10). I'm always a bit nervous of changing the behavior in this library as it's hard to verify that no regression is introduced. best regards, -- daniel 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 magnus.ihse.bursie at oracle.com Wed Sep 2 10:31:53 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 Sep 2020 12:31:53 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> Message-ID: On 2020-09-02 09:50, Kim Barrett wrote: >> On Sep 2, 2020, at 2:39 AM, Magnus Ihse Bursie wrote: >> >> On 2020-09-01 11:46, Kim Barrett wrote: >>> I really hate -Wstringop-truncation. It's been a constant source of churn >>> for us ever since it appeared. The changes being made to getIndex and >>> getFlags (NetworkInterface.c) are modifying lines that were changed very >>> recently to deal with such warnings from gcc10. I'm worried that these new >>> changes will re-trigger warnings from gcc10 (though this change isn't a >>> revert; the gcc10 warning was justifiable). I think it should be okay, but >>> there?s some risk here. >> Maybe we should have a common library for all native code where we supply our own string operation functions? It will then be much easier to make sure the implementation passes different compiler versions, and that we provide sane semantics (which isn't really the case with the original C library functions; hence all this warning churning). > For the recurring problems with strncpy, there?s already this: > https://bugs.openjdk.java.net/browse/JDK-8232187 > Nobody?s picked it up yet. Yes, but that's hotspot only. The other JDK libraries would not be able to use it. (And as I said, there are other, already existing functions, that ideally should be shared between hotspot and the rest of the libraries). /Magnus > From raffaello.giulietti at gmail.com Wed Sep 2 12:52:20 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 2 Sep 2020 14:52:20 +0200 Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) Message-ID: <623e9591-2caf-ecc4-0986-44cb90bc425f@gmail.com> Hi, here's a patch for [1], which is currently unassigned. Anybody willing to sponsor it? The fix is based on "Hacker's Delight" (2nd ed), section 9.3 and makes use of longs only, no BigInteger, no garbage to collect. It is faster and "greener" than the current code. Contrary to the dramatic plea in the subject, with this fix I think there's no pressing need for an intrinsic. The fix should be back-portable to 11 and 8, where the methods first appeared, but I only tried on a current changeset [2]. Passes tier1. If anybody needs the fix as attachment, just let me know. Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-8238669 [2] http://hg.openjdk.java.net/jdk/jdk/rev/2fc1acf9c894 # HG changeset patch # User lello # Date 1599044207 -7200 # Wed Sep 02 12:56:47 2020 +0200 # Node ID 7a844bedebbc753c5dee265fba8fe7ed30a79d31 # Parent 2fc1acf9c89458a1d05915963961d7c780cb6ad3 Patch to fix JDK-8238669 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) Reviewed-by: TBD Contributed-by: Raffaello Giulietti diff --git a/src/java.base/share/classes/java/lang/Long.java b/src/java.base/share/classes/java/lang/Long.java --- a/src/java.base/share/classes/java/lang/Long.java +++ b/src/java.base/share/classes/java/lang/Long.java @@ -1668,24 +1668,13 @@ * @since 1.8 */ public static long divideUnsigned(long dividend, long divisor) { - if (divisor < 0L) { // signed comparison - // Answer must be 0 or 1 depending on relative magnitude - // of dividend and divisor. - return (compareUnsigned(dividend, divisor)) < 0 ? 0L :1L; + // See Hacker's Delight (2nd ed), section 9.3 + if (divisor >= 0) { + final long q = (dividend >>> 1) / divisor << 1; + final long r = dividend - q * divisor; + return q + ((r | ~(r - divisor)) >>> Long.SIZE - 1); } - - if (dividend > 0) // Both inputs non-negative - return dividend/divisor; - else { - /* - * For simple code, leveraging BigInteger. Longer and faster - * code written directly in terms of operations on longs is - * possible; see "Hacker's Delight" for divide and remainder - * algorithms. - */ - return toUnsignedBigInteger(dividend). - divide(toUnsignedBigInteger(divisor)).longValue(); - } + return (dividend & ~(dividend - divisor)) >>> Long.SIZE - 1; } /** @@ -1701,15 +1690,13 @@ * @since 1.8 */ public static long remainderUnsigned(long dividend, long divisor) { - if (dividend > 0 && divisor > 0) { // signed comparisons - return dividend % divisor; - } else { - if (compareUnsigned(dividend, divisor) < 0) // Avoid explicit check for 0 divisor - return dividend; - else - return toUnsignedBigInteger(dividend). - remainder(toUnsignedBigInteger(divisor)).longValue(); + // See Hacker's Delight (2nd ed), section 9.3 + if (divisor >= 0) { + final long q = (dividend >>> 1) / divisor << 1; + final long r = dividend - q * divisor; + return r - (~(r - divisor) >> Long.SIZE - 1 & divisor); } + return dividend - ((dividend & ~(dividend - divisor)) >> Long.SIZE - 1 & divisor); } // Bit Twiddling From andy.herrick at oracle.com Wed Sep 2 14:04:09 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 2 Sep 2020 10:04:09 -0400 Subject: jpackage: support for environment variables in --java-options In-Reply-To: <2DA6F91C-22E7-4BE7-9B48-0B26D9541FB0@gmail.com> References: <02E3F745-BF17-4F4D-BD84-B840329B0AE6@gmail.com> <2DA6F91C-22E7-4BE7-9B48-0B26D9541FB0@gmail.com> Message-ID: <999e1fc7-39fa-475c-3c76-a4a7697aa36a@oracle.com> Yes - environment variables are not a good answer for this, not just mac, but even on windows the env variables at run time are different if launched from a shell (the env variables of that shell) vs. when run from a shortcut (the system-wide or user env variables set in Control Panel or Settings dialog). JEP-343 says jpackage should be "a tool for packaging self-contained Java applications.", so an app packaged with jpackage should run on a machine without requiring any other files to be installed .? That should not prohibit optional configuration from being discovered on a machine and used to tune the application or it's use of Java. Normally, any such discovery can be done by the application itself, except where it is the the java options that tune the java vm itself, and that is why we are considering mechanisms (such as expanding environment variables at runtime, or reading an installed configuration file of some kind) /Andy On 9/1/2020 7:08 PM, Michael Hall wrote: > > >> >> On macOS you need to set the variables differently, but I think it >> can still work. The variables known to your shell are not the same as >> those known to LaunchServices. For those use the launchctl command to >> set them. >> > > I?m not that familiar with launchctl. Is this something the > application user is expected to do? What experience I have had with > applications and environment variables involved adding the entries to > Info.plist. Making the environment variables normally available to the > application as environment variables. > > My question is if there is or will be any kind of OS X support for > this in jpackage? LSEnvironment settings in the Info.plist file. > > e.g. the following was what was recently mentioned on the javafx list? > https://github.com/fvarrui/JavaPackager > > envPath > > Defines PATH environment variable in GNU/Linux and Mac OS X startup > scripts. > > > Otherwise, this seems to be getting a little confusing, for me anyhow, > as to what you?re trying to do and when. Are you trying to use > environment variables at build time to replace variables that will be > resolved in the config file. Which seemed to be what Serban was > asking. Or did I misunderstand that and Serban actually wants settings > that will be resolved at application launch? > Or do you want to use them at application launch time as some kind of > mechanism to override config file settings there like jdk memory > settings? Which seems to what the jdk issue concerned. > > My question seems simpler. I will let others resolve other environment > variable usage at build or launch time. I am interested in runtime. > From brian.burkhalter at oracle.com Wed Sep 2 14:25:39 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 2 Sep 2020 07:25:39 -0700 Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) In-Reply-To: <623e9591-2caf-ecc4-0986-44cb90bc425f@gmail.com> References: <623e9591-2caf-ecc4-0986-44cb90bc425f@gmail.com> Message-ID: <2FD97380-F78B-4C15-A1FE-0415BA96C886@oracle.com> Hi Raffaello, I can take a look. Did you write any (JMH?) microbenchmarks? Thanks, Brian > On Sep 2, 2020, at 5:52 AM, Raffaello Giulietti wrote: > > here's a patch for [1], which is currently unassigned. Anybody willing to sponsor it? > > The fix is based on "Hacker's Delight" (2nd ed), section 9.3 and makes use of longs only, no BigInteger, no garbage to collect. It is faster and "greener" than the current code. > > Contrary to the dramatic plea in the subject, with this fix I think there's no pressing need for an intrinsic. > > The fix should be back-portable to 11 and 8, where the methods first appeared, but I only tried on a current changeset [2]. > > Passes tier1. > > If anybody needs the fix as attachment, just let me know. From raffaello.giulietti at gmail.com Wed Sep 2 14:37:11 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 2 Sep 2020 16:37:11 +0200 Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) In-Reply-To: <2FD97380-F78B-4C15-A1FE-0415BA96C886@oracle.com> References: <623e9591-2caf-ecc4-0986-44cb90bc425f@gmail.com> <2FD97380-F78B-4C15-A1FE-0415BA96C886@oracle.com> Message-ID: Hi Brian, thanks for taking a look. I didn't write JMH benchmarks. Greetings Raffaello On 2020-09-02 16:25, Brian Burkhalter wrote: > Hi?Raffaello, > > I can take a look. Did you write any (JMH?) microbenchmarks? > > Thanks, > > Brian > >> On Sep 2, 2020, at 5:52 AM, Raffaello Giulietti >> > >> wrote: >> >> here's a patch for [1], which is currently unassigned. Anybody willing >> to sponsor it? >> >> The fix is based on "Hacker's Delight" (2nd ed), section 9.3 and makes >> use of longs only, no BigInteger, no garbage to collect. It is faster >> and "greener" than the current code. >> >> Contrary to the dramatic plea in the subject, with this fix I think >> there's no pressing need for an intrinsic. >> >> The fix should be back-portable to 11 and 8, where the methods first >> appeared, but I only tried on a current changeset [2]. >> >> Passes tier1. >> >> If anybody needs the fix as attachment, just let me know. > From mik3hall at gmail.com Wed Sep 2 15:59:37 2020 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 2 Sep 2020 10:59:37 -0500 Subject: jpackage: support for environment variables in --java-options In-Reply-To: <999e1fc7-39fa-475c-3c76-a4a7697aa36a@oracle.com> References: <02E3F745-BF17-4F4D-BD84-B840329B0AE6@gmail.com> <2DA6F91C-22E7-4BE7-9B48-0B26D9541FB0@gmail.com> <999e1fc7-39fa-475c-3c76-a4a7697aa36a@oracle.com> Message-ID: <084B8AE1-1E40-4DF2-AD97-42104827F067@gmail.com> > On Sep 2, 2020, at 9:04 AM, Andy Herrick wrote: > > Yes - environment variables are not a good answer for this, not just mac, but even on windows the env variables at run time are different if launched from a shell (the env variables of that shell) vs. when run from a shortcut (the system-wide or user env variables set in Control Panel or Settings dialog). > > JEP-343 says jpackage should be "a tool for packaging self-contained Java applications.", so an app packaged with jpackage should run on a machine without requiring any other files to be installed . That should not prohibit optional configuration from being discovered on a machine and used to tune the application or it's use of Java. > > Normally, any such discovery can be done by the application itself, except where it is the the java options that tune the java vm itself, and that is why we are considering mechanisms (such as expanding environment variables at runtime, or reading an installed configuration file of some kind) > It?s difficult and was difficult with java applications on OS X from the start to have an application support anything like command line invoking with parameters. Maybe add standalone options for the command that update an existing application bundle? Of course then there would probably be signing and other issues. Again, for LSEnvironment on OS X I think it wouldn?t be terribly difficult to implement. You could handle it something like it appears file associations work. Although, I haven?t done anything with those yet. Then just modify the Info.plist. I have had code that does that in the past. XML right? In the past I have had need to add environment variables to my application to interface it with the R language. Also debugging AppleScript related at one point required environment variables. It was very much an OS X only java app at one point in time. Recently I had problems interfacing to Anaconda python that it seemed like being able to set the PATH variable might resolve. Although my own attempts to set the variables to get it to work failed. What did work was command line shell invoking the application. Like myApp.app/Contents/MacOS/myApp from Terminal. That was for someone else?s application. I decided just to set a alias for that in .bash_profile for my own use and not try to figure what exactly the Finder launched application needed to make it work. So these are some use cases where environment variables were involved. A feature to support them could occasionally be nice. From vipinsharma85 at gmail.com Wed Sep 2 16:18:04 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Wed, 2 Sep 2020 21:48:04 +0530 Subject: RFR 8252538: Replace @exception with @throws java.rmi package In-Reply-To: <3e68fe1f-be94-8549-bc89-eb148ac3864c@oracle.com> References: <3e68fe1f-be94-8549-bc89-eb148ac3864c@oracle.com> Message-ID: Hi Roger, On Tue, Sep 1, 2020 at 10:49 PM Roger Riggs wrote: > Hi Vipin, > > Looks fine. > > Though I would also correct the indentation and join source lines in a > few cases. > > MasrshalledObject.java. Continuation lines should be indented. Lines > 110 and 164, 166. > Fixed. > > Naming.java: Join line 110, 137, 162, 191: "appropriately... formatted URL" > Fixed lines 113, 140, and 164 as well, similar problems. > > Thanks, Roger > Updated webrev: https://cr.openjdk.java.net/~vsharma/8252538/webrev.02/ Regards, Vipin From serban.iordache at gmail.com Tue Sep 1 06:37:26 2020 From: serban.iordache at gmail.com (Serban Iordache) Date: Tue, 1 Sep 2020 08:37:26 +0200 Subject: jpackage: support for environment variables in --java-options In-Reply-To: References: Message-ID: Thanks, Michael! I maintain two Gradle plugins that help creating custom images and packages with jlink and jpackage (https://github.com/beryx/badass-jlink-plugin and https://github.com/beryx/badass-runtime-plugin). The request for supporting environment variables came from my users. They have actually other use cases than the one involving $HOME, which I used in my example. For some of these use cases, it's more difficult to find a solution that doesn't require environment variables. That's why I'm asking for a generic way of dealing with this issue. Supporting environment variables in --java-options may also be a solution for https://bugs.openjdk.java.net/browse/JDK-8250950 (allowing users to specify their own memory requirements), for example using: --java-options "-Xmx$MY_MAX_JAVA_HEAP". Am Mo., 31. Aug. 2020 um 22:14 Uhr schrieb Michael Hall : > > > > On Aug 31, 2020, at 3:07 PM, Michael Hall wrote: > > > > > > > >> On Aug 29, 2020, at 3:37 AM, Serban Iordache > wrote: > >> > >> Hi, > >> > >> Is there a way to pass values from environment variables when using > >> --java-options? > >> > >> It would be nice to be able to write something like this: > >> --java-options "-DmyAppData=$HOME/.myData? > > > > For this couldn?t you just pass the parameter without the path and then > add it later? > > > > -DmyAppData=/.myData > > > > final String HOME = System.getProperty(?user.home?); > > > System.setProperty(?myAppData?,HOME+System.getProperty(myAppData),?.myData?); > > For user data these days don?t many platforms have preferred places for > user data other than user home? > It has occurred to me it might be nice of java had an API that actually > automatically gave you the correct directory for a given platform to put > your data. Maybe different locations for different types of user data. > > From serban.iordache at gmail.com Tue Sep 1 07:07:22 2020 From: serban.iordache at gmail.com (Serban Iordache) Date: Tue, 1 Sep 2020 09:07:22 +0200 Subject: jpackage: support for environment variables in --java-options In-Reply-To: References: Message-ID: Not sure if it was clear from my previous messages, but what I am asking for is that the environment variables are expanded with the values they have on the user's machine (not on the machine where jpackage has been executed). Am Di., 1. Sept. 2020 um 08:37 Uhr schrieb Serban Iordache < serban.iordache at gmail.com>: > Thanks, Michael! > > I maintain two Gradle plugins that help creating custom images and > packages with jlink and jpackage ( > https://github.com/beryx/badass-jlink-plugin and > https://github.com/beryx/badass-runtime-plugin). The request for > supporting environment variables came from my users. They have actually > other use cases than the one involving $HOME, which I used in my example. > For some of these use cases, it's more difficult to find a solution that > doesn't require environment variables. That's why I'm asking for a generic > way of dealing with this issue. > > Supporting environment variables in --java-options may also be a solution > for https://bugs.openjdk.java.net/browse/JDK-8250950 (allowing users to > specify their own memory requirements), for example using: --java-options > "-Xmx$MY_MAX_JAVA_HEAP". > > Am Mo., 31. Aug. 2020 um 22:14 Uhr schrieb Michael Hall < > mik3hall at gmail.com>: > >> >> >> > On Aug 31, 2020, at 3:07 PM, Michael Hall wrote: >> > >> > >> > >> >> On Aug 29, 2020, at 3:37 AM, Serban Iordache < >> serban.iordache at gmail.com> wrote: >> >> >> >> Hi, >> >> >> >> Is there a way to pass values from environment variables when using >> >> --java-options? >> >> >> >> It would be nice to be able to write something like this: >> >> --java-options "-DmyAppData=$HOME/.myData? >> > >> > For this couldn?t you just pass the parameter without the path and then >> add it later? >> > >> > -DmyAppData=/.myData >> > >> > final String HOME = System.getProperty(?user.home?); >> > >> System.setProperty(?myAppData?,HOME+System.getProperty(myAppData),?.myData?); >> >> For user data these days don?t many platforms have preferred places for >> user data other than user home? >> It has occurred to me it might be nice of java had an API that actually >> automatically gave you the correct directory for a given platform to put >> your data. Maybe different locations for different types of user data. >> >> From swpalmer at gmail.com Wed Sep 2 17:14:02 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 2 Sep 2020 13:14:02 -0400 Subject: jpackage: support for environment variables in --java-options In-Reply-To: <084B8AE1-1E40-4DF2-AD97-42104827F067@gmail.com> References: <084B8AE1-1E40-4DF2-AD97-42104827F067@gmail.com> Message-ID: If your app need to use environment variables to configure something for runtime it is probably best to have your own stub launcher and launch a sub-process. It can be tricky to have a smooth user experience with that though. You would want to avoid an extra icon in the dock/start bar. You don?t want the other process to show up as ?java.exe?, etc. That?s the benefit of trying to solve this in the launcher created by jpackage. Scott > On Sep 2, 2020, at 11:59 AM, Michael Hall wrote: > > ? > >> On Sep 2, 2020, at 9:04 AM, Andy Herrick wrote: >> >> Yes - environment variables are not a good answer for this, not just mac, but even on windows the env variables at run time are different if launched from a shell (the env variables of that shell) vs. when run from a shortcut (the system-wide or user env variables set in Control Panel or Settings dialog). >> >> JEP-343 says jpackage should be "a tool for packaging self-contained Java applications.", so an app packaged with jpackage should run on a machine without requiring any other files to be installed . That should not prohibit optional configuration from being discovered on a machine and used to tune the application or it's use of Java. >> >> Normally, any such discovery can be done by the application itself, except where it is the the java options that tune the java vm itself, and that is why we are considering mechanisms (such as expanding environment variables at runtime, or reading an installed configuration file of some kind) >> > It?s difficult and was difficult with java applications on OS X from the start to have an application support anything like command line invoking with parameters. > > Maybe add standalone options for the command that update an existing application bundle? Of course then there would probably be signing and other issues. > > Again, for LSEnvironment on OS X I think it wouldn?t be terribly difficult to implement. You could handle it something like it appears file associations work. Although, I haven?t done anything with those yet. Then just modify the Info.plist. I have had code that does that in the past. XML right? > > In the past I have had need to add environment variables to my application to interface it with the R language. Also debugging AppleScript related at one point required environment variables. It was very much an OS X only java app at one point in time. > Recently I had problems interfacing to Anaconda python that it seemed like being able to set the PATH variable might resolve. Although my own attempts to set the variables to get it to work failed. What did work was command line shell invoking the application. Like myApp.app/Contents/MacOS/myApp from Terminal. That was for someone else?s application. > I decided just to set a alias for that in .bash_profile for my own use and not try to figure what exactly the Finder launched application needed to make it work. > So these are some use cases where environment variables were involved. A feature to support them could occasionally be nice. > > > > > > > From mik3hall at gmail.com Wed Sep 2 17:20:59 2020 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 2 Sep 2020 12:20:59 -0500 Subject: jpackage: support for environment variables in --java-options In-Reply-To: References: <084B8AE1-1E40-4DF2-AD97-42104827F067@gmail.com> Message-ID: > On Sep 2, 2020, at 12:14 PM, Scott Palmer wrote: > > If your app need to use environment variables to configure something for runtime it is probably best to have your own stub launcher and launch a sub-process. They need to be available at runtime for external native that expects them to be present. > > It can be tricky to have a smooth user experience with that though. You would want to avoid an extra icon in the dock/start bar. You don?t want the other process to show up as ?java.exe?, etc. That?s the benefit of trying to solve this in the launcher created by jpackage. > What I am suggesting would be handled by jpackage within the application bundle. It would modify the Info.plist to include the LSEnvironment entries. From joe.darcy at oracle.com Wed Sep 2 19:17:24 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 2 Sep 2020 12:17:24 -0700 Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) In-Reply-To: References: <623e9591-2caf-ecc4-0986-44cb90bc425f@gmail.com> <2FD97380-F78B-4C15-A1FE-0415BA96C886@oracle.com> Message-ID: <39c19044-e14f-5961-7746-a3872be95fd7@oracle.com> Hello, I also suggest taking a look at the existing regression tests in ??? test/jdk/java/lang/Long/Unsigned.java to see if more cases should be added with the new algorithm. Potentially, the existing algorithm could retire to serve as a reference in the regression tests. Thanks, -Joe On 9/2/2020 7:37 AM, Raffaello Giulietti wrote: > Hi Brian, > > thanks for taking a look. > > I didn't write JMH benchmarks. > > > Greetings > Raffaello > > > > On 2020-09-02 16:25, Brian Burkhalter wrote: >> Hi?Raffaello, >> >> I can take a look. Did you write any (JMH?) microbenchmarks? >> >> Thanks, >> >> Brian >> >>> On Sep 2, 2020, at 5:52 AM, Raffaello Giulietti >>> >> > wrote: >>> >>> here's a patch for [1], which is currently unassigned. Anybody >>> willing to sponsor it? >>> >>> The fix is based on "Hacker's Delight" (2nd ed), section 9.3 and >>> makes use of longs only, no BigInteger, no garbage to collect. It is >>> faster and "greener" than the current code. >>> >>> Contrary to the dramatic plea in the subject, with this fix I think >>> there's no pressing need for an intrinsic. >>> >>> The fix should be back-portable to 11 and 8, where the methods first >>> appeared, but I only tried on a current changeset [2]. >>> >>> Passes tier1. >>> >>> If anybody needs the fix as attachment, just let me know. >> > From Roger.Riggs at oracle.com Wed Sep 2 20:26:07 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 2 Sep 2020 16:26:07 -0400 Subject: RFR 8251989: Hex formatting and parsing In-Reply-To: <8985ea26-3847-c9b2-c52e-20f9e362f7a4@gmail.com> References: <6b9289fb-937d-70ca-55de-fa35f85797cb@gmail.com> <9952e7ed-4c88-c7b9-9c37-38ce8e070eda@oracle.com> <8985ea26-3847-c9b2-c52e-20f9e362f7a4@gmail.com> Message-ID: <180eca84-19fe-2dc4-9e57-1d05328e1c7b@oracle.com> Please review the updated API in the Javadoc. http://cr.openjdk.java.net/~rriggs/hex-formatter/java.base/java/util/Hex.html A few offline contacts encouaged me to explore expanding the support for formatting and parsing of primitive types. Adding formatting toHex methods and [arsing fromHex methods makes the API easier to use. For example, there are a number of protocols that need to escape char values as hex. For symmetry across the primitive types, byte, char, short, int, and long methods are added. The handling of invalid digits was changed to consistently throw IllegalArgumentException; it is unlikely that encoding and decoding run into invalid characters and the previous technique requiring the caller to check the value for negative numbers is error prone. There is some danger of proliferating methods yet, so not all combinations are included.? Feedback welcome. With the API still shifting, the implemention is not ready to review. Thanks, Roger From Roger.Riggs at oracle.com Wed Sep 2 20:47:46 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 2 Sep 2020 16:47:46 -0400 Subject: RFR 8252538: Replace @exception with @throws java.rmi package In-Reply-To: References: <3e68fe1f-be94-8549-bc89-eb148ac3864c@oracle.com> Message-ID: <40f610f6-d16d-f7d0-0ff7-416b64de6dfe@oracle.com> Hi Vipin, Looks fine. I see you filed separate tasks for the other packages in java.rmi. [1] That's unnecessarily fine grained. It would be more efficient to do them all in one code review, saving your time and reviewers time. Also, I noticed that those files still use the markup. Converting them to use {@code ... } is another useful task. Thanks, Roger [1]https://bugs.openjdk.java.net/browse/JDK-8252536 On 9/2/20 12:18 PM, Vipin Sharma wrote: > Hi Roger, > > On Tue, Sep 1, 2020 at 10:49 PM Roger Riggs > wrote: > > Hi Vipin, > > Looks fine. > > Though I would also correct the indentation and join source lines > in a > few cases. > > MasrshalledObject.java.? Continuation lines should be indented. Lines > 110 and 164, 166. > > Fixed. > > > Naming.java: Join line 110, 137, 162, 191: "appropriately... > formatted URL" > > Fixed lines 113, 140, and 164 as well, similar problems. > > > Thanks, Roger > > > Updated webrev: https://cr.openjdk.java.net/~vsharma/8252538/webrev.02/ > > Regards, > Vipin From mandy.chung at oracle.com Wed Sep 2 21:14:41 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Sep 2020 14:14:41 -0700 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate In-Reply-To: <4ADB21B2-A14F-4C7E-922E-B5E5F564CF92@oracle.com> References: <866762F3-AAB4-4673-80D1-841CE71513DC@azul.com> <4ADB21B2-A14F-4C7E-922E-B5E5F564CF92@oracle.com> Message-ID: <55eadba6-061b-953a-b0fa-a64bb6134bdf@oracle.com> On 8/25/20 10:11 PM, Kim Barrett wrote: > Finally getting back to this after some internal discussion that > dragged along because folks have been busy. > >> On Apr 8, 2020, at 12:05 PM, Gil Tene wrote: >> >> Lifting out of response from the JIRA issue: >> >> I always worry when proposing a change to an existing invariant, and >> PhantomReference currently carries the stated and specified behavior >> of "the referent of a phantom reference is always inaccessible". >> >> I can imagine quite a few forms of gaining new information I do not otherwise >> have access to by using PhantomReference::RefersTo if it allowed me to examine >> the current referent of a phantom reference and test to see if it is (a) null or (b) a >> specific object I have a reference to. Both of those would provide me with information >> that is impossible for me to get according to current specifications. With that newly >> available information one can come up with all sorts of nice things to do... Think in >> terms of "side-channel" as an example of the sort of thinking black hats can apply >> to this new knowledge, but the potential attacks are not limited to side-channels. >> >> While it will be "obviously safe" to have Reference:RefersTo(obj) provide the same >> information that (Reference.get() == obj) would, providing more information than >> that would be a change to the specified behavior of Reference types, which we >> should be extra paranoid about. Since PhantomReference::get returns null by >> definition, we should remain consistent with that in PhantomReference::refersTo > [copied from JIRA issue] > That all assumes that I'm giving you access to my phantom references. > But if I'm doing that then I've got much worse problems than any > potential information leakage of the kind being suggested. If you have > one of my phantom references then you can enqueue it, triggering any > associated cleanup while I'm still using the referent. One should not > give one's phantom references to untrusted code. That's nothing new, > and is not made any worse by having Reference.refersTo work the same > way for phantom references as for other reference types. > > Agree.??? We should probably document this in the Java security code guideline to advice the developers be cautious and not to leak Reference objects. Mandy From raffaello.giulietti at gmail.com Wed Sep 2 21:26:07 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 2 Sep 2020 23:26:07 +0200 Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) In-Reply-To: <39c19044-e14f-5961-7746-a3872be95fd7@oracle.com> References: <623e9591-2caf-ecc4-0986-44cb90bc425f@gmail.com> <2FD97380-F78B-4C15-A1FE-0415BA96C886@oracle.com> <39c19044-e14f-5961-7746-a3872be95fd7@oracle.com> Message-ID: <3892472a-559e-4f4e-a773-2e14694fb050@gmail.com> Hi Joe, will do in the next days, hopefully before the transition to Skara. I'll also add JMH results. Greetings Raffaello On 2020-09-02 21:17, Joe Darcy wrote: > Hello, > > I also suggest taking a look at the existing regression tests in > > ??? test/jdk/java/lang/Long/Unsigned.java > > to see if more cases should be added with the new algorithm. > Potentially, the existing algorithm could retire to serve as a reference > in the regression tests. > > Thanks, > > -Joe > > On 9/2/2020 7:37 AM, Raffaello Giulietti wrote: >> Hi Brian, >> >> thanks for taking a look. >> >> I didn't write JMH benchmarks. >> >> >> Greetings >> Raffaello >> >> >> >> On 2020-09-02 16:25, Brian Burkhalter wrote: >>> Hi?Raffaello, >>> >>> I can take a look. Did you write any (JMH?) microbenchmarks? >>> >>> Thanks, >>> >>> Brian >>> >>>> On Sep 2, 2020, at 5:52 AM, Raffaello Giulietti >>>> >>> > wrote: >>>> >>>> here's a patch for [1], which is currently unassigned. Anybody >>>> willing to sponsor it? >>>> >>>> The fix is based on "Hacker's Delight" (2nd ed), section 9.3 and >>>> makes use of longs only, no BigInteger, no garbage to collect. It is >>>> faster and "greener" than the current code. >>>> >>>> Contrary to the dramatic plea in the subject, with this fix I think >>>> there's no pressing need for an intrinsic. >>>> >>>> The fix should be back-portable to 11 and 8, where the methods first >>>> appeared, but I only tried on a current changeset [2]. >>>> >>>> Passes tier1. >>>> >>>> If anybody needs the fix as attachment, just let me know. >>> >> From douglas.surber at oracle.com Wed Sep 2 22:12:03 2020 From: douglas.surber at oracle.com (Douglas Surber) Date: Wed, 2 Sep 2020 15:12:03 -0700 Subject: RFR 8251989: Hex formatting and parsing In-Reply-To: References: Message-ID: <935FDA14-123E-4048-A43D-60E7A7E68F4F@oracle.com> I still want to know how to format a byte sequence where each byte has a prefix (or suffix). Eg. { 0x00, 0x01, 0x02, 0xOD, 0x0E, 0x0F } Douglas > On Sep 2, 2020, at 2:26 PM, core-libs-dev-request at openjdk.java.net wrote: > > Date: Wed, 2 Sep 2020 16:26:07 -0400 > From: Roger Riggs > > To: core-libs-dev > > Subject: RFR 8251989: Hex formatting and parsing > Message-ID: <180eca84-19fe-2dc4-9e57-1d05328e1c7b at oracle.com > > Content-Type: text/plain; charset=utf-8; format=flowed > > Please review the updated API in the Javadoc. > http://cr.openjdk.java.net/~rriggs/hex-formatter/java.base/java/util/Hex.html > > A few offline contacts encouaged me to explore expanding the support > for formatting and parsing of primitive types. > Adding formatting toHex methods and [arsing fromHex methods makes the > API easier to use. > > For example, there are a number of protocols that need to escape char > values > as hex. For symmetry across the primitive types, byte, char, short, int, > and long > methods are added. > > The handling of invalid digits was changed to consistently throw > IllegalArgumentException; it is unlikely that encoding and decoding > run into invalid characters and the previous technique requiring the caller > to check the value for negative numbers is error prone. > > There is some danger of proliferating methods yet, so not all combinations > are included.? Feedback welcome. > > With the API still shifting, the implemention is not ready to review. > > Thanks, Roger > From brian.burkhalter at oracle.com Wed Sep 2 22:44:39 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 2 Sep 2020 15:44:39 -0700 Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) In-Reply-To: <3892472a-559e-4f4e-a773-2e14694fb050@gmail.com> References: <623e9591-2caf-ecc4-0986-44cb90bc425f@gmail.com> <2FD97380-F78B-4C15-A1FE-0415BA96C886@oracle.com> <39c19044-e14f-5961-7746-a3872be95fd7@oracle.com> <3892472a-559e-4f4e-a773-2e14694fb050@gmail.com> Message-ID: <1FC89344-6D17-448D-BE77-36BD32BDDB37@oracle.com> Good move. ;-) Brian > On Sep 2, 2020, at 2:26 PM, Raffaello Giulietti wrote: > > will do in the next days, hopefully before the transition to Skara. From swpalmer at gmail.com Thu Sep 3 03:07:34 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 2 Sep 2020 23:07:34 -0400 Subject: jpackage: support for environment variables in --java-options In-Reply-To: References: <084B8AE1-1E40-4DF2-AD97-42104827F067@gmail.com> Message-ID: <78534E85-893A-4B5E-B85B-BE654397EED3@gmail.com> There is already a way to supply a custom Info.plist. That can have the LSEnvironment entries you want. https://bugs.openjdk.java.net/browse/JDK-8233175 I was under the impression that we were after something that would allow different values to get to the application based on environment variables. The env var values can?t be hard-coded in the Info.plist to do that, we want values that are expanded based on set environment variables on the user?s machine. Isn?t that what this is about? Scott > On Sep 2, 2020, at 1:20 PM, Michael Hall wrote: > > > >> On Sep 2, 2020, at 12:14 PM, Scott Palmer wrote: >> >> If your app need to use environment variables to configure something for runtime it is probably best to have your own stub launcher and launch a sub-process. > > They need to be available at runtime for external native that expects them to be present. > >> >> It can be tricky to have a smooth user experience with that though. You would want to avoid an extra icon in the dock/start bar. You don?t want the other process to show up as ?java.exe?, etc. That?s the benefit of trying to solve this in the launcher created by jpackage. >> > > What I am suggesting would be handled by jpackage within the application bundle. It would modify the Info.plist to include the LSEnvironment entries. 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 mik3hall at gmail.com Thu Sep 3 08:26:11 2020 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 3 Sep 2020 03:26:11 -0500 Subject: jpackage: support for environment variables in --java-options In-Reply-To: <78534E85-893A-4B5E-B85B-BE654397EED3@gmail.com> References: <084B8AE1-1E40-4DF2-AD97-42104827F067@gmail.com> <78534E85-893A-4B5E-B85B-BE654397EED3@gmail.com> Message-ID: <3BC2E4B4-7195-4DC9-B7A5-7AB18E14A304@gmail.com> > On Sep 2, 2020, at 10:07 PM, Scott Palmer wrote: > > There is already a way to supply a custom Info.plist. > That can have the LSEnvironment entries you want. > > https://bugs.openjdk.java.net/browse/JDK-8233175 > > I was under the impression that we were after something that would allow different values to get to the application based on environment variables. The env var values can?t be hard-coded in the Info.plist to do that, we want values that are expanded based on set environment variables on the user?s machine. Isn?t that what this is about? > > Scott Yes for Serban?s thread. Which was already shown not to work OS X on the users machine because user environment variables aren?t passed to applications. Since the interest there mainly seemed to be turning environment variables into jdk option parameters for that part your stub launcher was a more valid suggestion. The original is not the purpose of environment variables that interested me. I think might of been a little questionable trying to use for this purpose. I had sort of been still been discussing my own separate question on providing the application environment variables Doing it on this thread probably wasn?t proper. Sorry. > https://bugs.openjdk.java.net/browse/JDK-8233175 OK. Basically this gives a plugin method to provide your own Info.plist. As of yet undocumented. That documentation still being as far as I know jpackage ?help. Info.plist is not normally placed into the resources directory. I assume the issue resolution involves simply moving the Info.plist out of that directory to where it actually should be. --resource-dir Path to override jpackage resources Icons, template files, and other resources of jpackage can be over-ridden by adding replacement resources to this directory. (absolute path or relative to the current directory) Everything mentioned in the ?help properly I think ends up in a OS X applications resources directory. Although I just get the icns. ls outputdir/HalfPipe.app/Contents/Resources HalfPipe.icns But it is not usually the spot for Info.plist. As a work-around it probably does work. It does make the Info.plist (plugin?) provider responsible for everything that goes into the plist that jpackage would normally handle. Like --mac-package-identifier. But that is fine I guess. Being able to sort of custom plugin parts of the build might be nice. Rather than try to have jpackage handle everything from start to finish in one pass for everything that every application needs based solely on parameters. In this case I think maybe though having a explicit parameter indicating this is the developers wish might be cleaner? Something like ?mac-info-plist . Maybe I?ll go back to the recent situation where a PATH environment variable seemed to be needed and see if I can in fact come up with plugin type code that puts together a Info.plist that works. From jiefu at tencent.com Thu Sep 3 09:22:21 2020 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Thu, 3 Sep 2020 09:22:21 +0000 Subject: RFR: 8252740: java/util/Properties/LoadAndStoreXMLWithDefaults.java fails after JDK-8252354 Message-ID: Hi all, JBS: https://bugs.openjdk.java.net/browse/JDK-8252740 Webrev: http://cr.openjdk.java.net/~jiefu/8252740/webrev.00/ After JDK-8252354, properties whose keys or values are none strings won't be skipped any more. Instead, ClassCastException will be thrown. So this part of testing code is incorrect. The fix just removes it. Thanks. Best regards, Jie From Alan.Bateman at oracle.com Thu Sep 3 09:51:18 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 3 Sep 2020 10:51:18 +0100 Subject: RFR: 8252740: java/util/Properties/LoadAndStoreXMLWithDefaults.java fails after JDK-8252354 In-Reply-To: References: Message-ID: On 03/09/2020 10:22, jiefu(??) wrote: > Hi all, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8252740 > Webrev: http://cr.openjdk.java.net/~jiefu/8252740/webrev.00/ > > After JDK-8252354, properties whose keys or values are none strings won't be skipped any more. > Instead, ClassCastException will be thrown. > Looks like the update to the test is missing from changes for JDK-8252354. Your change looks okay but I don't understand why this wasn't caught, maybe the test change was in Joe's changes that he tested? -Alan From fernando.guallini at oracle.com Thu Sep 3 10:40:29 2020 From: fernando.guallini at oracle.com (Fernando Guallini) Date: Thu, 3 Sep 2020 11:40:29 +0100 Subject: RFR: 8249694 - [TestBug] java/lang/StringBuffer/HugeCapacity.java and j/l/StringBuilder/HugeCapacity.java tests shouldn't be @ignore-d In-Reply-To: <5a0ea05b-24b7-d0f7-600b-8724db3a15a0@oracle.com> References: <5a0ea05b-24b7-d0f7-600b-8724db3a15a0@oracle.com> Message-ID: <464A560B-7DAF-4093-8B6E-74A44BF79007@oracle.com> Hi Sean, Right, it also applies for these tests, changes: --- a/test/jdk/java/lang/StringBuffer/HugeCapacity.java +++ b/test/jdk/java/lang/StringBuffer/HugeCapacity.java - * @requires os.maxMemory >= 6G + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 6G) --- a/test/jdk/java/lang/StringBuilder/HugeCapacity.java +++ b/test/jdk/java/lang/StringBuilder/HugeCapacity.java - * @requires os.maxMemory >= 6G + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 6G) Regards, Fernando > On 1 Sep 2020, at 17:25, Se?n Coffey wrote: > > Wouldn't you require the sun.arch.data.model == "64" jtreg config in these tests also ? > > regards, > Sean. > > On 28/08/2020 19:13, Fernando Guallini wrote: >> >> >> >> >> >> >> >> Hi, >> >> May I please get reviews and a sponsor for this trivial change: >> >> webrev: http://cr.openjdk.java.net/~fguallini/8249694/webrev.00/ >> Testbug: https://bugs.openjdk.java.net/browse/JDK-8249694 >> >> Tests do not need to have ?@ignore' because with @requires os.maxMemory is enough to ensure they will not be executed if memory requirements are not satisfied. They run in Mach5 with no issues. >> >> Thanks >> >> -Fernando From sean.coffey at oracle.com Thu Sep 3 10:58:26 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 3 Sep 2020 11:58:26 +0100 Subject: RFR: 8249694 - [TestBug] java/lang/StringBuffer/HugeCapacity.java and j/l/StringBuilder/HugeCapacity.java tests shouldn't be @ignore-d In-Reply-To: <464A560B-7DAF-4093-8B6E-74A44BF79007@oracle.com> References: <5a0ea05b-24b7-d0f7-600b-8724db3a15a0@oracle.com> <464A560B-7DAF-4093-8B6E-74A44BF79007@oracle.com> Message-ID: <09d55947-8f8b-1409-5705-f224ce173baa@oracle.com> Looks fine to me. regards, Sean. On 03/09/2020 11:40, Fernando Guallini wrote: > Hi Sean, > Right, it also applies for these tests, changes: > --- a/test/jdk/java/lang/StringBuffer/HugeCapacity.java > +++ b/test/jdk/java/lang/StringBuffer/HugeCapacity.java > - * @requires os.maxMemory >= 6G > + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 6G) > --- a/test/jdk/java/lang/StringBuilder/HugeCapacity.java > +++ b/test/jdk/java/lang/StringBuilder/HugeCapacity.java > - * @requires os.maxMemory >= 6G > + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 6G) > > Regards, > Fernando > >> On 1 Sep 2020, at 17:25, Se?n Coffey > > wrote: >> >> Wouldn't you require the sun.arch.data.model == "64" jtreg config in >> these tests also ? >> >> regards, >> Sean. >> >> On 28/08/2020 19:13, Fernando Guallini wrote: >>> >>> >>> >>> >>> >>> >>> >>> Hi, >>> >>> May I please get reviews and a sponsor for this trivial change: >>> >>> webrev: http://cr.openjdk.java.net/~fguallini/8249694/webrev.00/ >>> Testbug: https://bugs.openjdk.java.net/browse/JDK-8249694 >>> >>> Tests do not need to have ?@ignore' because with @requires >>> os.maxMemory is enough to ensure they will not be executed if memory >>> requirements are not satisfied. They run in Mach5 with no issues. >>> >>> Thanks >>> >>> -Fernando > From swpalmer at gmail.com Thu Sep 3 12:12:14 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 3 Sep 2020 08:12:14 -0400 Subject: jpackage: support for environment variables in --java-options In-Reply-To: <3BC2E4B4-7195-4DC9-B7A5-7AB18E14A304@gmail.com> References: <084B8AE1-1E40-4DF2-AD97-42104827F067@gmail.com> <78534E85-893A-4B5E-B85B-BE654397EED3@gmail.com> <3BC2E4B4-7195-4DC9-B7A5-7AB18E14A304@gmail.com> Message-ID: <558005DB-CB86-469D-96AD-22C3383091BE@gmail.com> > On Sep 3, 2020, at 4:26 AM, Michael Hall wrote: > > > >> On Sep 2, 2020, at 10:07 PM, Scott Palmer > wrote: >> >> There is already a way to supply a custom Info.plist. >> That can have the LSEnvironment entries you want. >> >> https://bugs.openjdk.java.net/browse/JDK-8233175 >> >> I was under the impression that we were after something that would allow different values to get to the application based on environment variables. The env var values can?t be hard-coded in the Info.plist to do that, we want values that are expanded based on set environment variables on the user?s machine. Isn?t that what this is about? >> >> Scott > > Yes for Serban?s thread. Which was already shown not to work OS X on the users machine because user environment variables aren?t passed to applications. As I mentioned earlier, launchctl must be used to set environment variables that you want passed to GUI applications. Scott From raffaello.giulietti at gmail.com Thu Sep 3 12:53:16 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 3 Sep 2020 14:53:16 +0200 Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) In-Reply-To: <3892472a-559e-4f4e-a773-2e14694fb050@gmail.com> References: <623e9591-2caf-ecc4-0986-44cb90bc425f@gmail.com> <2FD97380-F78B-4C15-A1FE-0415BA96C886@oracle.com> <39c19044-e14f-5961-7746-a3872be95fd7@oracle.com> <3892472a-559e-4f4e-a773-2e14694fb050@gmail.com> Message-ID: <41a54d3e-dd12-2910-ca1d-1042cae1178b@gmail.com> Hi Brian, setting up ?-benchmarks to get meaningful results on code that has execution paths with quite different shapes, like the current and the patched one, requires some care. I chose to exercise all paths at each iteration rather than to rely on a high iteration count. Without real world data at hand, I assume the arguments are uniformly distributed. (Exercising individual paths by choosing appropriate data tends to show optimistic results because the JIT can use profiling information to get rid of the unused code in the other paths and thus optimize better. This might or might not be realistic, depending on use cases.) Here's how I did the measurements. @Benchmark public long testUdiv() { return Long.divideUnsigned(n0, d0) | Long.divideUnsigned(n1, d1) | Long.divideUnsigned(n2, d2) | Long.divideUnsigned(n3, d3); } The different paths can all be exercised in the same benchmark. I hope that combining the longs with | doesn't taint the results significantly. In case of the current code, the arguments are setup at each iteration as random long such that n0 any, d0 < 0 n1 any, d1 < 0 n2 > 0, d2 > 0 n3 <= 0, d3 > 0 The path with negative divisor is executed two times more than the other paths to account for a 50% + 25% + 25% probability distribution to hit the paths. For the patched code, the setup is n0 any, d0 > 0 n1 any, d1 > 0 n2 any, d2 < 0 n3 any , d3 < 0 so that the two paths are executed with equal probability. The results on the current code: MyBenchmark.testUdiv thrpt 25 6617777.520 ? 238817.781 ops/s and on the patched code: MyBenchmark.testUdiv thrpt 25 33763422.461 ? 446012.270 ops/s showing a speedup of about 5x, provided the rationale is sound. After these, I didn't care to measure remainderUnsigned(). It could be done similarly. Greetings Raffaello On 2020-09-02 23:26, Raffaello Giulietti wrote: > I'll also add JMH results. > From mik3hall at gmail.com Thu Sep 3 12:55:07 2020 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 3 Sep 2020 07:55:07 -0500 Subject: jpackage: support for environment variables in --java-options In-Reply-To: <558005DB-CB86-469D-96AD-22C3383091BE@gmail.com> References: <084B8AE1-1E40-4DF2-AD97-42104827F067@gmail.com> <78534E85-893A-4B5E-B85B-BE654397EED3@gmail.com> <3BC2E4B4-7195-4DC9-B7A5-7AB18E14A304@gmail.com> <558005DB-CB86-469D-96AD-22C3383091BE@gmail.com> Message-ID: <686F7844-D682-45E3-B235-828D0D78491C@gmail.com> > On Sep 3, 2020, at 7:12 AM, Scott Palmer wrote: > > > >> On Sep 3, 2020, at 4:26 AM, Michael Hall > wrote: >> >> >> >>> On Sep 2, 2020, at 10:07 PM, Scott Palmer > wrote: >>> >>> There is already a way to supply a custom Info.plist. >>> That can have the LSEnvironment entries you want. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8233175 >>> >>> I was under the impression that we were after something that would allow different values to get to the application based on environment variables. The env var values can?t be hard-coded in the Info.plist to do that, we want values that are expanded based on set environment variables on the user?s machine. Isn?t that what this is about? >>> >>> Scott >> >> Yes for Serban?s thread. Which was already shown not to work OS X on the users machine because user environment variables aren?t passed to applications. > > As I mentioned earlier, launchctl must be used to set environment variables that you want passed to GUI applications. This is not how I?ve done it before. I did a little googling and it seemed to indicate launchctl could somehow be used for ?global? environment variables. It didn?t sound application specific. I have successfully done this on a application basis a couple times in the past as I mentioned earlier. Also from the old javafx JavaPackager I also mentioned earlier is this in Info.plist.vtl? #if ($info.bundleJre) LSEnvironment JAVA_HOME Contents/PlugIns/${info.jreDirectoryName}/Contents/Home #if($info.envPath) PATH ${info.envPath} #end The incident mentioned earlier showed a resolution of having the user provide their own custom Info.plist. While plain old edit would probably be fine for this some sort of code to provide it without manual intervention might also be nice. I believe I have some old code lying around that might just provide a beginning for such a thing. From mik3hall at gmail.com Thu Sep 3 13:02:30 2020 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 3 Sep 2020 08:02:30 -0500 Subject: jpackage: support for environment variables in --java-options In-Reply-To: <686F7844-D682-45E3-B235-828D0D78491C@gmail.com> References: <084B8AE1-1E40-4DF2-AD97-42104827F067@gmail.com> <78534E85-893A-4B5E-B85B-BE654397EED3@gmail.com> <3BC2E4B4-7195-4DC9-B7A5-7AB18E14A304@gmail.com> <558005DB-CB86-469D-96AD-22C3383091BE@gmail.com> <686F7844-D682-45E3-B235-828D0D78491C@gmail.com> Message-ID: > > The incident mentioned earlier showed a resolution of having the user provide their own custom Info.plist. While plain old edit would probably be fine for this some sort of code to provide it without manual intervention might also be nice. I believe I have some old code lying around that might just provide a beginning for such a thing. As another possible alternative for working with an Info.plist this was recently mentioned on I think it was a Cocoa mail list. https://medium.com/@marksiu/what-is-plistbuddy-76cb4f0c262d 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 jiefu at tencent.com Thu Sep 3 14:10:21 2020 From: jiefu at tencent.com (=?gb2312?B?amllZnUouLW93Ck=?=) Date: Thu, 3 Sep 2020 14:10:21 +0000 Subject: RFR: 8252740: java/util/Properties/LoadAndStoreXMLWithDefaults.java fails after JDK-8252354(Internet mail) In-Reply-To: References: , Message-ID: <321aed81b87c4719a08b17f840380673@tencent.com> Thanks Alan for your review. Will push it tomorrow. Best regards, Jie ________________________________ From: Alan Bateman Sent: Thursday, September 3, 2020 5:51 PM To: jiefu(??); core-libs-dev at openjdk.java.net Subject: Re: RFR: 8252740: java/util/Properties/LoadAndStoreXMLWithDefaults.java fails after JDK-8252354(Internet mail) On 03/09/2020 10:22, jiefu(??) wrote: > Hi all, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8252740 > Webrev: http://cr.openjdk.java.net/~jiefu/8252740/webrev.00/ > > After JDK-8252354, properties whose keys or values are none strings won't be skipped any more. > Instead, ClassCastException will be thrown. > Looks like the update to the test is missing from changes for JDK-8252354. Your change looks okay but I don't understand why this wasn't caught, maybe the test change was in Joe's changes that he tested? -Alan From raffaello.giulietti at gmail.com Thu Sep 3 15:09:40 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 3 Sep 2020 17:09:40 +0200 Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) In-Reply-To: <3892472a-559e-4f4e-a773-2e14694fb050@gmail.com> References: <623e9591-2caf-ecc4-0986-44cb90bc425f@gmail.com> <2FD97380-F78B-4C15-A1FE-0415BA96C886@oracle.com> <39c19044-e14f-5961-7746-a3872be95fd7@oracle.com> <3892472a-559e-4f4e-a773-2e14694fb050@gmail.com> Message-ID: <0ae5d46a-1f78-79ff-912d-685a382edf20@gmail.com> Hi Joe, I modified the values in method testDivideAndRemainder(), without touching the logic. The values are odd and even dividends and divisors around 0, 2^31, 2^32, 2^33, 2^63 and 2^64. Is this OK? Greetings Raffaello On 2020-09-02 23:26, Raffaello Giulietti wrote: > will do in the next days, hopefully before the transition to Skara. > # HG changeset patch # User lello # Date 1599145128 -7200 # Thu Sep 03 16:58:48 2020 +0200 # Node ID 3b3304879831cb1e76e4edbc2303efcf620d63b8 # Parent 6ab9279c0e99bf28d813c54c3c2645df61e654e7 Patch to fix JDK-8238669 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) Reviewed-by: TBD Contributed-by: Raffaello Giulietti diff --git a/src/java.base/share/classes/java/lang/Long.java b/src/java.base/share/classes/java/lang/Long.java --- a/src/java.base/share/classes/java/lang/Long.java +++ b/src/java.base/share/classes/java/lang/Long.java @@ -1668,24 +1668,13 @@ * @since 1.8 */ public static long divideUnsigned(long dividend, long divisor) { - if (divisor < 0L) { // signed comparison - // Answer must be 0 or 1 depending on relative magnitude - // of dividend and divisor. - return (compareUnsigned(dividend, divisor)) < 0 ? 0L :1L; + // See Hacker's Delight (2nd ed), section 9.3 + if (divisor >= 0) { + final long q = (dividend >>> 1) / divisor << 1; + final long r = dividend - q * divisor; + return q + ((r | ~(r - divisor)) >>> Long.SIZE - 1); } - - if (dividend > 0) // Both inputs non-negative - return dividend/divisor; - else { - /* - * For simple code, leveraging BigInteger. Longer and faster - * code written directly in terms of operations on longs is - * possible; see "Hacker's Delight" for divide and remainder - * algorithms. - */ - return toUnsignedBigInteger(dividend). - divide(toUnsignedBigInteger(divisor)).longValue(); - } + return (dividend & ~(dividend - divisor)) >>> Long.SIZE - 1; } /** @@ -1701,15 +1690,13 @@ * @since 1.8 */ public static long remainderUnsigned(long dividend, long divisor) { - if (dividend > 0 && divisor > 0) { // signed comparisons - return dividend % divisor; - } else { - if (compareUnsigned(dividend, divisor) < 0) // Avoid explicit check for 0 divisor - return dividend; - else - return toUnsignedBigInteger(dividend). - remainder(toUnsignedBigInteger(divisor)).longValue(); + // See Hacker's Delight (2nd ed), section 9.3 + if (divisor >= 0) { + final long q = (dividend >>> 1) / divisor << 1; + final long r = dividend - q * divisor; + return r - (~(r - divisor) >> Long.SIZE - 1 & divisor); } + return dividend - ((dividend & ~(dividend - divisor)) >> Long.SIZE - 1 & divisor); } // Bit Twiddling diff --git a/test/jdk/java/lang/Long/Unsigned.java b/test/jdk/java/lang/Long/Unsigned.java --- a/test/jdk/java/lang/Long/Unsigned.java +++ b/test/jdk/java/lang/Long/Unsigned.java @@ -375,24 +375,54 @@ private static int testDivideAndRemainder() { int errors = 0; - long MAX_UNSIGNED_INT = Integer.toUnsignedLong(0xffff_ffff); + long TWO_31 = 1L << Integer.SIZE - 1; + long TWO_32 = 1L << Integer.SIZE; + long TWO_33 = 1L << Integer.SIZE + 1; + BigInteger NINETEEN = BigInteger.valueOf(19L); + BigInteger TWO_63 = BigInteger.ONE.shiftLeft(Long.SIZE - 1); + BigInteger TWO_64 = BigInteger.ONE.shiftLeft(Long.SIZE); BigInteger[] inRange = { - BigInteger.valueOf(0L), - BigInteger.valueOf(1L), - BigInteger.valueOf(10L), - BigInteger.valueOf(2147483646L), // Integer.MAX_VALUE - 1 - BigInteger.valueOf(2147483647L), // Integer.MAX_VALUE - BigInteger.valueOf(2147483648L), // Integer.MAX_VALUE + 1 + BigInteger.ZERO, + BigInteger.ONE, + BigInteger.TEN, + NINETEEN, + + BigInteger.valueOf(TWO_31 - 19L), + BigInteger.valueOf(TWO_31 - 10L), + BigInteger.valueOf(TWO_31 - 1L), + BigInteger.valueOf(TWO_31), + BigInteger.valueOf(TWO_31 + 1L), + BigInteger.valueOf(TWO_31 + 10L), + BigInteger.valueOf(TWO_31 + 19L), - BigInteger.valueOf(MAX_UNSIGNED_INT - 1L), - BigInteger.valueOf(MAX_UNSIGNED_INT), + BigInteger.valueOf(TWO_32 - 19L), + BigInteger.valueOf(TWO_32 - 10L), + BigInteger.valueOf(TWO_32 - 1L), + BigInteger.valueOf(TWO_32), + BigInteger.valueOf(TWO_32 + 1L), + BigInteger.valueOf(TWO_32 + 10L), + BigInteger.valueOf(TWO_32 - 19L), - BigInteger.valueOf(Long.MAX_VALUE - 1L), - BigInteger.valueOf(Long.MAX_VALUE), - BigInteger.valueOf(Long.MAX_VALUE).add(BigInteger.ONE), + BigInteger.valueOf(TWO_33 - 19L), + BigInteger.valueOf(TWO_33 - 10L), + BigInteger.valueOf(TWO_33 - 1L), + BigInteger.valueOf(TWO_33), + BigInteger.valueOf(TWO_33 + 1L), + BigInteger.valueOf(TWO_33 + 10L), + BigInteger.valueOf(TWO_33 + 19L), - TWO.pow(64).subtract(BigInteger.ONE) + TWO_63.subtract(NINETEEN), + TWO_63.subtract(BigInteger.TEN), + TWO_63.subtract(BigInteger.ONE), + TWO_63, + TWO_63.add(BigInteger.ONE), + TWO_63.add(BigInteger.TEN), + TWO_63.add(NINETEEN), + + TWO_64.subtract(NINETEEN), + TWO_64.subtract(BigInteger.TEN), + TWO_64.subtract(BigInteger.ONE), }; for(BigInteger dividend : inRange) { From yumin.qi at oracle.com Thu Sep 3 15:36:28 2020 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 3 Sep 2020 08:36:28 -0700 Subject: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code Message-ID: Hi, Please review bug: https://bugs.openjdk.java.net/browse/JDK-8252725 webrev: http://cr.openjdk.java.net/~minqi/2020/8252725/webrev-01/ Summary: The work is part of 8247536, which supports archive pre-generated java.lang.invoke classes in CDS. In this patch (thanks to Mandy): 1. Two methods for tracing SPECIES_RESOLVE and LF_RESOLVE are added to GenerateJLIClassesHelper: traceSpeciesType and traceLambdaForm respectively; 2. Move log file parsing work to java.lang.InvokeJLIClassesHelper; 3. Clean up interface APIs since old APIs no longer used with the moving; 4. New API JavaLangInvokeAccess::generateHolderClassesreturns a map of class name, which in internal form as key rather than the jimage entry point, vs class bytes. This makes both JLI and CDS can use the new interface easily. CDS will add a new function (in 8247536 patch, only for convenience for converting the map to array) to GenerateJLIClassesHelper to call the new added interface API (generateHolderClasses)to regenerate holder classes during dump time. Thanks Yumin From yumin.qi at oracle.com Thu Sep 3 15:41:05 2020 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 3 Sep 2020 08:41:05 -0700 Subject: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code In-Reply-To: References: Message-ID: <34eeb2ba-4f8a-37ea-861f-e946ae1fd22c@oracle.com> Sorry push "send" too soon: Tests: local build. mach5 tier1-4 have 2 timeouts on build which I think related to lab move(?). Thanks Yumin On 9/3/20 8:36 AM, Yumin Qi wrote: > Hi, Please review > > > bug: https://bugs.openjdk.java.net/browse/JDK-8252725 > > webrev: http://cr.openjdk.java.net/~minqi/2020/8252725/webrev-01/ > > > Summary: The work is part of 8247536, which supports archive pre-generated java.lang.invoke classes in CDS. In this patch (thanks to Mandy): > > 1. Two methods for tracing SPECIES_RESOLVE and LF_RESOLVE are added to GenerateJLIClassesHelper: traceSpeciesType and traceLambdaForm respectively; > > 2. Move log file parsing work to java.lang.InvokeJLIClassesHelper; > > 3. Clean up interface APIs since old APIs no longer used with the moving; > > 4. New API JavaLangInvokeAccess::generateHolderClassesreturns a map of class name, which in internal form as key rather than the jimage entry point, vs class bytes. > > This makes both JLI and CDS can use the new interface easily. CDS will add a new function (in 8247536 patch, only for convenience for converting the map to array) to GenerateJLIClassesHelper to call the new added interface API (generateHolderClasses)to regenerate holder classes during dump time. > > > Thanks > > Yumin > > From mandy.chung at oracle.com Thu Sep 3 16:13:39 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Sep 2020 09:13:39 -0700 Subject: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code In-Reply-To: References: Message-ID: <4be47e30-aa69-7db0-ff04-f2d379fb8b38@oracle.com> On 9/3/20 8:36 AM, Yumin Qi wrote: > Hi, Please review > > > bug: https://bugs.openjdk.java.net/browse/JDK-8252725 > > webrev: http://cr.openjdk.java.net/~minqi/2020/8252725/webrev-01/ > Looks good to me.?? Sundar should also review it. A few things to mention compared to the proposed patch from 8247536:? we no longer log the error case for LF_RESOLVE since it's ignored anyway.? As the code is moved to java.lang.invoke, we also clean up the code to use constants and methods defined in LambdaForm and MethodTypeForm and BasicType (rather than duplicating such definitions). Mandy > > Summary: The work is part of 8247536, which supports archive > pre-generated java.lang.invoke classes in CDS. In this patch (thanks > to Mandy): > > 1. Two methods for tracing SPECIES_RESOLVE and LF_RESOLVE are added to > GenerateJLIClassesHelper: traceSpeciesType and traceLambdaForm > respectively; > > 2. Move log file parsing work to java.lang.InvokeJLIClassesHelper; > > 3. Clean up interface APIs since old APIs no longer used with the moving; > > 4. New API JavaLangInvokeAccess::generateHolderClassesreturns a map of > class name, which in internal form as key rather than the jimage entry > point, vs class bytes. > > This makes both JLI and CDS can use the new interface easily. CDS will > add a new function (in 8247536 patch, only for convenience for > converting the map to array) to GenerateJLIClassesHelper to call the > new added interface API (generateHolderClasses)to regenerate holder > classes during dump time. > > > Thanks > > Yumin > > From huizhe.wang at oracle.com Thu Sep 3 16:16:57 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 3 Sep 2020 09:16:57 -0700 Subject: RFR: 8252740: java/util/Properties/LoadAndStoreXMLWithDefaults.java fails after JDK-8252354 In-Reply-To: References: Message-ID: <2f545ef2-3ea5-0f01-5663-cd68288cd6dc@oracle.com> On 9/3/20 2:51 AM, Alan Bateman wrote: > On 03/09/2020 10:22, jiefu(??) wrote: >> Hi all, >> >> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8252740 >> Webrev: http://cr.openjdk.java.net/~jiefu/8252740/webrev.00/ >> >> After JDK-8252354, properties whose keys or values are none strings >> won't be skipped any more. >> Instead, ClassCastException will be thrown. >> > Looks like the update to the test is missing from changes for > JDK-8252354. Your change looks okay but I don't understand why this > wasn't caught, maybe the test change was in Joe's changes that he tested? My bad, needed more coffee. I got too used to my routine test script that covers java.xml, and a bit too eager to get the fix in before the transition to Git. The change looks good to me as well. -Joe > > -Alan From chris.w.dennis at gmail.com Thu Sep 3 16:29:39 2020 From: chris.w.dennis at gmail.com (Chris Dennis) Date: Thu, 3 Sep 2020 16:29:39 +0000 Subject: RFR 8214761 : Bug in parallel Kahan summation implementation In-Reply-To: References: <6fb0565c-81cd-07fa-1c4f-fdf406b75f25@oracle.com> Message-ID: In case there is a need for extra motivation here: import java.util.stream.DoubleStream; public class Test8214761 { public static void main(String[] args) { double a = Double.valueOf(args[0]); if (Math.ulp(a) <= Math.ulp(Math.nextAfter(a, 0))) { System.out.println("Stable addition"); } else { double b = Math.signum(a) * Math.ulp(a) / 2; double sum = a + b; double streamSum = DoubleStream.of(a, b).sum(); System.out.println(a + " + " + b + "\n => " + sum); System.out.println("DoubleStream.of(" + a + ", " + b + ").sum()\n => " + streamSum); } } } $ java -showversion Test8214761 1 openjdk version "16-internal" 2021-03-16 OpenJDK Runtime Environment (build 16-internal+0-cdennis.0178d0f136e9) OpenJDK 64-Bit Server VM (build 16-internal+0-cdennis.0178d0f136e9, mixed mode, sharing) 1.0 + 1.1102230246251565E-16 => 1.0 DoubleStream.of(1.0, 1.1102230246251565E-16).sum() => 0.9999999999999999 That's the sum of two positive doubles returning a result smaller than one of the two. Apologies for the zeal, Chris ?On 8/27/20, 10:52 AM, "Chris Dennis" wrote: Bump... I've run in to this while running tests that check computation results against the expected bounds of a Kahan summation. Any chance that this gets picked up in the near future? Thanks, Chris ?On 12/13/18, 6:16 PM, "core-libs-dev on behalf of Ivan Gerasimov" wrote: Gentle ping. On 12/9/18 7:37 PM, Ivan Gerasimov wrote: > Hello! > > DoubleSummaryStatistics takes advantage of Kahan summation algorithm > to reduce the error of the total sum. > > Internally it maintains a field double sumCompensation, which keeps > lower bits (which were rounded off) of the last addition. > > Note, that the compensation has to be subtracted from the result to > add those bits back: > > 166 private void sumWithCompensation(double value) { > 167 double tmp = value - sumCompensation; > 168 double velvel = sum + tmp; // Little wolf of rounding error > 169 sumCompensation = (velvel - sum) - tmp; > 170 sum = velvel; > 171 } > > At the line 169, tmp normally has more lower bits than (velvel - sum). > > However, when two DoubleSummaryStatistics objects are combined, this > compensation part is *added* to the total, which may result in a less > accurate result. > > The same bug is replicated in DoubleStreams. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8214761 > WEBREV: http://cr.openjdk.java.net/~igerasim/8214761/00/webrev/ > -- With kind regards, Ivan Gerasimov From vipinsharma85 at gmail.com Thu Sep 3 17:51:57 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Thu, 3 Sep 2020 23:21:57 +0530 Subject: RFR 8252538: Replace @exception with @throws java.rmi package In-Reply-To: <40f610f6-d16d-f7d0-0ff7-416b64de6dfe@oracle.com> References: <3e68fe1f-be94-8549-bc89-eb148ac3864c@oracle.com> <40f610f6-d16d-f7d0-0ff7-416b64de6dfe@oracle.com> Message-ID: Hi Roger, On Thu, Sep 3, 2020 at 2:20 AM Roger Riggs wrote: > Hi Vipin, > > Looks fine. > > I see you filed separate tasks for the other packages in java.rmi. [1] > That's unnecessarily fine grained. > It would be more efficient to do them all in one code review, saving your > time and reviewers time. > I agree. In the next patch, I will include all remaining occurrences of @exception in the core-libs area. Also, I noticed that those files still use the markup. > Converting them to use {@code ... } is another useful task. > I will take this task. > Thanks, Roger > > [1]https://bugs.openjdk.java.net/browse/JDK-8252536 > Thanks, Vipin From swpalmer at gmail.com Thu Sep 3 18:41:36 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 3 Sep 2020 14:41:36 -0400 Subject: jpackage: support for environment variables in --java-options In-Reply-To: <686F7844-D682-45E3-B235-828D0D78491C@gmail.com> References: <084B8AE1-1E40-4DF2-AD97-42104827F067@gmail.com> <78534E85-893A-4B5E-B85B-BE654397EED3@gmail.com> <3BC2E4B4-7195-4DC9-B7A5-7AB18E14A304@gmail.com> <558005DB-CB86-469D-96AD-22C3383091BE@gmail.com> <686F7844-D682-45E3-B235-828D0D78491C@gmail.com> Message-ID: <5E152EC2-3A98-4023-A0CB-D23FB381B1EC@gmail.com> > On Sep 3, 2020, at 8:55 AM, Michael Hall wrote: > > > >> On Sep 3, 2020, at 7:12 AM, Scott Palmer > wrote: >> >> >> >>> On Sep 3, 2020, at 4:26 AM, Michael Hall > wrote: >>> >>> >>> >>>> On Sep 2, 2020, at 10:07 PM, Scott Palmer > wrote: >>>> >>>> There is already a way to supply a custom Info.plist. >>>> That can have the LSEnvironment entries you want. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8233175 >>>> >>>> I was under the impression that we were after something that would allow different values to get to the application based on environment variables. The env var values can?t be hard-coded in the Info.plist to do that, we want values that are expanded based on set environment variables on the user?s machine. Isn?t that what this is about? >>>> >>>> Scott >>> >>> Yes for Serban?s thread. Which was already shown not to work OS X on the users machine because user environment variables aren?t passed to applications. >> >> As I mentioned earlier, launchctl must be used to set environment variables that you want passed to GUI applications. > > This is not how I?ve done it before. I did a little googling and it seemed to indicate launchctl could somehow be used for ?global? environment variables. It didn?t sound application specific. Right it isn?t application specific. If you need a separate environment for your application, that wouldn?t work. But if you are passing parameters that are specific to the application launcher, why use environment variables at all? > The incident mentioned earlier showed a resolution of having the user provide their own custom Info.plist. Just use a config file that can be platform independent. Modifying the Info.plist for each specific install smells wrong. Scott > While plain old edit would probably be fine for this some sort of code to provide it without manual intervention might also be nice. I believe I have some old code lying around that might just provide a beginning for such a thing. From lois.foltan at oracle.com Thu Sep 3 18:45:45 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 3 Sep 2020 14:45:45 -0400 Subject: RFR(L) 8244778 Archive full module graph in CDS In-Reply-To: References: <9e6b0043-65a1-dd97-a3d2-33679c8048d4@oracle.com> <234856fa-1eb1-8514-6786-bce6689afd16@oracle.com> Message-ID: On 8/31/2020 11:31 AM, Ioi Lam wrote: > Hi Lois, > > Thanks for the review. Your comments has led me to discover a couple > of pretty serious issues, which hopefully I have fixed. Also the code > is cleaner now, with much fewer control-flow changes than the last > webrev. > > http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/ > > http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03.delta/ > Hi Ioi, Looks very good, thanks for making those changes.? One minor comment here then another comment below when you discuss the addition of check_cds_restrictions(). 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. > > Please see my comments in-line. > > On 8/25/20 7:58 AM, Lois Foltan wrote: >> >> Hi Ioi, >> >> Changes looks really good.? Comments interspersed below. >> >> Thanks, >> Lois >> >> On 8/12/2020 6:06 PM, Ioi Lam wrote: >>> Hi Lois, >>> >>> Thanks for the comments. I have an updated webrev >>> >>> http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v02/ >>> >>> http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v02.delta/ >>> >>> >>> Here are the general notes on the changes. Replies to your questions >>> are in-line below. >>> >>> (1) Integrated updates in the Java code from Alan Bateman. Here are >>> Alan's >>> ? ? notes: >>> >>> ??? The archive of the boot layer is as before, except that >>> archiving is >>> ??? skipped if there are split packages or incubator modules. >>> Incubating >>> ??? modules aren't resolved by default so we shouldn't have them in the >>> ??? boot layer by default anyway. >>> >>> ??? I've dropped the module finders from the boot layer archive. I've >>> ??? left the IllegalAccessLogger.Builder in the acrhive for now (even >>> ??? though it is not the boot layer). We should be able to remove that >>> ??? once the JEP to disallow illegal access by default is in. >>> >>> ??? Related is that I don't like the archive for the module graph >>> ??? (ArchivedModuleGraph, pre-dates this RFE) including the set of >>> ??? packages to export/open for illegal access as they aren't part >>> ??? of the module graph. I've left it for now but we can also remove >>> ??? that once we disallow illegal access by default (as those sets >>> ??? will be empty). >>> >>> ??? The archive of built-in class loaders is now in one object >>> ??? jdk.internal.loader.ArchivedClassLoaders which I think will be a >>> ??? bit more maintainable. I've also drop the ucp field from the >>> ??? AppClassLoader as the changes to BuiltinClassLoader means is no >>> ??? longer needs to duplicated. >>> >>> ??? There's one remaining issue in ModuleBootstrap.boot where it has >>> fix >>> ??? an app class loader value (ModuleLayer.CLV). Ideally the >>> initialization >>> ??? of the built-in class loaders would do this but we are kinda forced >>> ??? to separate the archiving of the built-in class loaders from the >>> boot >>> ??? layer. I might look at this again some time. >>> >>> >>> (2) Moved code from classLoaderData.cpp -> classLoaderSharedData.cpp >>> >>> (3) Reverted unnecessary changes in JavaClasses::compute_offset >>> >>> (4) Minor clean up to use QuickSort::sort() instead of qsort() >>> >>> (5) Moved the C-side of module initialization for platform/system >>> ? ? loaders to inside java.lang.System::initPhase2(), so this happens >>> ??? at the same time as without full module archiving. >>> >>> (6) Moved the use of Module_lock to so all modules in a class loader >>> ??? are restored atomically. See ArchivedClassLoaderData::restore() >>> >>> ??? This fixed a bug where test/jdk/com/sun/jdi/ModulesTest.java >>> ? ? would fail as it sees a partially restored set of modules. >>> >>> >>> >>> On 8/7/20 12:06 PM, Lois Foltan wrote: >>>> Hi Ioi, >>>> >>>> Overall looks promising.? I have some review comments below, but >>>> not a complete review.? I concentrated on the JVM side primarily >>>> how the archived module graph is read in, how the ModuleEntry and >>>> PackageEntry tables are created from the archive for the 3 builtin >>>> loaders and potential timing issues during start up. >>>> >>>> On 7/22/2020 3:36 PM, Ioi Lam wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8244778 >>>>> http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v01/ >>>>> >>>>> >>>>> Please review this patch that stores the full module graph in the CDS >>>>> archive heap. This reduces the initialization time of the basic >>>>> JVM by >>>>> about 22%: >>>>> >>>>> $ perf stat -r 100 bin/java -version >>>>> before: 98,219,329 instructions 0.03971 secs elapsed (+- 0.44%) >>>>> after:? 55,835,815 instructions 0.03109 secs elapsed (+- 0.65%) >>>>> >>>>> [1] Start with ModuleBootstrap.java. The current implementation is >>>>> ??? quite restrictive: the archived module graph is used only when no >>>>> ??? module options are specified. >>>>> >>>>> ??? See ModuleBootstrap.mayUseArchivedBootLayer(). >>>>> >>>>> ??? We can probably support options such as main module and module >>>>> path >>>>> ??? in a future RFE. >>>> >>>> Yes, I noticed the restrictions.? The JBS issue discusses the >>>> possibility of using the dumped module graph in the event that the >>>> value of the options are the same.? I think for this implementation >>>> to be viable and have a positive impact you should consider >>>> comparing at least the options --add-modules, --add-exports and >>>> --add-reads. >>> >>> I agree. I want to keep the changes minimal in this RFE, and will >>> add more support for other use cases in follow-on RFEs. Instead of >>> requiring these options to be unspecified, we can relax the >>> restriction such that these options must be the same between archive >>> dump time and run time. >> >> Sounds good! >> >>> >>>> >>>> >>>>> >>>>> [2] In the current JDK implementation, there is no single object >>>>> ??? that represents "the module graph". Most of the information >>>>> ??? is stored in the archive bootLayer object, but a few additional >>>>> ??? restoration operations need to be performed: >>>>> >>>>> ??? + See ModuleBootstrap.getArchivedBootLayer() >>>>> ??? + Some static fields need to be archived/restored in >>>>> ????? Module.java, BuiltinClassLoader.java, ClassLoaders.java >>>>> ????? and BootLoader.java >>>>> >>>>> [3] I ran into a complication with two loader instances of >>>>> ??? PlatformClassLoader and AppClassLoader. They are stored in >>>>> ??? multiple tables inside the module graph (e.g., >>>>> ??? BuiltinClassLoader$LoadedModule) so I cannot easily recreate >>>>> ??? them at runtime. >>>>> >>>>> ??? However, these two loaders contain information specific to the >>>>> ??? dump time VM lifecycle (such as the classes that were loaded >>>>> ??? during CDS dumping) that need to be scrubbed. I couldn't find an >>>>> ??? elegant way of doing this, so I added a private >>>>> "resetArchivedStates" >>>>> ??? method to a few classes. They are called inside >>>>> ??? HeapShared::reset_archived_object_states(). >>>>> >>>>> [4] Related native data structures (PackageEntry and ModuleEntry) >>>>> ??? are also archived. Start with classLoaderData.cpp >>>>> >>>>> Passes mach5 tiers 1-4. I will test with additional tiers. >>>>> >>>>> Thanks >>>>> - Ioi >>>> >>>> classfile/classLoader.cpp >>>> - line #1644 pulling the javabase_moduleEntry() check outside of >>>> the Module_lock maybe problematic if after you check it another >>>> ? thread initializes in the time between the check and the >>>> obtaining of the Module_lock on line #1645. >>> >>> Fixed. >> >> That looks good.? I think it is fine that you are checking if >> java.base is defined via a call to javabase_moduleEntry() because you >> are just trying to determine if a ModuleEntry should be created or >> not.? In most cases though using ModuleEntryTable::javabase_defined() >> is the correct way to ensure that both the ModuleEntry for java.base >> has been created and that the ModuleEntry has been injected in the >> corresponding java.lang.Module oop. >> >>> >>>> >>>> classfile/classLoader.hpp >>>> - somewhere in ArchivedClassLoaderData there should be an assert to >>>> make sure that the CLD, whose package entries and module entries >>>> are being archived is not a "_has_class_mirror_holder" CLD for a >>>> weakly defined hidden class.? Those dedicated CLDs should never >>>> have package entries or module entries. >>>> >>> >>> I added ArchivedClassLoaderData::assert_valid() >>> >>>> classfile/moduleEntry.cpp >>>> - line #400, typo "conver" --> "convert" >>>> - line #500, maybe sort if n is greater than 1 instead of 0 (same >>>> comment for packageEntry.cpp line #270) >>>> >>> Fixed >>> >>>> classfile/systemDictionary.cpp >>>> - It looks like the PackageEntry and ModuleEntry tables for the >>>> system and platform class loaders are? added within >>>> SystemDictionary::compute_java_loaders() which is called from >>>> Thread::create_vm() but after the call in Thread::create_vm() to >>>> call_initPhase2 which is when Universe::_module_initialized is set >>>> to true.? Did I read this correctly?? If yes, then I think you have >>>> to be sure that Universe::_module_initialized is not set until the >>>> module graph for the 3 builtin loaders is loaded from the archive. >>>> >>> >>> I moved the code to be called by ModuleBootstrap::boot() so it >>> should now happen inside call_initPhase2. >> >> Yes, that looks good. >> >>> >>>> memory/filemap.cpp >>>> - line #237 typo "modue" --> "module" >>>> >>> >>> Fixed >>> >>>> - Since the CDS support for capturing the module graph does not >>>> archive unnamed modules, I assume >>>> Modules::set_bootloader_unnamed_module() is still called. Is this >>>> true or does the unnamed module for the boot loader get archived? >>> The unnamed module for the boot loader is not archived. >>> >>> Modules::set_bootloader_unnamed_module()? wasn't called in my last >>> webrev. Thanks for catching it. >>> >>> I added a call to BootLoader.getUnnamedModule() in >>> ModuleBootstrap::boot()? to trigger of BootLoader, which >>> will call into the VM for Modules::set_bootloader_unnamed_module(). >> >> Looks good. >> >>> >>> >>> >>>> Clarification/timing questions: >>>> >>> >>> Here's an overall problem I am facing: >>> >>> The module graph is archived after the module system has fully >>> started up. This means that for the boot loader, we only know the >>> full set of modules/packages, but we don't know which part is the >>> subset that was initialized during early VM bootstraping (e.g., when >>> ModuleEntryTable::javabase_defined() == false). >>> >>> So the behavior is a bit different during the early bootstrap phase >>> (all the way before we reach ModuleBootstrap::boot()): >>> ClassLoaderData::the_null_class_loader_data()->modules() and >>> ClassLoaderData::the_null_class_loader_data()->packages() are >>> already populated before a single class is loaded. >> >> If this is the case then, at the point when a ModuleEntry is created >> for java.base using the archived module graph, there should be a >> assertion that java_lang_Class::_fixup_module_field_list is NULL. To >> confirm no class has been loaded before java.base is defined. Maybe >> in ClassLoaderDataShared::serialize where you restore the boot >> loader's archived modules? > > Thanks for pointing this out. It turned out that in the last webrev > (v02), I had a bug where the module of the primitive classes were not > initialized. Now I have changed the initialization code to behave the > same whether archived full module graph is used or not. The only > differences are: > > [1] ClassLoader::create_javabase(): > ModuleEntryTable::javabase_moduleEntry() may be inited by CDS. > > [2] When archived full module graph is used, > ModuleEntryTable::patch_javabase_entries is called from > Modules::define_archived_modules. > (java_lang_Class::_fixup_module_field_list is used within this call.) > > I also added a new test case: cds/PrimitiveClassMirrors.java Good test, I'm glad you added that! > >> >>> This difference doesn't seem to make a practical difference. E.g., >>> none of our code seems to assume that "before any classes in the >>> java.util package is loaded, >>> ClassLoaderData::the_null_class_loader_data()->packages() must not >>> contain an entry for java.util". >>> >>> I think we have two choices when the archived module graph is used: >>> >>> [1] We require that the state of the module system must, at every >>> step of VM initialization, be identical to that of a VM that doesn't >>> use an archived module graph. >>> >>> [2] We make sure that the VM/JDK bootstrap code can tolerate the >>> existence of module/packages that are added earlier than a VM that >>> doesn't use an archived module graph. >>> >>> I tried doing a version of [1] and found that to be too difficult. >>> [2] seems much simpler and is the approach I am using now. >> >> I think [2] is reasonable. >> >>> >>>> oops/instanceKlass.cpp >>>> - line #2545, comment "TO DO? -- point it to the archived >>>> PackageEntry (JDK-8249262)" >>>> are you thinking that since the module graph is read in ahead of >>>> time that it can be set when an InstanceKlass is created? There is >>>> a point before java.base is defined that InstanceKlass::set_package >>>> takes into account that could be a timing issue. >>>> >>>> >>> >>> I think it will work as if another class in the same package has >>> already been defined. >>> >>>> - There are some checks in modules.cpp that are valuable to have >>>> during bootstrapping.? For example, packages that are encountered >>>> during bootstrapping before java.base is defined are put into the >>>> java.base module but then verified after java.base is defined via >>>> verify_javabase_packages.? So at what point in the bootstrapping >>>> process does the boot loader's archived module's become known? >>>> Could classes have been defined to the VM before this point? Then >>>> their packages will have to be verified to be sure that they are >>>> indeed packages within java.base.? Consider looking at other checks >>>> that occur within classfile/modules.cpp as well. >>>> >>> As mentioned above, calling verify_javabase_packages() at run time >>> will fail, as we have loaded all packages for the boot loader, not >>> just those for java.base. >> >> I think not calling verify_javabase_packages works because as you >> stated above no classes have been loaded before java.base is defined >> which is not the same situation as running without the archived >> module graph. >> >> A couple of additional comments: >> >> - ModuleEntry's reads list and PackageEntry's exports list.? We had >> hoped eventually to change these lists from being a c heap allocated >> GrowableArray over to a ResourceHashTable for faster lookup.? Doing >> that as a separate RFE might help CDS archiving not to have to >> archive those lists as an Array? >> > > CDS cannot archive ResourceHashTable either. We have CompactHashtable > which can be archived, but it cannot be modified at run time. I think > the export list can be modified at run time with > java.lang.Module::addExports(), so we probably need to do it like: > > - if a Module was archived, check its CompactHashtable first > - if not found, check the ResourceHashTable > > This would make the start-up a little faster (no more copying from the > array lists into the hashtable, but would make the code more > complicated. I need to investigate to see if it's worthwhile. > >> - moduleEntry.cpp and packageEntry.cpp: Both methods >> "compare_module_by_name" and "compare_package_by_name" should have an >> assert if the names are equal.? No ModuleEntryTable or >> PackageEntryTable should ever have 2 same named modules or packages. >> > > I tried adding: > > static int compare_package_by_name(PackageEntry* a, PackageEntry* b) { > ? assert(a != b && a->name() != b->name(), "array should not contain > duplicated entries"); > ? return a->name()->fast_compare(b->name()); > } > > but this caused an assert, because our QuickSort implementation would > sometimes compare the same element! > > #7? 0x00007ffff659238b in QuickSort::partition int (*)(void const*, void const*)> (array=0x80043fcb0, > ??? pivot=248, length=496, comparator=0x7ffff6590a5a > ) > ??? at /jdk2/gil/open/src/hotspot/share/utilities/quickSort.hpp:76 > 76??? ????? for ( ; comparator(array[left_index], pivot_val) < 0; > ++left_index) { > (gdb) p array[left_index] > $1 = (PackageEntry *) 0x7ffff0439d00 > (gdb) p pivot_val > $2 = (PackageEntry *) 0x7ffff0439d00 > (gdb) p pivot > $3 = 248 > (gdb) p left_index > $4 = 248 > > So I ended up with: > > static int compare_package_by_name(PackageEntry* a, PackageEntry* b) { > ? assert(a == b || a->name() != b->name(), "no duplicated names"); > ? return a->name()->fast_compare(b->name()); > } Looks good to me! > >> - Another timing clarification question for me.? I assume that the >> module graph is dumped post module initialization when Java has >> completely defined the module graph to the JVM, is this correct? > > Yes > >> My concern is that there could be a window post module initialization >> and pre archiving the module graph where another thread could define >> a new module or add Module readability or add Package exportability.? >> So that the module graph you are dumping is not the same module graph >> at the end of module initialization.? Is this a concern? > > We don't allow arbitrary code to be executed during -Xshare:dump, so > the module graph shouldn't be changed after module initialization has > finished. > > I've added Modules::check_cds_restrictions() to check for this. 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? Thanks, Lois > > I also added asserts to make sure that none of the classes used by the > archived module graph can be modified by JVMTI. All these classes are > loaded in the "early" phase of JVMTI, and we would disable CDS if a > JVMTI agent is registered to modify classes in this phase, so we > should be safe, but the asserts will ensure that. I updated the > ReplaceCriticalClassesForSubgraphs.java test and added a new test > RedefineClassesInModuleGraph.java. > > > Thanks > - Ioi > > >> >> Thanks, >> Lois >> >>> >>> Well, verify_javabase_packages() was called once and it succeeded, >>> but that was during CDS dump time. So we know at least we have >>> verified this once :-) >>> >>> Thanks >>> - Ioi >>> >>>> I may have more review comments as I continue to look at this! >>>> >>>> Thanks, >>>> Lois >>>> >>>> >>>> >>>> >>>> >>> >> >> >> >> > From pavel.rappo at oracle.com Thu Sep 3 18:54:14 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 3 Sep 2020 19:54:14 +0100 Subject: RFR 8252538: Replace @exception with @throws java.rmi package In-Reply-To: References: <3e68fe1f-be94-8549-bc89-eb148ac3864c@oracle.com> <40f610f6-d16d-f7d0-0ff7-416b64de6dfe@oracle.com> Message-ID: <7287A60C-09CE-4F66-B737-EA71D449FDF9@oracle.com> > On 3 Sep 2020, at 18:51, Vipin Sharma wrote: > > I agree. In the next patch, I will include all remaining occurrences of > @exception in the core-libs > area. > > Also, I noticed that those files still use the markup. >> Converting them to use {@code ... } is another useful task. >> > > I will take this task. Please be careful and always build documentation to check that it looks the way you think it looks. -Pavel From vipinsharma85 at gmail.com Thu Sep 3 19:33:33 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Fri, 4 Sep 2020 01:03:33 +0530 Subject: RFR 8252537: Replace @exception with @throws for core-libs Message-ID: Hi, Please review and sponsor the fix for replacing @exception with @throws for core-libs. Issue: https://bugs.openjdk.java.net/browse/JDK-8252537 Webrev: https://cr.openjdk.java.net/~vsharma/8252537 As suggested in the previous discussion , this webrev has a consolidated fix for all subtasks of the JDK-8252536 . There is no change in the indentation as part of this webrev. Regards, Vipin From LANCE.ANDERSEN at ORACLE.COM Thu Sep 3 19:41:11 2020 From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen) Date: Thu, 3 Sep 2020 15:41:11 -0400 Subject: RFR 8252537: Replace @exception with @throws for core-libs In-Reply-To: References: Message-ID: <6875F1B9-F3C6-4A28-A941-F97979A4D0AD@ORACLE.COM> Hi Vipin I can sponsor once the review is complete as a vast majority are in java.sql I will look at this tomorrow > On Sep 3, 2020, at 3:33 PM, Vipin Sharma wrote: > > Hi, > > Please review and sponsor the fix for replacing @exception with @throws for > core-libs. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8252537 > Webrev: https://cr.openjdk.java.net/~vsharma/8252537 > > As suggested in the previous discussion > , > this webrev has a consolidated fix for all subtasks of the JDK-8252536 > . > There is no change in the indentation as part of this webrev. > > Regards, > Vipin Best Lance ------------------ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From martinrb at google.com Thu Sep 3 19:44:27 2020 From: martinrb at google.com (Martin Buchholz) Date: Thu, 3 Sep 2020 12:44:27 -0700 Subject: RFR 8252537: Replace @exception with @throws for core-libs In-Reply-To: References: Message-ID: Thanks for doing this! 15 years ago I considered taking on this task, eventually backing away because it was too much work (!). But I made sure most of the classes I maintained were using @throws. When considering this, I thought that tidying the whitespace after conversion would be a big part of the task, even though it is technically non-essential. Current use of whitespace with @throws is inconsistent, as you have seen. On Thu, Sep 3, 2020 at 12:34 PM Vipin Sharma wrote: > > Hi, > > Please review and sponsor the fix for replacing @exception with @throws for > core-libs. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8252537 > Webrev: https://cr.openjdk.java.net/~vsharma/8252537 > > As suggested in the previous discussion > , > this webrev has a consolidated fix for all subtasks of the JDK-8252536 > . > There is no change in the indentation as part of this webrev. > > Regards, > Vipin From Roger.Riggs at oracle.com Thu Sep 3 20:13:49 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 3 Sep 2020 16:13:49 -0400 Subject: RFR 8251989: Hex formatting and parsing In-Reply-To: <935FDA14-123E-4048-A43D-60E7A7E68F4F@oracle.com> References: <935FDA14-123E-4048-A43D-60E7A7E68F4F@oracle.com> Message-ID: <7135b593-e48e-6931-4577-eb4350e51fd9@oracle.com> Hi Douglas, I think you answered your own question at the outset. (with the API as it stands). Are there current hex formatting in code you are aware of that already uses prefixes or suffixes on each byte? I'm evauating whether there is consensus to change the semantics of prefix and suffix. Thanks, Roger On 9/2/20 6:12 PM, Douglas Surber wrote: > I still want to know how to format a byte sequence where each byte has a prefix (or suffix). > > Eg. > > { 0x00, 0x01, 0x02, 0xOD, 0x0E, 0x0F } > > Douglas > >> On Sep 2, 2020, at 2:26 PM, core-libs-dev-request at openjdk.java.net wrote: >> >> Date: Wed, 2 Sep 2020 16:26:07 -0400 >> From: Roger Riggs > >> To: core-libs-dev > >> Subject: RFR 8251989: Hex formatting and parsing >> Message-ID: <180eca84-19fe-2dc4-9e57-1d05328e1c7b at oracle.com > >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> Please review the updated API in the Javadoc. >> http://cr.openjdk.java.net/~rriggs/hex-formatter/java.base/java/util/Hex.html >> >> A few offline contacts encouaged me to explore expanding the support >> for formatting and parsing of primitive types. >> Adding formatting toHex methods and [arsing fromHex methods makes the >> API easier to use. >> >> For example, there are a number of protocols that need to escape char >> values >> as hex. For symmetry across the primitive types, byte, char, short, int, >> and long >> methods are added. >> >> The handling of invalid digits was changed to consistently throw >> IllegalArgumentException; it is unlikely that encoding and decoding >> run into invalid characters and the previous technique requiring the caller >> to check the value for negative numbers is error prone. >> >> There is some danger of proliferating methods yet, so not all combinations >> are included.? Feedback welcome. >> >> With the API still shifting, the implemention is not ready to review. >> >> Thanks, Roger >> From raffaello.giulietti at gmail.com Thu Sep 3 20:27:16 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 3 Sep 2020 22:27:16 +0200 Subject: RFR 8251989: Hex formatting and parsing Message-ID: Hi Roger, In Formatter (1) The javadoc reads: "Returns up to sixteen [...]" rather than "Returns sixteen [...]", similar to the other toHex() methods. (2) equals() and hashCode() are missing. In Parser (1) In methods fromHex(), isHex(), xxxFromHex(), you probably meant "static" rather than "final" ;-) (2) In the javadoc for isHex() please use "non negative" or ">= 0", as "positive" means > 0 to most ears. (3) equals() and hashCode() are missing. Greetings Raffaello > Please review the updated API in the Javadoc. > http://cr.openjdk.java.net/~rriggs/hex-formatter/java.base/java/util/Hex.html > > A few offline contacts encouaged me to explore expanding the support > for formatting and parsing of primitive types. > Adding formatting toHex methods and [arsing fromHex methods makes the > API easier to use. > > For example, there are a number of protocols that need to escape char > values > as hex. For symmetry across the primitive types, byte, char, short, int, > and long > methods are added. > > The handling of invalid digits was changed to consistently throw > IllegalArgumentException; it is unlikely that encoding and decoding > run into invalid characters and the previous technique requiring the caller > to check the value for negative numbers is error prone. > > There is some danger of proliferating methods yet, so not all combinations > are included. Feedback welcome. > > With the API still shifting, the implemention is not ready to review. > > Thanks, Roger From mik3hall at gmail.com Thu Sep 3 21:23:53 2020 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 3 Sep 2020 16:23:53 -0500 Subject: jpackage: support for environment variables in --java-options In-Reply-To: <5E152EC2-3A98-4023-A0CB-D23FB381B1EC@gmail.com> References: <084B8AE1-1E40-4DF2-AD97-42104827F067@gmail.com> <78534E85-893A-4B5E-B85B-BE654397EED3@gmail.com> <3BC2E4B4-7195-4DC9-B7A5-7AB18E14A304@gmail.com> <558005DB-CB86-469D-96AD-22C3383091BE@gmail.com> <686F7844-D682-45E3-B235-828D0D78491C@gmail.com> <5E152EC2-3A98-4023-A0CB-D23FB381B1EC@gmail.com> Message-ID: <3553FB95-6B8C-49DC-B656-B4C2A3E4FE4D@gmail.com> >> >> This is not how I?ve done it before. I did a little googling and it seemed to indicate launchctl could somehow be used for ?global? environment variables. It didn?t sound application specific. > > Right it isn?t application specific. If you need a separate environment for your application, that wouldn?t work. But if you are passing parameters that are specific to the application launcher, why use environment variables at all? See my prior examples of usage. Basically because other code requires the environment variables to be there. > > >> The incident mentioned earlier showed a resolution of having the user provide their own custom Info.plist. > > Just use a config file that can be platform independent. Modifying the Info.plist for each specific install smells wrong. Because modifying the Info.plist is only way to do it. To the incident https://bugs.openjdk.java.net/browse/JDK-8233175 Doing some testing with plistbuddy it does seem to work following the resolution. It appears to even work without following the resolution. Possibly though that might break signed applications. Following the resolution I took the Info.plist from a application and put it into a template/ directory. Then doing? cp template/Info.plist resources/Info.plist /usr/libexec/plistbuddy -c 'Add:NSRequiresAquaSystemAppearance bool false' resources/Info.plist And including this on the jpackage invocation? --resource-dir resources \ We get? /usr/libexec/plistbuddy -c print outputdir/HalfPipe.app/Contents/Info.plist Dict { CFBundleName = HalfPipe CFBundleIdentifier = us.hall.HalfPipe CFBundleInfoDictionaryVersion = 6.0 LSApplicationCategoryType = Unknown CFBundleVersion = 1.0 CFBundleExecutable = HalfPipe CFBundleAllowMixedLocalizations = true NSHighResolutionCapable = true CFBundlePackageType = APPL CFBundleIconFile = HalfPipe.icns CFBundleSignature = ???? NSRequiresAquaSystemAppearance = false LSMinimumSystemVersion = 10.9 CFBundleDevelopmentRegion = English NSHumanReadableCopyright = Copyright (C) 2020 CFBundleShortVersionString = 1.0 } Including the incident mentioned NSRequiresAquaSystemAppearance. Setting it off appears to be about the only reason you would want to include the plist entry. As I said this will also work by just directly working with the application Info.plist, at least as long as the application is unsigned. I don?t know if it would invalidate a signed signature. Probably best if it did, then the ?resource-dir would be needed. For environment variables I checked my manual changes with the application where I can ?exec env? and they seemed set correctly. So I?m not sure yet what actual difference between shell invoked and Finder invoked is the issue. Possibly not that I have the environment variables wrong. So. If anyone actually wants to update the plist as part of the build plistbuddy seems a valid way to go. Doing this one time up front and assuming the plist never changes would be another. Xcode provides an editor if you only have to do a one time change and want to do that manually. plistbuddy almost seems a way jpackage could provide the functionality itself at some point fairly easily? It was included on my machine although I?m not sure how officially Apple supports it. Xcode native app developers do seem to use it in their builds so you would think it would not casually disappear. You might consider it sometime. From jptatton at amazon.com Thu Sep 3 21:28:56 2020 From: jptatton at amazon.com (Tatton, Jason) Date: Thu, 3 Sep 2020 21:28:56 +0000 Subject: JDK-8173585: Intrinsify StringLatin1.indexOf(char) Message-ID: <0cbe7d8f594349b59504c42f89c6f268@EX13D46EUB003.ant.amazon.com> Hi All, Please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8173585 http://cr.openjdk.java.net/~phh/8173585/webrev.00/ This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and java/lang/StringLatin1.java Details of testing: ============== I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the input String. Hence the test has been designed to cover all these cases. In summary they are: ? A ?short? string of < 16 characters. ? A SIMD String of 16 ? 31 characters. ? A AVX2 SIMD String of 32 characters+. Hardware used for testing: ------------------------------------ ? Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). ? AWS Graviton 2 (ARM 64 processor). I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. Possible future enhancements: ========================= For the x86 implementation there may be two further improvements we can make in order to improve performance of both the StringUTF16 and StringLatin1 indexOf(char) intrinsics: 1. Make use of AVX-512 instructions. 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD instructions instead of a loop. JMH Benchmark results: ==================== The benchmarks examine the 3 codepaths for StringLatin1 and StringUTF16. Here are the results for Intel x86 (ARM is similar): FYI, String lengths in characters (1byte for Latin1, 2bytes for UTF16): ?????? Latin1? UTF16 Short: 15?????? 7 SSE4:? 16?????? 8 AVX2:? 32?????? 16 Without StringLatin1 indexofchar intrinsic: Benchmark????????????????????????????? Mode? Cnt?????? Score????? Error? Units IndexOfBenchmark.latin1_AVX2_String?? thrpt??? 5? 121781.424 ? 355.085? ops/s IndexOfBenchmark.latin1_AVX2_char???? thrpt ???5?? 46060.612 ? 151.274? ops/s IndexOfBenchmark.latin1_SSE4_String?? thrpt??? 5? 197339.146 ?? 90.333? ops/s IndexOfBenchmark.latin1_SSE4_char???? thrpt??? 5?? 61401.204 ? 426.761? ops/s IndexOfBenchmark.latin1_Short_String? thrpt??? 5? 175389.355 ? 294.976? ops/s IndexOfBenchmark.latin1_Short_char??? thrpt??? 5?? 60759.868 ? 124.349? ops/s IndexOfBenchmark.utf16_AVX2_String??? thrpt??? 5? 123601.020 ? 111.981? ops/s IndexOfBenchmark.utf16_AVX2_char????? thrpt??? 5? 141116.832 ? 380.489? ops/s IndexOfBenchmark.utf16_SSE4_String??? thrpt??? 5? 178136.762 ? 143.227? ops/s IndexOfBenchmark.utf16_SSE4_char????? thrpt??? 5? 181430.649 ? 120.097? ops/s IndexOfBenchmark.utf16_Short_String?? thrpt??? 5? 158301.361 ? 182.738? ops/s IndexOfBenchmark.utf16_Short_char???? thrpt??? 5?? 84876.919 ? 247.769? ops/s With StringLatin1 indexofchar intrinsic: Benchmark????????????????????????????? Mode? Cnt?????? Score????? Error? Units IndexOfBenchmark.latin1_AVX2_String?? thrpt??? 5? 113621.676 ??? 68.235? ops/s IndexOfBenchmark.latin1_AVX2_char???? thrpt??? 5? 177757.909 ?? 727.308? ops/s IndexOfBenchmark.latin1_SSE4_String?? thrpt??? 5? 180529.049 ??? 57.356? ops/s IndexOfBenchmark.latin1_SSE4_char???? thrpt??? 5? 235087.776 ?? 457.024? ops/s IndexOfBenchmark.latin1_Short_String? thrpt??? 5? 165914.990 ?? 329.024? ops/s IndexOfBenchmark.latin1_Short_char??? thrpt??? 5?? 53989.544 ??? 65.393? ops/s IndexOfBenchmark.utf16_AVX2_String??? thrpt??? 5? 107632.783 ?? 446.272? ops/s IndexOfBenchmark.utf16_AVX2_char????? thrpt??? 5? 143131.734 ?? 159.944? ops/s IndexOfBenchmark.utf16_SSE4_String??? thrpt??? 5? 169882.703 ? 1024.367? ops/s IndexOfBenchmark.utf16_SSE4_char????? thrpt??? 5? 175693.972 ?? 775.423? ops/s IndexOfBenchmark.utf16_Short_String?? thrpt??? 5? 163595.993 ?? 225.089? ops/s IndexOfBenchmark.utf16_Short_char???? thrpt??? 5?? 90126.154 ?? 365.642? ops/s We can see above that indexOf(char) now behaves similarly between StringUTF16 and StringLatin1. JMH benchmark code: ------------------------------ package?org.sample; import?java.util.Random; import?org.openjdk.jmh.annotations.Benchmark; import?org.openjdk.jmh.annotations.Scope; import?org.openjdk.jmh.annotations.State; @State(Scope.Thread) public?class?IndexOfBenchmark?{ ????private?static?final?int?loops?=?100000; ????private?static?final?Random?rng?=?new?Random(1999); ????private?static?final?int?pathCnt?=?1000; ????private?static?final?String?[]?latn1_short?=?new?String[pathCnt]; ????private?static?final?String?[]?latn1_sse4??=?new?String[pathCnt]; ????private?static?final?String?[]?latn1_avx2??=?new?String[pathCnt]; ????private?static?final?String?[]?utf16_short?=?new?String[pathCnt]; ????private?static?final?String?[]?utf16_sse4??=?new?String[pathCnt]; ????private?static?final?String?[]?utf16_avx2??=?new?String[pathCnt]; ????static?{ ????????for?(int?i?=?0;?i? References: Message-ID: <2222AF5A-1EFB-418D-9ABF-066E47104EEF@oracle.com> > Are there current hex formatting in code you are aware of that already uses > prefixes or suffixes on each byte? > Java. My example. > { 0x00, 0x01, 0x02, 0xOD, 0x0E, 0x0F } Douglas > On Sep 3, 2020, at 2:24 PM, core-libs-dev-request at openjdk.java.net wrote: > > Date: Thu, 3 Sep 2020 16:13:49 -0400 > From: Roger Riggs > > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR 8251989: Hex formatting and parsing > Message-ID: <7135b593-e48e-6931-4577-eb4350e51fd9 at oracle.com > > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi Douglas, > > I think you answered your own question at the outset. (with the API as > it stands). > > Are there current hex formatting in code you are aware of that already uses > prefixes or suffixes on each byte? > > I'm evauating whether there is consensus to change the semantics of > prefix and suffix. > > Thanks, Roger > > From yumin.qi at oracle.com Thu Sep 3 22:11:39 2020 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 3 Sep 2020 15:11:39 -0700 Subject: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code In-Reply-To: <4be47e30-aa69-7db0-ff04-f2d379fb8b38@oracle.com> References: <4be47e30-aa69-7db0-ff04-f2d379fb8b38@oracle.com> Message-ID: HI, Mandy ? Thanks for review and comment. Yumin On 9/3/20 9:13 AM, Mandy Chung wrote: > > > On 9/3/20 8:36 AM, Yumin Qi wrote: >> Hi, Please review >> >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8252725 >> >> webrev: http://cr.openjdk.java.net/~minqi/2020/8252725/webrev-01/ >> > > Looks good to me.?? Sundar should also review it. > > A few things to mention compared to the proposed patch from 8247536:? we no longer log the error case for LF_RESOLVE since it's ignored anyway.? As the code is moved to java.lang.invoke, we also clean up the code to use constants and methods defined in LambdaForm and MethodTypeForm and BasicType (rather than duplicating such definitions). > > Mandy >> >> Summary: The work is part of 8247536, which supports archive pre-generated java.lang.invoke classes in CDS. In this patch (thanks to Mandy): >> >> 1. Two methods for tracing SPECIES_RESOLVE and LF_RESOLVE are added to GenerateJLIClassesHelper: traceSpeciesType and traceLambdaForm respectively; >> >> 2. Move log file parsing work to java.lang.InvokeJLIClassesHelper; >> >> 3. Clean up interface APIs since old APIs no longer used with the moving; >> >> 4. New API JavaLangInvokeAccess::generateHolderClassesreturns a map of class name, which in internal form as key rather than the jimage entry point, vs class bytes. >> >> This makes both JLI and CDS can use the new interface easily. CDS will add a new function (in 8247536 patch, only for convenience for converting the map to array) to GenerateJLIClassesHelper to call the new added interface API (generateHolderClasses)to regenerate holder classes during dump time. >> >> >> Thanks >> >> Yumin >> >> > From joe.darcy at oracle.com Thu Sep 3 22:32:53 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 3 Sep 2020 15:32:53 -0700 Subject: RFR 8214761 : Bug in parallel Kahan summation implementation In-Reply-To: References: <6fb0565c-81cd-07fa-1c4f-fdf406b75f25@oracle.com> Message-ID: <1cc6eb2c-3ed7-f683-18a1-c40efd9e8f7f@oracle.com> Hello, Thanks for the nudge; I'll get to this sometime after the Skara transition for jdk/jdk. Cheers, -Joe On 9/3/2020 9:29 AM, Chris Dennis wrote: > In case there is a need for extra motivation here: > > import java.util.stream.DoubleStream; > > public class Test8214761 { > public static void main(String[] args) { > double a = Double.valueOf(args[0]); > if (Math.ulp(a) <= Math.ulp(Math.nextAfter(a, 0))) { > System.out.println("Stable addition"); > } else { > double b = Math.signum(a) * Math.ulp(a) / 2; > > double sum = a + b; > double streamSum = DoubleStream.of(a, b).sum(); > > System.out.println(a + " + " + b + "\n => " + sum); > System.out.println("DoubleStream.of(" + a + ", " + b + ").sum()\n => " + streamSum); > } > } > } > > $ java -showversion Test8214761 1 > openjdk version "16-internal" 2021-03-16 > OpenJDK Runtime Environment (build 16-internal+0-cdennis.0178d0f136e9) > OpenJDK 64-Bit Server VM (build 16-internal+0-cdennis.0178d0f136e9, mixed mode, sharing) > 1.0 + 1.1102230246251565E-16 > => 1.0 > DoubleStream.of(1.0, 1.1102230246251565E-16).sum() > => 0.9999999999999999 > > That's the sum of two positive doubles returning a result smaller than one of the two. > > Apologies for the zeal, > > Chris > > ?On 8/27/20, 10:52 AM, "Chris Dennis" wrote: > > Bump... > > I've run in to this while running tests that check computation results against the expected bounds of a Kahan summation. Any chance that this gets picked up in the near future? > > Thanks, > > Chris > > ?On 12/13/18, 6:16 PM, "core-libs-dev on behalf of Ivan Gerasimov" wrote: > > Gentle ping. > > > On 12/9/18 7:37 PM, Ivan Gerasimov wrote: > > Hello! > > > > DoubleSummaryStatistics takes advantage of Kahan summation algorithm > > to reduce the error of the total sum. > > > > Internally it maintains a field double sumCompensation, which keeps > > lower bits (which were rounded off) of the last addition. > > > > Note, that the compensation has to be subtracted from the result to > > add those bits back: > > > > 166 private void sumWithCompensation(double value) { > > 167 double tmp = value - sumCompensation; > > 168 double velvel = sum + tmp; // Little wolf of rounding error > > 169 sumCompensation = (velvel - sum) - tmp; > > 170 sum = velvel; > > 171 } > > > > At the line 169, tmp normally has more lower bits than (velvel - sum). > > > > However, when two DoubleSummaryStatistics objects are combined, this > > compensation part is *added* to the total, which may result in a less > > accurate result. > > > > The same bug is replicated in DoubleStreams. > > > > Would you please help review the fix? > > > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8214761 > > WEBREV: http://cr.openjdk.java.net/~igerasim/8214761/00/webrev/ > > > > -- > With kind regards, > Ivan Gerasimov > From jiefu at tencent.com Thu Sep 3 23:45:00 2020 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Thu, 3 Sep 2020 23:45:00 +0000 Subject: RFR: 8252740: java/util/Properties/LoadAndStoreXMLWithDefaults.java fails after JDK-8252354(Internet mail) Message-ID: <35BA6672-FF50-4FEE-92C5-3B25D8F2AA98@tencent.com> Thanks Joe for your review. Pushed. Best regards, Jie ?On 2020/9/4, 12:18 AM, "Joe Wang" wrote: On 9/3/20 2:51 AM, Alan Bateman wrote: > On 03/09/2020 10:22, jiefu(??) wrote: >> Hi all, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8252740 >> Webrev: http://cr.openjdk.java.net/~jiefu/8252740/webrev.00/ >> >> After JDK-8252354, properties whose keys or values are none strings >> won't be skipped any more. >> Instead, ClassCastException will be thrown. >> > Looks like the update to the test is missing from changes for > JDK-8252354. Your change looks okay but I don't understand why this > wasn't caught, maybe the test change was in Joe's changes that he tested? My bad, needed more coffee. I got too used to my routine test script that covers java.xml, and a bit too eager to get the fix in before the transition to Git. The change looks good to me as well. -Joe > > -Alan From sundararajan.athijegannathan at oracle.com Fri Sep 4 01:34:29 2020 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 4 Sep 2020 07:04:29 +0530 Subject: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code In-Reply-To: References: <4be47e30-aa69-7db0-ff04-f2d379fb8b38@oracle.com> Message-ID: <1face782-cc07-dfad-35c9-3247e556827c@oracle.com> Looks good to me. Few minor comment: * traceFileStream (and even the preexisting mainArgument) is accessed only inside GenerateJLIClassesPlugin. Could be private? -Sundar On 04/09/20 3:41 am, Yumin Qi wrote: > HI, Mandy > > ? Thanks for review and comment. > > > Yumin > > On 9/3/20 9:13 AM, Mandy Chung wrote: >> >> >> On 9/3/20 8:36 AM, Yumin Qi wrote: >>> Hi, Please review >>> >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8252725 >>> >>> webrev: http://cr.openjdk.java.net/~minqi/2020/8252725/webrev-01/ >>> >> >> Looks good to me.?? Sundar should also review it. >> >> A few things to mention compared to the proposed patch from 8247536:? >> we no longer log the error case for LF_RESOLVE since it's ignored >> anyway.? As the code is moved to java.lang.invoke, we also clean up >> the code to use constants and methods defined in LambdaForm and >> MethodTypeForm and BasicType (rather than duplicating such definitions). >> >> Mandy >>> >>> Summary: The work is part of 8247536, which supports archive >>> pre-generated java.lang.invoke classes in CDS. In this patch (thanks >>> to Mandy): >>> >>> 1. Two methods for tracing SPECIES_RESOLVE and LF_RESOLVE are added >>> to GenerateJLIClassesHelper: traceSpeciesType and traceLambdaForm >>> respectively; >>> >>> 2. Move log file parsing work to java.lang.InvokeJLIClassesHelper; >>> >>> 3. Clean up interface APIs since old APIs no longer used with the >>> moving; >>> >>> 4. New API JavaLangInvokeAccess::generateHolderClassesreturns a map >>> of class name, which in internal form as key rather than the jimage >>> entry point, vs class bytes. >>> >>> This makes both JLI and CDS can use the new interface easily. CDS >>> will add a new function (in 8247536 patch, only for convenience for >>> converting the map to array) to GenerateJLIClassesHelper to call the >>> new added interface API (generateHolderClasses)to regenerate holder >>> classes during dump time. >>> >>> >>> Thanks >>> >>> Yumin >>> >>> >> From yumin.qi at oracle.com Fri Sep 4 04:37:53 2020 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 3 Sep 2020 21:37:53 -0700 Subject: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code In-Reply-To: <1face782-cc07-dfad-35c9-3247e556827c@oracle.com> References: <4be47e30-aa69-7db0-ff04-f2d379fb8b38@oracle.com> <1face782-cc07-dfad-35c9-3247e556827c@oracle.com> Message-ID: <6a4bbb92-7e6a-f037-a2dd-220aba9c6374@oracle.com> HI, Sundar ? Thanks for review. On 9/3/20 6:34 PM, sundararajan.athijegannathan at oracle.com wrote: > Looks good to me. > > Few minor comment: > > * traceFileStream (and even the preexisting mainArgument) is accessed only inside GenerateJLIClassesPlugin. Could be private? > I will fix them before push. (Certainly will build first to verify that). Thanks Yumin > -Sundar > > On 04/09/20 3:41 am, Yumin Qi wrote: >> HI, Mandy >> >> ? Thanks for review and comment. >> >> >> Yumin >> >> On 9/3/20 9:13 AM, Mandy Chung wrote: >>> >>> >>> On 9/3/20 8:36 AM, Yumin Qi wrote: >>>> Hi, Please review >>>> >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8252725 >>>> >>>> webrev: http://cr.openjdk.java.net/~minqi/2020/8252725/webrev-01/ >>>> >>> >>> Looks good to me.?? Sundar should also review it. >>> >>> A few things to mention compared to the proposed patch from 8247536:? we no longer log the error case for LF_RESOLVE since it's ignored anyway.? As the code is moved to java.lang.invoke, we also clean up the code to use constants and methods defined in LambdaForm and MethodTypeForm and BasicType (rather than duplicating such definitions). >>> >>> Mandy >>>> >>>> Summary: The work is part of 8247536, which supports archive pre-generated java.lang.invoke classes in CDS. In this patch (thanks to Mandy): >>>> >>>> 1. Two methods for tracing SPECIES_RESOLVE and LF_RESOLVE are added to GenerateJLIClassesHelper: traceSpeciesType and traceLambdaForm respectively; >>>> >>>> 2. Move log file parsing work to java.lang.InvokeJLIClassesHelper; >>>> >>>> 3. Clean up interface APIs since old APIs no longer used with the moving; >>>> >>>> 4. New API JavaLangInvokeAccess::generateHolderClassesreturns a map of class name, which in internal form as key rather than the jimage entry point, vs class bytes. >>>> >>>> This makes both JLI and CDS can use the new interface easily. CDS will add a new function (in 8247536 patch, only for convenience for converting the map to array) to GenerateJLIClassesHelper to call the new added interface API (generateHolderClasses)to regenerate holder classes during dump time. >>>> >>>> >>>> Thanks >>>> >>>> Yumin >>>> >>>> >>> 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 pavel.rappo at oracle.com Fri Sep 4 08:52:34 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 4 Sep 2020 09:52:34 +0100 Subject: RFR 8252537: Replace @exception with @throws for core-libs In-Reply-To: References: Message-ID: It would be nice to compare documentation HTML files generated before and after that patch: there's a possibility of non-local consequences, see JDK-6509045. -Pavel > On 3 Sep 2020, at 20:33, Vipin Sharma wrote: > > Hi, > > Please review and sponsor the fix for replacing @exception with @throws for > core-libs. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8252537 > Webrev: https://cr.openjdk.java.net/~vsharma/8252537 > > As suggested in the previous discussion > , > this webrev has a consolidated fix for all subtasks of the JDK-8252536 > . > There is no change in the indentation as part of this webrev. > > Regards, > Vipin From pavel.rappo at oracle.com Fri Sep 4 08:57:29 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 4 Sep 2020 09:57:29 +0100 Subject: RFR 8252537: Replace @exception with @throws for core-libs In-Reply-To: References: Message-ID: Oops, wrong issue number. Here's the correct one: JDK-8157682. > On 4 Sep 2020, at 09:52, Pavel Rappo wrote: > > It would be nice to compare documentation HTML files generated before and after that patch: there's a possibility of non-local consequences, see JDK-6509045. > > -Pavel > >> On 3 Sep 2020, at 20:33, Vipin Sharma wrote: >> >> Hi, >> >> Please review and sponsor the fix for replacing @exception with @throws for >> core-libs. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8252537 >> Webrev: https://cr.openjdk.java.net/~vsharma/8252537 >> >> As suggested in the previous discussion >> , >> this webrev has a consolidated fix for all subtasks of the JDK-8252536 >> . >> There is no change in the indentation as part of this webrev. >> >> Regards, >> Vipin > 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 Alan.Bateman at oracle.com Fri Sep 4 09:10:07 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Sep 2020 10:10:07 +0100 Subject: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code In-Reply-To: <6a4bbb92-7e6a-f037-a2dd-220aba9c6374@oracle.com> References: <4be47e30-aa69-7db0-ff04-f2d379fb8b38@oracle.com> <1face782-cc07-dfad-35c9-3247e556827c@oracle.com> <6a4bbb92-7e6a-f037-a2dd-220aba9c6374@oracle.com> Message-ID: <0eab9ecd-50f7-f91d-06af-e526b193826f@oracle.com> On 04/09/2020 05:37, Yumin Qi wrote: > HI, Sundar > > ? Thanks for review. > > On 9/3/20 6:34 PM, sundararajan.athijegannathan at oracle.com wrote: >> Looks good to me. >> >> Few minor comment: >> >> * traceFileStream (and even the preexisting mainArgument) is accessed >> only inside GenerateJLIClassesPlugin. Could be private? >> > I will fix them before push. (Certainly will build first to verify that). I went through the refactoring of the jlink plugin and I think it looks good too. -Alan. From fweimer at redhat.com Fri Sep 4 11:50:55 2020 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 04 Sep 2020 13:50:55 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: (Daniel Fuchs's message of "Wed, 2 Sep 2020 10:26:29 +0100") References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> Message-ID: <87sgbxhiao.fsf@oldenburg2.str.redhat.com> * Daniel Fuchs: > Hi, > > On 02/09/2020 08:19, Florian Weimer wrote: >> At least one of the bugs was in theory user-visible: the network >> interface code would return data for an interface that does not actually >> exist on the system. > > WRT NetworkInterface.c, I might support using `strnlen` to check > the length before hand, if that solves both cases (gcc8 and gcc10). > I'm always a bit nervous of changing the behavior in this library > as it's hard to verify that no regression is introduced. I think you should use strlen. If the string is longer than the buffer sent to the kernel, it cannot match an existing interface because all the names are shorter. So some sort of ?not found? error needs to reported. (I assume that it's actually a bug that you can look up a network interface by a name that merely shares the same prefix with an actual interface on the system.) Thanks, Florian 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 sergei.tsypanov at yandex.ru Fri Sep 4 12:52:32 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 04 Sep 2020 14:52:32 +0200 Subject: [PATCH] Allocate uninitialized byte[] to improve performance of String-related operations Message-ID: <169211599221862@mail.yandex.ru> Hello, currently jdk.internal.misc.Unsafe declares method allocateUninitializedArray(Class, int) returning uninitialized array of given type and length. Allocation of uninitialized arrays is faster especially for larger ones, so we could use them for cases when we are sure that created array will be completely overwritten or is guarded by count field (e.g. in AbstractStringBuilder). I've exposed jdk.internal.misc.Unsafe.allocateUninitializedArray(Class, int) via delegating method of sun.misc.Unsafe to measure creation of byte[] with benchmark [1] and got those results: (length) Mode Cnt Score Error Units constructor 0 avgt 50 7.639 ? 0.629 ns/op constructor 10 avgt 50 9.448 ? 0.725 ns/op constructor 100 avgt 50 21.158 ? 1.865 ns/op constructor 1000 avgt 50 146.158 ? 9.836 ns/op constructor 10000 avgt 50 916.321 ? 50.618 ns/op unsafe 0 avgt 50 8.057 ? 0.599 ns/op unsafe 10 avgt 50 8.308 ? 0.907 ns/op unsafe 100 avgt 50 12.232 ? 1.813 ns/op unsafe 1000 avgt 50 37.679 ? 1.382 ns/op unsafe 10000 avgt 50 78.896 ? 6.758 ns/op As a result I propose to add the following methods into StringConcatHelper @ForceInline static byte[] newArray(int length) { return (byte[]) UNSAFE.allocateUninitializedArray(byte.class, length); } @ForceInline static char[] newCharArray(int length) { return (char[]) UNSAFE.allocateUninitializedArray(char.class, length); } along with existing StringConcatHelper.newArray(long indexCoder) and utilize them in String-related operations instead of conventional array creation with new-keyword. I've used benchmark [2] to measure impact on affected String-methods and found quite a good improvement: before after Benchmark (length) Score Error Score Error Units newStringBuilderWithLength 8 8.288 ? 0.411 5.656 ? 0.019 ns/op newStringBuilderWithLength 64 12.954 ? 0.687 7.588 ? 0.009 ns/op newStringBuilderWithLength 128 20.603 ? 0.412 10.446 ? 0.005 ns/op newStringBuilderWithLength 1024 119.935 ? 2.383 35.452 ? 0.029 ns/op newStringBuilderWithString 8 19.721 ? 0.375 14.642 ? 0.052 ns/op newStringBuilderWithString 64 34.006 ? 1.523 15.479 ? 0.031 ns/op newStringBuilderWithString 128 36.697 ? 0.972 17.052 ? 0.133 ns/op newStringBuilderWithString 1024 140.486 ? 6.396 85.156 ? 0.175 ns/op repeatOneByteString 8 11.340 ? 0.197 9.736 ? 0.051 ns/op repeatOneByteString 64 20.859 ? 0.257 15.073 ? 0.024 ns/op repeatOneByteString 128 36.311 ? 1.162 22.808 ? 0.198 ns/op repeatOneByteString 1024 149.243 ? 3.083 82.839 ? 0.193 ns/op repeatOneChar 8 28.033 ? 0.615 20.377 ? 0.137 ns/op repeatOneChar 64 56.399 ? 1.094 36.230 ? 0.051 ns/op repeatOneChar 128 68.423 ? 5.647 44.157 ? 0.239 ns/op repeatOneChar 1024 230.115 ? 0.312 179.126 ? 0.437 ns/op replace 8 14.684 ? 0.088 14.434 ? 0.057 ns/op replace 64 56.811 ? 0.612 56.420 ? 0.050 ns/op replace 128 112.694 ? 0.404 109.799 ? 1.202 ns/op replace 1024 837.939 ? 0.855 818.802 ? 0.408 ns/op replaceUtf 8 17.802 ? 0.074 15.744 ? 0.094 ns/op replaceUtf 64 45.754 ? 0.139 39.228 ? 0.864 ns/op replaceUtf 128 67.170 ? 0.353 50.497 ? 1.218 ns/op replaceUtf 1024 415.767 ? 6.829 297.831 ? 22.510 ns/op toCharArray 8 6.164 ? 0.033 6.128 ? 0.064 ns/op toCharArray 64 10.960 ? 0.032 13.566 ? 0.802 ns/op toCharArray 128 20.373 ? 0.013 20.823 ? 0.376 ns/op toCharArray 1024 165.923 ? 0.098 164.362 ? 0.065 ns/op toCharArrayUTF 8 8.009 ? 0.067 7.778 ? 0.026 ns/op toCharArrayUTF 64 11.112 ? 0.014 10.880 ? 0.010 ns/op toCharArrayUTF 128 20.390 ? 0.014 20.103 ? 0.017 ns/op toCharArrayUTF 1024 166.233 ? 0.076 163.827 ? 0.099 ns/op So the question is could we include the changes of attached patch into JDK? With best regards, Sergey Tsypanov 1. Benchmark for array-allocation @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class ArrayAllocationBenchmark { private static Unsafe U; static { try { Field f = Unsafe.class.getDeclaredField("theUnsafe"); f.setAccessible(true); U = (Unsafe) f.get(null); } catch (Exception e) { new RuntimeException(e); } } @Benchmark public byte[] constructor(Data data) { return new byte[data.length]; } @Benchmark public byte[] unsafe(Data data) { return (byte[]) U.allocateUninitializedArray(byte.class, data.length); } @State(Scope.Thread) public static class Data { @Param({"0", "10", "100", "1000", "10000"}) private int length; } } 2. Benchmark for String-method measurements @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class MiscStringBenchmark { @Benchmark public char[] toCharArrayLatin1(Data data) { return data.string.toCharArray(); } @Benchmark public char[] toCharArrayUTF(Data data) { return data.utfString.toCharArray(); } @Benchmark public String repeatOneByteString(Data data) { return data.oneCharString.repeat(data.length); } @Benchmark public String repeatOneChar(Data data) { return data.oneUtfCharString.repeat(data.length); } @Benchmark public String replace(Data data){ return data.stringToReplace.replace('z', 'b'); } @Benchmark public String replaceUtf(Data data){ return data.utfStringToReplace.replace('?', '?'); } @Benchmark public StringBuilder newStringBuilderWithLength(Data data) { return new StringBuilder(data.length); } @Benchmark public StringBuilder newStringBuilderWithString(Data data) { return new StringBuilder(data.string); } @State(Scope.Thread) public static class Data { @Param({"8", "64", "128", "1024"}) private int length; private String string; public String utfString; private final String oneCharString = "a"; private final String oneUtfCharString = "?"; private String stringToReplace; private String utfStringToReplace; @Setup public void setup() { string = oneCharString.repeat(length); utfString = oneUtfCharString.repeat(length); stringToReplace = string + 'z'; utfStringToReplace = utfString + '?'; } } } -------------- next part -------------- A non-text attachment was scrubbed... Name: uninit_array.patch Type: text/x-diff Size: 7416 bytes Desc: not available URL: From Roger.Riggs at oracle.com Fri Sep 4 15:07:55 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Sep 2020 11:07:55 -0400 Subject: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: <11ca749f-3015-c004-aa6b-3194e1dfe4eb@linux.ibm.com> <8ece8d2e-fd99-b734-211e-a32b534a7dc8@linux.ibm.com> <8d53dcf8-635a-11e2-4f6a-39b70e2c3b8b@oracle.com> <65ed7919-86fc-adfa-3cd5-58dd96a3487f@linux.ibm.com> Message-ID: <4bc83479-1ed9-8cd8-22a0-1f19f315df7e@oracle.com> Hi Corey, The idea I had in mind is refactoring the fast path into the method you call decodeBlock. Base64: lines 751-768. It leaves all the unknown/illegal character handling to the Java code. And yes, it does not need to handle MIME, except to return on illegal characters. The patch is attached. Regards, Roger On 8/31/20 6:22 PM, Corey Ashford wrote: > On 8/29/20 1:19 PM, Corey Ashford wrote: >> Hi Roger, >> >> Thanks for your reply and thoughts!? Comments interspersed below: >> >> On 8/28/20 10:54 AM, Roger Riggs wrote: > ... >>> Comparing with the way that the Base64 encoder was intrinsified, the >>> method that is intrinsified should have a method body that does >>> the same function, so it is interchangable.? That likely will just >>> shift >>> the "fast path" code into the decodeBlock method. >>> Keeping the symmetry between encoder and decoder will >>> make it easier to maintain the code. >> >> Good point.? I'll investigate what this looks like in terms of the >> actual code, and will report back (perhaps in a new webrev). >> > > Having looked at this again, I don't think it makes sense.? One thing > that differs significantly from the encodeBlock intrinsic is that the > decodeBlock intrinsic only needs to process a prefix of the data, and > so it can leave virtually any amount of data at the end of the src > buffer unprocessed, where as with the encodeBlock intrinsic, if it > exists, it must process the entire buffer. > > In the (common) case where the decodeBlock intrinsic returns not > having processed everything, it still needs to call the Java code, and > if that Java code is "replaced" by the intrinsic, it's inaccessible. > > Is there something I'm overlooking here?? Basically I want the decode > API to behave differently than the encode API, mostly to make the > arch-specific intrinsic easier to implement. If that's not acceptable, > then I need to rethink the API, and also figure out how to deal with > the illegal character case.? The latter could perhaps be done by > throwing an exception from the intrinsic, or maybe by returning a > negative length that specifies the index of the illegal src byte, and > then have the Java code throw the exception). > > Regards, > > - Corey > -------------- next part -------------- diff --git a/src/java.base/share/classes/java/util/Base64.java b/src/java.base/share/classes/java/util/Base64.java index 34b39b18a54..e2b3a686d70 100644 --- a/src/java.base/share/classes/java/util/Base64.java +++ b/src/java.base/share/classes/java/util/Base64.java @@ -741,6 +741,27 @@ public class Base64 { return 3 * (int) ((len + 3L) / 4) - paddings; } + // Fast path for full 4 byte -> 3 byte conversion w/o errors + private int decodeBlock(byte[] src, int sp, int sl, byte[] dst, boolean isURL) { + int[] base64 = isURL ? fromBase64URL : fromBase64; + int dp = 0; + int sl0 = sp + ((sl - sp) & ~0b11); + while (sp < sl0) { + int b1 = base64[src[sp++] & 0xff]; + int b2 = base64[src[sp++] & 0xff]; + int b3 = base64[src[sp++] & 0xff]; + int b4 = base64[src[sp++] & 0xff]; + if ((b1 | b2 | b3 | b4) < 0) { // non base64 byte + return dp; + } + int bits0 = b1 << 18 | b2 << 12 | b3 << 6 | b4; + dst[dp++] = (byte)(bits0 >> 16); + dst[dp++] = (byte)(bits0 >> 8); + dst[dp++] = (byte)(bits0); + } + return dp; + } + private int decode0(byte[] src, int sp, int sl, byte[] dst) { int[] base64 = isURL ? fromBase64URL : fromBase64; int dp = 0; @@ -749,23 +770,34 @@ public class Base64 { while (sp < sl) { if (shiftto == 18 && sp + 4 < sl) { // fast path - int sl0 = sp + ((sl - sp) & ~0b11); - while (sp < sl0) { - int b1 = base64[src[sp++] & 0xff]; - int b2 = base64[src[sp++] & 0xff]; - int b3 = base64[src[sp++] & 0xff]; - int b4 = base64[src[sp++] & 0xff]; - if ((b1 | b2 | b3 | b4) < 0) { // non base64 byte - sp -= 4; - break; - } - int bits0 = b1 << 18 | b2 << 12 | b3 << 6 | b4; - dst[dp++] = (byte)(bits0 >> 16); - dst[dp++] = (byte)(bits0 >> 8); - dst[dp++] = (byte)(bits0); - } - if (sp >= sl) - break; + int dl = decodeBlock(src, sp, sl, dst, isURL); + /* + * Calculate how many characters were processed by how many + * bytes of data were returned. + */ + + /* + * Base64 characters always come in groups of four, + * producing three bytes of binary data (except for on + * the final four-character piece where it can produce + * one to three data bytes depending on how many fill + * characters there - zero, one, or two). The only + * case where there should be a non-multiple of three + * returned is if the intrinsic has processed all of + * the characters passed to it. At this point in the + * logic, however, we know the instrinsic hasn't + * processed all of the chracters. + * + * Round dl down to the nearest three-byte boundary. + */ + dl = (dl / 3) * 3; + + // Recalculate chars_decoded based on the rounded dl + int chars_decoded = (dl / 3) * 4; + + sp += chars_decoded; + dp += dl; + continue; } int b = src[sp++] & 0xff; if ((b = base64[b]) < 0) { From yumin.qi at oracle.com Fri Sep 4 16:49:18 2020 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 4 Sep 2020 09:49:18 -0700 Subject: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code In-Reply-To: <0eab9ecd-50f7-f91d-06af-e526b193826f@oracle.com> References: <4be47e30-aa69-7db0-ff04-f2d379fb8b38@oracle.com> <1face782-cc07-dfad-35c9-3247e556827c@oracle.com> <6a4bbb92-7e6a-f037-a2dd-220aba9c6374@oracle.com> <0eab9ecd-50f7-f91d-06af-e526b193826f@oracle.com> Message-ID: <4c134304-9ccd-b1b0-1f27-979b5191d3e1@oracle.com> Hi, Alan ? Thanks. Pushed before saw your email, could not credit you on reviewers. Thanks Yumin On 9/4/20 2:10 AM, Alan Bateman wrote: > On 04/09/2020 05:37, Yumin Qi wrote: >> HI, Sundar >> >> ? Thanks for review. >> >> On 9/3/20 6:34 PM, sundararajan.athijegannathan at oracle.com wrote: >>> Looks good to me. >>> >>> Few minor comment: >>> >>> * traceFileStream (and even the preexisting mainArgument) is accessed only inside GenerateJLIClassesPlugin. Could be private? >>> >> I will fix them before push. (Certainly will build first to verify that). > I went through the refactoring of the jlink plugin and I think it looks good too. > > -Alan. From vipinsharma85 at gmail.com Fri Sep 4 19:05:03 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Sat, 5 Sep 2020 00:35:03 +0530 Subject: RFR 8252537: Replace @exception with @throws for core-libs In-Reply-To: References: Message-ID: <24FEA3D8-E01B-4B66-BFBE-97282388BD10@gmail.com> Hi Martin, > On Sep 4, 2020, at 1:14 AM, Martin Buchholz wrote: > > Thanks for doing this! > > 15 years ago I considered taking on this task, eventually backing away > because it was too much work (!). But I made sure most of the classes > I maintained were using @throws. > > When considering this, I thought that tidying the whitespace after > conversion would be a big part of the task, even though it is > technically non-essential. Current use of whitespace with @throws is > inconsistent, as you have seen. > In these inconsistencies majority of the cases, we have more than one whitespace after @throws. There are a few cases where we have more than one whitespace character before @throws as well. I think if we are fixing whitespace inconsistencies of @throws then at the same time we should fix for other tags as well. Following are occurrences from jdk/src/ for some of the Javadoc tags along with regex used. If you think it is worth fixing I can start it from core-libs. \*[ ]{1}@throws[ ]{2,} Occurrences 4191 \*[ ]{1}@param[ ]{2,} Occurrences 7543 \*[ ]{1}@return[ ]{2,} Occurrences 3830 \*[ ]{1}@see[ ]{2,} Occurrences 3886 \*[ ]{1}@since[ ]{2,} Occurrences 1826 \*[ ]{1}@author[ ]{2,} Occurrences 1156 \*[ ]{1}@deprecated [ ]{2,} 22 Occurrences \*[ ]{1}@serial[ ]{2,} 4 Occurrences \*[ ]{1}@serialData[ ]{2,} 3 Occurrences \*[ ]{1}@serialField[ ]{2,} 10 Occurrences \*[ ]{1}@version[ ]{2,} 1 Occurrence > On Thu, Sep 3, 2020 at 12:34 PM Vipin Sharma wrote: >> >> Hi, >> >> Please review and sponsor the fix for replacing @exception with @throws for >> core-libs. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8252537 >> Webrev: https://cr.openjdk.java.net/~vsharma/8252537 >> >> As suggested in the previous discussion >> , >> this webrev has a consolidated fix for all subtasks of the JDK-8252536 >> . >> There is no change in the indentation as part of this webrev. >> >> Regards, >> Vipin Regards, Vipin From vipinsharma85 at gmail.com Fri Sep 4 19:17:15 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Sat, 5 Sep 2020 00:47:15 +0530 Subject: RFR 8252537: Replace @exception with @throws for core-libs In-Reply-To: References: Message-ID: <4CD716A6-B9DC-4C81-8B25-D1E074B39731@gmail.com> Hi Pavel, > On Sep 4, 2020, at 2:27 PM, Pavel Rappo wrote: > > Oops, wrong issue number. Here's the correct one: JDK-8157682. > >> On 4 Sep 2020, at 09:52, Pavel Rappo wrote: >> >> It would be nice to compare documentation HTML files generated before and after that patch: there's a possibility of non-local consequences, see JDK-6509045. There are ~ 1.5K lines, 86 files changed in this patch, do we have any tool to compare Javadoc or it should be done manually ? >> >> -Pavel >> >>> On 3 Sep 2020, at 20:33, Vipin Sharma wrote: >>> >>> Hi, >>> >>> Please review and sponsor the fix for replacing @exception with @throws for >>> core-libs. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8252537 >>> Webrev: https://cr.openjdk.java.net/~vsharma/8252537 >>> >>> As suggested in the previous discussion >>> , >>> this webrev has a consolidated fix for all subtasks of the JDK-8252536 >>> . >>> There is no change in the indentation as part of this webrev. >>> >>> Regards, >>> Vipin >> > Regards, Vipin From vipinsharma85 at gmail.com Fri Sep 4 20:32:14 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Sat, 5 Sep 2020 02:02:14 +0530 Subject: RFR 8252537: Replace @exception with @throws for core-libs In-Reply-To: <4CD716A6-B9DC-4C81-8B25-D1E074B39731@gmail.com> References: <4CD716A6-B9DC-4C81-8B25-D1E074B39731@gmail.com> Message-ID: <757F8572-4186-471A-AB34-7A5BAD13C4B8@gmail.com> Hi, I have generated Javadoc for all updated packages and compared html files, before and after changes. All looks good, only generation time is different in html files. Regards, Vipin > On Sep 5, 2020, at 12:47 AM, Vipin Sharma wrote: > > Hi Pavel, > > >> On Sep 4, 2020, at 2:27 PM, Pavel Rappo > wrote: >> >> Oops, wrong issue number. Here's the correct one: JDK-8157682. >> >>> On 4 Sep 2020, at 09:52, Pavel Rappo > wrote: >>> >>> It would be nice to compare documentation HTML files generated before and after that patch: there's a possibility of non-local consequences, see JDK-6509045. > > There are ~ 1.5K lines, 86 files changed in this patch, do we have any tool to compare Javadoc or it should be done manually ? > >>> >>> -Pavel >>> >>>> On 3 Sep 2020, at 20:33, Vipin Sharma wrote: >>>> >>>> Hi, >>>> >>>> Please review and sponsor the fix for replacing @exception with @throws for >>>> core-libs. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8252537 >>>> Webrev: https://cr.openjdk.java.net/~vsharma/8252537 >>>> >>>> As suggested in the previous discussion >>>> , >>>> this webrev has a consolidated fix for all subtasks of the JDK-8252536 >>>> . >>>> There is no change in the indentation as part of this webrev. >>>> >>>> Regards, >>>> Vipin >>> >> > Regards, > Vipin 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 uschindler at apache.org Sat Sep 5 11:55:03 2020 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 5 Sep 2020 13:55:03 +0200 Subject: JDK 15 hidden classes & stack trace visibility Message-ID: <004c01d6837b$6545fd30$2fd1f790$@apache.org> Hi, I am doing a mockup for dynamically compiled scripts in Apache Lucene (later also painless scripting in elastcsearch), where I tried to use Lookup#defineHiddenClass (with default parameters, so weak and no nestmates - but: for painless scripts of Elasticsearch, nestmates will be great). It all looks great, as sometimes for every query a new class is generated. The current approach (Java 8, Java 11) uses a Classloader per script, which is mostly OK, but hidden classes would be better, especially under high load with many new classes. The problem I see is: The hidden class and their methods are also hidden from stack traces, so people neither get the script source code reference, nor they get the method, which was called at all. My question is: is it possible to mark such a hidden class in byte code or by a flag to defineHiddenClass() so it is "unhidden"? - I know you can do this by a command line option, but that's for developers and debugging only. In some cases, this is really wanted (like for scripting languages), but code still wants to use the better class unloading. If this is not possible, how about extending the Lookup.ClassOption enum (last parameter of defineHiddenClass), to also pass a flag to show them in stack traces? Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany https://lucene.apache.org/ From aph at redhat.com Sat Sep 5 14:47:00 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 5 Sep 2020 15:47:00 +0100 Subject: JDK-8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <0cbe7d8f594349b59504c42f89c6f268@EX13D46EUB003.ant.amazon.com> References: <0cbe7d8f594349b59504c42f89c6f268@EX13D46EUB003.ant.amazon.com> Message-ID: On 03/09/2020 22:28, Tatton, Jason wrote: > > JMH Benchmark results: > ==================== > The benchmarks examine the 3 codepaths for StringLatin1 and > StringUTF16. Here are the results for Intel x86 (ARM is similar): > > FYI, String lengths in characters (1byte for Latin1, 2bytes for UTF16): > Latin1 UTF16 > Short: 15 7 > SSE4: 16 8 > AVX2: 32 16 > > Without StringLatin1 indexofchar intrinsic: > Benchmark Mode Cnt Score Error Units > IndexOfBenchmark.latin1_AVX2_String thrpt 5 121781.424 ? 355.085 ops/s > IndexOfBenchmark.latin1_AVX2_char thrpt 5 46060.612 ? 151.274 ops/s > IndexOfBenchmark.latin1_SSE4_String thrpt 5 197339.146 ? 90.333 ops/s > IndexOfBenchmark.latin1_SSE4_char thrpt 5 61401.204 ? 426.761 ops/s > IndexOfBenchmark.latin1_Short_String thrpt 5 175389.355 ? 294.976 ops/s > IndexOfBenchmark.latin1_Short_char thrpt 5 60759.868 ? 124.349 ops/s > IndexOfBenchmark.utf16_AVX2_String thrpt 5 123601.020 ? 111.981 ops/s > IndexOfBenchmark.utf16_AVX2_char thrpt 5 141116.832 ? 380.489 ops/s > IndexOfBenchmark.utf16_SSE4_String thrpt 5 178136.762 ? 143.227 ops/s > IndexOfBenchmark.utf16_SSE4_char thrpt 5 181430.649 ? 120.097 ops/s > IndexOfBenchmark.utf16_Short_String thrpt 5 158301.361 ? 182.738 ops/s > IndexOfBenchmark.utf16_Short_char thrpt 5 84876.919 ? 247.769 ops/s > > With StringLatin1 indexofchar intrinsic: > Benchmark Mode Cnt Score Error Units > IndexOfBenchmark.latin1_AVX2_String thrpt 5 113621.676 ? 68.235 ops/s > IndexOfBenchmark.latin1_AVX2_char thrpt 5 177757.909 ? 727.308 ops/s > IndexOfBenchmark.latin1_SSE4_String thrpt 5 180529.049 ? 57.356 ops/s > IndexOfBenchmark.latin1_SSE4_char thrpt 5 235087.776 ? 457.024 ops/s > IndexOfBenchmark.latin1_Short_String thrpt 5 165914.990 ? 329.024 ops/s > IndexOfBenchmark.latin1_Short_char thrpt 5 53989.544 ? 65.393 ops/s > IndexOfBenchmark.utf16_AVX2_String thrpt 5 107632.783 ? 446.272 ops/s > IndexOfBenchmark.utf16_AVX2_char thrpt 5 143131.734 ? 159.944 ops/s > IndexOfBenchmark.utf16_SSE4_String thrpt 5 169882.703 ? 1024.367 ops/s > IndexOfBenchmark.utf16_SSE4_char thrpt 5 175693.972 ? 775.423 ops/s > IndexOfBenchmark.utf16_Short_String thrpt 5 163595.993 ? 225.089 ops/s > IndexOfBenchmark.utf16_Short_char thrpt 5 90126.154 ? 365.642 ops/s > > We can see above that indexOf(char) now behaves similarly between > StringUTF16 and StringLatin1. This is confusing. Can you please make the times nanoseconds? It's quite a struggle trying to think in reciprocal units for these very low-level benchmarks. Maybe it's just me. There are 1000 strings of length 32 bytes, so I guess that makes everything fit in L1, just. I guess that was the idea? > //'a is never present in rnd string So you only benchmarks searches that always fail? I don't get that at all. I'd also vary string lengths. 32 characters is a good average, so you should have a decent spread of different lengths, average over the whole set 32. I'd place a terminating character randomly in *at least* 50% of the strings. I think that would be much more representative. -- 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 forax at univ-mlv.fr Sat Sep 5 23:18:35 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 6 Sep 2020 01:18:35 +0200 (CEST) Subject: JDK 15 hidden classes & stack trace visibility In-Reply-To: <004c01d6837b$6545fd30$2fd1f790$@apache.org> References: <004c01d6837b$6545fd30$2fd1f790$@apache.org> Message-ID: <1786587116.1535772.1599347915295.JavaMail.zimbra@u-pem.fr> Hi Uwe, ----- Mail original ----- > De: "Uwe Schindler" > ?: "core-libs-dev" > Envoy?: Samedi 5 Septembre 2020 13:55:03 > Objet: JDK 15 hidden classes & stack trace visibility > Hi, > > I am doing a mockup for dynamically compiled scripts in Apache Lucene (later > also painless scripting in elastcsearch), where I tried to use > Lookup#defineHiddenClass (with default parameters, so weak and no nestmates > - but: for painless scripts of Elasticsearch, nestmates will be great). It > all looks great, as sometimes for every query a new class is generated. > > The current approach (Java 8, Java 11) uses a Classloader per script, which > is mostly OK, but hidden classes would be better, especially under high load > with many new classes. The problem I see is: The hidden class and their > methods are also hidden from stack traces, so people neither get the script > source code reference, nor they get the method, which was called at all. > > My question is: is it possible to mark such a hidden class in byte code or > by a flag to defineHiddenClass() so it is "unhidden"? - I know you can do > this by a command line option, but that's for developers and debugging only. > In some cases, this is really wanted (like for scripting languages), but > code still wants to use the better class unloading. If this is not possible, > how about extending the Lookup.ClassOption enum (last parameter of > defineHiddenClass), to also pass a flag to show them in stack traces? If you don't want a hidden class, why not using Lookup.defineClass() for 11 and calling ClassLoader.defineClass() by reflection in 8 ? With defineClass you get a resolvable real name and methods are visible in the stacktrace. Obviously, it means that you are grouping several classes in the same classloader which may be not what you want. > > Uwe R?mi > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > https://lucene.apache.org/ From uschindler at apache.org Sun Sep 6 07:39:05 2020 From: uschindler at apache.org (Uwe Schindler) Date: Sun, 06 Sep 2020 07:39:05 +0000 Subject: JDK 15 hidden classes & stack trace visibility In-Reply-To: <1786587116.1535772.1599347915295.JavaMail.zimbra@u-pem.fr> References: <004c01d6837b$6545fd30$2fd1f790$@apache.org> <1786587116.1535772.1599347915295.JavaMail.zimbra@u-pem.fr> Message-ID: <3E335BFE-AA22-44F2-A8EA-717ACBF416C5@apache.org> Hi Remy, Those classes would get a strong relationship to class loader. So I would like to have the anonymous class features in combination with make them visible in stack traces. The current approach using separate classloader works fine for that as it unloads perfectly (exactly what's discussed in the JEP), so I would like to only reduce overhead of the added classloader (which is used only to allow unloading of those short living objects). The hidden classes work exactly like expected for this dynamic situation of short living classes, but the backside is the "hidden" feature. I'd like to make the hidden-ness a feature. My question is if this can be decoupled. The hidden feature is wanted for lambdas and such stuff, but in some situations stack traces are essential. Uwe Am September 5, 2020 11:18:35 PM UTC schrieb Remi Forax : >Hi Uwe, > >----- Mail original ----- >> De: "Uwe Schindler" >> ?: "core-libs-dev" >> Envoy?: Samedi 5 Septembre 2020 13:55:03 >> Objet: JDK 15 hidden classes & stack trace visibility > >> Hi, >> >> I am doing a mockup for dynamically compiled scripts in Apache Lucene >(later >> also painless scripting in elastcsearch), where I tried to use >> Lookup#defineHiddenClass (with default parameters, so weak and no >nestmates >> - but: for painless scripts of Elasticsearch, nestmates will be >great). It >> all looks great, as sometimes for every query a new class is >generated. >> >> The current approach (Java 8, Java 11) uses a Classloader per script, >which >> is mostly OK, but hidden classes would be better, especially under >high load >> with many new classes. The problem I see is: The hidden class and >their >> methods are also hidden from stack traces, so people neither get the >script >> source code reference, nor they get the method, which was called at >all. >> >> My question is: is it possible to mark such a hidden class in byte >code or >> by a flag to defineHiddenClass() so it is "unhidden"? - I know you >can do >> this by a command line option, but that's for developers and >debugging only. >> In some cases, this is really wanted (like for scripting languages), >but >> code still wants to use the better class unloading. If this is not >possible, >> how about extending the Lookup.ClassOption enum (last parameter of >> defineHiddenClass), to also pass a flag to show them in stack traces? > >If you don't want a hidden class, why not using Lookup.defineClass() >for 11 and calling ClassLoader.defineClass() by reflection in 8 ? >With defineClass you get a resolvable real name and methods are visible >in the stacktrace. > >Obviously, it means that you are grouping several classes in the same >classloader which may be not what you want. > >> >> Uwe > >R?mi > >> >> ----- >> Uwe Schindler >> uschindler at apache.org >> ASF Member, Apache Lucene PMC / Committer >> Bremen, Germany >> https://lucene.apache.org/ 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 kim.barrett at oracle.com Sun Sep 6 11:30:09 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 07:30:09 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87sgbxhiao.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> Message-ID: <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> > On Sep 4, 2020, at 7:50 AM, Florian Weimer wrote: > > * Daniel Fuchs: > >> Hi, >> >> On 02/09/2020 08:19, Florian Weimer wrote: >>> At least one of the bugs was in theory user-visible: the network >>> interface code would return data for an interface that does not actually >>> exist on the system. >> >> WRT NetworkInterface.c, I might support using `strnlen` to check >> the length before hand, if that solves both cases (gcc8 and gcc10). >> I'm always a bit nervous of changing the behavior in this library >> as it's hard to verify that no regression is introduced. > > I think you should use strlen. If the string is longer than the buffer > sent to the kernel, it cannot match an existing interface because all > the names are shorter. So some sort of ?not found? error needs to > reported. That may be, but I think doing so probably won't do anything to address the -Wstringop-truncation warnings. > (I assume that it's actually a bug that you can look up a network > interface by a name that merely shares the same prefix with an actual > interface on the system.) > > Thanks, > Florian From kim.barrett at oracle.com Sun Sep 6 11:35:40 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 07:35:40 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: > On Sep 1, 2020, at 9:59 AM, Eric Liu wrote: > I just tested this patch by GCC (10.1.0) and it would really re-trigger those warnings :( > I have not noticed the history before, but it's really hard to imagine that GCC would > have different behaviors. Can you be (very) specific about this. Do all of these changes cause gcc10 to warn? Or do only some of them. If only some, specifically which ones? I have a conjecture about some of them (see below). (I should probably try this myself; I know we have done some testing with gcc10, but I don?t remember where to find that devkit.) ------------------------------------------------------------------------------ src/java.base/unix/native/libnet/NetworkInterface.c 232 strncpy(searchName, name_utf, IFNAMESIZE - 1); A better solution here would be to eliminate the strncpy entirely. The strncpy is used to make a copy of a string so the copy can be searched for a colon, and if one is found, terminate the string there. But there's no need to make such a copy. The string being copied is the local temporary string name_utf. We could instead use name_utf everywhere searchName is currently used, including clobbering the first colon to NUL. We'd have to undo that before the later loop at line 249, but we have the information needed to do so. ------------------------------------------------------------------------------ src/java.base/unix/native/libnet/NetworkInterface.c 1298 memset((char *)&if2, 0, sizeof(if2)); 1299 strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); 1300 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; (in getIndex) So gcc8 does not warn about this, but gcc10 does? That would be a regression in gcc10 (and should be reported as such), because the documentation for -Wstringop-truncate is clear that the above is the proper idiom for avoiding the warning. Regardless, the memset on 1298 is useless. The code from before JDK-8250863 was the memset then the strncpy with sizeof(if2.ifr_name)-1 as the bound, which worked because the memset would have zeroed the last element. The change for JDK-8250863 did not follow the documented idiom though. It would be interesting to find out if removal of the memset changes anything. It's barely conceivable that it's confusing the heuristics used to decide whether -Wstringop-truncation should trigger. For example, the compiler might decide that the subsequent assignment of the last element is unnecessary because of the memset and optimize the assignment away, removing the idiomatic warning suppression. If gcc10 still warns about the above after removing the memset then I see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. Similarly for the strncpy in getFlags: 1362 memset((char *)&if2, 0, sizeof(if2)); 1363 strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); 1364 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; ------------------------------------------------------------------------------ src/java.base/unix/native/libnet/NetworkInterface.c 937 strncpy(name, if_name, IFNAMESIZE - 1); 938 name[IFNAMESIZE - 1] = '\0'; gcc10 presumably did not complain about the old version here, and this was not touched as part of JDK-8250863. Does gcc10 complain about this new version? If so, then I see little recoarse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here, because a gcc10 warning here is contrary to the documentation. ------------------------------------------------------------------------------ src/hotspot/share/compiler/compileBroker.hpp 64 PRAGMA_DIAG_PUSH 65 PRAGMA_STRINGOP_TRUNCATION_IGNORED 66 // This code can incorrectly cause a "stringop-truncation" warning with gcc 67 strncpy(_current_method, method, (size_t)cmname_buffer_length-1); 68 PRAGMA_DIAG_POP 69 _current_method[cmname_buffer_length-1] = '\0'; I think I'd prefer the PRAGMA_DIAG_POP moved one line further down, so that the push/pop surrounds the entire idiomactic usage that is supposed to prevent the warning. This seems to be a gcc8 bug. gcc10 doesn't warn about this (and shouldn't). It would be interesting to know if it too warns with --enable-asan. ------------------------------------------------------------------------------ src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c est/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp These changes look good, as they follow the documented idiom for suppressing -Wstringop-truncation. Does gcc10 warn after these changes? ------------------------------------------------------------------------------ test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/libInheritedChannel.c (In Java_UnixDomainSocket_bind0) 234 memset(&addr, 0, sizeof(addr)); 235 addr.sun_family = AF_UNIX; 236 strncpy(addr.sun_path, nameUtf, length - 1); 237 addr.sun_path[length - 1] = '\0'; (In Java_UnixDomainSocket_connect0) 267 memset(&addr, 0, sizeof(addr)); 268 addr.sun_family = AF_UNIX; 269 strncpy(addr.sun_path, nameUtf, length - 1); 270 addr.sun_path[length - 1] = '\0'; These changes look good, as they follow the documented idiom for suppressing -Wstringop-truncation. Does gcc10 warn after these changes? Per the discussion above about getIndex in NetworkInterface.c, does removing the memsets change that? The memsets seem entirely unnecessary, since we're filling in all (both) members. ------------------------------------------------------------------------------ From raffaello.giulietti at gmail.com Sun Sep 6 15:49:02 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Sun, 6 Sep 2020 17:49:02 +0200 Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) In-Reply-To: <1FC89344-6D17-448D-BE77-36BD32BDDB37@oracle.com> References: <623e9591-2caf-ecc4-0986-44cb90bc425f@gmail.com> <2FD97380-F78B-4C15-A1FE-0415BA96C886@oracle.com> <39c19044-e14f-5961-7746-a3872be95fd7@oracle.com> <3892472a-559e-4f4e-a773-2e14694fb050@gmail.com> <1FC89344-6D17-448D-BE77-36BD32BDDB37@oracle.com> Message-ID: Hello, FYI I just opened a PR on GitHub for this RFR. Greetings Raffaello On 2020-09-03 00:44, Brian Burkhalter wrote: > Good move. ;-) > > Brian > >> On Sep 2, 2020, at 2:26 PM, Raffaello Giulietti >> > >> wrote: >> >> will do in the next days, hopefully before the transition to Skara. > From fweimer at redhat.com Sun Sep 6 17:03:55 2020 From: fweimer at redhat.com (Florian Weimer) Date: Sun, 06 Sep 2020 19:03:55 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> (Kim Barrett's message of "Sun, 6 Sep 2020 07:30:09 -0400") References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> Message-ID: <87sgbuet1g.fsf@oldenburg2.str.redhat.com> * Kim Barrett: >> On Sep 4, 2020, at 7:50 AM, Florian Weimer wrote: >> >> * Daniel Fuchs: >> >>> Hi, >>> >>> On 02/09/2020 08:19, Florian Weimer wrote: >>>> At least one of the bugs was in theory user-visible: the network >>>> interface code would return data for an interface that does not actually >>>> exist on the system. >>> >>> WRT NetworkInterface.c, I might support using `strnlen` to check >>> the length before hand, if that solves both cases (gcc8 and gcc10). >>> I'm always a bit nervous of changing the behavior in this library >>> as it's hard to verify that no regression is introduced. >> >> I think you should use strlen. If the string is longer than the buffer >> sent to the kernel, it cannot match an existing interface because all >> the names are shorter. So some sort of ?not found? error needs to >> reported. > > That may be, but I think doing so probably won't do anything to > address the -Wstringop-truncation warnings. There is no reason to use strncpy. At least on Linux, the struct field needs to be null-terminated, and you need to compute the length for the length check. So you might as well use memcpy with the length plus one (to copy the null terminator). You can keep using strncpy, and the warning should be gone (because GCC will recognize a dominating strlen check), but it's not necessary. On current GNU/Linux, the most common structs now have the appropriate annotations, so you get the strncpy warnings only in cases where there is an actual truncation bug. Thanks, Florian From sean.coffey at oracle.com Sun Sep 6 19:43:33 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Sun, 6 Sep 2020 20:43:33 +0100 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <8946D5E0-8438-43EC-A987-4FEBF5779343@oracle.com> References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> <940A8A93-BB70-48CD-B1DE-0E9EC17E2791@ORACLE.COM> <3b9c3aa9-df9b-5ae3-2301-2e08c8e9f769@oracle.com> <1582051D-5EDD-4F16-88D3-A064683023D3@ORACLE.COM> <8946D5E0-8438-43EC-A987-4FEBF5779343@oracle.com> Message-ID: <1b02d2f3-3491-03cb-b4ac-b90e1b3d1bb9@oracle.com> Thanks for the review Hai-May. I've implemented all your suggestions. The CSR was approved late on Friday so I'll now submit this via PR on github infra. regards, Sean. On 28/08/2020 21:08, Hai-May Chao wrote: > JarSigner.java #953: The output debug message can be removed from the > code. > JavaUtilZipFileAccess.java #44: Change posixPerms to extraAttrs. > ZipFile.java #661: Suggest to keep the comment and update it with the > additional 4 bits for symlink. > > The rest of code changes and CSR look good. > > Thanks, > Hai-May > > >> On Aug 28, 2020, at 7:17 AM, Se?n Coffey > > wrote: >> >> I've been poking around the zip internals and am now able to locate >> the 16 bits of interest. The position of these actual bits does >> appear to move around from one test run to another. For now, I guess >> it's sufficient to look for the pattern of interest in the signed zip >> file. New testcase added. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8250968.v4/webrev/ >> >> regards, >> Sean. >> >> On 27/08/2020 15:58, Weijun Wang wrote: >>>> Looks like it was a conscious design decision to only allow recording of POSIX permission bits for this field (& 0xFFF). I don't see anything about symlink support in zipfs docs. >>> As long as that*byte* is there and it?s not difficult to locate, we can manually add the*bit* for symlink and see if jarsigner can keep it. >>> >>> ?Max >>> > From kim.barrett at oracle.com Mon Sep 7 01:49:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 21:49:48 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <63FFE48F-03C1-4F2E-9ECE-8C3303C6AF8F@oracle.com> > On Sep 6, 2020, at 7:35 AM, Kim Barrett wrote: > src/hotspot/share/compiler/compileBroker.hpp > 64 PRAGMA_DIAG_PUSH > 65 PRAGMA_STRINGOP_TRUNCATION_IGNORED > 66 // This code can incorrectly cause a "stringop-truncation" warning with gcc > 67 strncpy(_current_method, method, (size_t)cmname_buffer_length-1); > 68 PRAGMA_DIAG_POP > 69 _current_method[cmname_buffer_length-1] = '\0'; > > I think I'd prefer the PRAGMA_DIAG_POP moved one line further down, so > that the push/pop surrounds the entire idiomactic usage that is > supposed to prevent the warning. This seems to be a gcc8 bug. > > gcc10 doesn't warn about this (and shouldn't). It would be > interesting to know if it too warns with --enable-asan. I keep forgetting. This is the one where we think the cast on line 67 might be confusing gcc8, and if it were eliminated we might not need the PRAGMA dance here after all. From kim.barrett at oracle.com Mon Sep 7 01:51:06 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 21:51:06 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <47D04DC0-DF34-49D4-B901-5544BEFB09BB@oracle.com> > On Sep 6, 2020, at 7:35 AM, Kim Barrett wrote: > src/java.base/unix/native/libnet/NetworkInterface.c > 1298 memset((char *)&if2, 0, sizeof(if2)); > 1299 strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); > 1300 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; > > (in getIndex) > > So gcc8 does not warn about this, but gcc10 does? That would be a > regression in gcc10 (and should be reported as such), because the > documentation for -Wstringop-truncate is clear that the above is the > proper idiom for avoiding the warning. > > Regardless, the memset on 1298 is useless. The code from before > JDK-8250863 was the memset then the strncpy with > sizeof(if2.ifr_name)-1 as the bound, which worked because the memset > would have zeroed the last element. > > The change for JDK-8250863 did not follow the documented idiom though. > > It would be interesting to find out if removal of the memset changes > anything. It's barely conceivable that it's confusing the heuristics > used to decide whether -Wstringop-truncation should trigger. For > example, the compiler might decide that the subsequent assignment of > the last element is unnecessary because of the memset and optimize the > assignment away, removing the idiomatic warning suppression. > > If gcc10 still warns about the above after removing the memset then I > see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. I found a gcc10.2 devkit that I could take for a spin with Eric's patches. I got -Wstringop-truncation warnings in NetworkInterface.c, in getIndex and getFlags. Removing the immediately preceeding memset removed those warnings. (Note that in these two cases the memset is otherwise completely superfluous, both before and after Eric's changes.) Strangely, there are other places in this file where a strncpy is preceeded by a memcpy and there is no assignment of the last element to NUL, but which no version of gcc seems to complain about. Examples include getMacAddress, getMTU, enumIPv6Interfaces. Oh, good grief! This file contains 3 identical copies of getMTU and getFlags, one each for linux, AIX, and BSD. And getIndex is kind of a mess. If changing any of these for linux, probably similar changes ought to be applied to the other copies to keep things in sync. After removing the superfluous memsets from getIndex and getFlags, my test build with gcc10.2 completed successfully with Eric's patches. From kim.barrett at oracle.com Mon Sep 7 02:19:05 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 22:19:05 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87sgbuet1g.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> <87sgbuet1g.fsf@oldenburg2.str.redhat.com> Message-ID: <211FC028-8CE8-4296-BEC5-BE927558BDA0@oracle.com> > On Sep 6, 2020, at 1:03 PM, Florian Weimer wrote: > There is no reason to use strncpy. At least on Linux, the struct field > needs to be null-terminated, and you need to compute the length for the > length check. So you might as well use memcpy with the length plus one > (to copy the null terminator). You can keep using strncpy, and the > warning should be gone (because GCC will recognize a dominating strlen > check), but it's not necessary. > > On current GNU/Linux, the most common structs now have the appropriate > annotations, so you get the strncpy warnings only in cases where there > is an actual truncation bug. [Keep in mind that gcc on recent GNU/Linux is not the only platform this code base needs to worry about. Though it is the one that is driving us a bit batty with its varying warnings here.] I'm not sure whether you are suggesting one should never use strncpy anywhere, or whether there is some specific place(s) from this webrev you are suggesting it should be avoided? I agree there are some uses of strncpy that look at least somewhat suspect. Without further analysis it's hard to know whether there is really a problem with truncation (can it occur at all, and is it a problem if it does). Figuring that out seems somewhat beyond the scope of what this change is trying to do. Please file bugs about problematic uses. (A bug of the form "don't use strncpy" might not get quick action.) And strlen is not even necessarily the best solution, as it likely introduces an additional otherwise unnecessary string traversal. For example, getFlags could be changed to reject an overly long ifname, without using strlen, thusly: strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name)); if (if2.ifr_name[sizeof(if2.ifr_name) - 1] != '\0') { return -1; } Unfortunately, gcc10 -Wstringop-truncation whines about this entirely reasonable code. From kim.barrett at oracle.com Mon Sep 7 02:36:33 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 22:36:33 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <47D04DC0-DF34-49D4-B901-5544BEFB09BB@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <47D04DC0-DF34-49D4-B901-5544BEFB09BB@oracle.com> Message-ID: > On Sep 6, 2020, at 9:51 PM, Kim Barrett wrote: > Oh, good grief! This file contains 3 identical copies of getMTU and > getFlags, one each for linux, AIX, and BSD. And getIndex is kind of a > mess. If changing any of these for linux, probably similar changes > ought to be applied to the other copies to keep things in sync. Is there any reason the linux version of getIndex couldn?t be changed to use if_nametoindex (like the AIX version)? That would eliminate one of the cases that is causing problems. From fweimer at redhat.com Mon Sep 7 09:55:28 2020 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 07 Sep 2020 11:55:28 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <211FC028-8CE8-4296-BEC5-BE927558BDA0@oracle.com> (Kim Barrett's message of "Sun, 6 Sep 2020 22:19:05 -0400") References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> <87sgbuet1g.fsf@oldenburg2.str.redhat.com> <211FC028-8CE8-4296-BEC5-BE927558BDA0@oracle.com> Message-ID: <87o8mh7vxr.fsf@oldenburg2.str.redhat.com> * Kim Barrett: > And strlen is not even necessarily the best solution, as it likely > introduces an additional otherwise unnecessary string traversal. For > example, getFlags could be changed to reject an overly long ifname, > without using strlen, thusly: > > strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name)); > if (if2.ifr_name[sizeof(if2.ifr_name) - 1] != '\0') { > return -1; > } > > Unfortunately, gcc10 -Wstringop-truncation whines about this entirely > reasonable code. Thanks, I filed this as: Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill From martin.doerr at sap.com Mon Sep 7 10:08:57 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 7 Sep 2020 10:08:57 +0000 Subject: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: <5ac1ac19-af1c-4ee6-b478-873031710081@linux.ibm.com> References: <11ca749f-3015-c004-aa6b-3194e1dfe4eb@linux.ibm.com> <5ac1ac19-af1c-4ee6-b478-873031710081@linux.ibm.com> Message-ID: Hi Corey, thanks for investigating. Note that we use xlclang++ on AIX. It may possibly understand the directives as gcc on linux. Gcc 7.3.1 is the minimum for BE linux. But if you protect your code by #ifdef VM_LITTLE_ENDIAN no compiler except gcc >= 7.4.0 should ever look at it. Best regards, Martin > -----Original Message----- > From: Corey Ashford > Sent: Dienstag, 1. September 2020 02:17 > To: Doerr, Martin > Cc: Michihiro Horie ; hotspot-compiler- > dev at openjdk.java.net; core-libs-dev ; > Kazunori Ogata ; joserz at br.ibm.com > Subject: Re: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and > API for Base64 decoding > > On 8/27/20 8:07 AM, Doerr, Martin wrote: > >>> I will use __attribute__ ((align(16))) instead of __vector, and make > >> them arrays of 16 unsigned char. > > Maybe __vectors works as expected, too, now. Whatever we use, I'd > appreciate to double-check the alignment e.g. by using gdb. > > I don't remember what we had tried and why it didn't work as desired. > > > I just now tried on gcc-7.5.0, declaring a __vector at 1, 2, 3, 8, 9, > and 15 byte offsets in a struct, trying to force a misalignment, but the > compiler realigned all of them on 16-byte boundaries. > > If someone decides to make the intrinsic work on AIX (big endian), and > compiles with 7.3.1, I don't know what will happen w.r.t. alignment, so > to be on the safe side, I will make the declarations 16-byte unsigned > char arrays with an align attribute. > > Looking a bit deeper, I see that the __vector type comes out of the C > preprocessor as: __attribute__((altivec(vector__))). It's part of the > compiler's basic set of predefined macros, and can be seen using this > command: > > % gcc -dM -E - < /dev/null | grep __vector > > #define __vector __attribute__((altivec(vector__))) > > Some information here: > https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Type-Attributes.html > > I don't know if this is helpful or not, but it might answer part of your > question about the meaning of __vector. > > Regards, > > - Corey From michaelm at openjdk.java.net Mon Sep 7 12:14:37 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 7 Sep 2020 12:14:37 GMT Subject: RFR: 8245194: Unix domain socket channel implementation Message-ID: Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more iterations before integrating. On 06/09/2020 19:47, Alan Bateman wrote: > On 26/08/2020 15:24, Michael McMahon wrote: >> >> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >> think of that. >> >> There is a fair bit of other refactoring and simplification done also. Next version is at: >> >> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >> > Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the > encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved > path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a > number points that require clarification to fully understand how this will work with relative, directly relative and > drive relative paths. > Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That would leave WindowsPath unchanged. I also changed the > In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a > method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place > to get the file path in bytes. > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to be useful by other components. > One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its > fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main > issue is that class is that it means we end up with two classes with static factory methods doing the same thing). Okay, that does simplify it a bit. Thanks, Michael. > -Alan. > > > > > > ------------- Commit messages: - unixdomainchannels: fixing compile error on Windows and Alan's review comment this morning - unixdomainchannels: initial commit from hg sandbox with changes from Alan's email 06/09/2020 Changes: https://git.openjdk.java.net/jdk/pull/52/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245194 Stats: 6960 lines in 87 files changed: 5902 ins; 763 del; 295 mod Patch: https://git.openjdk.java.net/jdk/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk/pull/52 From coffeys at openjdk.java.net Mon Sep 7 13:58:10 2020 From: coffeys at openjdk.java.net (Sean Coffey) Date: Mon, 7 Sep 2020 13:58:10 GMT Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files Message-ID: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html CSR has been approved. ------------- Commit messages: - JDK-8250968 Changes: https://git.openjdk.java.net/jdk/pull/56/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=56&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250968 Stats: 198 lines in 10 files changed: 162 ins; 1 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/56.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/56/head:pull/56 PR: https://git.openjdk.java.net/jdk/pull/56 From eric.c.liu at arm.com Mon Sep 7 14:56:53 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Mon, 7 Sep 2020 14:56:53 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> , Message-ID: Hi Kim: Thanks for the discussion, this makes more sense to me now. > Kim Barrett on 06 September 2020 19:35 wrote: > > Can you be (very) specific about this.? Do all of these changes cause gcc10 to warn?? Or > do only some of them.? If only some, specifically which ones??I have a conjecture about > some of them (see below).? (I should probably try this myself; I know we have done some > testing with gcc10, but I don?t remember where to find that devkit.) I have tested 4 cases for those warnings: a) Without my patch, without asan, gcc-8 and gcc-10 are OK. b) Without my patch, with asan, gcc-8 has warned, gcc-10 is OK. c) With my patch, without asan, gcc-8 and gcc-10 are OK. d) With my patch, with asan, gcc-8 is OK, gcc-10 has warned. Those warnings can be reported by both gcc-8 and gcc-10 only when asan enabled. Without asan, no warning would be found even through some of them doesn't align with the documentation. > ------------------------------------------------------------------------------ > src/java.base/unix/native/libnet/NetworkInterface.c >?232???? strncpy(searchName, name_utf, IFNAMESIZE - 1); > > A better solution here would be to eliminate the strncpy entirely. > > The strncpy is used to make a copy of a string so the copy can be > searched for a colon, and if one is found, terminate the string there. > > But there's no need to make such a copy.? The string being copied is > the local temporary string name_utf.? We could instead use name_utf > everywhere searchName is currently used, including clobbering the > first colon to NUL.? We'd have to undo that before the later loop at > line 249, but we have the information needed to do so. Yes, this copy seems unnecessary. I was thinking whether it's a good way to find parent by using strstr, so that we can not have to recover the zero. Will that be much slower? > ------------------------------------------------------------------------------ > src/java.base/unix/native/libnet/NetworkInterface.c > 1298???? memset((char *)&if2, 0, sizeof(if2)); > 1299???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); > 1300???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; > > (in getIndex) > > So gcc8 does not warn about this, but gcc10 does? That would be a > regression in gcc10 (and should be reported as such), because the > documentation for -Wstringop-truncate is clear that the above is the > proper idiom for avoiding the warning. Yse, I followed the documentation and gcc-8 does not warn about this, but gcc-10 does (both with asan enabled). > Regardless, the memset on 1298 is useless.? The code from before > JDK-8250863 was the memset then the strncpy with > sizeof(if2.ifr_name)-1 as the bound, which worked because the memset > would have zeroed the last element. > > The change for JDK-8250863 did not follow the documented idiom though. > > It would be interesting to find out if removal of the memset changes > anything.? It's barely conceivable that it's confusing the heuristics > used to decide whether -Wstringop-truncation should trigger.? For > example, the compiler might decide that the subsequent assignment of > the last element is unnecessary because of the memset and optimize the > assignment away, removing the idiomatic warning suppression. > > If gcc10 still warns about the above after removing the memset then I > see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. > > Similarly for the strncpy in getFlags: > 1362???? memset((char *)&if2, 0, sizeof(if2)); > 1363???? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); > 1364???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; After removing the memset, gcc-10(10.1.0) still warns about it, gcc-8 and gcc-9 also. > ------------------------------------------------------------------------------ > src/java.base/unix/native/libnet/NetworkInterface.c > ?937???? strncpy(name, if_name, IFNAMESIZE - 1); > ?938???? name[IFNAMESIZE - 1] = '\0'; > > gcc10 presumably did not complain about the old version here, and this > was not touched as part of JDK-8250863.? Does gcc10 complain about > this new version?? If so, then I see little recoarse but to use > PRAGMA_STRINGOP_TRUNCATION_IGNORED here, because a gcc10 warning here > is contrary to the documentation. Yes, gcc-10 would warn about this both before and after my patch if asan enabled. > ------------------------------------------------------------------------------ > src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > est/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp > > These changes look good, as they follow the documented idiom for > suppressing -Wstringop-truncation. Does gcc10 warn after these changes? Gcc-10 does'n warn about this changes. > ------------------------------------------------------------------------------ > test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/libInheritedChannel.c > (In Java_UnixDomainSocket_bind0)? > 234???? memset(&addr, 0, sizeof(addr)); > 235???? addr.sun_family = AF_UNIX; > 236???? strncpy(addr.sun_path, nameUtf, length - 1); > 237???? addr.sun_path[length - 1] = '\0'; > > (In Java_UnixDomainSocket_connect0) > 267???? memset(&addr, 0, sizeof(addr)); > 268???? addr.sun_family = AF_UNIX; > 269???? strncpy(addr.sun_path, nameUtf, length - 1); > 270???? addr.sun_path[length - 1] = '\0'; > > These changes look good, as they follow the documented idiom for > suppressing -Wstringop-truncation. > > Does gcc10 warn after these changes? Gcc-10 doesn't warn about these changes. I'm working on a new patch that to make both gcc-8 and gcc-10 happy. Thanks, Eric From lancea at openjdk.java.net Mon Sep 7 16:43:58 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Sep 2020 16:43:58 GMT Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> References: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> Message-ID: On Mon, 7 Sep 2020 13:48:57 GMT, Sean Coffey wrote: > Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html > > CSR has been approved. I think this looks good over all Sean. In your SymLinkTest, I probably would have the test delete the file if it exists prior to writing to it. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/56 From mandy.chung at oracle.com Mon Sep 7 16:44:18 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 7 Sep 2020 09:44:18 -0700 Subject: JDK 15 hidden classes & stack trace visibility In-Reply-To: <004c01d6837b$6545fd30$2fd1f790$@apache.org> References: <004c01d6837b$6545fd30$2fd1f790$@apache.org> Message-ID: Hi Uwe, It's a future enhancement to allow a class/method to request filtering from stack trace: ??? https://bugs.openjdk.java.net/browse/JDK-8212620 This RFE should also take hidden classes into account. Mandy On 9/5/20 4:55 AM, Uwe Schindler wrote: > Hi, > > I am doing a mockup for dynamically compiled scripts in Apache Lucene (later > also painless scripting in elastcsearch), where I tried to use > Lookup#defineHiddenClass (with default parameters, so weak and no nestmates > - but: for painless scripts of Elasticsearch, nestmates will be great). It > all looks great, as sometimes for every query a new class is generated. > > The current approach (Java 8, Java 11) uses a Classloader per script, which > is mostly OK, but hidden classes would be better, especially under high load > with many new classes. The problem I see is: The hidden class and their > methods are also hidden from stack traces, so people neither get the script > source code reference, nor they get the method, which was called at all. > > My question is: is it possible to mark such a hidden class in byte code or > by a flag to defineHiddenClass() so it is "unhidden"? - I know you can do > this by a command line option, but that's for developers and debugging only. > In some cases, this is really wanted (like for scripting languages), but > code still wants to use the better class unloading. If this is not possible, > how about extending the Lookup.ClassOption enum (last parameter of > defineHiddenClass), to also pass a flag to show them in stack traces? > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > https://lucene.apache.org/ > > From weijun at openjdk.java.net Mon Sep 7 16:49:19 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 7 Sep 2020 16:49:19 GMT Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> References: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> Message-ID: On Mon, 7 Sep 2020 13:48:57 GMT, Sean Coffey wrote: > Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html > > CSR has been approved. Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/56 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 github.com+70726043+rgiulietti at openjdk.java.net Mon Sep 7 17:17:14 2020 From: github.com+70726043+rgiulietti at openjdk.java.net (rgiulietti) Date: Mon, 7 Sep 2020 17:17:14 GMT Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) Message-ID: This is a follow-up of the Mercurial-based workflow initiated on the core-lib-devs mailing list [0]. Not sure if this one is strictly necessary or if the patches sent on the list are sufficient. Anyway, I exploit this PR as a test ;-) [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068474.html ------------- Commit messages: - 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) Changes: https://git.openjdk.java.net/jdk/pull/31/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=31&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238669 Stats: 73 lines in 2 files changed: 32 ins; 15 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/31/head:pull/31 PR: https://git.openjdk.java.net/jdk/pull/31 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 uschindler at apache.org Mon Sep 7 18:39:13 2020 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 07 Sep 2020 18:39:13 +0000 Subject: JDK 15 hidden classes & stack trace visibility In-Reply-To: References: <004c01d6837b$6545fd30$2fd1f790$@apache.org> Message-ID: Thanks Mandy. In my opinion for the hidden classes an additional enum constant in ClassOption would be fine: ClassOption.SHOW_IN_STACKTRACE (or similar). That would be simplest to implement and allows also for the caller to enable it like strong references or nestmate features. So it's consistent with the other API parts. The annotations are good for fine granular hiding (like complex classes recursively calling methods). Or for frameworks like Spring. Should I add a comment to this issue? We are now doing some testing in Lucene's expressions module (it's about scoring formulas in query execution). Here's the draft PR: https://github.com/apache/lucene-solr/pull/1837/files We use the new features in Lucene when the static initializer detects defineHiddenClass using a publicLookup. Currently a test fails, because of missing debug information in stack traces. The executed scoring formula is part of the filename attribute in class file. As this is missing, test fails. ?? Uwe Am September 7, 2020 4:44:18 PM UTC schrieb Mandy Chung : >Hi Uwe, > >It's a future enhancement to allow a class/method to request filtering >from stack trace: > ??? https://bugs.openjdk.java.net/browse/JDK-8212620 > >This RFE should also take hidden classes into account. > >Mandy > >On 9/5/20 4:55 AM, Uwe Schindler wrote: >> Hi, >> >> I am doing a mockup for dynamically compiled scripts in Apache Lucene >(later >> also painless scripting in elastcsearch), where I tried to use >> Lookup#defineHiddenClass (with default parameters, so weak and no >nestmates >> - but: for painless scripts of Elasticsearch, nestmates will be >great). It >> all looks great, as sometimes for every query a new class is >generated. >> >> The current approach (Java 8, Java 11) uses a Classloader per script, >which >> is mostly OK, but hidden classes would be better, especially under >high load >> with many new classes. The problem I see is: The hidden class and >their >> methods are also hidden from stack traces, so people neither get the >script >> source code reference, nor they get the method, which was called at >all. >> >> My question is: is it possible to mark such a hidden class in byte >code or >> by a flag to defineHiddenClass() so it is "unhidden"? - I know you >can do >> this by a command line option, but that's for developers and >debugging only. >> In some cases, this is really wanted (like for scripting languages), >but >> code still wants to use the better class unloading. If this is not >possible, >> how about extending the Lookup.ClassOption enum (last parameter of >> defineHiddenClass), to also pass a flag to show them in stack traces? >> >> Uwe >> >> ----- >> Uwe Schindler >> uschindler at apache.org >> ASF Member, Apache Lucene PMC / Committer >> Bremen, Germany >> https://lucene.apache.org/ >> >> From coffeys at openjdk.java.net Mon Sep 7 18:57:11 2020 From: coffeys at openjdk.java.net (Sean Coffey) Date: Mon, 7 Sep 2020 18:57:11 GMT Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files [v2] In-Reply-To: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> References: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> Message-ID: > Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html > > CSR has been approved. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Copyright and test clean up ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/56/files - new: https://git.openjdk.java.net/jdk/pull/56/files/2f656ce0..27cb91f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=56&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=56&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/56.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/56/head:pull/56 PR: https://git.openjdk.java.net/jdk/pull/56 From coffeys at openjdk.java.net Mon Sep 7 19:04:08 2020 From: coffeys at openjdk.java.net (Sean Coffey) Date: Mon, 7 Sep 2020 19:04:08 GMT Subject: Integrated: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> References: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> Message-ID: On Mon, 7 Sep 2020 13:48:57 GMT, Sean Coffey wrote: > Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html > > CSR has been approved. This pull request has now been integrated. Changeset: 7686e871 Author: Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/7686e871 Stats: 200 lines in 10 files changed: 1 ins; 162 del; 37 mod 8250968: Symlinks attributes not preserved when using jarsigner on zip files Reviewed-by: lancea, weijun, hchao ------------- PR: https://git.openjdk.java.net/jdk/pull/56 From lancea at openjdk.java.net Mon Sep 7 19:04:07 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Sep 2020 19:04:07 GMT Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files [v2] In-Reply-To: References: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> Message-ID: On Mon, 7 Sep 2020 18:57:11 GMT, Sean Coffey wrote: >> Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html >> >> CSR has been approved. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Copyright and test clean up Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/56 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 jptatton at amazon.com Tue Sep 8 12:02:14 2020 From: jptatton at amazon.com (Tatton, Jason) Date: Tue, 8 Sep 2020 12:02:14 +0000 Subject: JDK-8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <0cbe7d8f594349b59504c42f89c6f268@EX13D46EUB003.ant.amazon.com> Message-ID: Hi Andrew, thank you for taking the time to review this. Since we have now moved to git, I have raised a new PR for this RFR: https://github.com/openjdk/jdk/pull/71 https://bugs.openjdk.java.net/browse/JDK-8173585 I have improved the micro benchmark in the ways which you and others have requested, namely: + The benchmark is now included in test/micro/org/openjdk/bench/java/lang as StringIndexOfChar (as advised by my colleagues here at AWS; Xin Liu and Volker Simonis). + Times are now in nanoseconds. + Terminating characters ('a') are in 66.666% of tested strings. + I have added four new benchmarks which operate on a random length strings (32 characters being the average) of type either StringLatin1 of StringUTF16 and call indexOf(char) or indexOf(String). I have included below the output of these four tests below: Without the new StringLatin1 indexOf(char) intrinsic: Benchmark Mode Cnt Score Error Units IndexOfBenchmark.latin1_mixed_char avgt 5 26389.129 ? 182.581 ns/op IndexOfBenchmark.utf16_mixed_char avgt 5 17885.383 ? 435.933 ns/op With the new StringLatin1 indexOf(char) intrinsic: Benchmark Mode Cnt Score Error Units IndexOfBenchmark.latin1_mixed_char avgt 5 17875.185 ? 407.716 ns/op IndexOfBenchmark.utf16_mixed_char avgt 5 18292.802 ? 167.306 ns/op The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when running on ARM. Regards, Jason -----Original Message----- From: Andrew Haley Sent: 05 September 2020 15:47 To: Tatton, Jason ; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: RE: [EXTERNAL] JDK-8173585: Intrinsify StringLatin1.indexOf(char) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On 03/09/2020 22:28, Tatton, Jason wrote: > > JMH Benchmark results: > ==================== > The benchmarks examine the 3 codepaths for StringLatin1 and > StringUTF16. Here are the results for Intel x86 (ARM is similar): > > FYI, String lengths in characters (1byte for Latin1, 2bytes for UTF16): > Latin1 UTF16 > Short: 15 7 > SSE4: 16 8 > AVX2: 32 16 > > Without StringLatin1 indexofchar intrinsic: > Benchmark Mode Cnt Score Error Units > IndexOfBenchmark.latin1_AVX2_String thrpt 5 121781.424 ? 355.085 ops/s > IndexOfBenchmark.latin1_AVX2_char thrpt 5 46060.612 ? 151.274 ops/s > IndexOfBenchmark.latin1_SSE4_String thrpt 5 197339.146 ? 90.333 ops/s > IndexOfBenchmark.latin1_SSE4_char thrpt 5 61401.204 ? 426.761 ops/s > IndexOfBenchmark.latin1_Short_String thrpt 5 175389.355 ? 294.976 ops/s > IndexOfBenchmark.latin1_Short_char thrpt 5 60759.868 ? 124.349 ops/s > IndexOfBenchmark.utf16_AVX2_String thrpt 5 123601.020 ? 111.981 ops/s > IndexOfBenchmark.utf16_AVX2_char thrpt 5 141116.832 ? 380.489 ops/s > IndexOfBenchmark.utf16_SSE4_String thrpt 5 178136.762 ? 143.227 ops/s > IndexOfBenchmark.utf16_SSE4_char thrpt 5 181430.649 ? 120.097 ops/s > IndexOfBenchmark.utf16_Short_String thrpt 5 158301.361 ? 182.738 ops/s > IndexOfBenchmark.utf16_Short_char thrpt 5 84876.919 ? 247.769 ops/s > > With StringLatin1 indexofchar intrinsic: > Benchmark Mode Cnt Score Error Units > IndexOfBenchmark.latin1_AVX2_String thrpt 5 113621.676 ? 68.235 ops/s > IndexOfBenchmark.latin1_AVX2_char thrpt 5 177757.909 ? 727.308 ops/s > IndexOfBenchmark.latin1_SSE4_String thrpt 5 180529.049 ? 57.356 ops/s > IndexOfBenchmark.latin1_SSE4_char thrpt 5 235087.776 ? 457.024 ops/s > IndexOfBenchmark.latin1_Short_String thrpt 5 165914.990 ? 329.024 ops/s > IndexOfBenchmark.latin1_Short_char thrpt 5 53989.544 ? 65.393 ops/s > IndexOfBenchmark.utf16_AVX2_String thrpt 5 107632.783 ? 446.272 ops/s > IndexOfBenchmark.utf16_AVX2_char thrpt 5 143131.734 ? 159.944 ops/s > IndexOfBenchmark.utf16_SSE4_String thrpt 5 169882.703 ? 1024.367 ops/s > IndexOfBenchmark.utf16_SSE4_char thrpt 5 175693.972 ? 775.423 ops/s > IndexOfBenchmark.utf16_Short_String thrpt 5 163595.993 ? 225.089 ops/s > IndexOfBenchmark.utf16_Short_char thrpt 5 90126.154 ? 365.642 ops/s > > We can see above that indexOf(char) now behaves similarly between > StringUTF16 and StringLatin1. This is confusing. Can you please make the times nanoseconds? It's quite a struggle trying to think in reciprocal units for these very low-level benchmarks. Maybe it's just me. There are 1000 strings of length 32 bytes, so I guess that makes everything fit in L1, just. I guess that was the idea? > //'a is never present in rnd string So you only benchmarks searches that always fail? I don't get that at all. I'd also vary string lengths. 32 characters is a good average, so you should have a decent spread of different lengths, average over the whole set 32. I'd place a terminating character randomly in *at least* 50% of the strings. I think that would be much more representative. -- 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 kim.barrett at oracle.com Tue Sep 8 12:28:21 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Sep 2020 08:28:21 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> > On Sep 7, 2020, at 10:56 AM, Eric Liu wrote: > I have tested 4 cases for those warnings: > a) Without my patch, without asan, gcc-8 and gcc-10 are OK. > b) Without my patch, with asan, gcc-8 has warned, gcc-10 is OK. > c) With my patch, without asan, gcc-8 and gcc-10 are OK. That?s *very* strange, since I get warnings in NetworkInterface getIndex and getFlags with gcc10.2 + your patch. > d) With my patch, with asan, gcc-8 is OK, gcc-10 has warned. > > Those warnings can be reported by both gcc-8 and gcc-10 only when asan enabled. Without > asan, no warning would be found even through some of them doesn't align with the documentation. >> src/java.base/unix/native/libnet/NetworkInterface.c >> 1298 memset((char *)&if2, 0, sizeof(if2)); >> 1299 strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); >> 1300 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; >> >> (in getIndex) >> >> So gcc8 does not warn about this, but gcc10 does? That would be a >> regression in gcc10 (and should be reported as such), because the >> documentation for -Wstringop-truncate is clear that the above is the >> proper idiom for avoiding the warning. > > Yse, I followed the documentation and gcc-8 does not warn about this, but > gcc-10 does (both with asan enabled). > >> Regardless, the memset on 1298 is useless. The code from before >> JDK-8250863 was the memset then the strncpy with >> sizeof(if2.ifr_name)-1 as the bound, which worked because the memset >> would have zeroed the last element. >> >> The change for JDK-8250863 did not follow the documented idiom though. >> >> It would be interesting to find out if removal of the memset changes >> anything. It's barely conceivable that it's confusing the heuristics >> used to decide whether -Wstringop-truncation should trigger. For >> example, the compiler might decide that the subsequent assignment of >> the last element is unnecessary because of the memset and optimize the >> assignment away, removing the idiomatic warning suppression. >> >> If gcc10 still warns about the above after removing the memset then I >> see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. >> >> Similarly for the strncpy in getFlags: >> 1362 memset((char *)&if2, 0, sizeof(if2)); >> 1363 strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); >> 1364 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; > > After removing the memset, gcc-10(10.1.0) still warns about it, gcc-8 and gcc-9 also. I?m confused. Above you said that with your patch + asan gcc-8 did not warn. Maybe what you are saying is that *just* removing the memset, and not applying your patch, for this case with asan warns with all of gcc-8,9,10? > I'm working on a new patch that to make both gcc-8 and gcc-10 happy. Good luck! I think I?m coming around to Florian?s ?never use strncpy? position, not so much because it?s the wrong function to use (though sometimes it probably is, or is being used wrongly), but because fighting with -Wstringop-truncation is just not worth the aggravation. From kim.barrett at oracle.com Tue Sep 8 12:29:42 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Sep 2020 08:29:42 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87o8mh7vxr.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> <87sgbuet1g.fsf@oldenburg2.str.redhat.com> <211FC028-8CE8-4296-BEC5-BE927558BDA0@oracle.com> <87o8mh7vxr.fsf@oldenburg2.str.redhat.com> Message-ID: <089F94C7-4126-4D7C-A3E9-33373B960D7F@oracle.com> > On Sep 7, 2020, at 5:55 AM, Florian Weimer wrote: > > * Kim Barrett: > >> And strlen is not even necessarily the best solution, as it likely >> introduces an additional otherwise unnecessary string traversal. For >> example, getFlags could be changed to reject an overly long ifname, >> without using strlen, thusly: >> >> strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name)); >> if (if2.ifr_name[sizeof(if2.ifr_name) - 1] != '\0') { >> return -1; >> } >> >> Unfortunately, gcc10 -Wstringop-truncation whines about this entirely >> reasonable code. > > Thanks, I filed this as: Thanks. Though it looks like the response is just ?don?t use strncpy?. 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 Roger.Riggs at oracle.com Tue Sep 8 14:54:00 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 8 Sep 2020 10:54:00 -0400 Subject: JDK-8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <0cbe7d8f594349b59504c42f89c6f268@EX13D46EUB003.ant.amazon.com> Message-ID: <445645fe-b4b1-0c48-0191-8f71f17f0042@oracle.com> Hi Jason, With respect to the increased ns/op in the utf16_mixed_char benchmark, how should we understand the lower performance? Thanks, Roger On 9/8/20 8:02 AM, Tatton, Jason wrote: > Hi Andrew, thank you for taking the time to review this. > > Since we have now moved to git, I have raised a new PR for this RFR: > > https://github.com/openjdk/jdk/pull/71 > https://bugs.openjdk.java.net/browse/JDK-8173585 > > I have improved the micro benchmark in the ways which you and others have requested, namely: > + The benchmark is now included in test/micro/org/openjdk/bench/java/lang as StringIndexOfChar (as advised by my colleagues here at AWS; Xin Liu and Volker Simonis). > + Times are now in nanoseconds. > + Terminating characters ('a') are in 66.666% of tested strings. > + I have added four new benchmarks which operate on a random length strings (32 characters being the average) of type either StringLatin1 of StringUTF16 and call indexOf(char) or indexOf(String). > > I have included below the output of these four tests below: > > Without the new StringLatin1 indexOf(char) intrinsic: > > Benchmark Mode Cnt Score Error Units > IndexOfBenchmark.latin1_mixed_char avgt 5 26389.129 ? 182.581 ns/op > IndexOfBenchmark.utf16_mixed_char avgt 5 17885.383 ? 435.933 ns/op > > > With the new StringLatin1 indexOf(char) intrinsic: > > Benchmark Mode Cnt Score Error Units > IndexOfBenchmark.latin1_mixed_char avgt 5 17875.185 ? 407.716 ns/op > IndexOfBenchmark.utf16_mixed_char avgt 5 18292.802 ? 167.306 ns/op > > The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when running on ARM. > > Regards, > Jason From rriggs at openjdk.java.net Tue Sep 8 15:30:06 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 8 Sep 2020 15:30:06 GMT Subject: RFR: 8252830: Added missing javadoc comments in java.rmi Message-ID: 8252830: Added missing javadoc comments in java.rmi ------------- Commit messages: - Added missing comments in java.rmi Changes: https://git.openjdk.java.net/jdk/pull/79/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=79&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252830 Stats: 28 lines in 4 files changed: 27 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/79.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/79/head:pull/79 PR: https://git.openjdk.java.net/jdk/pull/79 From rriggs at openjdk.java.net Tue Sep 8 15:30:06 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 8 Sep 2020 15:30:06 GMT Subject: RFR: 8252830: Added missing javadoc comments in java.rmi In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 15:19:40 GMT, Roger Riggs wrote: > 8252830: Added missing javadoc comments in java.rmi Add the missing comments where required by javadoc -Xdoclint to document public and serializable classes, methods, and fields. ------------- PR: https://git.openjdk.java.net/jdk/pull/79 From sean.mullan at oracle.com Tue Sep 8 16:15:56 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 8 Sep 2020 12:15:56 -0400 Subject: [aarch64-port-dev ] RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: <95965aeb-9d97-3b27-e684-967b6155eb34@redhat.com> References: <1729f1b1-056d-76c9-c820-d38bd6c1235d@redhat.com> <95965aeb-9d97-3b27-e684-967b6155eb34@redhat.com> Message-ID: Since this change affects security code, please make sure you add security-dev at openjdk.java.net on any followup code reviews. Thanks, Sean On 9/1/20 10:44 AM, Andrew Haley wrote: > On 01/09/2020 11:53, Yangfei (Felix) wrote: >> Sure, I am happy if the original author of the assembly code or someone else from Linaro could help here. >> I wasn't aware there was such an requirement here given that assembly code is licensed under GPL. > > There sure is. All code must be contributed by its owner and put on the > cr.openjdk site. Especially GPL code. > >> Should we separate the patch into two parts: changes for the shared code part and the aarch64 port-specific changes? > > I think not. > 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 dfuchs at openjdk.java.net Tue Sep 8 16:29:44 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 8 Sep 2020 16:29:44 GMT Subject: RFR: 8252830: Correct missing javadoc comments in java.rmi module In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 15:19:40 GMT, Roger Riggs wrote: > 8252830: Correct missing javadoc comments in java.rmi module Changes requested by dfuchs (Reviewer). src/java.rmi/share/classes/java/rmi/activation/ActivationGroupDesc.java line 321: > 319: * > 320: */ > 321: private void readObject(ObjectInputStream in) Hi Roger, you could take this opportunity to add the `@Serial` annotation to this method (here and in the other files you modified as well. src/java.rmi/share/classes/java/rmi/activation/ActivationID.java line 235: > 233: * @throws IOException if an I/O error occurs > 234: **/ > 235: private void writeObject(ObjectOutputStream out) Same comment as above... ------------- PR: https://git.openjdk.java.net/jdk/pull/79 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 mandy.chung at oracle.com Tue Sep 8 17:36:53 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Sep 2020 10:36:53 -0700 Subject: JDK 15 hidden classes & stack trace visibility In-Reply-To: References: <004c01d6837b$6545fd30$2fd1f790$@apache.org> Message-ID: Can you use StackWalker with StackWalker.Option::SHOW_HIDDEN_FRAMES to programmatically find the appropriate frame as an interim solution? ClassOption.SHOW_IN_STACKTRACE might be one possibility. ? IMO we should take the time and consider together with JDK-8212620 what other options could be explored before we provide an easy simple fix just for this specific case. Mandy On 9/7/20 11:39 AM, Uwe Schindler wrote: > Thanks Mandy. > > In my opinion for the hidden classes an additional enum constant in > ClassOption would be fine: ClassOption.SHOW_IN_STACKTRACE (or similar). > > That would be simplest to implement and allows also for the caller to > enable it like strong references or nestmate features. So it's > consistent with the other API parts. > > The annotations are good for fine granular hiding (like complex > classes recursively calling methods). Or for frameworks like Spring. > > Should I add a comment to this issue? > > We are now doing some testing in Lucene's expressions module (it's > about scoring formulas in query execution). Here's the draft PR: > https://github.com/apache/lucene-solr/pull/1837/files > > > We use the new features in Lucene when the static initializer detects > defineHiddenClass using a publicLookup. > > Currently a test fails, because of missing debug information in stack > traces. The executed scoring formula is part of the filename attribute > in class file. As this is missing, test fails. ?? > > Uwe > > Am September 7, 2020 4:44:18 PM UTC schrieb Mandy Chung > : > > Hi Uwe, > > It's a future enhancement to allow a class/method to request > filtering from stack trace: > https://bugs.openjdk.java.net/browse/JDK-8212620 > > This RFE should also take hidden classes into account. > > Mandy > > On 9/5/20 4:55 AM, Uwe Schindler wrote: >> Hi, >> >> I am doing a mockup for dynamically compiled scripts in Apache Lucene (later >> also painless scripting in elastcsearch), where I tried to use >> Lookup#defineHiddenClass (with default parameters, so weak and no nestmates >> - but: for painless scripts of Elasticsearch, nestmates will be great). It >> all looks great, as sometimes for every query a new class is generated. >> >> The current approach (Java 8, Java 11) uses a Classloader per script, which >> is mostly OK, but hidden classes would be better, especially under high load >> with many new classes. The problem I see is: The hidden class and their >> methods are also hidden from stack traces, so people neither get the script >> source code reference, nor they get the method, which was called at all. >> >> My question is: is it possible to mark such a hidden class in byte code or >> by a flag to defineHiddenClass() so it is "unhidden"? - I know you can do >> this by a command line option, but that's for developers and debugging only. >> In some cases, this is really wanted (like for scripting languages), but >> code still wants to use the better class unloading. If this is not possible, >> how about extending the Lookup.ClassOption enum (last parameter of >> defineHiddenClass), to also pass a flag to show them in stack traces? >> >> Uwe >> >> ----- >> Uwe Schindler >> uschindler at apache.org >> ASF Member, Apache Lucene PMC / Committer >> Bremen, Germany >> https://lucene.apache.org/ >> >> > From rriggs at openjdk.java.net Tue Sep 8 18:55:40 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 8 Sep 2020 18:55:40 GMT Subject: RFR: 8252830: Correct missing javadoc comments in java.rmi module [v2] In-Reply-To: References: Message-ID: > 8252830: Correct missing javadoc comments in java.rmi module Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Added @java.io.Serial annotation to serializable methods and fields ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/79/files - new: https://git.openjdk.java.net/jdk/pull/79/files/448061c0..8aeaf5ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=79&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=79&range=00-01 Stats: 10 lines in 4 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/79.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/79/head:pull/79 PR: https://git.openjdk.java.net/jdk/pull/79 From lancea at openjdk.java.net Tue Sep 8 19:03:57 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Sep 2020 19:03:57 GMT Subject: RFR: 8252830: Correct missing javadoc comments in java.rmi module [v2] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 18:55:40 GMT, Roger Riggs wrote: >> 8252830: Correct missing javadoc comments in java.rmi module > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Added @java.io.Serial annotation to serializable methods and fields Hi Roger, The combined changes to both commits look good ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/79 From erikj at openjdk.java.net Tue Sep 8 19:27:08 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Sep 2020 19:27:08 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. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/80 From dfuchs at openjdk.java.net Tue Sep 8 19:40:25 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 8 Sep 2020 19:40:25 GMT Subject: RFR: 8252830: Correct missing javadoc comments in java.rmi module [v2] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 18:55:40 GMT, Roger Riggs wrote: >> 8252830: Correct missing javadoc comments in java.rmi module > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Added @java.io.Serial annotation to serializable methods and fields Otherwise looks good. src/java.rmi/share/classes/java/rmi/activation/ActivationID.java line 236: > 234: * @throws IOException if an I/O error occurs > 235: **/ > 236: private void writeObject(ObjectOutputStream out) one `@Serial` still missing here? ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/79 From rriggs at openjdk.java.net Tue Sep 8 19:44:21 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 8 Sep 2020 19:44:21 GMT Subject: RFR: 8252830: Correct missing javadoc comments in java.rmi module [v3] In-Reply-To: References: Message-ID: > 8252830: Correct missing javadoc comments in java.rmi module Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Added java.io.Serial to java.rmi.activation.ActivationID ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/79/files - new: https://git.openjdk.java.net/jdk/pull/79/files/8aeaf5ed..c5813e9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=79&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=79&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/79.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/79/head:pull/79 PR: https://git.openjdk.java.net/jdk/pull/79 From lancea at openjdk.java.net Tue Sep 8 19:48:17 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Sep 2020 19:48:17 GMT Subject: RFR: 8252830: Correct missing javadoc comments in java.rmi module [v3] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 19:44:21 GMT, Roger Riggs wrote: >> 8252830: Correct missing javadoc comments in java.rmi module > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Added java.io.Serial to java.rmi.activation.ActivationID Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/79 From dfuchs at openjdk.java.net Tue Sep 8 19:48:17 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 8 Sep 2020 19:48:17 GMT Subject: RFR: 8252830: Correct missing javadoc comments in java.rmi module [v3] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 19:44:21 GMT, Roger Riggs wrote: >> 8252830: Correct missing javadoc comments in java.rmi module > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Added java.io.Serial to java.rmi.activation.ActivationID Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/79 From github.com+5246810+eamonnmcmanus at openjdk.java.net Tue Sep 8 20:24:51 2020 From: github.com+5246810+eamonnmcmanus at openjdk.java.net (=?UTF-8?B?w4lhbW9ubg==?= McManus) Date: Tue, 8 Sep 2020 20:24:51 GMT Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 15:25:10 GMT, rgiulietti wrote: > This is a follow-up of the Mercurial-based workflow initiated on the core-lib-devs mailing list [0]. Not sure if this > one is strictly necessary or if the patches sent on the list are sufficient. Anyway, I exploit this PR as a test ;-) > [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068474.html src/java.base/share/classes/java/lang/Long.java line 1675: > 1673: final long q = (dividend >>> 1) / divisor << 1; > 1674: final long r = dividend - q * divisor; > 1675: return q + ((r | ~(r - divisor)) >>> Long.SIZE - 1); I think it would be worth parenthesizing the right hand size of the `>>>` operator here too. src/java.base/share/classes/java/lang/Long.java line 1677: > 1675: return q + ((r | ~(r - divisor)) >>> Long.SIZE - 1); > 1676: } > 1677: return (dividend & ~(dividend - divisor)) >>> Long.SIZE - 1; Parenthesize RHS? ------------- PR: https://git.openjdk.java.net/jdk/pull/31 From github.com+5246810+eamonnmcmanus at openjdk.java.net Tue Sep 8 20:33:03 2020 From: github.com+5246810+eamonnmcmanus at openjdk.java.net (=?UTF-8?B?w4lhbW9ubg==?= McManus) Date: Tue, 8 Sep 2020 20:33:03 GMT Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 15:25:10 GMT, rgiulietti wrote: > This is a follow-up of the Mercurial-based workflow initiated on the core-lib-devs mailing list [0]. Not sure if this > one is strictly necessary or if the patches sent on the list are sufficient. Anyway, I exploit this PR as a test ;-) > [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068474.html src/java.base/share/classes/java/lang/Long.java line 1697: > 1695: final long q = (dividend >>> 1) / divisor << 1; > 1696: final long r = dividend - q * divisor; > 1697: return r - (~(r - divisor) >> Long.SIZE - 1 & divisor); Parentheses would be particularly helpful here. I'd certainly have to think hard about the relative precedences of `>>`, `-`, and `&`, whereas I wouldn't have to with: return r - ((~(r - divisor) >> (Long.SIZE - 1)) & divisor); I also think it would be worth adding a comment saying that this is deliberately `>>` not `>>>`, even though we have `>>>` in the divide method. Here we're propagating the sign bit so that `thing & divisor` is either 0 or `divisor` according as `thing` is ?1 or 0. ------------- PR: https://git.openjdk.java.net/jdk/pull/31 From github.com+70726043+rgiulietti at openjdk.java.net Tue Sep 8 20:45:15 2020 From: github.com+70726043+rgiulietti at openjdk.java.net (rgiulietti) Date: Tue, 8 Sep 2020 20:45:15 GMT Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 20:30:36 GMT, ?amonn McManus wrote: >> This is a follow-up of the Mercurial-based workflow initiated on the core-lib-devs mailing list [0]. Not sure if this >> one is strictly necessary or if the patches sent on the list are sufficient. Anyway, I exploit this PR as a test ;-) >> [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068474.html > > src/java.base/share/classes/java/lang/Long.java line 1697: > >> 1695: final long q = (dividend >>> 1) / divisor << 1; >> 1696: final long r = dividend - q * divisor; >> 1697: return r - (~(r - divisor) >> Long.SIZE - 1 & divisor); > > Parentheses would be particularly helpful here. I'd certainly have to think hard about the relative precedences of > `>>`, `-`, and `&`, whereas I wouldn't have to with: return r - ((~(r - divisor) >> (Long.SIZE - 1)) & divisor); > > I also think it would be worth adding a comment saying that this is deliberately `>>` not `>>>`, even though we have > `>>>` in the divide method. Here we're propagating the sign bit so that `thing & divisor` is either 0 or `divisor` > according as `thing` is ?1 or 0. Hi ?amonn, I have no problems adding non-strictly needed parentheses. I usually don't because I'm quite familiar with operator precedence and often forget that other people are not. I'll add comments for parts, like the one you point out, that are not already discussed at length in the bibliographical reference. Thanks Raffaello ------------- PR: https://git.openjdk.java.net/jdk/pull/31 From smarks at openjdk.java.net Tue Sep 8 21:41:27 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 8 Sep 2020 21:41:27 GMT Subject: RFR: 8252830: Correct missing javadoc comments in java.rmi module [v3] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 19:44:21 GMT, Roger Riggs wrote: >> 8252830: Correct missing javadoc comments in java.rmi module > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Added java.io.Serial to java.rmi.activation.ActivationID Marked as reviewed by smarks (Reviewer). src/java.rmi/share/classes/java/rmi/server/RemoteObject.java line 368: > 366: @java.io.Serial > 367: private void writeObject(java.io.ObjectOutputStream out) > 368: throws java.io.IOException It's a little odd to see an import of java.io.IOException (which is used by the `@throws` tag) but not to have it used here. There's another occurrence down below. These files have a mixture of imports and fully qualified names, which I find irritating, which might be nice to clean up. But you might find beyond the scope of this change. So, clean up as much of this as you like, or none if you prefer, no big deal. ------------- PR: https://git.openjdk.java.net/jdk/pull/79 From github.com+70726043+rgiulietti at openjdk.java.net Tue Sep 8 22:05:13 2020 From: github.com+70726043+rgiulietti at openjdk.java.net (rgiulietti) Date: Tue, 8 Sep 2020 22:05:13 GMT Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) [v2] In-Reply-To: References: Message-ID: <1afMfHAUJEnM5nUkl-LbkSxjYOZwjKgWu2NDIfhbc5U=.bbeab3f9-1278-4103-b5b3-dd9a2ae745a8@github.com> > This is a follow-up of the Mercurial-based workflow initiated on the core-lib-devs mailing list [0]. Not sure if this > one is strictly necessary or if the patches sent on the list are sufficient. Anyway, I exploit this PR as a test ;-) > [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068474.html rgiulietti has updated the pull request incrementally with one additional commit since the last revision: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) Added helpful parentheses and comments to clarify aspects not discussed in "Hacker's Delight". ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/31/files - new: https://git.openjdk.java.net/jdk/pull/31/files/6ae462c4..e1563721 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=31&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=31&range=00-01 Stats: 26 lines in 1 file changed: 20 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/31/head:pull/31 PR: https://git.openjdk.java.net/jdk/pull/31 From github.com+70726043+rgiulietti at openjdk.java.net Tue Sep 8 22:07:41 2020 From: github.com+70726043+rgiulietti at openjdk.java.net (rgiulietti) Date: Tue, 8 Sep 2020 22:07:41 GMT Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) [v2] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 20:42:41 GMT, rgiulietti wrote: >> src/java.base/share/classes/java/lang/Long.java line 1697: >> >>> 1695: final long q = (dividend >>> 1) / divisor << 1; >>> 1696: final long r = dividend - q * divisor; >>> 1697: return r - (~(r - divisor) >> Long.SIZE - 1 & divisor); >> >> Parentheses would be particularly helpful here. I'd certainly have to think hard about the relative precedences of >> `>>`, `-`, and `&`, whereas I wouldn't have to with: return r - ((~(r - divisor) >> (Long.SIZE - 1)) & divisor); >> >> I also think it would be worth adding a comment saying that this is deliberately `>>` not `>>>`, even though we have >> `>>>` in the divide method. Here we're propagating the sign bit so that `thing & divisor` is either 0 or `divisor` >> according as `thing` is ?1 or 0. > > Hi ?amonn, > > I have no problems adding non-strictly needed parentheses. I usually don't because I'm quite familiar with operator > precedence and often forget that other people are not. > I'll add comments for parts, like the one you point out, that are not already discussed at length in the > bibliographical reference. > Thanks > Raffaello Hi, I just committed the changes. Greetings Raffaello ------------- PR: https://git.openjdk.java.net/jdk/pull/31 From smarks at openjdk.java.net Tue Sep 8 22:39:10 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 8 Sep 2020 22:39:10 GMT Subject: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types Message-ID: Add some generics and wrap in `{@code}` to protect angle brackets. ------------- Commit messages: - 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types Changes: https://git.openjdk.java.net/jdk/pull/87/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=87&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8157729 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/87.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/87/head:pull/87 PR: https://git.openjdk.java.net/jdk/pull/87 From darcy at openjdk.java.net Tue Sep 8 22:51:08 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Sep 2020 22:51:08 GMT Subject: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 22:32:47 GMT, Stuart Marks wrote: > Add some generics and wrap in `{@code}` to protect angle brackets. Marked as reviewed by darcy (Reviewer). Looks fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/87 From naoto at openjdk.java.net Tue Sep 8 22:51:08 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 8 Sep 2020 22:51:08 GMT Subject: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 22:32:47 GMT, Stuart Marks wrote: > Add some generics and wrap in `{@code}` to protect angle brackets. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/87 From naoto at openjdk.java.net Tue Sep 8 22:51:08 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 8 Sep 2020 22:51:08 GMT Subject: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 22:47:40 GMT, Joe Darcy wrote: >> Add some generics and wrap in `{@code}` to protect angle brackets. > > Marked as reviewed by darcy (Reviewer). Looks good with the copyright year update. ------------- PR: https://git.openjdk.java.net/jdk/pull/87 From lancea at openjdk.java.net Tue Sep 8 22:55:12 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Sep 2020 22:55:12 GMT Subject: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 22:32:47 GMT, Stuart Marks wrote: > Add some generics and wrap in `{@code}` to protect angle brackets. Looks good ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/87 From smarks at openjdk.java.net Tue Sep 8 23:03:25 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 8 Sep 2020 23:03:25 GMT Subject: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types [v2] In-Reply-To: References: Message-ID: <3pKMNg64d_YDGLJr4f1CcxhCcgaQbw26ICU3Vf5FjCs=.56012406-2449-4d54-9c24-c0d23c043823@github.com> > Add some generics and wrap in `{@code}` to protect angle brackets. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Update copyright years. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/87/files - new: https://git.openjdk.java.net/jdk/pull/87/files/b40485ba..527d8a16 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=87&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=87&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/87.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/87/head:pull/87 PR: https://git.openjdk.java.net/jdk/pull/87 From lancea at openjdk.java.net Tue Sep 8 23:03:26 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Sep 2020 23:03:26 GMT Subject: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types [v2] In-Reply-To: <3pKMNg64d_YDGLJr4f1CcxhCcgaQbw26ICU3Vf5FjCs=.56012406-2449-4d54-9c24-c0d23c043823@github.com> References: <3pKMNg64d_YDGLJr4f1CcxhCcgaQbw26ICU3Vf5FjCs=.56012406-2449-4d54-9c24-c0d23c043823@github.com> Message-ID: On Tue, 8 Sep 2020 23:00:21 GMT, Stuart Marks wrote: >> Add some generics and wrap in `{@code}` to protect angle brackets. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/87 From smarks at openjdk.java.net Tue Sep 8 23:03:26 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 8 Sep 2020 23:03:26 GMT Subject: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types [v2] In-Reply-To: References: <3pKMNg64d_YDGLJr4f1CcxhCcgaQbw26ICU3Vf5FjCs=.56012406-2449-4d54-9c24-c0d23c043823@github.com> Message-ID: On Tue, 8 Sep 2020 22:58:58 GMT, Lance Andersen wrote: >> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright years. > > Marked as reviewed by lancea (Reviewer). Aha, I knew I forgot something! The copyright years. Actually, I did that on purpose...to practice updating an existing PR. Heh, heh, heh. BTW I believe this does not require a CSR since this is merely example code. Thanks for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/87 From naoto at openjdk.java.net Tue Sep 8 23:18:50 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 8 Sep 2020 23:18:50 GMT Subject: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types [v2] In-Reply-To: <3pKMNg64d_YDGLJr4f1CcxhCcgaQbw26ICU3Vf5FjCs=.56012406-2449-4d54-9c24-c0d23c043823@github.com> References: <3pKMNg64d_YDGLJr4f1CcxhCcgaQbw26ICU3Vf5FjCs=.56012406-2449-4d54-9c24-c0d23c043823@github.com> Message-ID: On Tue, 8 Sep 2020 23:03:25 GMT, Stuart Marks wrote: >> Add some generics and wrap in `{@code}` to protect angle brackets. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years. All good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/87 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 smarks at openjdk.java.net Wed Sep 9 00:46:34 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 9 Sep 2020 00:46:34 GMT Subject: Integrated: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 22:32:47 GMT, Stuart Marks wrote: > Add some generics and wrap in `{@code}` to protect angle brackets. This pull request has now been integrated. Changeset: 30fa8d5d Author: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/30fa8d5d Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types Reviewed-by: darcy, naoto, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/87 From eric.c.liu at arm.com Wed Sep 9 06:06:51 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Wed, 9 Sep 2020 06:06:51 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> , <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> Message-ID: Hi Kim, > Kim Barrett on Sent: 08 September 2020 20:28 ? >> On Sep 7, 2020, at 10:56 AM, Eric Liu wrote: >> I have tested 4 cases for those warnings: >> a) Without my patch, without asan, gcc-8 and gcc-10 are OK. >> b) Without my patch, with asan, gcc-8 has warned, gcc-10 is OK. >> c) With my patch, without asan, gcc-8 and gcc-10 are OK. > That?s *very* strange, since I get warnings in NetworkInterface getIndex and getFlags > with gcc10.2 + your patch. Sorry for the mistake, gcc-10 exactly warn?about my patch. >> d) With my patch, with asan, gcc-8 is OK, gcc-10 has warned. >> >> Those warnings can be reported by both gcc-8 and gcc-10 only when asan enabled. Without >> asan, no warning would be found even through some of them doesn't align with the documentation. >>> src/java.base/unix/native/libnet/NetworkInterface.c >>> 1298???? memset((char *)&if2, 0, sizeof(if2)); >>> 1299???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); >>> 1300???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; >>> >>> (in getIndex) >>> >>> So gcc8 does not warn about this, but gcc10 does? That would be a >>> regression in gcc10 (and should be reported as such), because the >>> documentation for -Wstringop-truncate is clear that the above is the >>> proper idiom for avoiding the warning. >> >> Yse, I followed the documentation and gcc-8 does not warn about this, but >> gcc-10 does (both with asan enabled). >> >>> Regardless, the memset on 1298 is useless.? The code from before >>> JDK-8250863 was the memset then the strncpy with >>> sizeof(if2.ifr_name)-1 as the bound, which worked because the memset >>> would have zeroed the last element. >>> >>> The change for JDK-8250863 did not follow the documented idiom though. >>> >>> It would be interesting to find out if removal of the memset changes >>> anything.? It's barely conceivable that it's confusing the heuristics >>> used to decide whether -Wstringop-truncation should trigger.? For >>> example, the compiler might decide that the subsequent assignment of >>> the last element is unnecessary because of the memset and optimize the >>> assignment away, removing the idiomatic warning suppression. >>> >>> If gcc10 still warns about the above after removing the memset then I >>> see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. >>> >>> Similarly for the strncpy in getFlags: >>> 1362???? memset((char *)&if2, 0, sizeof(if2)); >>> 1363???? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); >>> 1364???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; >> >> After removing the memset, gcc-10(10.1.0) still warns about it, gcc-8 and gcc-9 also. > I?m confused.? Above you said that with your patch + asan gcc-8 did not warn. > Maybe what you are saying is that *just* removing the memset, and not applying > your patch, for this case with asan warns with all of gcc-8,9,10? Sorry for my bad expression. Actually removing memset could not make things better. My patch + asan would annoy gcc-10, removing memset changed nothing. For gcc-8 and gcc-9 part, without my patch they would warn about with asan, and removing memset can not fix them as well. Thanks, Eric From shade at openjdk.java.net Wed Sep 9 06:28:11 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 9 Sep 2020 06:28:11 GMT Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) [v2] In-Reply-To: <1afMfHAUJEnM5nUkl-LbkSxjYOZwjKgWu2NDIfhbc5U=.bbeab3f9-1278-4103-b5b3-dd9a2ae745a8@github.com> References: <1afMfHAUJEnM5nUkl-LbkSxjYOZwjKgWu2NDIfhbc5U=.bbeab3f9-1278-4103-b5b3-dd9a2ae745a8@github.com> Message-ID: On Tue, 8 Sep 2020 22:05:13 GMT, rgiulietti wrote: >> This is a follow-up of the Mercurial-based workflow initiated on the core-lib-devs mailing list [0]. Not sure if this >> one is strictly necessary or if the patches sent on the list are sufficient. Anyway, I exploit this PR as a test ;-) >> [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068474.html > > rgiulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) > > Added helpful parentheses and comments to clarify aspects not discussed in "Hacker's Delight". Since this patch does not involve adding the intrinsic, maybe drop "(Needs to be intrinsic)" from the synopsis? ------------- PR: https://git.openjdk.java.net/jdk/pull/31 From chegar at openjdk.java.net Wed Sep 9 07:27:32 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 9 Sep 2020 07:27:32 GMT Subject: RFR: 8252830: Correct missing javadoc comments in java.rmi module [v3] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 19:44:21 GMT, Roger Riggs wrote: >> 8252830: Correct missing javadoc comments in java.rmi module > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Added java.io.Serial to java.rmi.activation.ActivationID Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/79 From github.com+70726043+rgiulietti at openjdk.java.net Wed Sep 9 07:41:13 2020 From: github.com+70726043+rgiulietti at openjdk.java.net (rgiulietti) Date: Wed, 9 Sep 2020 07:41:13 GMT Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) [v2] In-Reply-To: References: <1afMfHAUJEnM5nUkl-LbkSxjYOZwjKgWu2NDIfhbc5U=.bbeab3f9-1278-4103-b5b3-dd9a2ae745a8@github.com> Message-ID: On Wed, 9 Sep 2020 06:25:40 GMT, Aleksey Shipilev wrote: >> rgiulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) >> >> Added helpful parentheses and comments to clarify aspects not discussed in "Hacker's Delight". > > Since this patch does not involve adding the intrinsic, maybe drop "(Needs to be intrinsic)" from the synopsis? @shipilev I agree, but that's the title chosen by the reporter of the JBS issue. Not sure I can edit it without impacting bots and tools. ------------- PR: https://git.openjdk.java.net/jdk/pull/31 From gdub at openjdk.java.net Wed Sep 9 08:25:10 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Wed, 9 Sep 2020 08:25:10 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode Message-ID: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance behaviour of lambdas in either direction. ------------- Commit messages: - 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode Changes: https://git.openjdk.java.net/jdk/pull/93/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242451 Stats: 97 lines in 2 files changed: 73 ins; 5 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/93/head:pull/93 PR: https://git.openjdk.java.net/jdk/pull/93 From kustos at gmx.net Wed Sep 9 08:27:16 2020 From: kustos at gmx.net (Philippe Marschall) Date: Wed, 9 Sep 2020 10:27:16 +0200 Subject: How to proceed with 8138732 Message-ID: Hello I started working on 8138732 [2] as described in the issue [1]. However the question about the impact and coordination with other projects came up, eg.: - projects that implement their own intrinsics - Graal - somebody else? How do we want to address this and coordinate with these projects? Given all the possible impact do we still want the issue to be implemented as described? Or do we want to have it implemented differently or not at all? [1] https://bugs.openjdk.java.net/browse/JDK-8138732 [2] https://github.com/openjdk/jdk/pull/45 Cheers Philippe From Alan.Bateman at oracle.com Wed Sep 9 08:55:23 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 9 Sep 2020 09:55:23 +0100 Subject: How to proceed with 8138732 In-Reply-To: References: Message-ID: <3f54e471-596a-c18b-014b-4b57e55d65fa@oracle.com> On 09/09/2020 09:27, Philippe Marschall wrote: > Hello > > I started working on 8138732 [2] as described in the issue [1]. However > the question about the impact and coordination with other projects came > up, eg.: > > ?- projects that implement their own intrinsics > ?- Graal > ?- somebody else? > > How do we want to address this and coordinate with these projects? > > Given all the possible impact do we still want the issue to be > implemented as described? Or do we want to have it implemented > differently or not at all? Maybe Igor Veresov or someone else on hotspot-compiler-dev that is familiar with the process for pulling Graal compiler changes from upstream could comment in case there is coordination needed. It's just a move/rename so shouldn't be too disruptive. There are several projects in OpenJDK with additional instrinics and they'll just need to switch over when they pull the change from the main repo, shouldn't be an issue. I did comment on the update to java.base's module-info.java as I don't expect that jdk.internal needs to be exported to jdk.jfr with the change. Once @PreviewFeature moves to java.lang.annotation then that package will be likely be "empty" so won't be exported to anyone. -Alan 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 jlahoda at openjdk.java.net Wed Sep 9 12:21:25 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 9 Sep 2020 12:21:25 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: <9ARL_A2daS8-nEhhporpJpuRtdJJz8XY1mwyH_i99I8=.c3c3df72-8039-4243-b8c6-bd5040aabe64@github.com> On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java line 29: > 27: * @summary Add lambda tests > 28: * Test bridge methods for certain SAM conversions > 29: * Test the set of generate fields I would suggest to consider having the test under test/jdk/(java/lang/invoke/lambda), not under test/langtools/tools/javac. ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From galder at redhat.com Wed Sep 9 12:38:20 2020 From: galder at redhat.com (Galder Zamarreno) Date: Wed, 9 Sep 2020 14:38:20 +0200 Subject: RFR: JDK-8251397 NPE on ClassValue.ClassValueMap.cacheArray In-Reply-To: <99F198CA-B83B-4399-B337-B979570791AD@oracle.com> References: <99F198CA-B83B-4399-B337-B979570791AD@oracle.com> Message-ID: Hi Paul, Thanks a lot for the feedback. I've waited a bit before tackling your feedback to see if others would provide further feedback. Not yet able to create webrevs (not yet author), so I've gone ahead and created a PR with the updated changes [6]. Basically, I've moved the fence to `initializeMap` method. Indeed it felt like a better location. Also added the comment you suggested. Galder [6] https://github.com/openjdk/jdk/pull/94 On Wed, Aug 19, 2020 at 8:50 PM Paul Sandoz wrote: > Hi Galder, > > Thanks for doing the fix and the work verifying. > > I also verified using a fence fixes the jcstress test. Similarly, I found > I could only reproduce the issue in HotSpot when running a test more like > ClassValue (the double checked locking pattern when publishing to a plan > field) with the options -XX:+StressLCM -XX:+StressGCM. I analyzed assembler > output (-XX:+PrintOptoAssembly) to observe the publish store occurring > before some stores to fields. It?s highly likely that with HotSpot we got > lucky in this case :-) > > > I don?t object to the use of a release fence (LoadStore|StoreStore), but I > believe we could also use a StoreStore fence in this case. Perhaps the ARM > folks have a stronger opinion on this? > > > I marginally prefer placing the fence in the initializeMap, since the > relationship between construction and publish is very clear. In either case > I recommend adding a comment on why the fence is required e.g.: > > // Place a Store fence as the last operation of the constructor to emulate > // ClassValueMap containing final fields. This ensures it can be > // published safely in the non-volatile field Class.classValueMap, (see > initializeMap) > // since stores to the fields of ClassValueMap will not be reordered > // to occur after the store to the field type.classValueMap > > > I also noticed we can change the field Class.classValueMap to be @Stable, > but I think we should follow up on that investigation separately. > Relatedly, I had an idea to modify HotSpot so it places a StoreStore fence > directly before the store to a @Stable field. > > Paul. > > > On Aug 19, 2020, at 4:53 AM, Galder Zamarreno wrote: > > > > Hi all, > > > > I've created patch [1] to fix the ClassValue$ClassValueMap NPE bug in > [2]. > > > > The bug has been discussed by other members in the list in thread [3]. > > > > The patch follows the simple fix suggested by Doug and others in that > > exchange, e.g. [4]. That is, it adds a release fence > > to ClassValue$ClassValueMap constructor to avoid the NPE. > > > > To verify the fix, I ran the jcstress test that Paul posted in [5] and > > played around with the difference fixes suggested in the thread. Adding > the > > release fence did indeed fix the jcstress test. > > > > To further verify the issue, I've successfully run both the tier1 tests > and > > the Quarkus native testsuite with a Mandrel 20.1 built with JDK 11.0.8 > > version patched with the fix (higher JDKs not supported yet). Note that > > this NPE happens on rare occasions. > > > > The patch applies cleanly to JDK 11. > > > > Galder > > > > [1] Webrev: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/galder/JDK-8251397/01/webrev/ > > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8251397 > > [3] > > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068086.html > > [4] > > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068126.html > > [5] > > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068110.html > > From rriggs at openjdk.java.net Wed Sep 9 13:19:04 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 9 Sep 2020 13:19:04 GMT Subject: RFR: 8252830: Correct missing javadoc comments in java.rmi module [v3] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 07:24:57 GMT, Chris Hegarty wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Added java.io.Serial to java.rmi.activation.ActivationID > > Marked as reviewed by chegar (Reviewer). Hi Stuart, I'm going to leave this for later, its a bit out of scope and every change prompts the people who have already reviewed it to need to review it again. Thanks, Roger On 9/8/20 5:38 PM, Stuart Marks wrote: > > *@stuart-marks* commented on this pull request. > > ------------------------------------------------------------------------ > > In src/java.rmi/share/classes/java/rmi/server/RemoteObject.java > : > > > */ > + @java.io.Serial > private void writeObject(java.io.ObjectOutputStream out) > throws java.io.IOException > > It's a little odd to see an import of java.io.IOException (which is > used by the |@throws| tag) but not to have it used here. There's > another occurrence down below. These files have a mixture of imports > and fully qualified names, which I find irritating, which might be > nice to clean up. But you might find beyond the scope of this change. > So, clean up as much of this as you like, or none if you prefer, no > big deal. > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > ------------- PR: https://git.openjdk.java.net/jdk/pull/79 From coleenp at openjdk.java.net Wed Sep 9 14:22:05 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Sep 2020 14:22:05 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. Marked as reviewed by coleenp (Reviewer). src/hotspot/share/classfile/classLoaderDataShared.cpp line 132: > 130: assert(loader_data != NULL, "must be"); > 131: return loader_data; > 132: } This and other private functions should probably be a static function inside classLoaderDataShared.cpp. src/hotspot/share/classfile/classLoaderDataShared.hpp line 28: > 26: #define SHARE_CLASSFILE_CLASSLOADERDATASHARED_HPP > 27: > 28: #include "utilities/exceptions.hpp" There's a memory/allStatic.hpp file now that this should include. src/hotspot/share/classfile/modules.cpp line 495: > 493: } > 494: } > 495: #endif Nit: can you add // INCLUDE_CDS_JAVA_HEAP src/hotspot/share/classfile/classLoaderDataShared.cpp line 171: > 169: } > 170: > 171: void ClassLoaderDataShared::serialize(class SerializeClosure* f) { Why is there a 'class' keyword here? ------------- PR: https://git.openjdk.java.net/jdk/pull/80 From mchung at openjdk.java.net Wed Sep 9 16:39:20 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Sep 2020 16:39:20 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 215: > 213: if (disableEagerInitialization) { > 214: try { > 215: return new ConstantCallSite(caller.findStaticGetter(innerClass, LAMBDA_INSTANCE_FIELD, > invokedType.returnType())); Nit: it'd be good to wrap this long line. There are a couple long lines in this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From mchung at openjdk.java.net Wed Sep 9 16:43:45 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Sep 2020 16:43:45 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. Looks good. I agree with Jan's suggestion that it's good to move the test to test/jdk/java/lang/invoke/lambda which is a better home for it. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/93 From mchung at openjdk.java.net Wed Sep 9 16:43:45 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Sep 2020 16:43:45 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode In-Reply-To: <9ARL_A2daS8-nEhhporpJpuRtdJJz8XY1mwyH_i99I8=.c3c3df72-8039-4243-b8c6-bd5040aabe64@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> <9ARL_A2daS8-nEhhporpJpuRtdJJz8XY1mwyH_i99I8=.c3c3df72-8039-4243-b8c6-bd5040aabe64@github.com> Message-ID: On Wed, 9 Sep 2020 12:19:04 GMT, Jan Lahoda wrote: >> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the >> jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda >> classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the >> context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of >> non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas >> are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely >> _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and >> ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance >> behaviour of lambdas in either direction. > > test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java line 29: > >> 27: * @summary Add lambda tests >> 28: * Test bridge methods for certain SAM conversions >> 29: * Test the set of generate fields > > I would suggest to consider having the test under test/jdk/(java/lang/invoke/lambda), not under > test/langtools/tools/javac. It's a good suggestion as `disableEagerInitialization` support is not part of javac. ------------- PR: https://git.openjdk.java.net/jdk/pull/93 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 github.com+66382410+lfoltan at openjdk.java.net Wed Sep 9 18:49:12 2020 From: github.com+66382410+lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 9 Sep 2020 18:49:12 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. Thanks Ioi for addressing my review comments. Overall, looks great! src/hotspot/share/classfile/moduleEntry.cpp line 419: > 417: } > 418: > 419: GrowableArray* ModuleEntry::restore_growable_array(Array* archived_array) { Thanks for renaming these methods src/hotspot/share/oops/instanceKlass.cpp line 2550: > 2548: // clear _nest_host to ensure re-load at runtime > 2549: _nest_host = NULL; > 2550: _package_entry = NULL; // TODO -- point it to the archived PackageEntry (JDK-8249262) Would you consider removing this comment? I tend not to like TODO comments since sometimes the open enhancement remains unaddressed. ------------- Marked as reviewed by lfoltan at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/80 From cjashfor at linux.ibm.com Wed Sep 9 19:13:55 2020 From: cjashfor at linux.ibm.com (Corey Ashford) Date: Wed, 9 Sep 2020 12:13:55 -0700 Subject: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: <4bc83479-1ed9-8cd8-22a0-1f19f315df7e@oracle.com> References: <11ca749f-3015-c004-aa6b-3194e1dfe4eb@linux.ibm.com> <8ece8d2e-fd99-b734-211e-a32b534a7dc8@linux.ibm.com> <8d53dcf8-635a-11e2-4f6a-39b70e2c3b8b@oracle.com> <65ed7919-86fc-adfa-3cd5-58dd96a3487f@linux.ibm.com> <4bc83479-1ed9-8cd8-22a0-1f19f315df7e@oracle.com> Message-ID: On 9/4/20 8:07 AM, Roger Riggs wrote: > Hi Corey, > > The idea I had in mind is refactoring the fast path into the method you > call decodeBlock. > Base64: lines 751-768. > > It leaves all the unknown/illegal character handling to the Java code. > And yes, it does not need to handle MIME, except to return on illegal > characters. > > The patch is attached. Ah, I see what you mean now, and thanks for the patch! The patch as presented doesn't work, however, because the intrinsic processes fewer bytes than are in the src buffer, and then executes a "continue;", which then proceeds to loop infinitely because the intrinsic won't process any more bytes after that. I tried dropping the continue, but that doesn't work because the Java (non-intrinsic) code processes all of the bytes, and the line of code following the loop accesses one byte after the end of the src buffer causing an array bounds error. So this needs to be re-thought a little, but it shouldn't be too difficult. I will work on it. Regards, - Corey > > Regards, Roger > > > > On 8/31/20 6:22 PM, Corey Ashford wrote: >> On 8/29/20 1:19 PM, Corey Ashford wrote: >>> Hi Roger, >>> >>> Thanks for your reply and thoughts!? Comments interspersed below: >>> >>> On 8/28/20 10:54 AM, Roger Riggs wrote: >> ... >>>> Comparing with the way that the Base64 encoder was intrinsified, the >>>> method that is intrinsified should have a method body that does >>>> the same function, so it is interchangable.? That likely will just >>>> shift >>>> the "fast path" code into the decodeBlock method. >>>> Keeping the symmetry between encoder and decoder will >>>> make it easier to maintain the code. >>> >>> Good point.? I'll investigate what this looks like in terms of the >>> actual code, and will report back (perhaps in a new webrev). >>> >> >> Having looked at this again, I don't think it makes sense.? One thing >> that differs significantly from the encodeBlock intrinsic is that the >> decodeBlock intrinsic only needs to process a prefix of the data, and >> so it can leave virtually any amount of data at the end of the src >> buffer unprocessed, where as with the encodeBlock intrinsic, if it >> exists, it must process the entire buffer. >> >> In the (common) case where the decodeBlock intrinsic returns not >> having processed everything, it still needs to call the Java code, and >> if that Java code is "replaced" by the intrinsic, it's inaccessible. >> >> Is there something I'm overlooking here?? Basically I want the decode >> API to behave differently than the encode API, mostly to make the >> arch-specific intrinsic easier to implement. If that's not acceptable, >> then I need to rethink the API, and also figure out how to deal with >> the illegal character case.? The latter could perhaps be done by >> throwing an exception from the intrinsic, or maybe by returning a >> negative length that specifies the index of the illegal src byte, and >> then have the Java code throw the exception). >> >> Regards, >> >> - Corey >> > From jptatton at amazon.com Wed Sep 9 19:17:17 2020 From: jptatton at amazon.com (Tatton, Jason) Date: Wed, 9 Sep 2020 19:17:17 +0000 Subject: JDK-8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <445645fe-b4b1-0c48-0191-8f71f17f0042@oracle.com> References: <0cbe7d8f594349b59504c42f89c6f268@EX13D46EUB003.ant.amazon.com> <445645fe-b4b1-0c48-0191-8f71f17f0042@oracle.com> Message-ID: <4ca5d5da2d404f4cbe205af36af4e5b0@EX13D46EUB003.ant.amazon.com> Hi Roger, Thanks for your question. The code path for UTF16 has hasn't been interacted with in a meaningful way in this patch so I think this is just noise. To validate this hypothesis I re-ran the benchmark with 10 forks (default is 5), the results indicate that the performance of the UTF16 implementation of indexOf(char) has not been materially changed: Without the new StringLatin1 indexOf(char) intrinsic: Benchmark Mode Cnt Score Error Units IndexOfBenchmark.latin1_mixed_char avgt 25 27550.832 ? 347.570 ns/op IndexOfBenchmark.utf16_mixed_char avgt 25 18472.190 ? 219.185 ns/op With the new StringLatin1 indexOf(char) intrinsic: Benchmark Mode Cnt Score Error Units IndexOfBenchmark.latin1_mixed_char avgt 5 17806.338 ? 217.399 ns/op IndexOfBenchmark.utf16_mixed_char avgt 5 18276.366 ? 470.528 ns/op In fact, on this run the performance of utf16 was better than without this patch, this is however a 1% improvement which fits within the error range seen on these tests of between 1-2%. So I think it's fair to say that this patch has no effect on the performance of the existing StringUTF16 indexOf(char) method. -----Original Message----- From: core-libs-dev On Behalf Of Roger Riggs Sent: 08 September 2020 15:54 To: core-libs-dev at openjdk.java.net Subject: RE: [EXTERNAL] JDK-8173585: Intrinsify StringLatin1.indexOf(char) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Jason, With respect to the increased ns/op in the utf16_mixed_char benchmark, how should we understand the lower performance? Thanks, Roger On 9/8/20 8:02 AM, Tatton, Jason wrote: > Hi Andrew, thank you for taking the time to review this. > > Since we have now moved to git, I have raised a new PR for this RFR: > > https://github.com/openjdk/jdk/pull/71 > https://bugs.openjdk.java.net/browse/JDK-8173585 > > I have improved the micro benchmark in the ways which you and others have requested, namely: > + The benchmark is now included in test/micro/org/openjdk/bench/java/lang as StringIndexOfChar (as advised by my colleagues here at AWS; Xin Liu and Volker Simonis). > + Times are now in nanoseconds. > + Terminating characters ('a') are in 66.666% of tested strings. > + I have added four new benchmarks which operate on a random length strings (32 characters being the average) of type either StringLatin1 of StringUTF16 and call indexOf(char) or indexOf(String). > > I have included below the output of these four tests below: > > Without the new StringLatin1 indexOf(char) intrinsic: > > Benchmark Mode Cnt Score Error Units > IndexOfBenchmark.latin1_mixed_char avgt 5 26389.129 ? 182.581 ns/op > IndexOfBenchmark.utf16_mixed_char avgt 5 17885.383 ? 435.933 ns/op > > > With the new StringLatin1 indexOf(char) intrinsic: > > Benchmark Mode Cnt Score Error Units > IndexOfBenchmark.latin1_mixed_char avgt 5 17875.185 ? 407.716 ns/op > IndexOfBenchmark.utf16_mixed_char avgt 5 18292.802 ? 167.306 ns/op > > The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when running on ARM. > > Regards, > Jason From vsharma at openjdk.java.net Wed Sep 9 19:38:56 2020 From: vsharma at openjdk.java.net (Vipin Sharma) Date: Wed, 9 Sep 2020 19:38:56 GMT Subject: RFR: 8252537: Updated @exception with @throws Message-ID: Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. Open Subtasks part of this fix are: 1. JDK-8252537 2. JDK-8252539 3. JDK-8252540 4. JDK-8252541 ------------- Commit messages: - JDK-8252537 Updated @exception with @throws Changes: https://git.openjdk.java.net/jdk/pull/95/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=95&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252537 Stats: 1585 lines in 86 files changed: 0 ins; 0 del; 1585 mod Patch: https://git.openjdk.java.net/jdk/pull/95.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/95/head:pull/95 PR: https://git.openjdk.java.net/jdk/pull/95 From mchung at openjdk.java.net Wed Sep 9 19:43:59 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Sep 2020 19:43:59 GMT Subject: RFR: 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError Message-ID: `jlink --generate-jli-classes` plugin should retain the original holder classes if the default_jli_trace.txt file does not exist. Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes` methods are invoked unconditionally and therefore the holder classes are "regenerated" when default_jli_trace.txt does not exist. JDK-8252725 does not handle this case properly and results in an image missing the holder classes when the specified trace file does not exist. The fix is very simple. Retains the original holder classes when the file does not exist. ------------- Commit messages: - 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError: DirectMethodHandle Changes: https://git.openjdk.java.net/jdk/pull/96/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=96&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252919 Stats: 47 lines in 2 files changed: 36 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/96.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/96/head:pull/96 PR: https://git.openjdk.java.net/jdk/pull/96 From Roger.Riggs at oracle.com Wed Sep 9 21:04:21 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 9 Sep 2020 17:04:21 -0400 Subject: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: <11ca749f-3015-c004-aa6b-3194e1dfe4eb@linux.ibm.com> <8ece8d2e-fd99-b734-211e-a32b534a7dc8@linux.ibm.com> <8d53dcf8-635a-11e2-4f6a-39b70e2c3b8b@oracle.com> <65ed7919-86fc-adfa-3cd5-58dd96a3487f@linux.ibm.com> <4bc83479-1ed9-8cd8-22a0-1f19f315df7e@oracle.com> Message-ID: <196a4e58-0710-2f3e-6d1b-e78ab03a185d@oracle.com> Hi Corey, Right,? the continue was so it would go back and check if the conversion was complete.? An alternative would be to repeat the check and return if there was no bytes left to process. Thanks, Roger On 9/9/20 3:13 PM, Corey Ashford wrote: > On 9/4/20 8:07 AM, Roger Riggs wrote: >> Hi Corey, >> >> The idea I had in mind is refactoring the fast path into the method >> you call decodeBlock. >> Base64: lines 751-768. >> >> It leaves all the unknown/illegal character handling to the Java code. >> And yes, it does not need to handle MIME, except to return on illegal >> characters. >> >> The patch is attached. > > Ah, I see what you mean now, and thanks for the patch!? The patch as > presented doesn't work, however, because the intrinsic processes fewer > bytes than are in the src buffer, and then executes a "continue;", > which then proceeds to loop infinitely because the intrinsic won't > process any more bytes after that. > > I tried dropping the continue, but that doesn't work because the Java > (non-intrinsic) code processes all of the bytes, and the line of code > following the loop accesses one byte after the end of the src buffer > causing an array bounds error. > > So this needs to be re-thought a little, but it shouldn't be too > difficult.? I will work on it. > > Regards, > > - Corey > >> >> Regards, Roger >> >> >> >> On 8/31/20 6:22 PM, Corey Ashford wrote: >>> On 8/29/20 1:19 PM, Corey Ashford wrote: >>>> Hi Roger, >>>> >>>> Thanks for your reply and thoughts!? Comments interspersed below: >>>> >>>> On 8/28/20 10:54 AM, Roger Riggs wrote: >>> ... >>>>> Comparing with the way that the Base64 encoder was intrinsified, the >>>>> method that is intrinsified should have a method body that does >>>>> the same function, so it is interchangable.? That likely will just >>>>> shift >>>>> the "fast path" code into the decodeBlock method. >>>>> Keeping the symmetry between encoder and decoder will >>>>> make it easier to maintain the code. >>>> >>>> Good point.? I'll investigate what this looks like in terms of the >>>> actual code, and will report back (perhaps in a new webrev). >>>> >>> >>> Having looked at this again, I don't think it makes sense. One thing >>> that differs significantly from the encodeBlock intrinsic is that >>> the decodeBlock intrinsic only needs to process a prefix of the >>> data, and so it can leave virtually any amount of data at the end of >>> the src buffer unprocessed, where as with the encodeBlock intrinsic, >>> if it exists, it must process the entire buffer. >>> >>> In the (common) case where the decodeBlock intrinsic returns not >>> having processed everything, it still needs to call the Java code, >>> and if that Java code is "replaced" by the intrinsic, it's >>> inaccessible. >>> >>> Is there something I'm overlooking here?? Basically I want the >>> decode API to behave differently than the encode API, mostly to make >>> the arch-specific intrinsic easier to implement. If that's not >>> acceptable, then I need to rethink the API, and also figure out how >>> to deal with the illegal character case. The latter could perhaps be >>> done by throwing an exception from the intrinsic, or maybe by >>> returning a negative length that specifies the index of the illegal >>> src byte, and then have the Java code throw the exception). >>> >>> Regards, >>> >>> - Corey >>> >> > From Roger.Riggs at oracle.com Wed Sep 9 21:05:34 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 9 Sep 2020 17:05:34 -0400 Subject: JDK-8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <4ca5d5da2d404f4cbe205af36af4e5b0@EX13D46EUB003.ant.amazon.com> References: <0cbe7d8f594349b59504c42f89c6f268@EX13D46EUB003.ant.amazon.com> <445645fe-b4b1-0c48-0191-8f71f17f0042@oracle.com> <4ca5d5da2d404f4cbe205af36af4e5b0@EX13D46EUB003.ant.amazon.com> Message-ID: <86724624-addb-cfc0-1813-7acc0ef4af06@oracle.com> Hi Jason, Thanks for checking, the difference of the utf16 numbers seemed to be just outside of the error range. Regards, Roger On 9/9/20 3:17 PM, Tatton, Jason wrote: > Hi Roger, > > Thanks for your question. The code path for UTF16 has hasn't been interacted with in a meaningful way in this patch so I think this is just noise. To validate this hypothesis I re-ran the benchmark with 10 forks (default is 5), the results indicate that the performance of the UTF16 implementation of indexOf(char) has not been materially changed: > > Without the new StringLatin1 indexOf(char) intrinsic: > Benchmark Mode Cnt Score Error Units > IndexOfBenchmark.latin1_mixed_char avgt 25 27550.832 ? 347.570 ns/op > IndexOfBenchmark.utf16_mixed_char avgt 25 18472.190 ? 219.185 ns/op > > > With the new StringLatin1 indexOf(char) intrinsic: > Benchmark Mode Cnt Score Error Units > IndexOfBenchmark.latin1_mixed_char avgt 5 17806.338 ? 217.399 ns/op > IndexOfBenchmark.utf16_mixed_char avgt 5 18276.366 ? 470.528 ns/op > > In fact, on this run the performance of utf16 was better than without this patch, this is however a 1% improvement which fits within the error range seen on these tests of between 1-2%. So I think it's fair to say that this patch has no effect on the performance of the existing StringUTF16 indexOf(char) method. > > -----Original Message----- > From: core-libs-dev On Behalf Of Roger Riggs > Sent: 08 September 2020 15:54 > To: core-libs-dev at openjdk.java.net > Subject: RE: [EXTERNAL] JDK-8173585: Intrinsify StringLatin1.indexOf(char) > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi Jason, > > With respect to the increased ns/op in the utf16_mixed_char benchmark, how should we understand the lower performance? > > Thanks, Roger > > > On 9/8/20 8:02 AM, Tatton, Jason wrote: >> Hi Andrew, thank you for taking the time to review this. >> >> Since we have now moved to git, I have raised a new PR for this RFR: >> >> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/71__;!!GqivPVa7Brio!NewvwHYXhjOSSwNJArOOHrkBu818bCSzfDOe8hgvEM5idglmYuTub0vn0Ydzi02o$ >> https://bugs.openjdk.java.net/browse/JDK-8173585 >> >> I have improved the micro benchmark in the ways which you and others have requested, namely: >> + The benchmark is now included in test/micro/org/openjdk/bench/java/lang as StringIndexOfChar (as advised by my colleagues here at AWS; Xin Liu and Volker Simonis). >> + Times are now in nanoseconds. >> + Terminating characters ('a') are in 66.666% of tested strings. >> + I have added four new benchmarks which operate on a random length strings (32 characters being the average) of type either StringLatin1 of StringUTF16 and call indexOf(char) or indexOf(String). >> >> I have included below the output of these four tests below: >> >> Without the new StringLatin1 indexOf(char) intrinsic: >> >> Benchmark Mode Cnt Score Error Units >> IndexOfBenchmark.latin1_mixed_char avgt 5 26389.129 ? 182.581 ns/op >> IndexOfBenchmark.utf16_mixed_char avgt 5 17885.383 ? 435.933 ns/op >> >> >> With the new StringLatin1 indexOf(char) intrinsic: >> >> Benchmark Mode Cnt Score Error Units >> IndexOfBenchmark.latin1_mixed_char avgt 5 17875.185 ? 407.716 ns/op >> IndexOfBenchmark.utf16_mixed_char avgt 5 18292.802 ? 167.306 ns/op >> >> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when running on ARM. >> >> Regards, >> Jason From iklam at openjdk.java.net Wed Sep 9 21:58:24 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 21:58:24 GMT Subject: RFR: 8244778: Archive full module graph in CDS [v2] In-Reply-To: References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: <62HGLspnAFezsLXCpQn7kBBlBiOYnPxLXfF2xImO5m0=.c44b6297-ee33-4ee6-a049-2701f7f80813@github.com> On Wed, 9 Sep 2020 18:41:25 GMT, Lois Foltan wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes >> the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last >> revision: >> - Removed TODO comment referring to JBS issue >> - Merge branch 'master' into 8244778-archive-full-module-graph >> - fixed trailing spaces >> - Renamed ModuleEntry::write_growable_array >> - Update to latest repo (JDK-8251557); added comments >> - 8244778: Archive full module graph in CDS > > src/hotspot/share/oops/instanceKlass.cpp line 2550: > >> 2548: // clear _nest_host to ensure re-load at runtime >> 2549: _nest_host = NULL; >> 2550: _package_entry = NULL; // TODO -- point it to the archived PackageEntry (JDK-8249262) > > Would you consider removing this comment? I tend not to like TODO comments since sometimes the open enhancement > remains unaddressed. I removed the comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/80 From iklam at openjdk.java.net Wed Sep 9 21:58:16 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 21:58:16 GMT Subject: RFR: 8244778: Archive full module graph in CDS [v2] In-Reply-To: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: > 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. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Removed TODO comment referring to JBS issue - Merge branch 'master' into 8244778-archive-full-module-graph - fixed trailing spaces - Renamed ModuleEntry::write_growable_array - Update to latest repo (JDK-8251557); added comments - 8244778: Archive full module graph in CDS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/80/files - new: https://git.openjdk.java.net/jdk/pull/80/files/89f33274..92b4202b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=00-01 Stats: 439 lines in 53 files changed: 165 ins; 162 del; 112 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 minqi at openjdk.java.net Wed Sep 9 21:59:07 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 9 Sep 2020 21:59:07 GMT Subject: RFR: 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote: > `jlink --generate-jli-classes` plugin should retain the original holder classes if the default_jli_trace.txt > file does not exist. > > Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes` methods are invoked > unconditionally and therefore the holder classes are "regenerated" when default_jli_trace.txt > does not exist. JDK-8252725 does not handle this case properly and results in an image missing > the holder classes when the specified trace file does not exist. > > The fix is very simple. Retains the original holder classes when the file does not exist. Looks good! ------------- PR: https://git.openjdk.java.net/jdk/pull/96 From minqi at openjdk.java.net Wed Sep 9 22:03:00 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 9 Sep 2020 22:03:00 GMT Subject: RFR: 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote: > `jlink --generate-jli-classes` plugin should retain the original holder classes if the default_jli_trace.txt > file does not exist. > > Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes` methods are invoked > unconditionally and therefore the holder classes are "regenerated" when default_jli_trace.txt > does not exist. JDK-8252725 does not handle this case properly and results in an image missing > the holder classes when the specified trace file does not exist. > > The fix is very simple. Retains the original holder classes when the file does not exist. Marked as reviewed by minqi (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/96 From iklam at openjdk.java.net Wed Sep 9 22:08:26 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 22:08:26 GMT Subject: RFR: 8244778: Archive full module graph in CDS [v3] In-Reply-To: References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: On Tue, 8 Sep 2020 17:32:44 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback from Coleen > > src/hotspot/share/classfile/classLoaderDataShared.cpp line 171: > >> 169: } >> 170: >> 171: void ClassLoaderDataShared::serialize(class SerializeClosure* f) { > > Why is there a 'class' keyword here? I fixed this one and other issues you reported for the same commit (I didn't want to respond to each one individually to avoid the e-mail avalanche). New version: [e541890](https://github.com/openjdk/jdk/pull/80/commits/e541890e037ff40ec9134a54e5c7a878ab9259f3) ------------- PR: https://git.openjdk.java.net/jdk/pull/80 From iklam at openjdk.java.net Wed Sep 9 22:08:25 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 22:08:25 GMT Subject: RFR: 8244778: Archive full module graph in CDS [v3] In-Reply-To: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: > 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. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Feedback from Coleen ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/80/files - new: https://git.openjdk.java.net/jdk/pull/80/files/92b4202b..e541890e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=01-02 Stats: 14 lines in 3 files changed: 3 ins; 5 del; 6 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 coleenp at openjdk.java.net Wed Sep 9 22:21:19 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Sep 2020 22:21:19 GMT Subject: RFR: 8244778: Archive full module graph in CDS [v3] In-Reply-To: References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: On Wed, 9 Sep 2020 18:46:33 GMT, Lois Foltan wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback from Coleen > > Thanks Ioi for addressing my review comments. Overall, looks great! Ok thanks! So many emails ... ------------- PR: https://git.openjdk.java.net/jdk/pull/80 From joehw at openjdk.java.net Wed Sep 9 23:04:44 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 9 Sep 2020 23:04:44 GMT Subject: RFR: 8251495: Clarify DOM documentation Message-ID: Revert changes made by JDK-8249643, removing the implNote. ------------- Commit messages: - 8251495: Clarify DOM documentation Changes: https://git.openjdk.java.net/jdk/pull/100/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=100&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251495 Stats: 25 lines in 1 file changed: 0 ins; 25 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/100.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/100/head:pull/100 PR: https://git.openjdk.java.net/jdk/pull/100 From lancea at openjdk.java.net Wed Sep 9 23:18:37 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 9 Sep 2020 23:18:37 GMT Subject: RFR: 8251495: Clarify DOM documentation In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote: > Revert changes made by JDK-8249643, removing the implNote. Based on the spec review and follow-on discussions, this change makes sense ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/100 From paul.sandoz at oracle.com Wed Sep 9 23:22:34 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 Sep 2020 16:22:34 -0700 Subject: [PATCH] Allocate uninitialized byte[] to improve performance of String-related operations In-Reply-To: <169211599221862@mail.yandex.ru> References: <169211599221862@mail.yandex.ru> Message-ID: <4949EA2E-88E2-4C0B-8AD5-BEE3C65EBAF2@oracle.com> Hi Sergey, Unsafe.allocateUninitializedArray should be used with great care, so as we are confident that no array, covering uninitialized memory, leaks out. Or later we unintentionally introduce a problem through refactoring. The update to AbstractStringBuilder is problematic because the uninitialized array could potentially be accessed through reflection. In other cases it seems you have slotted in the allocation at a low-level e.g. StringUTF16.newBytesFor. That makes it hard for me to evaluate the implications, and it's not clear to me it offers advantages in all cases, especially given the risks. The toCharArray/Utf allocation costs appear to be lost in the noise, at least from your benchmark results. The method repeat seems a good candidate to focus on given the allocation and looping is obviously localized. However, in the repeat of 1 case I would like to know why C2 does not elide the zeroing of the array, since it should know that the fill covers the whole array. For the repeat > 2 we can excuse C2 for not seeing through to the ranges passed to System.arraycopy. Separately, renaming StringConcatHelper.new{Char}Array to StringConcatHelper.newUninitialized{Char}Array would be clearer, and perhaps moving to somewhere else. Paul. > On Sep 4, 2020, at 5:52 AM, ?????? ??????? wrote: > > Hello, > > currently jdk.internal.misc.Unsafe declares method allocateUninitializedArray(Class, int) returning uninitialized array of given type and length. > > Allocation of uninitialized arrays is faster especially for larger ones, so we could use them for cases > when we are sure that created array will be completely overwritten or is guarded by count field (e.g. in AbstractStringBuilder). > > I've exposed jdk.internal.misc.Unsafe.allocateUninitializedArray(Class, int) > via delegating method of sun.misc.Unsafe to measure creation of byte[] with benchmark [1] > and got those results: > > (length) Mode Cnt Score Error Units > constructor 0 avgt 50 7.639 ? 0.629 ns/op > constructor 10 avgt 50 9.448 ? 0.725 ns/op > constructor 100 avgt 50 21.158 ? 1.865 ns/op > constructor 1000 avgt 50 146.158 ? 9.836 ns/op > constructor 10000 avgt 50 916.321 ? 50.618 ns/op > > unsafe 0 avgt 50 8.057 ? 0.599 ns/op > unsafe 10 avgt 50 8.308 ? 0.907 ns/op > unsafe 100 avgt 50 12.232 ? 1.813 ns/op > unsafe 1000 avgt 50 37.679 ? 1.382 ns/op > unsafe 10000 avgt 50 78.896 ? 6.758 ns/op > > As a result I propose to add the following methods into StringConcatHelper > > @ForceInline > static byte[] newArray(int length) { > return (byte[]) UNSAFE.allocateUninitializedArray(byte.class, length); > } > > @ForceInline > static char[] newCharArray(int length) { > return (char[]) UNSAFE.allocateUninitializedArray(char.class, length); > } > > along with existing StringConcatHelper.newArray(long indexCoder) and utilize them in String-related operations > instead of conventional array creation with new-keyword. > > I've used benchmark [2] to measure impact on affected String-methods and found quite a good improvement: > > before after > > Benchmark (length) Score Error Score Error Units > > newStringBuilderWithLength 8 8.288 ? 0.411 5.656 ? 0.019 ns/op > newStringBuilderWithLength 64 12.954 ? 0.687 7.588 ? 0.009 ns/op > newStringBuilderWithLength 128 20.603 ? 0.412 10.446 ? 0.005 ns/op > newStringBuilderWithLength 1024 119.935 ? 2.383 35.452 ? 0.029 ns/op > > newStringBuilderWithString 8 19.721 ? 0.375 14.642 ? 0.052 ns/op > newStringBuilderWithString 64 34.006 ? 1.523 15.479 ? 0.031 ns/op > newStringBuilderWithString 128 36.697 ? 0.972 17.052 ? 0.133 ns/op > newStringBuilderWithString 1024 140.486 ? 6.396 85.156 ? 0.175 ns/op > > repeatOneByteString 8 11.340 ? 0.197 9.736 ? 0.051 ns/op > repeatOneByteString 64 20.859 ? 0.257 15.073 ? 0.024 ns/op > repeatOneByteString 128 36.311 ? 1.162 22.808 ? 0.198 ns/op > repeatOneByteString 1024 149.243 ? 3.083 82.839 ? 0.193 ns/op > > repeatOneChar 8 28.033 ? 0.615 20.377 ? 0.137 ns/op > repeatOneChar 64 56.399 ? 1.094 36.230 ? 0.051 ns/op > repeatOneChar 128 68.423 ? 5.647 44.157 ? 0.239 ns/op > repeatOneChar 1024 230.115 ? 0.312 179.126 ? 0.437 ns/op > > replace 8 14.684 ? 0.088 14.434 ? 0.057 ns/op > replace 64 56.811 ? 0.612 56.420 ? 0.050 ns/op > replace 128 112.694 ? 0.404 109.799 ? 1.202 ns/op > replace 1024 837.939 ? 0.855 818.802 ? 0.408 ns/op > > replaceUtf 8 17.802 ? 0.074 15.744 ? 0.094 ns/op > replaceUtf 64 45.754 ? 0.139 39.228 ? 0.864 ns/op > replaceUtf 128 67.170 ? 0.353 50.497 ? 1.218 ns/op > replaceUtf 1024 415.767 ? 6.829 297.831 ? 22.510 ns/op > > toCharArray 8 6.164 ? 0.033 6.128 ? 0.064 ns/op > toCharArray 64 10.960 ? 0.032 13.566 ? 0.802 ns/op > toCharArray 128 20.373 ? 0.013 20.823 ? 0.376 ns/op > toCharArray 1024 165.923 ? 0.098 164.362 ? 0.065 ns/op > > toCharArrayUTF 8 8.009 ? 0.067 7.778 ? 0.026 ns/op > toCharArrayUTF 64 11.112 ? 0.014 10.880 ? 0.010 ns/op > toCharArrayUTF 128 20.390 ? 0.014 20.103 ? 0.017 ns/op > toCharArrayUTF 1024 166.233 ? 0.076 163.827 ? 0.099 ns/op > > So the question is could we include the changes of attached patch into JDK? > > With best regards, > Sergey Tsypanov > > > 1. Benchmark for array-allocation > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class ArrayAllocationBenchmark { > private static Unsafe U; > > static { > try { > Field f = Unsafe.class.getDeclaredField("theUnsafe"); > f.setAccessible(true); > U = (Unsafe) f.get(null); > } catch (Exception e) { > new RuntimeException(e); > } > } > > @Benchmark > public byte[] constructor(Data data) { > return new byte[data.length]; > } > > @Benchmark > public byte[] unsafe(Data data) { > return (byte[]) U.allocateUninitializedArray(byte.class, data.length); > } > > @State(Scope.Thread) > public static class Data { > @Param({"0", "10", "100", "1000", "10000"}) > private int length; > } > } > > > 2. Benchmark for String-method measurements > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class MiscStringBenchmark { > > @Benchmark > public char[] toCharArrayLatin1(Data data) { > return data.string.toCharArray(); > } > > @Benchmark > public char[] toCharArrayUTF(Data data) { > return data.utfString.toCharArray(); > } > > @Benchmark > public String repeatOneByteString(Data data) { > return data.oneCharString.repeat(data.length); > } > > @Benchmark > public String repeatOneChar(Data data) { > return data.oneUtfCharString.repeat(data.length); > } > > @Benchmark > public String replace(Data data){ > return data.stringToReplace.replace('z', 'b'); > } > > @Benchmark > public String replaceUtf(Data data){ > return data.utfStringToReplace.replace('?', '?'); > } > > @Benchmark > public StringBuilder newStringBuilderWithLength(Data data) { > return new StringBuilder(data.length); > } > > @Benchmark > public StringBuilder newStringBuilderWithString(Data data) { > return new StringBuilder(data.string); > } > > @State(Scope.Thread) > public static class Data { > > @Param({"8", "64", "128", "1024"}) > private int length; > > private String string; > public String utfString; > private final String oneCharString = "a"; > private final String oneUtfCharString = "?"; > private String stringToReplace; > private String utfStringToReplace; > > @Setup > public void setup() { > string = oneCharString.repeat(length); > utfString = oneUtfCharString.repeat(length); > > stringToReplace = string + 'z'; > utfStringToReplace = utfString + '?'; > } > } > } > From cjashfor at linux.ibm.com Wed Sep 9 23:32:59 2020 From: cjashfor at linux.ibm.com (Corey Ashford) Date: Wed, 9 Sep 2020 16:32:59 -0700 Subject: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: <196a4e58-0710-2f3e-6d1b-e78ab03a185d@oracle.com> References: <11ca749f-3015-c004-aa6b-3194e1dfe4eb@linux.ibm.com> <8ece8d2e-fd99-b734-211e-a32b534a7dc8@linux.ibm.com> <8d53dcf8-635a-11e2-4f6a-39b70e2c3b8b@oracle.com> <65ed7919-86fc-adfa-3cd5-58dd96a3487f@linux.ibm.com> <4bc83479-1ed9-8cd8-22a0-1f19f315df7e@oracle.com> <196a4e58-0710-2f3e-6d1b-e78ab03a185d@oracle.com> Message-ID: <91b1717e-f9f4-0b5c-d410-e25507206812@linux.ibm.com> On 9/9/20 2:04 PM, Roger Riggs wrote: > Hi Corey, > > Right,? the continue was so it would go back and check if the conversion > was > complete.? An alternative would be to repeat the check and return if > there was > no bytes left to process. Another issue I just discovered is that the way the loop is structured, decodeBlock could be called multiple times in the event that isMIME is true, and in that case, decodeBlock will try to write into dst[] starting at offset 0 again. My original intention was for the intrinsic to be called a single time because it never attempted process bytes in the isMIME==true case, and because of that, the offset into the destination buffer would always be zero. With this loop, on the second and later calls, the offset into dst[] should be non-zero. This means that I also need to pass dp into decodeBlock. That necessitates a change in the parameter passing down to the intrinsic. Not a big deal, but it is a ripple. I'll get working on it. The upside of this change is that it makes the decode and encode intrinsics closely mirror each other, and handles the isMIME==true case as a happy side-effect. With the overhead of the call to the intrinsic, it's not clear there will be a performance gain when isMIME==true, but a benchmark should make that clear. I'm guessing maybe 1.5X to 2X is about the best that could be expected when linemax is the default 76. - Corey > > Thanks, Roger > > On 9/9/20 3:13 PM, Corey Ashford wrote: >> On 9/4/20 8:07 AM, Roger Riggs wrote: >>> Hi Corey, >>> >>> The idea I had in mind is refactoring the fast path into the method >>> you call decodeBlock. >>> Base64: lines 751-768. >>> >>> It leaves all the unknown/illegal character handling to the Java code. >>> And yes, it does not need to handle MIME, except to return on illegal >>> characters. >>> >>> The patch is attached. >> >> Ah, I see what you mean now, and thanks for the patch!? The patch as >> presented doesn't work, however, because the intrinsic processes fewer >> bytes than are in the src buffer, and then executes a "continue;", >> which then proceeds to loop infinitely because the intrinsic won't >> process any more bytes after that. >> >> I tried dropping the continue, but that doesn't work because the Java >> (non-intrinsic) code processes all of the bytes, and the line of code >> following the loop accesses one byte after the end of the src buffer >> causing an array bounds error. >> >> So this needs to be re-thought a little, but it shouldn't be too >> difficult.? I will work on it. >> >> Regards, >> >> - Corey >> >>> >>> Regards, Roger >>> >>> >>> >>> On 8/31/20 6:22 PM, Corey Ashford wrote: >>>> On 8/29/20 1:19 PM, Corey Ashford wrote: >>>>> Hi Roger, >>>>> >>>>> Thanks for your reply and thoughts!? Comments interspersed below: >>>>> >>>>> On 8/28/20 10:54 AM, Roger Riggs wrote: >>>> ... >>>>>> Comparing with the way that the Base64 encoder was intrinsified, the >>>>>> method that is intrinsified should have a method body that does >>>>>> the same function, so it is interchangable.? That likely will just >>>>>> shift >>>>>> the "fast path" code into the decodeBlock method. >>>>>> Keeping the symmetry between encoder and decoder will >>>>>> make it easier to maintain the code. >>>>> >>>>> Good point.? I'll investigate what this looks like in terms of the >>>>> actual code, and will report back (perhaps in a new webrev). >>>>> >>>> >>>> Having looked at this again, I don't think it makes sense. One thing >>>> that differs significantly from the encodeBlock intrinsic is that >>>> the decodeBlock intrinsic only needs to process a prefix of the >>>> data, and so it can leave virtually any amount of data at the end of >>>> the src buffer unprocessed, where as with the encodeBlock intrinsic, >>>> if it exists, it must process the entire buffer. >>>> >>>> In the (common) case where the decodeBlock intrinsic returns not >>>> having processed everything, it still needs to call the Java code, >>>> and if that Java code is "replaced" by the intrinsic, it's >>>> inaccessible. >>>> >>>> Is there something I'm overlooking here?? Basically I want the >>>> decode API to behave differently than the encode API, mostly to make >>>> the arch-specific intrinsic easier to implement. If that's not >>>> acceptable, then I need to rethink the API, and also figure out how >>>> to deal with the illegal character case. The latter could perhaps be >>>> done by throwing an exception from the intrinsic, or maybe by >>>> returning a negative length that specifies the index of the illegal >>>> src byte, and then have the Java code throw the exception). >>>> >>>> Regards, >>>> >>>> - Corey >>>> >>> >> > From joehw at openjdk.java.net Wed Sep 9 23:49:10 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 9 Sep 2020 23:49:10 GMT Subject: RFR: 8251495: Clarify DOM documentation In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 23:15:58 GMT, Lance Andersen wrote: >> Revert changes made by JDK-8249643, removing the implNote. > > Based on the spec review and follow-on discussions, this change makes sense An implNote was added to the DOM's package description in an attempt to document the JDK implementation's deviation from the DOM specification. However, a further study showed that was incorrect because the XML specification did include range [#x10000-#x10FFFF]. The Impl's interpretation was based on the clause "excluding the surrogate blocks". The problem was it used Java char to determine it. Thus instead of excluding the surrogate blocks with codepoints ranging from U+D800 to U+DBFF and U+DC00 to U+DFFF, it converted characters with a Java representation of a surrogate pair into character references. ------------- PR: https://git.openjdk.java.net/jdk/pull/100 From smarks at openjdk.java.net Thu Sep 10 00:56:46 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 10 Sep 2020 00:56:46 GMT Subject: RFR: 8251495: Clarify DOM documentation In-Reply-To: References: Message-ID: <51FVPmIRqkZ4glhqRZuRjllF9s2krz7d29A2A-3Fmb4=.853039fc-ac09-4fdc-9fa5-c508de353fb9@github.com> On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote: > Revert changes made by JDK-8249643, removing the implNote. Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/100 From naoto at openjdk.java.net Thu Sep 10 01:48:37 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Sep 2020 01:48:37 GMT Subject: RFR: 8251495: Clarify DOM documentation In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote: > Revert changes made by JDK-8249643, removing the implNote. Looks good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/100 From valeriep at openjdk.java.net Thu Sep 10 02:06:43 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 10 Sep 2020 02:06:43 GMT Subject: RFR: 8172366: Support SHA-3 based signatures Message-ID: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Could someone please help review this RFE? Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will be updated separately (JDK-8242332). This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to various signature algorithms. Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 Thanks! Valerie ------------- Commit messages: - 8172366: Support SHA-3 based signatures Changes: https://git.openjdk.java.net/jdk/pull/102/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=102&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8172366 Stats: 613 lines in 20 files changed: 541 ins; 8 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/102/head:pull/102 PR: https://git.openjdk.java.net/jdk/pull/102 From sundar at openjdk.java.net Thu Sep 10 03:34:59 2020 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 10 Sep 2020 03:34:59 GMT Subject: RFR: 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote: > `jlink --generate-jli-classes` plugin should retain the original holder classes if the default_jli_trace.txt > file does not exist. > > Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes` methods are invoked > unconditionally and therefore the holder classes are "regenerated" when default_jli_trace.txt > does not exist. JDK-8252725 does not handle this case properly and results in an image missing > the holder classes when the specified trace file does not exist. > > The fix is very simple. Retains the original holder classes when the file does not exist. Looks good ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/96 From alanb at openjdk.java.net Thu Sep 10 05:48:27 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 05:48:27 GMT Subject: RFR: 8251495: Clarify DOM documentation In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote: > Revert changes made by JDK-8249643, removing the implNote. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/100 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 pavel.rappo at oracle.com Thu Sep 10 08:52:07 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 10 Sep 2020 09:52:07 +0100 Subject: RFR 8252537: Replace @exception with @throws for core-libs In-Reply-To: <757F8572-4186-471A-AB34-7A5BAD13C4B8@gmail.com> References: <4CD716A6-B9DC-4C81-8B25-D1E074B39731@gmail.com> <757F8572-4186-471A-AB34-7A5BAD13C4B8@gmail.com> Message-ID: <59C9864F-513F-47A6-BDBA-BBFC69E8CBD2@oracle.com> > On 4 Sep 2020, at 21:32, Vipin Sharma wrote: > > > I have generated Javadoc for all updated packages and compared html files, before and after changes. Since effects can be nonlocal (e.g. {@inheritDoc}), you should always compare everything. >> There are ~ 1.5K lines, 86 files changed in this patch, do we have any tool to compare Javadoc or it should be done manually ? diff(1) does the job. -Pavel 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 archana.nogriya at uk.ibm.com Thu Sep 10 09:42:36 2020 From: archana.nogriya at uk.ibm.com (Archana Nogriya) Date: Thu, 10 Sep 2020 10:42:36 +0100 Subject: JDK-8252802 - Performance optimization by setting MALLOCOPTIONS and LDR_CNTRL java launcher in order to use 64KB pages by default for perf on AIX. Message-ID: Hi, I am requesting a proposal for the contribution to OpenJDK. I have created webrev with my changes. Please can I have someone to review my changes and suggest further. Details description is as follow, ======================================= Title : Performance optimization by setting MALLOCOPTIONS and LDR_CNTRL java launcher in order to use 64KB pages by default for perf on AIX. Description: The malloc subsystem provides an optional multiheap capability to allow the use of multiple heaps of free memory, rather than just one, to improve performance this is the fix . Also to setting LDR_CNTRL on AIX java launcher in order to use 64KB pages by default for perf. Changed File: http://hg.openjdk.java.net/jdk/jdk/file/5aeebd3bb33a/src/java.base/unix/native/libjli/java_md.c Webrev url: https://bugs.openjdk.java.net/browse/JDK-8252802 ============================================= Many Thanks & Regards Archana Nogriya Java Runtimes Development and Project Manager IBM Hursley IBM United Kingdom Ltd internet email: archana.nogriya at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From archana.nogriya at uk.ibm.com Thu Sep 10 09:44:20 2020 From: archana.nogriya at uk.ibm.com (Archana Nogriya) Date: Thu, 10 Sep 2020 10:44:20 +0100 Subject: JDK-8252803: Add the /LARGEADDRESSAWARE flag when linking executables for Windows 32-bit. Message-ID: Hi, I am requesting a proposal for the contribution to OpenJDK. I have created webrev with my changes. Please can I have someone to review my changes and suggest further. Details description is as follow, ================================================== Title : Add the /LARGEADDRESSAWARE flag when linking executables for Windows 32-bit. Description: The following change to add the /LARGEADDRESSAWARE flag when linking executables for Windows 32-bit. This simple change allows java to use more than 2GB address space. IBM Java uses this flag. Changed File: http://hg.openjdk.java.net/jdk/jdk/file/5aeebd3bb33a/make/autoconf/spec.gmk.in Webrev url: https://bugs.openjdk.java.net/browse/JDK-8252803 ================================================== Many Thanks & Regards Archana Nogriya Java Runtimes Development and Project Manager IBM Hursley IBM United Kingdom Ltd internet email: archana.nogriya at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From alanb at openjdk.java.net Thu Sep 10 09:50:04 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 09:50:04 GMT Subject: RFR: 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote: > `jlink --generate-jli-classes` plugin should retain the original holder classes if the default_jli_trace.txt > file does not exist. > > Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes` methods are invoked > unconditionally and therefore the holder classes are "regenerated" when default_jli_trace.txt > does not exist. JDK-8252725 does not handle this case properly and results in an image missing > the holder classes when the specified trace file does not exist. > > The fix is very simple. Retains the original holder classes when the file does not exist. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/96 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 gdub at openjdk.java.net Thu Sep 10 11:52:47 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Thu, 10 Sep 2020 11:52:47 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> <9ARL_A2daS8-nEhhporpJpuRtdJJz8XY1mwyH_i99I8=.c3c3df72-8039-4243-b8c6-bd5040aabe64@github.com> Message-ID: On Wed, 9 Sep 2020 16:39:25 GMT, Mandy Chung wrote: >> test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java line 29: >> >>> 27: * @summary Add lambda tests >>> 28: * Test bridge methods for certain SAM conversions >>> 29: * Test the set of generate fields >> >> I would suggest to consider having the test under test/jdk/(java/lang/invoke/lambda), not under >> test/langtools/tools/javac. > > It's a good suggestion as `disableEagerInitialization` support is not part of javac. OK makes sense. I guess it's still good to clean the test comments of the old `disableEagerInitialization` references? ------------- PR: https://git.openjdk.java.net/jdk/pull/93 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 redestad at openjdk.java.net Thu Sep 10 12:21:27 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 10 Sep 2020 12:21:27 GMT Subject: RFR: 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote: > `jlink --generate-jli-classes` plugin should retain the original holder classes if the default_jli_trace.txt > file does not exist. > > Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes` methods are invoked > unconditionally and therefore the holder classes are "regenerated" when default_jli_trace.txt > does not exist. JDK-8252725 does not handle this case properly and results in an image missing > the holder classes when the specified trace file does not exist. > > The fix is very simple. Retains the original holder classes when the file does not exist. Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/96 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 enikitin at openjdk.java.net Thu Sep 10 12:26:33 2020 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Thu, 10 Sep 2020 12:26:33 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures Message-ID: pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html) Error reporting was improved by writing a C-style escaped string representations for the variables passed to the methods being tested. For array comparisons, a dedicated diff-formatter was implemented. Sample output for comparing byte arrays (with artificial failure): ----------System.err:(21/1553)---------- Result: (false) of 'arrayEqualsB' is not equal to expected (true) Arrays differ starting from [index: 7]: ... 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... ^^^^ java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not equal to expected (true) at compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273) at ... stack trace continues - E.N. Sample output for comparing char arrays: ----------System.err:(21/1579)*---------- Result: (false) of 'arrayEqualsC' is not equal to expected (true) Arrays differ starting from [index: 7]: ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ... ... \\u0005, \\u0006, }, \\u0008, \\u0009, \\n, ... ^^^^^^^ java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not equal to expected (true) at compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280) at ... and so on - E.N. testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx. ------------- Commit messages: - 8229186: Improve error messages for TestStringIntrinsics failures Changes: https://git.openjdk.java.net/jdk/pull/112/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8229186 Stats: 1078 lines in 6 files changed: 1066 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/112/head:pull/112 PR: https://git.openjdk.java.net/jdk/pull/112 From enikitin at openjdk.java.net Thu Sep 10 12:31:49 2020 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Thu, 10 Sep 2020 12:31:49 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures In-Reply-To: References: Message-ID: <8n8KvhWjyaRXASTq32-P5KXojlOFB2-JIvPTu88oJRg=.b32b5bd1-5ddc-43a6-bcf0-18b1bc24de26@github.com> On Thu, 10 Sep 2020 12:20:05 GMT, Evgeny Nikitin wrote: > pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html) > > Error reporting was improved by writing a C-style escaped string representations for the variables passed to the > methods being tested. For array comparisons, a dedicated diff-formatter was implemented. > Sample output for comparing byte arrays (with artificial failure): > ----------System.err:(21/1553)---------- > Result: (false) of 'arrayEqualsB' is not equal to expected (true) > Arrays differ starting from [index: 7]: > ... 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... > ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... > ^^^^ > java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not > equal to expected (true) > at > compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273) > at ... stack trace continues - E.N. > Sample output for comparing char arrays: > ----------System.err:(21/1579)*---------- > Result: (false) of 'arrayEqualsC' is not equal to expected (true) > Arrays differ starting from [index: 7]: > ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ... > ... \\u0005, \\u0006, }, \\u0008, \\u0009, \\n, ... > ^^^^^^^ > java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not > equal to expected (true) > at > compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280) > at > ... and so on - E.N. > > testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx. Responding to the comments from pre-Skara thread: > test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java: > I'd prefer invokeAndCompareArrays and invokeAndCheck to be as close as possible: have both of them to accept either > boolean or Object as 2nd arg; print/throw the same error message the invokeAndCheck is very generic, it can be called with different objects and expect any kind of result, not only boolean. Therefore its output format radically differs from what an array-comparator should show. > maybe I'm missing smth, but I don't understand why ArrayCodec supports only char and byte arrays; and hence I don't > understand why you need ArrayCodec::of methods, as you can simply do new > ArrayCoded(Arrays.stream(a).collect(Collectors.toList()) where a is an array of any type for Object arrays, one can use that. for integer primitives one needs Arrays.stream(a).boxed.collect(Collectors.toList()), please note 'boxed' - it is required and not generic. for bytes or chars, there is none (no overload methos in the Arrays.stream(a)); To sum up, I can't see how with the given type system and utilities set I can make in a better, less wordy way. I've added int and long overloads, support for String and Object arrays to make it more complete. > it seems that ArrayCodec should be an inner static class of ArrayDiff I would argue that - I find it useful for printing arrays (and this usage has been utilised in the TestStringIntrinsics.java). In addition, I dont' like the practice of making such huge classes an inner classes as this reduces readability and modularity. Other issues have been fixed. I added support for int, long, Object and String arrays. ------------- PR: https://git.openjdk.java.net/jdk/pull/112 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 rriggs at openjdk.java.net Thu Sep 10 14:40:50 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 10 Sep 2020 14:40:50 GMT Subject: Integrated: 8252830: Correct missing javadoc comments in java.rmi module In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 15:19:40 GMT, Roger Riggs wrote: > 8252830: Correct missing javadoc comments in java.rmi module This pull request has now been integrated. Changeset: 418e4a25 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/418e4a25 Stats: 39 lines in 4 files changed: 1 ins; 38 del; 0 mod 8252830: Correct missing javadoc comments in java.rmi module Reviewed-by: dfuchs, lancea, smarks, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/79 From gdub at openjdk.java.net Thu Sep 10 15:23:14 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Thu, 10 Sep 2020 15:23:14 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v2] In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. Gilles Duboscq has updated the pull request incrementally with three additional commits since the last revision: - Remove extra field test from LambdaTest6 - Wrap long lines - Add deciated test in the jdk tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/93/files - new: https://git.openjdk.java.net/jdk/pull/93/files/979186b8..422cd01d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=00-01 Stats: 111 lines in 3 files changed: 76 ins; 32 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/93/head:pull/93 PR: https://git.openjdk.java.net/jdk/pull/93 From gdub at openjdk.java.net Thu Sep 10 15:23:16 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Thu, 10 Sep 2020 15:23:16 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v2] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Wed, 9 Sep 2020 16:36:43 GMT, Mandy Chung wrote: >> Gilles Duboscq has updated the pull request incrementally with three additional commits since the last revision: >> >> - Remove extra field test from LambdaTest6 >> - Wrap long lines >> - Add deciated test in the jdk tests > > src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 215: > >> 213: if (disableEagerInitialization) { >> 214: try { >> 215: return new ConstantCallSite(caller.findStaticGetter(innerClass, LAMBDA_INSTANCE_FIELD, >> invokedType.returnType())); > > Nit: it'd be good to wrap this long line. There are a couple long lines in this patch. I have wrapped some lines that were longer than the typical line in this file. Let me know if the wrapping looks good to you. ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From gdub at openjdk.java.net Thu Sep 10 15:23:17 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Thu, 10 Sep 2020 15:23:17 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v2] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> <9ARL_A2daS8-nEhhporpJpuRtdJJz8XY1mwyH_i99I8=.c3c3df72-8039-4243-b8c6-bd5040aabe64@github.com> Message-ID: On Thu, 10 Sep 2020 11:50:04 GMT, Gilles Duboscq wrote: >> It's a good suggestion as `disableEagerInitialization` support is not part of javac. > > OK makes sense. I guess it's still good to clean the test comments of the old `disableEagerInitialization` references? I have created a new test under `test/jdk/java/lang/invoke/lambda` and cleaned up `LambdaTest6.java` ------------- PR: https://git.openjdk.java.net/jdk/pull/93 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 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 mchung at openjdk.java.net Thu Sep 10 16:08:25 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 10 Sep 2020 16:08:25 GMT Subject: Integrated: 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError In-Reply-To: References: Message-ID: <_b0I5MEgY2nqWl5LOnjjT3G6mkaYPyhHqP7d1f2Sxu0=.9074a599-4b40-4361-b591-2fbde92696d2@github.com> On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote: > `jlink --generate-jli-classes` plugin should retain the original holder classes if the default_jli_trace.txt > file does not exist. > > Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes` methods are invoked > unconditionally and therefore the holder classes are "regenerated" when default_jli_trace.txt > does not exist. JDK-8252725 does not handle this case properly and results in an image missing > the holder classes when the specified trace file does not exist. > > The fix is very simple. Retains the original holder classes when the file does not exist. This pull request has now been integrated. Changeset: 44a74dac Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/44a74dac Stats: 47 lines in 2 files changed: 4 ins; 36 del; 7 mod 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError Reviewed-by: minqi, sundar, alanb, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/96 From joehw at openjdk.java.net Thu Sep 10 16:19:27 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 10 Sep 2020 16:19:27 GMT Subject: RFR: 8251495: Clarify DOM documentation In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 05:45:59 GMT, Alan Bateman wrote: >> Revert changes made by JDK-8249643, removing the implNote. > > Marked as reviewed by alanb (Reviewer). Remove the implNote from the package description added by JDK-8249643. The implementation's deviation from the specification was actually wrong. It incorrectly identified characters from #x10000 to #x10FFFF as in the surrogate blocks. ------------- PR: https://git.openjdk.java.net/jdk/pull/100 From joehw at openjdk.java.net Thu Sep 10 16:23:59 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 10 Sep 2020 16:23:59 GMT Subject: RFR: 8251495: Clarify DOM documentation In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 16:16:57 GMT, Joe Wang wrote: >> Marked as reviewed by alanb (Reviewer). > > Remove the implNote from the package description added by JDK-8249643. > The implementation's deviation from the specification was actually wrong. > It incorrectly identified characters from #x10000 to #x10FFFF as in the > surrogate blocks. Remove the implNote from the package description added by JDK-8249643. ------------- PR: https://git.openjdk.java.net/jdk/pull/100 From mchung at openjdk.java.net Thu Sep 10 16:36:51 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 10 Sep 2020 16:36:51 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v2] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Thu, 10 Sep 2020 15:23:14 GMT, Gilles Duboscq wrote: >> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the >> jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda >> classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the >> context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of >> non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas >> are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely >> _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and >> ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance >> behaviour of lambdas in either direction. > > Gilles Duboscq has updated the pull request incrementally with three additional commits since the last revision: > > - Remove extra field test from LambdaTest6 > - Wrap long lines > - Add deciated test in the jdk tests test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java line 33: > 31: * @compile LambdaTest6.java > 32: * @run main LambdaTest6 > 33: */ This line was added by JDK-8232806 (https://hg.openjdk.java.net/jdk/jdk/rev/27c2d2a4b695). I assume you want to move the test case for JDK-8232806 to test/jdk/java/lang/invoke? If so, BridgeMethod.java should be looked at too. ------------- PR: https://git.openjdk.java.net/jdk/pull/93 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 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 gil at azul.com Thu Sep 10 18:25:00 2020 From: gil at azul.com (Gil Tene) Date: Thu, 10 Sep 2020 18:25:00 +0000 Subject: Coordinated Restore at Checkpoint: A new project for start-up optimization? Message-ID: <9884BB85-1950-4C61-930B-FD8FA7852C8E@azul.com> Hello, We would like to open a discussion about a new project focused on "Coordinated Restore at Checkpoint". A possible relevant project name might be Tubthumpting [9]. Over the years, we [at Azul] have tinkered with various ways to improve java start-up time and warmup behavior for different use cases for such improvements. One of the interesting focus areas has been the "starting of a new instance" of an application that has already run instances using identical code, a similar expected profile, and potentially a similar initialization sequence in the past. This is a common scenario in modern application deployments, when e.g. rolling out new code in continuous deployment environment, and when e.g. elastically changing instance counts in e.g. auto-scaling situations. Checkpoint/Restore technologies have evolved in various forms over the past few years, and are available in the multiple forms, including e.g. CRIU [1] and Docker Checkpoint & Restore [2]. While Checkpoint/Restore capabilities have been shown to work across a wide range of applications for e.g. live process or application migration, there are various challenges present for their generic application for new instance deployment. Many of these challenges have to do with the need to deal with a checkpointed state that may not be validly reproducible when restoring multiple instances from the same checkpoint image. This is where Coordinate Restore at Checkpoint (CRaC) comes in. At a high level, CRaC aims to systemically address these challenges by facilitating explicit and intentional coordination between checkpointed applications and a checkpointing mechanism. Such coordination will allow applications to proactively discard problematic state ahead of checkpointing and to reestablish needed state upon restoration. [e.g. closing open file descriptors ahead of a checkpoint, and recreating and binding them after a restore]. Coordination is a powerful enabler in this space. Contrary to the approaches attempting transparent, uncoordinated checkpoint/restore, CRaC's approach to the date has focused on assisting with the detection of situations that would prevent a successful checkpoint, and simply refusing to checkpoint if such conditions are identified. This approach leaves it up to the application frameworks and the applications themselves to remedy the situation during development, and before attempting actual deployment (or simply accept non-CRaC startup times since a restorable checkpoint state will not be available). In the Java arena, we aim to create a generic CRaC API that would allow applications and/or application frameworks to coordinate with an arbitrary checkpoint/restore mechanism, without being tied to a specific implementation or to the operational means by which checkpointing and restoration is achieved. Such an API would allow application frameworks (e.g. Tomcat, Quarkus, MicroNaut, etc.) to perform the needed coordination in a portable way, which would not require coding that is specific to a checkpoint/restore mechanism. E.g. the same Tomcat CRaC coordination code would be able to properly coordinate with a generic Linux CRIU utility, with Docker Checkpoint & Restore, or with future OpenJDK implementations that may support checkpoint/restore functionality directly or via the use of libraries or system services. Our hope is to start a project that will focus on specifying a CRaC API, and will provide at least one CRaC-supporting checkpoint/restore OpenJDK implementation with the hope of eventual upstream inclusion in a future OpenJDK version via associated JEPs. We would potentially want to include the API in a future Java SE specification as well. In reality, we expect that more than one checkpoint/restore mechanism may be supported, as we have already identified at least two probable modes of operation that would be useful for OpenJDK: - We have prototyped [3] a JDK-driven, modified-CRIU [4] based checkpoint/restore implementation that leverages on-demand paging during startup to deliver very promising start times for e.g microservices running on Quarkus, Micronaut, and Tomcat, and reaching "full speed" condition in sub-50-msec times.[5] - We anticipate external-to-the-JDK checkpoint/restore implementations such as Docker Checkpoint & Restore [2] and potential possible support within orchestration frameworks (such as future Kubernetes versions) will drive a need for non-Java-specific means of coordinating restoration from checkpointed conditions, and that in such environments JDKs will likely wish to provide external controls (such jcmd or other APIs) that would deal with coordination, but leave the actual checkpointing and restore work to external entities. Below are short summaries of: - CRaC API concepts - What a prototype OpenJDK implementation looks like - Preliminary uses of CRaC API in some application frameworks - Some promising preliminary results What do you think? Please chime in. ? Gil. P.S. Anton Kozlov has done the vast majority of the technical work on this so far, and will be joining the discussion here. ????????????????? CRaC API, conceptually The high-level concepts of a CRaC API as we see it thus far include: - Application code (a "resource") can register its interest in coordinating with checkpoint/restore operations. - When a checkpoint operation attempt is initiated, and before a checkpoint is actually taken, all registered "resources" will be notified that a checkpoint is being attempted via e.g. a beforeCheckpoint() call. - A JDK may (and likely will) refuse to complete a checkpoint attempt if it encounters any application state that it does not know how to checkpoint or restore. E.g. a JDK may (and likely will) refuse to complete a checkpoint attempt if any file descriptors that are not private to the JDK itself are open after all registered resources have been notified about the coming checkpoint attempt. - When a restore operation occurs, all registered resources will be notified via e.g. an afterRestore() callback. - Upon being notified of a coming checkpoint, a resource is responsible for destroying any state that may prevent the capturing of a checkpoint (e.g. close any objects that it is responsible and that may keep open file descriptors), as well as for capturing whatever information it may need in order to continue successfully after a restore (e.g. the knowledge of what needs to be "opened" before a restore is complete). - A resource may cause a checkpoint attempt to fail by throwing an exception when notified. - Upon being notified that a restore has occurred, a resource is responsible for any required restoration or recreation of the state that it destroyed before the checkpoint occurred. [e.g. opening, binding, listening, and possibly selecting on server ports that were closed for the checkpoint]. Note that although restoration is not functionally required in some cases, it may still be beneficial for faster functional startup upon restoration. E.g. outbound connections in a connection pool may not have to be reconnected, as normal connection failure handling will likely deal with their re-establishment in any case. However, initiating such reconnection upon restore will likely improve functional startup time. - A resource may indicate that a restore attempt should fail by throwing an exception when notified. ????????????????? Prototype JDK implementation The prototype JDK implementation [3] implements Coordinated Checkpoint and Restore using a modified version of CRIU. A snapshot image of the JDK process created at an arbitrary point of time, the image is later used to start a copy of the process that is identical to the original one. Hotspot change highlights: - Adds a Coordinated Checkpoint and Restore implementation for Linux - the checkpoint is performed in a JVM safepoint - currently depends on being able to reuse the checkpointed process pid. [not a problem in containers] - Adds a jcmd command for initiating Checkpoint (does not yet pass error information on failure) - Enforces no java user-visible file or socket resources are allowed at the checkpoint time. Exception message indicates the problematic resource information. - Changes in PerfMemory (/tmp/hsperfdata/) to work across multiple restores - Performs GC on checkpoint and zeros unused heap memory to minimize image size JDK change highlights: - a jdk.crac API providing Checkpoint and Restore notifications - uses of the jdk.crac API within the JDK: - support in sun.nio.ch.EPollSelectorImpl to handle epoll and pipe - jar file handling by the JDK - support in java.net.PlainSocketImpl and sun.nio.ch.FileDispatcherImpl to handle internal socket used for preclose ????????????????? Preliminary uses of CRaC API in some application frameworks AKA: What modifying common application frameworks to use a proposed CRaC API successfully on a prototype OpenJDK implementation looks like. The CRaC API was used to create modified versions of Quarkus [6], Micrnoaut [7] and Tomcat [8] (used by Spring Boot in our examples). The amount of code changes required has been surprisingly small. All three frameworks successfully coordinate checkpoint and restore operations with the prototype JDK without requiring any changes to the example code that runs on the framework. It is hoped that a large majority of applications that run on such frameworks would not require any CRaC API use, and CRaC awareness will only be needed at the framework and potentially at the library levels in most cases. ????????????????? Promising Preliminary Results The current prototype has demonstrated <50msec startup times [5] for fully warmed microservice examples running on modified Spring Boot, Quarkus, and Micronaut[4]. The examples demonstrate fully-JIT'ed performance out of the box: the immediate throughout of these <50msec starts matches the throughput achieved by a normal OpenJDK start only after the latter has fully warmed up, and after it had executed >10,000 example operations at significantly slower speeds. ????????????????? References [1] https://github.com/checkpoint-restore/criu [2] https://github.com/docker/cli/blob/master/experimental/checkpoint-restore.md [3] https://github.com/org-crac/jdk/compare/jdk-base..jdk-crac [4] https://github.com/org-crac/criu/compare/v3.14..crac [5] https://github.com/org-crac/docs#results [6] https://github.com/org-crac/quarkus/compare/master..crac-master [7] https://github.com/org-crac/micronaut-core/compare/1.3.x..crac-1.3.x [8] https://github.com/org-crac/tomcat/compare/8.5.x..crac [9] https://en.wikipedia.org/wiki/Tubthumping From sergei.tsypanov at yandex.ru Thu Sep 10 20:33:23 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Thu, 10 Sep 2020 22:33:23 +0200 Subject: [PATCH] Allocate uninitialized byte[] to improve performance of String-related operations References: <169211599221862@mail.yandex.ru> <4949EA2E-88E2-4C0B-8AD5-BEE3C65EBAF2@oracle.com> Message-ID: <16231599737784@mail.yandex.ru> Hi Paul, thanks for looking into this! > The update to AbstractStringBuilder is problematic because the uninitialized array could potentially be accessed through reflection. > > In other cases it seems you have slotted in the allocation at a low-level e.g. StringUTF16.newBytesFor. That makes it hard for me to evaluate the implications, and it's not clear to me it offers advantages in all cases, especially given the risks. The toCharArray/Utf allocation costs appear to be lost in the noise, at least from your benchmark results. I've reverted suspicious changes you've mentioned along with those that gave no improvement. > However, in the repeat of 1 case I would like to know why C2 does not elide the zeroing of the array, since it should know that the fill covers the whole array. Should I report this case to hotspot-compiler-dev mailing list? > Separately, renaming StringConcatHelper.new{Char}Array to StringConcatHelper.newUninitialized{Char}Array would be clearer, and perhaps moving to somewhere else. After reverting StringLatin1/StringUTF16.toChars() we don't need this any more, so I've reverted it too. Initially I decided to keep it within StringConcatHelper as the latter already contained Unsafe field. I've reworked the patch, benchmark is in [1] and the results are below. The patch is attached. I think these are useful changes bringing good improvement at low cost and no risk as we are sure that we are dealing only with local variables. Also pay attention, that StringLatin1.replace() has already been using StringConcatHelper.newArray() and improvement is achieved with usage of System.arraycopy() instead of manual copying. Is it ok to keep this along with other ca Benchmark (length) before after Units newString 8 12.805 ? 0.024 11.945 ? 0.124 ns/op newString 64 48.165 ? 0.105 38.525 ? 0.041 ns/op newString 128 79.746 ? 0.120 69.061 ? 0.081 ns/op newString 1024 631.384 ? 1.068 521.811 ? 0.592 ns/op repeatOneByteString 8 10.278 ? 0.017 9.751 ? 0.027 ns/op repeatOneByteString 64 18.034 ? 0.017 15.173 ? 0.060 ns/op repeatOneByteString 128 30.749 ? 0.491 22.568 ? 0.033 ns/op repeatOneByteString 1024 109.009 ? 2.476 82.269 ? 0.101 ns/op repeatOneCharString 8 22.141 ? 0.703 20.376 ? 0.171 ns/op repeatOneCharString 64 44.796 ? 0.764 36.344 ? 0.059 ns/op repeatOneCharString 128 57.736 ? 0.134 43.992 ? 0.287 ns/op repeatOneCharString 1024 229.131 ? 1.211 176.311 ? 0.497 ns/op replace 8 14.545 ? 0.019 13.426 ? 0.089 ns/op replace 64 56.453 ? 0.096 36.115 ? 0.107 ns/op replace 128 108.701 ? 1.201 65.387 ? 1.159 ns/op replace 1024 820.524 ? 0.852 427.047 ? 0.510 ns/op replaceUtf 8 17.480 ? 0.089 15.908 ? 0.175 ns/op replaceUtf 64 44.982 ? 0.500 34.091 ? 0.209 ns/op replaceUtf 128 66.433 ? 0.427 50.828 ? 0.645 ns/op replaceUtf 1024 407.634 ? 11.850 302.786 ? 1.152 ns/op With best regards, Sergey Tsypanov 1. Benchmark @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class MiscStringBenchmark { @Benchmark public String newString(Data data){ return new String(data.codepoints, 0, data.codepoints.length); } @Benchmark public String repeatOneByteString(Data data) { return data.oneCharString.repeat(data.length); } @Benchmark public String repeatOneCharString(Data data) { return data.oneUtfCharString.repeat(data.length); } @Benchmark public String replace(Data data){ return data.stringToReplace.replace('z', 'b'); } @Benchmark public String replaceUtf(Data data){ return data.utfStringToReplace.replace('?', '?'); } @State(Scope.Thread) public static class Data { @Param({"8", "64", "128", "1024"}) private int length; private final String oneCharString = "a"; private final String oneUtfCharString = "?"; private String stringToReplace; private String utfStringToReplace; private int[] codepoints; @Setup public void setup() { String string = oneCharString.repeat(length); String utfString = oneUtfCharString.repeat(length); stringToReplace = string + 'z'; codepoints = stringToReplace.codePoints().toArray(); utfStringToReplace = utfString + '?'; } } } 10.09.2020, 01:24, "Paul Sandoz" : > Hi Sergey, > > Unsafe.allocateUninitializedArray should be used with great care, so as we are confident that no array, covering uninitialized memory, leaks out. Or later we unintentionally introduce a problem through refactoring. > > The update to AbstractStringBuilder is problematic because the uninitialized array could potentially be accessed through reflection. > > In other cases it seems you have slotted in the allocation at a low-level e.g. StringUTF16.newBytesFor. That makes it hard for me to evaluate the implications, and it's not clear to me it offers advantages in all cases, especially given the risks. The toCharArray/Utf allocation costs appear to be lost in the noise, at least from your benchmark results. > > The method repeat seems a good candidate to focus on given the allocation and looping is obviously localized. > However, in the repeat of 1 case I would like to know why C2 does not elide the zeroing of the array, since it should know that the fill covers the whole array. > For the repeat > 2 we can excuse C2 for not seeing through to the ranges passed to System.arraycopy. > > Separately, renaming StringConcatHelper.new{Char}Array to StringConcatHelper.newUninitialized{Char}Array would be clearer, and perhaps moving to somewhere else. > > Paul. > >> ?On Sep 4, 2020, at 5:52 AM, ?????? ??????? wrote: >> >> ?Hello, >> >> ?currently jdk.internal.misc.Unsafe declares method allocateUninitializedArray(Class, int) returning uninitialized array of given type and length. >> >> ?Allocation of uninitialized arrays is faster especially for larger ones, so we could use them for cases >> ?when we are sure that created array will be completely overwritten or is guarded by count field (e.g. in AbstractStringBuilder). >> >> ?I've exposed jdk.internal.misc.Unsafe.allocateUninitializedArray(Class, int) >> ?via delegating method of sun.misc.Unsafe to measure creation of byte[] with benchmark [1] >> ?and got those results: >> >> ????????????????????(length) Mode Cnt Score Error Units >> ?constructor 0 avgt 50 7.639 ? 0.629 ns/op >> ?constructor 10 avgt 50 9.448 ? 0.725 ns/op >> ?constructor 100 avgt 50 21.158 ? 1.865 ns/op >> ?constructor 1000 avgt 50 146.158 ? 9.836 ns/op >> ?constructor 10000 avgt 50 916.321 ? 50.618 ns/op >> >> ?unsafe 0 avgt 50 8.057 ? 0.599 ns/op >> ?unsafe 10 avgt 50 8.308 ? 0.907 ns/op >> ?unsafe 100 avgt 50 12.232 ? 1.813 ns/op >> ?unsafe 1000 avgt 50 37.679 ? 1.382 ns/op >> ?unsafe 10000 avgt 50 78.896 ? 6.758 ns/op >> >> ?As a result I propose to add the following methods into StringConcatHelper >> >> ?@ForceInline >> ?static byte[] newArray(int length) { >> ????return (byte[]) UNSAFE.allocateUninitializedArray(byte.class, length); >> ?} >> >> ?@ForceInline >> ?static char[] newCharArray(int length) { >> ????return (char[]) UNSAFE.allocateUninitializedArray(char.class, length); >> ?} >> >> ?along with existing StringConcatHelper.newArray(long indexCoder) and utilize them in String-related operations >> ?instead of conventional array creation with new-keyword. >> >> ?I've used benchmark [2] to measure impact on affected String-methods and found quite a good improvement: >> >> ?????????????????????????????????????????????????before after >> >> ?Benchmark (length) Score Error Score Error Units >> >> ?newStringBuilderWithLength 8 8.288 ? 0.411 5.656 ? 0.019 ns/op >> ?newStringBuilderWithLength 64 12.954 ? 0.687 7.588 ? 0.009 ns/op >> ?newStringBuilderWithLength 128 20.603 ? 0.412 10.446 ? 0.005 ns/op >> ?newStringBuilderWithLength 1024 119.935 ? 2.383 35.452 ? 0.029 ns/op >> >> ?newStringBuilderWithString 8 19.721 ? 0.375 14.642 ? 0.052 ns/op >> ?newStringBuilderWithString 64 34.006 ? 1.523 15.479 ? 0.031 ns/op >> ?newStringBuilderWithString 128 36.697 ? 0.972 17.052 ? 0.133 ns/op >> ?newStringBuilderWithString 1024 140.486 ? 6.396 85.156 ? 0.175 ns/op >> >> ?repeatOneByteString 8 11.340 ? 0.197 9.736 ? 0.051 ns/op >> ?repeatOneByteString 64 20.859 ? 0.257 15.073 ? 0.024 ns/op >> ?repeatOneByteString 128 36.311 ? 1.162 22.808 ? 0.198 ns/op >> ?repeatOneByteString 1024 149.243 ? 3.083 82.839 ? 0.193 ns/op >> >> ?repeatOneChar 8 28.033 ? 0.615 20.377 ? 0.137 ns/op >> ?repeatOneChar 64 56.399 ? 1.094 36.230 ? 0.051 ns/op >> ?repeatOneChar 128 68.423 ? 5.647 44.157 ? 0.239 ns/op >> ?repeatOneChar 1024 230.115 ? 0.312 179.126 ? 0.437 ns/op >> >> ?replace 8 14.684 ? 0.088 14.434 ? 0.057 ns/op >> ?replace 64 56.811 ? 0.612 56.420 ? 0.050 ns/op >> ?replace 128 112.694 ? 0.404 109.799 ? 1.202 ns/op >> ?replace 1024 837.939 ? 0.855 818.802 ? 0.408 ns/op >> >> ?replaceUtf 8 17.802 ? 0.074 15.744 ? 0.094 ns/op >> ?replaceUtf 64 45.754 ? 0.139 39.228 ? 0.864 ns/op >> ?replaceUtf 128 67.170 ? 0.353 50.497 ? 1.218 ns/op >> ?replaceUtf 1024 415.767 ? 6.829 297.831 ? 22.510 ns/op >> >> ?toCharArray 8 6.164 ? 0.033 6.128 ? 0.064 ns/op >> ?toCharArray 64 10.960 ? 0.032 13.566 ? 0.802 ns/op >> ?toCharArray 128 20.373 ? 0.013 20.823 ? 0.376 ns/op >> ?toCharArray 1024 165.923 ? 0.098 164.362 ? 0.065 ns/op >> >> ?toCharArrayUTF 8 8.009 ? 0.067 7.778 ? 0.026 ns/op >> ?toCharArrayUTF 64 11.112 ? 0.014 10.880 ? 0.010 ns/op >> ?toCharArrayUTF 128 20.390 ? 0.014 20.103 ? 0.017 ns/op >> ?toCharArrayUTF 1024 166.233 ? 0.076 163.827 ? 0.099 ns/op >> >> ?So the question is could we include the changes of attached patch into JDK? >> >> ?With best regards, >> ?Sergey Tsypanov >> >> ?1. Benchmark for array-allocation >> >> ?@BenchmarkMode(Mode.AverageTime) >> ?@OutputTimeUnit(TimeUnit.NANOSECONDS) >> ?@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> ?public class ArrayAllocationBenchmark { >> ??private static Unsafe U; >> >> ??static { >> ????try { >> ??????Field f = Unsafe.class.getDeclaredField("theUnsafe"); >> ??????f.setAccessible(true); >> ??????U = (Unsafe) f.get(null); >> ????} catch (Exception e) { >> ??????new RuntimeException(e); >> ????} >> ??} >> >> ??@Benchmark >> ??public byte[] constructor(Data data) { >> ????return new byte[data.length]; >> ??} >> >> ??@Benchmark >> ??public byte[] unsafe(Data data) { >> ????return (byte[]) U.allocateUninitializedArray(byte.class, data.length); >> ??} >> >> ??@State(Scope.Thread) >> ??public static class Data { >> ????@Param({"0", "10", "100", "1000", "10000"}) >> ????private int length; >> ??} >> ?} >> >> ?2. Benchmark for String-method measurements >> >> ?@BenchmarkMode(Mode.AverageTime) >> ?@OutputTimeUnit(TimeUnit.NANOSECONDS) >> ?@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> ?public class MiscStringBenchmark { >> >> ??@Benchmark >> ??public char[] toCharArrayLatin1(Data data) { >> ????return data.string.toCharArray(); >> ??} >> >> ??@Benchmark >> ??public char[] toCharArrayUTF(Data data) { >> ????return data.utfString.toCharArray(); >> ??} >> >> ??@Benchmark >> ??public String repeatOneByteString(Data data) { >> ????return data.oneCharString.repeat(data.length); >> ??} >> >> ??@Benchmark >> ??public String repeatOneChar(Data data) { >> ????return data.oneUtfCharString.repeat(data.length); >> ??} >> >> ??@Benchmark >> ??public String replace(Data data){ >> ????return data.stringToReplace.replace('z', 'b'); >> ??} >> >> ??@Benchmark >> ??public String replaceUtf(Data data){ >> ????return data.utfStringToReplace.replace('?', '?'); >> ??} >> >> ??@Benchmark >> ??public StringBuilder newStringBuilderWithLength(Data data) { >> ????return new StringBuilder(data.length); >> ??} >> >> ??@Benchmark >> ??public StringBuilder newStringBuilderWithString(Data data) { >> ????return new StringBuilder(data.string); >> ??} >> >> ??@State(Scope.Thread) >> ??public static class Data { >> >> ????@Param({"8", "64", "128", "1024"}) >> ????private int length; >> >> ????private String string; >> ????public String utfString; >> ????private final String oneCharString = "a"; >> ????private final String oneUtfCharString = "?"; >> ????private String stringToReplace; >> ????private String utfStringToReplace; >> >> ????@Setup >> ????public void setup() { >> ??????string = oneCharString.repeat(length); >> ??????utfString = oneUtfCharString.repeat(length); >> >> ??????stringToReplace = string + 'z'; >> ??????utfStringToReplace = utfString + '?'; >> ????} >> ??} >> ?} >> ? -------------- next part -------------- A non-text attachment was scrubbed... Name: uninit_array.patch Type: text/x-diff Size: 4731 bytes Desc: not available URL: 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 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 github.com+70893615+jasontatton-aws at openjdk.java.net Fri Sep 11 10:23:31 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Fri, 11 Sep 2020 10:23:31 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) Message-ID: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 Details of testing: ============ I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the input String. Hence the test has been designed to cover all these cases. In summary they are: - A ?short? string of < 16 characters. - A SIMD String of 16 ? 31 characters. - A AVX2 SIMD String of 32 characters+. Hardware used for testing: ----------------------------- - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). - AWS Graviton 2 (ARM 64 processor). I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. Possible future enhancements: ==================== For the x86 implementation there may be two further improvements we can make in order to improve performance of both the StringUTF16 and StringLatin1 indexOf(char) intrinsics: 1. Make use of AVX-512 instructions. 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD instructions instead of a loop. Benchmark results: ============ **Without** the new StringLatin1 indexOf(char) intrinsic: | Benchmark | Mode | Cnt | Score | Error | Units | | ------------- | ------------- |------------- |------------- |------------- |------------- | | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | **With** the new StringLatin1 indexOf(char) intrinsic: | Benchmark | Mode | Cnt | Score | Error | Units | | ------------- | ------------- |------------- |------------- |------------- |------------- | | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when running on ARM. ------------- Commit messages: - 8173585: further whitespace changes required by jcheck - JDK-8173585 - whitespace changes required by jcheck - JDK-8173585 Changes: https://git.openjdk.java.net/jdk/pull/71/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8173585 Stats: 522 lines in 15 files changed: 506 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/71/head:pull/71 PR: https://git.openjdk.java.net/jdk/pull/71 From michaelm at openjdk.java.net Fri Sep 11 12:13:51 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 11 Sep 2020 12:13:51 GMT Subject: RFR: 8245194: Unix domain socket channel implementation [v2] In-Reply-To: References: Message-ID: > Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >>> think of that. >>> >>> There is a fair bit of other refactoring and simplification done also. Next version is at: >>> >>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >>> >> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the >> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved >> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a >> number points that require clarification to fully understand how this will work with relative, directly relative and >> drive relative paths. >> > > Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That > would leave WindowsPath unchanged. >> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >> to get the file path in bytes. >> > > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to > be useful by other components. >> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its >> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main >> issue is that class is that it means we end up with two classes with static factory methods doing the same thing). > > Okay, that does simplify it a bit. > > Thanks, > Michael. > >> -Alan. >> >> >> >> >> >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: Made some changes relating to selection of the local directory where automatically bound server sockets are created. After this change it is no longer necessary to specify the location in individual tests. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/52/files - new: https://git.openjdk.java.net/jdk/pull/52/files/6d164c91..4d08c15a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=00-01 Stats: 119 lines in 10 files changed: 89 ins; 18 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk/pull/52 From rrich at openjdk.java.net Fri Sep 11 12:51:29 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 11 Sep 2020 12:51:29 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: <5gn4kpaWm8gsnaLTyRdt5Dctl01I210lRJRpaFFhpP0=.ea91bc22-588f-4d7f-a271-4bcbb88129d5@github.com> On Fri, 11 Sep 2020 09:54:50 GMT, Erik Helin wrote: > > > Sorry, now I see. Yes, please remove `, 8233915` from the title! Thanks for helping. The commit message does look better now. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From jpai at openjdk.java.net Fri Sep 11 14:23:48 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 11 Sep 2020 14:23:48 GMT Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) Message-ID: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> 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 ------------- Commit messages: - 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) Changes: https://git.openjdk.java.net/jdk/pull/130/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=130&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244706 Stats: 82 lines in 2 files changed: 79 ins; 1 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 michaelm at openjdk.java.net Fri Sep 11 14:44:10 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 11 Sep 2020 14:44:10 GMT Subject: RFR: 8245194: Unix domain socket channel implementation In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 12:05:07 GMT, Michael McMahon wrote: > Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >>> think of that. >>> >>> There is a fair bit of other refactoring and simplification done also. Next version is at: >>> >>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >>> >> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the >> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved >> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a >> number points that require clarification to fully understand how this will work with relative, directly relative and >> drive relative paths. >> > > Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That > would leave WindowsPath unchanged. >> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >> to get the file path in bytes. >> > > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to > be useful by other components. >> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its >> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main >> issue is that class is that it means we end up with two classes with static factory methods doing the same thing). > > Okay, that does simplify it a bit. > > Thanks, > Michael. > >> -Alan. >> >> >> >> >> >> > _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on > [nio-dev](mailto:nio-dev at openjdk.java.net):_ > On 07/09/2020 13:14, Michael McMahon wrote: > > > > In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a > > > method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place > > > to get the file path in bytes. > > > > > > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to > > be useful by other components. > > The file system provider shouldn't know anything about Unix domain > sockets so I prefer not to have "UnixDomain" in the name of this method. > I also would prefer if null is an exception so that it is consistent > with the other methods. > I'm not sure what to call the method then. It returns a UTF-8 string converted to bytes on Windows and the output of getByteArrayForSysCalls on Unix. It could be called getByteArrayUTF8 on Windows, but that would not be right on Unix. Since sockets are file system entities, why not have socket in the method name? What about getByteArrayForSocket() ? > I think it would be useful to also summarize how the bind/connect works > on Windows. For example, suppose the working directory is 240 characters > and the UnixDomainSocketAddress is to a simple relative path of 20 > characters. If I understand correctly, the proposal will encode the > simple relative path (not the resolved absolute path) to bytes using > UTF-8 so it will probably be 20+ bytes in this case. Right > This hould be okay > but inconsistent with the rest of? file system implementation which will > use the long form. Also if the name is long then it won't use the long > path prefix (\?) but instead rely on failure because the resulting > sequence of bytes when encoded is > 100, is that correct? > Yes, that is how it is working currently. We check the length in native code just before calling bind(). Whether the long path prefix is present or not won't matter because the path will not be used once it is longer than ~100 bytes. Michael. > -Alan. ------------- PR: https://git.openjdk.java.net/jdk/pull/52 From gdub at openjdk.java.net Fri Sep 11 15:07:24 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Fri, 11 Sep 2020 15:07:24 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v3] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Thu, 10 Sep 2020 16:34:02 GMT, Mandy Chung wrote: >> Gilles Duboscq has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove disableEagerInitialization concerns from BridgeMethod.java > > test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java line 33: > >> 31: * @compile LambdaTest6.java >> 32: * @run main LambdaTest6 >> 33: */ > > This line was added by JDK-8232806 (https://hg.openjdk.java.net/jdk/jdk/rev/27c2d2a4b695). > I assume you want to move the test case for JDK-8232806 to test/jdk/java/lang/invoke? If so, > BridgeMethod.java should be looked at too. I have removed all the `disableEagerInitialization` tests from `BridgeMethod.java`. It is now restored to its pre-JDK-8232806 state. ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From gdub at openjdk.java.net Fri Sep 11 15:07:23 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Fri, 11 Sep 2020 15:07:23 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v3] In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. Gilles Duboscq has updated the pull request incrementally with one additional commit since the last revision: Remove disableEagerInitialization concerns from BridgeMethod.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/93/files - new: https://git.openjdk.java.net/jdk/pull/93/files/422cd01d..625feb94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=01-02 Stats: 32 lines in 1 file changed: 0 ins; 22 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/93/head:pull/93 PR: https://git.openjdk.java.net/jdk/pull/93 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 aph at redhat.com Fri Sep 11 15:59:00 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Sep 2020 16:59:00 +0100 Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: <531cacb8-ae5e-0b4c-3a98-7ff8f2b7a054@redhat.com> On 11/09/2020 11:23, Jason Tatton wrote: > For the x86 implementation there may be two further improvements we > can make in order to improve performance of both the StringUTF16 and > StringLatin1 indexOf(char) intrinsics: > > 1. Make use of AVX-512 instructions. Is this really a good idea? When the processor detects Intel AVX instructions, additional voltage is applied to the core. With the additional voltage applied, the processor could run hotter, requiring the operating frequency to be reduced to maintain operations within the TDP limits. The higher voltage is maintained for 1 millisecond after the last Intel AVX instruction completes, and then the voltage returns to the nominal TDP voltage level. https://computing.llnl.gov/tutorials/linux_clusters/intelAVXperformanceWhitePaper.pdf So, if StringLatin1.indexOf(char) executes enough to make a difference to any real-world program, the effect may well be to slow down the clock for all of the code that does not use AVX. > 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD > instructions instead of a loop. -- 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 naoto.sato at oracle.com Fri Sep 11 16:33:57 2020 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 11 Sep 2020 09:33:57 -0700 Subject: Case insensitive regexes and collators In-Reply-To: References: Message-ID: <6f7d07ad-a8e0-dc68-b7ce-a5b774adf228@oracle.com> Hi David, Glad to hear that you are delighted with the recent fix (JDK-8248655). The scope of the fix is limited to the String class, so it may or may not affect the said RegEx and/or Collator case insensitive operations. I created the following two issues to track your observations: https://bugs.openjdk.java.net/browse/JDK-8253058 https://bugs.openjdk.java.net/browse/JDK-8253059 And happy to take a look at them. PS. "jdk-dev" is for the technical discussion related to the "JDK Project", so I'd recommend choosing either core-libs and/or i18n-dev mailing lists for the further discussion. Naoto On 9/10/20 3:52 PM, Dai Conrad wrote: > I was delighted to hear the longstanding problem with > case-insensitive comparisons of strings with astral > characters (ones outside the basic multilingual plane) > was fixed in JDK 16 build 8. Methods equalsIgnoreCase, > regionMatches, and compareToIgnoreCase all work > correctly now. > > I had assumed this would also fix case-insensitive regular > expressions and java.text.Collator, since I guessed they > boiled down to a call to regionMatches somewhere under > the covers. But this appears not to be the... case. > > For scripts Deseret, Osage, Old Hungarian, Warang Citi, > Medefaidrin, and Adlam, for strings with upper- and > lowercase variants of the same letter, the following > code fails: > > Pattern pattern = Pattern.compile(lower, Pattern.CASE_INSENSITIVE); > Matcher matcher = pattern.matcher(upper); > assertThat(matcher.matches()).isTrue(); > > Collator collator = Collator.getInstance(); > collator.setStrength(Collator.PRIMARY); > assertThat(collator.compare(lower, upper)).isEqualTo(0); > > I'm not sure why the fix didn't fix these, but it would be > a shame to overlook them while fixing it in other places. > > David > From mchung at openjdk.java.net Fri Sep 11 18:22:56 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Sep 2020 18:22:56 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v3] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: <5L4AuJbxZaEaS14dbG3o9stCf4ZfdvJX8Db2xnJplcs=.ebfe1a20-d39e-4119-9c34-e4c70a6a5a3e@github.com> On Wed, 9 Sep 2020 16:41:22 GMT, Mandy Chung wrote: >> Gilles Duboscq has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove disableEagerInitialization concerns from BridgeMethod.java > > Looks good. I agree with Jan's suggestion that it's good to move the test to test/jdk/java/lang/invoke/lambda which > is a better home for it. Thanks for updating BridgeMethod.java. I expected that the new LambdaEagerInitTest.java will be updated to verify the capturing lambda case that does not have the static `LAMBDA_INSTANCE$` field. BTW, this new regression test should be moved to `test/jdk/java/lang/invoke/lambda/` instead of `test/jdk/java/lang/invoke`. The test uses `assert`. Note that java assertion is not enabled by default. So regression tests should do an explicit check and throw runtime exception when the test fails. You can also use the JDK test library `jdk.test.lib.Asserts` or make this a testng test to use TestNG Asserts API. I updated and improved the test for your reference (send you separately). ------------- PR: https://git.openjdk.java.net/jdk/pull/93 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 smarks at openjdk.java.net Fri Sep 11 22:28:49 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 11 Sep 2020 22:28:49 GMT Subject: RFR: 8253066: typo in Stream.mapMulti Message-ID: A simple typo fix. ------------- Commit messages: - fix typo in Stream.mapMulti Changes: https://git.openjdk.java.net/jdk/pull/137/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=137&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253066 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/137.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/137/head:pull/137 PR: https://git.openjdk.java.net/jdk/pull/137 From jptatton at amazon.com Fri Sep 11 22:44:39 2020 From: jptatton at amazon.com (Tatton, Jason) Date: Fri, 11 Sep 2020 22:44:39 +0000 Subject: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: Hi Everyone, Please could some reviewers volunteer their time to have a look at this patch? It was marked as a starter bug so I don't expect it will consume a lot of time. Thanks, Jason -----Original Message----- From: hotspot-dev On Behalf Of Jason Tatton Sent: 11 September 2020 11:24 To: core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 Details of testing: ============ I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the input String. Hence the test has been designed to cover all these cases. In summary they are: - A ?short? string of < 16 characters. - A SIMD String of 16 ? 31 characters. - A AVX2 SIMD String of 32 characters+. Hardware used for testing: ----------------------------- - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). - AWS Graviton 2 (ARM 64 processor). I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. Possible future enhancements: ==================== For the x86 implementation there may be two further improvements we can make in order to improve performance of both the StringUTF16 and StringLatin1 indexOf(char) intrinsics: 1. Make use of AVX-512 instructions. 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD instructions instead of a loop. Benchmark results: ============ **Without** the new StringLatin1 indexOf(char) intrinsic: | Benchmark | Mode | Cnt | Score | Error | Units | | ------------- | ------------- |------------- |------------- | |------------- |------------- | IndexOfBenchmark.latin1_mixed_char | | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | | ns/op | **With** the new StringLatin1 indexOf(char) intrinsic: | Benchmark | Mode | Cnt | Score | Error | Units | | ------------- | ------------- |------------- |------------- | |------------- |------------- | IndexOfBenchmark.latin1_mixed_char | | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | | ns/op | The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when running on ARM. ------------- Commit messages: - 8173585: further whitespace changes required by jcheck - JDK-8173585 - whitespace changes required by jcheck - JDK-8173585 Changes: https://git.openjdk.java.net/jdk/pull/71/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8173585 Stats: 522 lines in 15 files changed: 506 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/71/head:pull/71 PR: https://git.openjdk.java.net/jdk/pull/71 From github.com+70893615+jasontatton-aws at openjdk.java.net Fri Sep 11 23:06:42 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Fri, 11 Sep 2020 23:06:42 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: On Tue, 8 Sep 2020 11:59:36 GMT, Jason Tatton wrote: > This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for > x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it > I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as > code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and > java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 > > Details of testing: > ============ > I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note > that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the > input String. Hence the test has been designed to cover all these cases. In summary they are: > - A ?short? string of < 16 characters. > - A SIMD String of 16 ? 31 characters. > - A AVX2 SIMD String of 32 characters+. > > Hardware used for testing: > ----------------------------- > > - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). > - AWS Graviton 2 (ARM 64 processor). > > I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. > > Possible future enhancements: > ==================== > For the x86 implementation there may be two further improvements we can make in order to improve performance of both > the StringUTF16 and StringLatin1 indexOf(char) intrinsics: > 1. Make use of AVX-512 instructions. > 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD > instructions instead of a loop. > Benchmark results: > ============ > **Without** the new StringLatin1 indexOf(char) intrinsic: > > | Benchmark | Mode | Cnt | Score | Error | Units | > | ------------- | ------------- |------------- |------------- |------------- |------------- | > | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | > | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | > > > **With** the new StringLatin1 indexOf(char) intrinsic: > > | Benchmark | Mode | Cnt | Score | Error | Units | > | ------------- | ------------- |------------- |------------- |------------- |------------- | > | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | > | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | > > > The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 > indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when > running on ARM. Hi Andrew, The current indexOf char intrinsics for StringUTF16 and the new one here for StringLatin1 both use the AVX2 ? i.e. 256 bit instructions, these are also affected by the frequency scaling which affects the AVX-512 instructions you pointed out. Of course in a world where all the work taking place is AVX instructions this wouldn?t be an issue but in mixed mode execution this is a problem. However, the compiler does have knowledge of the capability of the CPU upon which it?s optimizing code for and is able to decide whether to use AVX instructions if they are supported by the CPU AND if it wouldn?t be detrimental for performance. In fact, there is a flag which one can use to interact with this: -XX:UseAVX=version. This of course made testing this patch an interesting experience as the AVX2 instructions were not enabled on the Xeon processors which I had access to at AWS, but in the end I was able to use an i7 on my corporate macbook to validate the code. From: mlbridge[bot] Sent: 11 September 2020 17:01 To: openjdk/jdk Cc: Tatton, Jason ; Mention Subject: Re: [openjdk/jdk] 8173585: Intrinsify StringLatin1.indexOf(char) (#71) Mailing list message from Andrew Haley on hotspot-dev: On 11/09/2020 11:23, Jason Tatton wrote: For the x86 implementation there may be two further improvements we can make in order to improve performance of both the StringUTF16 and StringLatin1 indexOf(char) intrinsics: 1. Make use of AVX-512 instructions. Is this really a good idea? When the processor detects Intel AVX instructions, additional voltage is applied to the core. With the additional voltage applied, the processor could run hotter, requiring the operating frequency to be reduced to maintain operations within the TDP limits. The higher voltage is maintained for 1 millisecond after the last Intel AVX instruction completes, and then the voltage returns to the nominal TDP voltage level. https://computing.llnl.gov/tutorials/linux_clusters/intelAVXperformanceWhitePaper.pdf So, if StringLatin1.indexOf(char) executes enough to make a difference to any real-world program, the effect may well be to slow down the clock for all of the code that does not use AVX. 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD instructions instead of a loop. -- 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 ? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From darcy at openjdk.java.net Fri Sep 11 23:08:21 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 11 Sep 2020 23:08:21 GMT Subject: RFR: 8253066: typo in Stream.mapMulti In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 22:20:48 GMT, Stuart Marks wrote: > A simple typo fix. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/137 From smarks at openjdk.java.net Fri Sep 11 23:13:52 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 11 Sep 2020 23:13:52 GMT Subject: Integrated: 8253066: typo in Stream.mapMulti In-Reply-To: References: Message-ID: <4D_UHYL9EIdmGM9e5YefFvAh29FUu0nZmi8ejQG9zSw=.3b761abb-82ce-494f-ba8e-3f28e664bbbd@github.com> On Fri, 11 Sep 2020 22:20:48 GMT, Stuart Marks wrote: > A simple typo fix. This pull request has now been integrated. Changeset: b1b0f0b2 Author: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/b1b0f0b2 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8253066: typo in Stream.mapMulti Reviewed-by: darcy, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/137 From lancea at openjdk.java.net Fri Sep 11 23:13:51 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 11 Sep 2020 23:13:51 GMT Subject: RFR: 8253066: typo in Stream.mapMulti In-Reply-To: References: Message-ID: <_n_p0apouYwowGk0dFFBwyvlWKoKY0G85ICp55eyI38=.2b8342de-a043-4790-8d7d-d9550a31f39a@github.com> On Fri, 11 Sep 2020 22:20:48 GMT, Stuart Marks wrote: > A simple typo fix. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/137 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 almatvee at openjdk.java.net Sat Sep 12 02:22:31 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 12 Sep 2020 02:22:31 GMT Subject: RFR: 8223187: Investigate setLocale() call in jpackage native launcher Message-ID: setlocale() affects several C functions. We do not use most of these functions. We only using isspace() and toLower(). Based on how we use it I do not see any needs for setlocale(). After removing it I retested jpackage by changing locally on machine and using different language as input parameters for jpackage. No issues found. ------------- Commit messages: - 8223187: Investigate setLocale() call in jpackage native launcher Changes: https://git.openjdk.java.net/jdk/pull/138/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=138&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223187 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/138.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/138/head:pull/138 PR: https://git.openjdk.java.net/jdk/pull/138 From iklam at openjdk.java.net Sat Sep 12 06:35:31 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 12 Sep 2020 06:35:31 GMT Subject: RFR: 8244778: Archive full module graph in CDS [v4] In-Reply-To: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: > 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. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into 8244778-archive-full-module-graph - Feedback from Coleen - Removed TODO comment referring to JBS issue - Merge branch 'master' into 8244778-archive-full-module-graph - fixed trailing spaces - Renamed ModuleEntry::write_growable_array - Update to latest repo (JDK-8251557); added comments - 8244778: Archive full module graph in CDS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/80/files - new: https://git.openjdk.java.net/jdk/pull/80/files/e541890e..a1abed8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=02-03 Stats: 8945 lines in 269 files changed: 3645 ins; 3698 del; 1602 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 github.com+50187+galderz at openjdk.java.net Sat Sep 12 12:11:00 2020 From: github.com+50187+galderz at openjdk.java.net (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Sat, 12 Sep 2020 12:11:00 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor Message-ID: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> * Release fence guarantees that cacheArray field will published with a non-null value. * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. This is a follow up to @PaulSandoz's feedback [here](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068248.html) for the first attempt to fix [JDK-8251397](https://bugs.openjdk.java.net/browse/JDK-8251397). In this update, the fence has been moved to `initializeMap()` and added Paul's suggested comment. Annotating `classValueMap` with `@Stable` is outside the scope of this issue. ------------- Commit messages: - 8251397: Add release fence to ClassValueMap constructor Changes: https://git.openjdk.java.net/jdk/pull/94/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=94&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251397 Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/94.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/94/head:pull/94 PR: https://git.openjdk.java.net/jdk/pull/94 From shade at openjdk.java.net Sat Sep 12 12:11:03 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sat, 12 Sep 2020 12:11:03 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: On Wed, 9 Sep 2020 12:35:06 GMT, Galder Zamarre?o wrote: > * Release fence guarantees that cacheArray field will published with a non-null value. > * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. > > This is a follow up to @PaulSandoz's feedback > [here](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068248.html) for the first attempt to fix > [JDK-8251397](https://bugs.openjdk.java.net/browse/JDK-8251397). In this update, the fence has been moved to > `initializeMap()` and added Paul's suggested comment. > Annotating `classValueMap` with `@Stable` is outside the scope of this issue. I believe current patch is incorrect. Marked as reviewed by shade (Reviewer). src/java.base/share/classes/java/lang/ClassValue.java line 386: > 384: // since stores to the fields of ClassValueMap will not be reordered > 385: // to occur after the store to the field type.classValueMap > 386: UNSAFE.storeFence(); Wait a second, how's that supposed to work? The `storeFence` should be between the end of `new ClassValueMap()` and the store to `classValueMap`. ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/94 From psandoz at openjdk.java.net Sat Sep 12 12:11:05 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Sat, 12 Sep 2020 12:11:05 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: On Wed, 9 Sep 2020 12:35:06 GMT, Galder Zamarre?o wrote: > * Release fence guarantees that cacheArray field will published with a non-null value. > * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. > > This is a follow up to @PaulSandoz's feedback > [here](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068248.html) for the first attempt to fix > [JDK-8251397](https://bugs.openjdk.java.net/browse/JDK-8251397). In this update, the fence has been moved to > `initializeMap()` and added Paul's suggested comment. > Annotating `classValueMap` with `@Stable` is outside the scope of this issue. Marked as reviewed by psandoz (Reviewer). src/java.base/share/classes/java/lang/ClassValue.java line 381: > 379: if ((map = type.classValueMap) == null) { > 380: map = new ClassValueMap(); > 381: // Place a Store fence as the last operation to emulate Since the store was moved i suggest the comment be slightly updated: "Place a Store fence after construction and before publishing to emulate" ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From sgehwolf at openjdk.java.net Sat Sep 12 12:11:06 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Sat, 12 Sep 2020 12:11:06 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: On Thu, 10 Sep 2020 08:08:10 GMT, Aleksey Shipilev wrote: >> * Release fence guarantees that cacheArray field will published with a non-null value. >> * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. >> >> This is a follow up to @PaulSandoz's feedback >> [here](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068248.html) for the first attempt to fix >> [JDK-8251397](https://bugs.openjdk.java.net/browse/JDK-8251397). In this update, the fence has been moved to >> `initializeMap()` and added Paul's suggested comment. >> Annotating `classValueMap` with `@Stable` is outside the scope of this issue. > > Marked as reviewed by shade (Reviewer). Just noting here that @galderz is a Red Hat employee and should be covered by the Red Hat OCA: https://www.oracle.com/technical-resources/oracle-contributor-agreement.html#r ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From sgehwolf at openjdk.java.net Sat Sep 12 12:11:07 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Sat, 12 Sep 2020 12:11:07 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: <4qAi85w_bpDAq9acEjisUho22TxE0_TPLkOjxoIFKlI=.ffe87726-9c97-46cc-b98b-659fb1e785e2@github.com> On Thu, 10 Sep 2020 10:03:53 GMT, Severin Gehwolf wrote: >> Marked as reviewed by shade (Reviewer). > > Just noting here that @galderz is a Red Hat employee and should be covered by the Red Hat OCA: > https://www.oracle.com/technical-resources/oracle-contributor-agreement.html#r @galderz We'll have to wait until somebody marks your github handle as OCA approved or some such :-/ ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From github.com+50187+galderz at openjdk.java.net Sat Sep 12 12:11:09 2020 From: github.com+50187+galderz at openjdk.java.net (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Sat, 12 Sep 2020 12:11:09 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: On Wed, 9 Sep 2020 12:43:20 GMT, Aleksey Shipilev wrote: >> * Release fence guarantees that cacheArray field will published with a non-null value. >> * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. >> >> This is a follow up to @PaulSandoz's feedback >> [here](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068248.html) for the first attempt to fix >> [JDK-8251397](https://bugs.openjdk.java.net/browse/JDK-8251397). In this update, the fence has been moved to >> `initializeMap()` and added Paul's suggested comment. >> Annotating `classValueMap` with `@Stable` is outside the scope of this issue. > > src/java.base/share/classes/java/lang/ClassValue.java line 386: > >> 384: // since stores to the fields of ClassValueMap will not be reordered >> 385: // to occur after the store to the field type.classValueMap >> 386: UNSAFE.storeFence(); > > Wait a second, how's that supposed to work? The `storeFence` should be between the end of `new ClassValueMap()` and the > store to `classValueMap`. Ah yes, my bad ????? ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From github.com+50187+galderz at openjdk.java.net Sat Sep 12 12:11:10 2020 From: github.com+50187+galderz at openjdk.java.net (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Sat, 12 Sep 2020 12:11:10 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: On Wed, 9 Sep 2020 12:50:07 GMT, Galder Zamarre?o wrote: >> src/java.base/share/classes/java/lang/ClassValue.java line 386: >> >>> 384: // since stores to the fields of ClassValueMap will not be reordered >>> 385: // to occur after the store to the field type.classValueMap >>> 386: UNSAFE.storeFence(); >> >> Wait a second, how's that supposed to work? The `storeFence` should be between the end of `new ClassValueMap()` and the >> store to `classValueMap`. > > Ah yes, my bad ????? Updated PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From shade at openjdk.java.net Sat Sep 12 12:11:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sat, 12 Sep 2020 12:11:10 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: On Wed, 9 Sep 2020 12:53:41 GMT, Galder Zamarre?o wrote: >> Ah yes, my bad ????? > > Updated PR. Now I wonder (after reading the discussion), why not `UNSAFE.storeStoreFence()`? I am basically okay with either, given they currently map to the same thing. But it seems that semantically only `storeStoreFence` is really needed here. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From shade at openjdk.java.net Sat Sep 12 12:11:11 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sat, 12 Sep 2020 12:11:11 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: On Wed, 9 Sep 2020 13:04:38 GMT, Aleksey Shipilev wrote: >> Updated PR. > > Now I wonder (after reading the discussion), why not `UNSAFE.storeStoreFence()`? I am basically okay with either, given > they currently map to the same thing. But it seems that semantically only `storeStoreFence` is really needed here. Scratch that. Hotspot does `MemBar_Release` for final stores, low-level Java code is better do the same: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/parse1.cpp#L1005 It deserves a separate follow-up to homogenize the uses of `Unsafe.storeStoreFence` and `Unsafe.storeFence` in other places in JDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From github.com+50187+galderz at openjdk.java.net Sat Sep 12 12:11:12 2020 From: github.com+50187+galderz at openjdk.java.net (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Sat, 12 Sep 2020 12:11:12 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: On Wed, 9 Sep 2020 15:13:29 GMT, Paul Sandoz wrote: >> * Release fence guarantees that cacheArray field will published with a non-null value. >> * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. >> >> This is a follow up to @PaulSandoz's feedback >> [here](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068248.html) for the first attempt to fix >> [JDK-8251397](https://bugs.openjdk.java.net/browse/JDK-8251397). In this update, the fence has been moved to >> `initializeMap()` and added Paul's suggested comment. >> Annotating `classValueMap` with `@Stable` is outside the scope of this issue. > > src/java.base/share/classes/java/lang/ClassValue.java line 381: > >> 379: if ((map = type.classValueMap) == null) { >> 380: map = new ClassValueMap(); >> 381: // Place a Store fence as the last operation to emulate > > Since the store was moved i suggest the comment be slightly updated: > "Place a Store fence after construction and before publishing to emulate" Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From kcr at openjdk.java.net Sat Sep 12 12:44:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Sep 2020 12:44:26 GMT Subject: RFR: 8223187: Investigate setLocale() call in jpackage native launcher In-Reply-To: References: Message-ID: <75RGu-VjYLN3LmRUThjNX9z0nBp_I2MwNZAeD7Vzvvc=.614ccc28-c57e-4117-a7b6-b56b44feb61d@github.com> On Sat, 12 Sep 2020 02:15:29 GMT, Alexander Matveev wrote: > setlocale() affects several C functions. We do not use most of these functions. We only using isspace() and toLower(). > Based on how we use it I do not see any needs for setlocale(). After removing it I retested jpackage by changing > locally on machine and using different language as input parameters for jpackage. No issues found. Looks good. I confirmed that these are the only two calls to `setlocale` in the jpackage sources. ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/138 From redestad at openjdk.java.net Sat Sep 12 12:46:43 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Sat, 12 Sep 2020 12:46:43 GMT Subject: RFR: 8244778: Archive full module graph in CDS [v4] In-Reply-To: References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: On Sat, 12 Sep 2020 06:35:31 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. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes > the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last > revision: > - Merge branch 'master' into 8244778-archive-full-module-graph > - Feedback from Coleen > - Removed TODO comment referring to JBS issue > - Merge branch 'master' into 8244778-archive-full-module-graph > - fixed trailing spaces > - Renamed ModuleEntry::write_growable_array > - Update to latest repo (JDK-8251557); added comments > - 8244778: Archive full module graph in CDS Excellent work! Only a few minor comments inline, which you can choose to ignore. src/hotspot/share/classfile/classLoaderDataShared.cpp line 82: > 80: assert_valid(loader_data); > 81: if (loader_data != NULL) { > 82: // We can't create hashtables at dump time because the hashcode dependes on the dependes -> depends src/hotspot/share/classfile/classLoaderDataShared.cpp line 84: > 82: // We can't create hashtables at dump time because the hashcode dependes on the > 83: // address of the Symbols, which may be relocated at run time due to ASLR. > 84: // So we store the packages/modules in a Arrays. At run time, we create run time -> runtime a Arrays -> Arrays src/hotspot/share/classfile/javaClasses.cpp line 4830: > 4828: if (klass == SystemDictionary::ClassLoader_klass() || // ClassLoader::loader_data is malloc'ed. > 4829: // The next 3 classes are used to implement java.lang.invoke, and are not used directly in > 4830: // regular Java code. The implementation of java.lang.invoke uses generated anonymoys classes pre-existing: anonymoys src/hotspot/share/classfile/modules.cpp line 462: > 460: > 461: // We don't want the classes used by the archived full module graph to be redefined by JVMTI. > 462: // Luckily, such classes are loaded in the JVMTI "early" phase, and CDS is disable if a JVMTI disabled src/hotspot/share/memory/heapShared.cpp line 76: > 74: // assigned at runtime. > 75: static ArchivableStaticFieldInfo closed_archive_subgraph_entry_fields[] = { > 76: {"java/lang/Integer$IntegerCache", 0, "archivedCache"}, Could the changes here be simplified or clarified? I think the new field should be a bool, or we could instead introduce a new array for the fields archived only when archiving the full module graph (the field is ignored on iteration over closed_archive_subgraph_entry_fields anyhow) ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/80 From kcr at openjdk.java.net Sat Sep 12 13:03:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Sep 2020 13:03:06 GMT Subject: RFR: 8223187: Investigate setLocale() call in jpackage native launcher In-Reply-To: <75RGu-VjYLN3LmRUThjNX9z0nBp_I2MwNZAeD7Vzvvc=.614ccc28-c57e-4117-a7b6-b56b44feb61d@github.com> References: <75RGu-VjYLN3LmRUThjNX9z0nBp_I2MwNZAeD7Vzvvc=.614ccc28-c57e-4117-a7b6-b56b44feb61d@github.com> Message-ID: On Sat, 12 Sep 2020 12:41:50 GMT, Kevin Rushforth wrote: >> setlocale() affects several C functions. We do not use most of these functions. We only using isspace() and toLower(). >> Based on how we use it I do not see any needs for setlocale(). After removing it I retested jpackage by changing >> locally on machine and using different language as input parameters for jpackage. No issues found. > > Looks good. I confirmed that these are the only two calls to `setlocale` in the jpackage sources. Note: the title of the JBS bug was updated. Can you update the PR title to match? ------------- PR: https://git.openjdk.java.net/jdk/pull/138 From ecki at zusammenkunft.net Sat Sep 12 13:45:37 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 12 Sep 2020 13:45:37 +0000 Subject: Fwd: RFR: 8223187: Investigate setLocale() call in jpackage native launcher In-Reply-To: References: , Message-ID: Hello, What about system errors (exception messages from strerr?). I mean in case one wants to enforce English version with user.locale for support reasons? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Alexander Matveev Gesendet: Saturday, September 12, 2020 4:22:31 AM An: core-libs-dev at openjdk.java.net Betreff: RFR: 8223187: Investigate setLocale() call in jpackage native launcher setlocale() affects several C functions. We do not use most of these functions. We only using isspace() and toLower(). Based on how we use it I do not see any needs for setlocale(). After removing it I retested jpackage by changing locally on machine and using different language as input parameters for jpackage. No issues found. ------------- Commit messages: - 8223187: Investigate setLocale() call in jpackage native launcher Changes: https://git.openjdk.java.net/jdk/pull/138/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=138&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223187 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/138.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/138/head:pull/138 PR: https://git.openjdk.java.net/jdk/pull/138 From herrick at openjdk.java.net Sat Sep 12 14:17:56 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Sat, 12 Sep 2020 14:17:56 GMT Subject: RFR: 8223187: Investigate setLocale() call in jpackage native launcher In-Reply-To: References: <75RGu-VjYLN3LmRUThjNX9z0nBp_I2MwNZAeD7Vzvvc=.614ccc28-c57e-4117-a7b6-b56b44feb61d@github.com> Message-ID: On Sat, 12 Sep 2020 13:00:22 GMT, Kevin Rushforth wrote: >> Looks good. I confirmed that these are the only two calls to `setlocale` in the jpackage sources. > > Note: the title of the JBS bug was updated. Can you update the PR title to match? Looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/138 From herrick at openjdk.java.net Sat Sep 12 14:58:23 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Sat, 12 Sep 2020 14:58:23 GMT Subject: RFR: 8223187: Investigate setLocale() call in jpackage native launcher In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 02:15:29 GMT, Alexander Matveev wrote: > setlocale() affects several C functions. We do not use most of these functions. We only using isspace() and toLower(). > Based on how we use it I do not see any needs for setlocale(). After removing it I retested jpackage by changing > locally on machine and using different language as input parameters for jpackage. No issues found. Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/138 From lancea at openjdk.java.net Sat Sep 12 17:41:05 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 12 Sep 2020 17:41:05 GMT Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) In-Reply-To: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> Message-ID: On Fri, 11 Sep 2020 14:17:45 GMT, Jaikiran Pai wrote: > 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 Hi Jaikiran, The change seems fine an inline with the RFC. I can sponsor this once we have another review. I have run the JCK tests for Zip/Gzip/Jar and Mach5 JDK tier1, tier2 and tier3 ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/130 From herrick at openjdk.java.net Sat Sep 12 18:36:56 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Sat, 12 Sep 2020 18:36:56 GMT Subject: RFR: JDK-8230652: Improve verbose output Message-ID: JDK-8230652 Extracting the commands displayed by verbose output (including commands called thru ToolProvider) , to contain the the command, it's output, and it's return value on separate lines and formatted in a way that they can be easily cut and pasted into a script. ------------- Commit messages: - JDK-8230652: Improve verbose output Changes: https://git.openjdk.java.net/jdk/pull/141/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=141&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8230652 Stats: 78 lines in 9 files changed: 42 ins; 25 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/141.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/141/head:pull/141 PR: https://git.openjdk.java.net/jdk/pull/141 From iklam at openjdk.java.net Sat Sep 12 18:37:35 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 12 Sep 2020 18:37:35 GMT Subject: RFR: 8244778: Archive full module graph in CDS [v4] In-Reply-To: References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: On Sat, 12 Sep 2020 12:34:06 GMT, Claes Redestad wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes >> the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last >> revision: >> - Merge branch 'master' into 8244778-archive-full-module-graph >> - Feedback from Coleen >> - Removed TODO comment referring to JBS issue >> - Merge branch 'master' into 8244778-archive-full-module-graph >> - fixed trailing spaces >> - Renamed ModuleEntry::write_growable_array >> - Update to latest repo (JDK-8251557); added comments >> - 8244778: Archive full module graph in CDS > > src/hotspot/share/memory/heapShared.cpp line 76: > >> 74: // assigned at runtime. >> 75: static ArchivableStaticFieldInfo closed_archive_subgraph_entry_fields[] = { >> 76: {"java/lang/Integer$IntegerCache", 0, "archivedCache"}, > > Could the changes here be simplified or clarified? I think the new field should be a bool, or we could instead > introduce a new array for the fields archived only when archiving the full module graph (the field is ignored on > iteration over closed_archive_subgraph_entry_fields anyhow) I split out the new fields into a separate array as you suggested. Also fixed the typos you found. See commit [e987110](https://github.com/openjdk/jdk/pull/80/commits/e98711029879ffa21757ca871120ad7b17344d01). ------------- PR: https://git.openjdk.java.net/jdk/pull/80 From iklam at openjdk.java.net Sat Sep 12 18:37:31 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 12 Sep 2020 18:37:31 GMT Subject: RFR: 8244778: Archive full module graph in CDS [v5] In-Reply-To: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: > 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. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Claes feedback (typos, refactored archived fields init); also added missing TRAPS param ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/80/files - new: https://git.openjdk.java.net/jdk/pull/80/files/a1abed8f..e9871102 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=03-04 Stats: 91 lines in 6 files changed: 38 ins; 16 del; 37 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 iklam at openjdk.java.net Sat Sep 12 22:41:36 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 12 Sep 2020 22:41:36 GMT Subject: RFR: 8244778: Archive full module graph in CDS [v6] In-Reply-To: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: <0xjoJLaycnQVcrxo61AvhCGz42xU6J3k3dGamDZLASQ=.4441ed23-e92c-4a4f-ad70-cd555dc9be17@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. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed failure in runtime/cds/DeterministicDump.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/80/files - new: https://git.openjdk.java.net/jdk/pull/80/files/e9871102..97706f58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=04-05 Stats: 27 lines in 2 files changed: 10 ins; 3 del; 14 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 jpai at openjdk.java.net Sun Sep 13 02:25:13 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 13 Sep 2020 02:25:13 GMT Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) In-Reply-To: References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> Message-ID: On Sat, 12 Sep 2020 17:38:34 GMT, Lance Andersen wrote: >> 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 > > Hi Jaikiran, > > The change seems fine an inline with the RFC. I can sponsor this once we have another review. > > I have run the JCK tests for Zip/Gzip/Jar and Mach5 JDK tier1, tier2 and tier3 Thank you Lance for the review and running the tests. I'll wait for another review before initiating the integrate command. ------------- PR: https://git.openjdk.java.net/jdk/pull/130 From redestad at openjdk.java.net Sun Sep 13 13:32:11 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Sun, 13 Sep 2020 13:32:11 GMT Subject: RFR: 8244778: Archive full module graph in CDS [v6] In-Reply-To: <0xjoJLaycnQVcrxo61AvhCGz42xU6J3k3dGamDZLASQ=.4441ed23-e92c-4a4f-ad70-cd555dc9be17@github.com> References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> <0xjoJLaycnQVcrxo61AvhCGz42xU6J3k3dGamDZLASQ=.4441ed23-e92c-4a4f-ad70-cd555dc9be17@github.com> Message-ID: On Sat, 12 Sep 2020 22:41:36 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. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed failure in runtime/cds/DeterministicDump.java Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/80 From iklam at openjdk.java.net Sun Sep 13 14:47:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Sun, 13 Sep 2020 14:47:57 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: 03a4df0a Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/03a4df0a Stats: 2080 lines in 59 files changed: 28 ins; 1916 del; 136 mod 8244778: Archive full module graph in CDS Reviewed-by: erikj, coleenp, lfoltan, redestad, alanb, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/80 From dholmes at openjdk.java.net Mon Sep 14 02:59:15 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Sep 2020 02:59:15 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: <4qAi85w_bpDAq9acEjisUho22TxE0_TPLkOjxoIFKlI=.ffe87726-9c97-46cc-b98b-659fb1e785e2@github.com> References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> <4qAi85w_bpDAq9acEjisUho22TxE0_TPLkOjxoIFKlI=.ffe87726-9c97-46cc-b98b-659fb1e785e2@github.com> Message-ID: On Thu, 10 Sep 2020 13:29:29 GMT, Severin Gehwolf wrote: >> Just noting here that @galderz is a Red Hat employee and should be covered by the Red Hat OCA: >> https://www.oracle.com/technical-resources/oracle-contributor-agreement.html#r > > @galderz We'll have to wait until somebody marks your github handle as OCA approved or some such :-/ Please ensure the PR title and the bug synopsis match before this in integrated! Please DO NOT force-push updates as you lose the history of commits and anyone following this cannot see what changes were actually made at each step! You do not need to worry about intermediate commits as they will only appear in your branch and in the PR. The actual committed changeset will be a single flattened version of your changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 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 dholmes at openjdk.java.net Mon Sep 14 06:05:36 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Sep 2020 06:05:36 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 20:48:23 GMT, Richard Reingruber wrote: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. I can't review this in-depth as I am not familiar with too much of the code. I have looked at some of the key threading related parts and have made a number of comments. src/hotspot/share/compiler/compileBroker.cpp line 831: > 829: MonitorLocker ml(dt, EscapeBarrier_lock, Mutex::_no_safepoint_check_flag); > 830: static int single_thread_count = 0; > 831: enter_single_loop = single_thread_count++ < DeoptimizeObjectsALotThreadCountSingle; The update to `single_thread_count` is not atomic. src/hotspot/share/compiler/compileBroker.cpp line 844: > 842: void DeoptimizeObjectsALotThread::deoptimize_objects_alot_loop_single() { > 843: HandleMark hm(this); > 844: while (!this->is_terminated()) { The terminated state of a thread is used to communicate to other threads whether this thread has terminated. It isn't something that can be used to control the work-loop of the thread itself! This is an infinite loop as far as I can see. src/hotspot/share/compiler/compileBroker.cpp line 862: > 860: void DeoptimizeObjectsALotThread::deoptimize_objects_alot_loop_all() { > 861: HandleMark hm(this); > 862: while (!is_terminated()) { Same comment as above. src/hotspot/share/opto/macro.cpp line 1096: > 1094: // interpreter frames for this compiled frame and that won't play > 1095: // nice with JVMTI popframe. > 1096: if (!EliminateAllocations || !alloc->_is_non_escaping) { The comment needs to be updated to match the new code. src/hotspot/share/prims/whitebox.cpp line 884: > 882: > 883: WB_ENTRY(jboolean, WB_IsFrameDeoptimized(JNIEnv* env, jobject o, jint depth)) > 884: JavaThread* t = JavaThread::current(); A WB_ENTRY is a JNI_ENTRY which means the current JavaThread is already available via the `thread` variable. src/hotspot/share/runtime/thread.cpp line 2647: > 2645: bool should_spin_wait = true; > 2646: do { > 2647: set_thread_state(_thread_blocked); It isn't obvious that this raw thread state change is safe. src/hotspot/share/runtime/thread.cpp line 2660: > 2658: // showed 5% better performance when spinning. > 2659: if (should_spin_wait) { > 2660: // Inspired by HandshakeSpinYield Can we not reuse any existing spinning code in the VM? src/hotspot/share/runtime/thread.cpp line 2640: > 2638: } > 2639: > 2640: void JavaThread::wait_for_object_deoptimization() { I find this method very complex, and the fact it needs to recheck many of the conditions already checked in the calling code, suggests to me that the structure here is not quite right. Perhaps JavaThread::handle_special_runtime_exit_condition should be the place where we loop over each of the potential conditions, instead of calling per-condition code that then loops and potentially rechecks other conditions. src/hotspot/share/runtime/thread.cpp line 1926: > 1924: delete dlv; > 1925: } while (deferred->length() != 0); > 1926: delete deferred_updates(); This looks suspect - we delete what is pointed to but we don't NULL the field. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 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 github.com+50187+galderz at openjdk.java.net Mon Sep 14 08:06:28 2020 From: github.com+50187+galderz at openjdk.java.net (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 14 Sep 2020 08:06:28 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> <4qAi85w_bpDAq9acEjisUho22TxE0_TPLkOjxoIFKlI=.ffe87726-9c97-46cc-b98b-659fb1e785e2@github.com> Message-ID: <96E0aveQi3HxE_R8L3aGo0Wy2uY25CtNOYERHDvblrk=.bdb70804-820d-4cfe-acec-1f6045d00a12@github.com> On Mon, 14 Sep 2020 02:56:43 GMT, David Holmes wrote: >> @galderz We'll have to wait until somebody marks your github handle as OCA approved or some such :-/ > > Please ensure the PR title and the bug synopsis match before this in integrated! > > Please DO NOT force-push updates as you lose the history of commits and anyone following this cannot see what changes > were actually made at each step! You do not need to worry about intermediate commits as they will only appear in your > branch and in the PR. The actual committed changeset will be a single flattened version of your changes. Are you expecting anything else from me? @jerboaa already proposed as sponsor above. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From rrich at openjdk.java.net Mon Sep 14 08:18:04 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 14 Sep 2020 08:18:04 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: <59VhddIbMR3X24jGMsDpR_wOSWypMFIeXbs5l5rhLYs=.2c5e00e4-8b16-4237-8a7c-4cdceaaebe18@github.com> On Mon, 14 Sep 2020 04:57:21 GMT, David Holmes wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >> >> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >> >> Thanks, Richard. > > src/hotspot/share/compiler/compileBroker.cpp line 831: > >> 829: MonitorLocker ml(dt, EscapeBarrier_lock, Mutex::_no_safepoint_check_flag); >> 830: static int single_thread_count = 0; >> 831: enter_single_loop = single_thread_count++ < DeoptimizeObjectsALotThreadCountSingle; > > The update to `single_thread_count` is not atomic. I think it is atomic because it is never accessed without holding EscapeBarrier_lock ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From sgehwolf at openjdk.java.net Mon Sep 14 08:28:16 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 14 Sep 2020 08:28:16 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: <96E0aveQi3HxE_R8L3aGo0Wy2uY25CtNOYERHDvblrk=.bdb70804-820d-4cfe-acec-1f6045d00a12@github.com> References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> <4qAi85w_bpDAq9acEjisUho22TxE0_TPLkOjxoIFKlI=.ffe87726-9c97-46cc-b98b-659fb1e785e2@github.com> <96E0aveQi3HxE_R8L3aGo0Wy2uY25CtNOYERHDvblrk=.bdb70804-820d-4cfe-acec-1f6045d00a12@github.com> Message-ID: On Mon, 14 Sep 2020 08:03:51 GMT, Galder Zamarre?o wrote: >> Please ensure the PR title and the bug synopsis match before this in integrated! >> >> Please DO NOT force-push updates as you lose the history of commits and anyone following this cannot see what changes >> were actually made at each step! You do not need to worry about intermediate commits as they will only appear in your >> branch and in the PR. The actual committed changeset will be a single flattened version of your changes. > > Are you expecting anything else from me? @jerboaa already proposed as sponsor above. @galderz The PR has this synopsis `8251397: Add release fence to ClassValueMap constructor`. The bug has this `8251397: NPE on ClassValue.ClassValueMap.cacheArray`. @dholmes-ora asked to make them matching. Let's fix that first. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From sgehwolf at openjdk.java.net Mon Sep 14 08:28:18 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 14 Sep 2020 08:28:18 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> <4qAi85w_bpDAq9acEjisUho22TxE0_TPLkOjxoIFKlI=.ffe87726-9c97-46cc-b98b-659fb1e785e2@github.com> <96E0aveQi3HxE_R8L3aGo0Wy2uY25CtNOYERHDvblrk=.bdb70804-820d-4cfe-acec-1f6045d00a12@github.com> Message-ID: On Mon, 14 Sep 2020 08:24:15 GMT, Severin Gehwolf wrote: >> Are you expecting anything else from me? @jerboaa already proposed as sponsor above. > > @galderz The PR has this synopsis `8251397: Add release fence to ClassValueMap constructor`. The bug has this `8251397: > NPE on ClassValue.ClassValueMap.cacheArray`. @dholmes-ora asked to make them matching. Let's fix that first. You can add what you have as synopsis now via /summary and the bot. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From aph at redhat.com Mon Sep 14 08:37:39 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Sep 2020 09:37:39 +0100 Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: On 12/09/2020 00:06, Jason Tatton wrote: > The current indexOf char intrinsics for StringUTF16 and the new one > here for StringLatin1 both use the AVX2 ? i.e. 256 bit instructions, > these are also affected by the frequency scaling which affects the > AVX-512 instructions you pointed out. Of course in a world where all > the work taking place is AVX instructions this wouldn?t be an issue > but in mixed mode execution this is a problem. Right. > However, the compiler does have knowledge of the capability of the > CPU upon which it?s optimizing code for and is able to decide > whether to use AVX instructions if they are supported by the CPU AND > if it wouldn?t be detrimental for performance. In fact, there is a > flag which one can use to interact with this: -XX:UseAVX=version. Sure. But the question to be answered is this: we can use AVX for this, but should we? "It's there, so we should use it" isn't sound reasoning. My guess is that there are no (non-FP) workloads where AVX dominates. And that therefore throwing AVX at trivial jobs may make our programs slower; this is a pessimization. I have to emphahsize that I don't know the answer to this question. > This of course made testing this patch an interesting experience as > the AVX2 instructions were not enabled on the Xeon processors which > I had access to at AWS, but in the end I was able to use an i7 on my > corporate macbook to validate the code. So: is this worth doing? Are there workloads where this helps? Where this hinders? This is the kind of systems thinking we should be doing when optimizing. -- 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 michaelm at openjdk.java.net Mon Sep 14 12:01:08 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 14 Sep 2020 12:01:08 GMT Subject: RFR: 8245194: Unix domain socket channel implementation [v3] In-Reply-To: References: Message-ID: > Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >>> think of that. >>> >>> There is a fair bit of other refactoring and simplification done also. Next version is at: >>> >>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >>> >> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the >> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved >> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a >> number points that require clarification to fully understand how this will work with relative, directly relative and >> drive relative paths. >> > > Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That > would leave WindowsPath unchanged. >> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >> to get the file path in bytes. >> > > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to > be useful by other components. >> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its >> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main >> issue is that class is that it means we end up with two classes with static factory methods doing the same thing). > > Okay, that does simplify it a bit. > > Thanks, > Michael. > >> -Alan. >> >> >> >> >> >> Michael McMahon 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 four additional commits since the last revision: - Merge branch 'master' into unixdomainchannels - Made some changes relating to selection of the local directory where automatically bound server sockets are created. After this change it is no longer necessary to specify the location in individual tests. - unixdomainchannels: fixing compile error on Windows and Alan's review comment this morning - unixdomainchannels: initial commit from hg sandbox with changes from Alan's email 06/09/2020 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/52/files - new: https://git.openjdk.java.net/jdk/pull/52/files/4d08c15a..110b45c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=01-02 Stats: 13647 lines in 426 files changed: 7255 ins; 4331 del; 2061 mod Patch: https://git.openjdk.java.net/jdk/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk/pull/52 From sgehwolf at openjdk.java.net Mon Sep 14 12:07:11 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 14 Sep 2020 12:07:11 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> <4qAi85w_bpDAq9acEjisUho22TxE0_TPLkOjxoIFKlI=.ffe87726-9c97-46cc-b98b-659fb1e785e2@github.com> <96E0aveQi3HxE_R8L3aGo0Wy2uY25CtNOYERHDvblrk=.bdb70804-820d-4cfe-acec-1f6045d00a12@github.com> Message-ID: On Mon, 14 Sep 2020 08:25:51 GMT, Severin Gehwolf wrote: >> @galderz The PR has this synopsis `8251397: Add release fence to ClassValueMap constructor`. The bug has this `8251397: >> NPE on ClassValue.ClassValueMap.cacheArray`. @dholmes-ora asked to make them matching. Let's fix that first. > > You can add what you have as synopsis now via /summary and the bot. @galderz Now it's the other way round. Commit message the bot mentions [here](https://github.com/openjdk/jdk/pull/94#issuecomment-691478179) should be something like this: 8251397: NPE on ClassValue.ClassValueMap.cacheArray Add release fence to ClassValueMap constructor. * Release fence guarantees that cacheArray field will published with a non-null value. * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. Reviewed-by: shade, psandoz The first line can be achieved by force-pushing with the changed commit message. I know David said to not force push, but the review is done and no other way to achieve this except changing the bug synopsis which isn't great either. The latter lines can be added with /summary e.g. Add release fence to ClassValueMap constructor. * Release fence guarantees that cacheArray field will published with a non-null value. * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. The `Reviewed-by:` line comes from the reviewers. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From sgehwolf at openjdk.java.net Mon Sep 14 12:07:11 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 14 Sep 2020 12:07:11 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> <4qAi85w_bpDAq9acEjisUho22TxE0_TPLkOjxoIFKlI=.ffe87726-9c97-46cc-b98b-659fb1e785e2@github.com> <96E0aveQi3HxE_R8L3aGo0Wy2uY25CtNOYERHDvblrk=.bdb70804-820d-4cfe-acec-1f6045d00a12@github.com> Message-ID: On Mon, 14 Sep 2020 12:02:14 GMT, Severin Gehwolf wrote: >> You can add what you have as synopsis now via /summary and the bot. > > @galderz Now it's the other way round. Commit message the bot mentions > [here](https://github.com/openjdk/jdk/pull/94#issuecomment-691478179) should be something like this: > 8251397: NPE on ClassValue.ClassValueMap.cacheArray > > Add release fence to ClassValueMap constructor. > > * Release fence guarantees that cacheArray field will published > with a non-null value. > * Without this fix, CacheValueMap.cacheArray can sometimes be > seen as null. > > Reviewed-by: shade, psandoz > > The first line can be achieved by force-pushing with the changed commit message. I know David said to not force push, > but the review is done and no other way to achieve this except changing the bug synopsis which isn't great either. The > latter lines can be added with /summary e.g. > Add release fence to ClassValueMap constructor. > > * Release fence guarantees that cacheArray field will published > with a non-null value. > * Without this fix, CacheValueMap.cacheArray can sometimes be > seen as null. > > The `Reviewed-by:` line comes from the reviewers. Note that I've opened [SKARA-633](https://bugs.openjdk.java.net/browse/SKARA-633) for pre-population of the commit message with an appropriate summary. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From michaelm at openjdk.java.net Mon Sep 14 12:21:04 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 14 Sep 2020 12:21:04 GMT Subject: RFR: 8245194: Unix domain socket channel implementation [v4] In-Reply-To: References: Message-ID: > Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >>> think of that. >>> >>> There is a fair bit of other refactoring and simplification done also. Next version is at: >>> >>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >>> >> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the >> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved >> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a >> number points that require clarification to fully understand how this will work with relative, directly relative and >> drive relative paths. >> > > Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That > would leave WindowsPath unchanged. >> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >> to get the file path in bytes. >> > > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to > be useful by other components. >> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its >> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main >> issue is that class is that it means we end up with two classes with static factory methods doing the same thing). > > Okay, that does simplify it a bit. > > Thanks, > Michael. > >> -Alan. >> >> >> >> >> >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: unixdomainchannels: updates from review of Sept 11 2020 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/52/files - new: https://git.openjdk.java.net/jdk/pull/52/files/110b45c0..22f37a82 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=02-03 Stats: 40 lines in 7 files changed: 16 ins; 7 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk/pull/52 From github.com+50187+galderz at openjdk.java.net Mon Sep 14 13:03:37 2020 From: github.com+50187+galderz at openjdk.java.net (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 14 Sep 2020 13:03:37 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor [v2] In-Reply-To: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: > * Release fence guarantees that cacheArray field will published with a non-null value. > * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. > > This is a follow up to @PaulSandoz's feedback > [here](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068248.html) for the first attempt to fix > [JDK-8251397](https://bugs.openjdk.java.net/browse/JDK-8251397). In this update, the fence has been moved to > `initializeMap()` and added Paul's suggested comment. > Annotating `classValueMap` with `@Stable` is outside the scope of this issue. Galder Zamarre?o 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: 8251397: NPE on ClassValue.ClassValueMap.cacheArray Add release fence to ClassValueMap constructor. * Release fence guarantees that cacheArray field will published with a non-null value. * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/94/files - new: https://git.openjdk.java.net/jdk/pull/94/files/48ff6dde..6c4e82d8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=94&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=94&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/94.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/94/head:pull/94 PR: https://git.openjdk.java.net/jdk/pull/94 From github.com+50187+galderz at openjdk.java.net Mon Sep 14 13:03:39 2020 From: github.com+50187+galderz at openjdk.java.net (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 14 Sep 2020 13:03:39 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor [v2] In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> <4qAi85w_bpDAq9acEjisUho22TxE0_TPLkOjxoIFKlI=.ffe87726-9c97-46cc-b98b-659fb1e785e2@github.com> <96E0aveQi3HxE_R8L3aGo0Wy2uY25CtNOYERHDvblrk=.bdb70804-820d-4cfe-acec-1f6045d00a12@github.com> Message-ID: <_1uIoxK8m8Lg6KJtwZ4yEBxeyVq7JI8CwrubBfD5qxg=.276b68bc-f84c-47c4-a276-a59b5bb57472@github.com> On Mon, 14 Sep 2020 12:04:30 GMT, Severin Gehwolf wrote: >> @galderz Now it's the other way round. Commit message the bot mentions >> [here](https://github.com/openjdk/jdk/pull/94#issuecomment-691478179) should be something like this: >> 8251397: NPE on ClassValue.ClassValueMap.cacheArray >> >> Add release fence to ClassValueMap constructor. >> >> * Release fence guarantees that cacheArray field will published >> with a non-null value. >> * Without this fix, CacheValueMap.cacheArray can sometimes be >> seen as null. >> >> Reviewed-by: shade, psandoz >> >> The first line can be achieved by force-pushing with the changed commit message. I know David said to not force push, >> but the review is done and no other way to achieve this except changing the bug synopsis which isn't great either. The >> latter lines can be added with /summary e.g. >> Add release fence to ClassValueMap constructor. >> >> * Release fence guarantees that cacheArray field will published >> with a non-null value. >> * Without this fix, CacheValueMap.cacheArray can sometimes be >> seen as null. >> >> The `Reviewed-by:` line comes from the reviewers. > > Note that I've opened [SKARA-633](https://bugs.openjdk.java.net/browse/SKARA-633) for pre-population of the commit > message with an appropriate summary. Add release fence to ClassValueMap constructor. * Release fence guarantees that cacheArray field will published with a non-null value. * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From sgehwolf at openjdk.java.net Mon Sep 14 13:11:40 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 14 Sep 2020 13:11:40 GMT Subject: RFR: 8251397: Add release fence to ClassValueMap constructor [v2] In-Reply-To: <_1uIoxK8m8Lg6KJtwZ4yEBxeyVq7JI8CwrubBfD5qxg=.276b68bc-f84c-47c4-a276-a59b5bb57472@github.com> References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> <4qAi85w_bpDAq9acEjisUho22TxE0_TPLkOjxoIFKlI=.ffe87726-9c97-46cc-b98b-659fb1e785e2@github.com> <96E0aveQi3HxE_R8L3aGo0Wy2uY25CtNOYERHDvblrk=.bdb70804-820d-4cfe-acec-1f6045d00a12@github.com> <_1uIoxK8m8Lg6KJtwZ4yEBxeyVq7JI8Cwru bBfD5qxg=.276b68bc-f84c-47c4-a276-a59b5bb57472@github.com> Message-ID: On Mon, 14 Sep 2020 12:59:00 GMT, Galder Zamarre?o wrote: >> Note that I've opened [SKARA-633](https://bugs.openjdk.java.net/browse/SKARA-633) for pre-population of the commit >> message with an appropriate summary. > > Add release fence to ClassValueMap constructor. > > * Release fence guarantees that cacheArray field will published > with a non-null value. > * Without this fix, CacheValueMap.cacheArray can sometimes be > seen as null. @galderz Hmm, sorry. Apparently it's the PR title which makes up the synopsis. Probably has to be changed in the UI here. I didn't know that :( ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From github.com+50187+galderz at openjdk.java.net Mon Sep 14 14:36:04 2020 From: github.com+50187+galderz at openjdk.java.net (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 14 Sep 2020 14:36:04 GMT Subject: RFR: 8251397: NPE on ClassValue.ClassValueMap.cacheArray [v2] In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> <4qAi85w_bpDAq9acEjisUho22TxE0_TPLkOjxoIFKlI=.ffe87726-9c97-46cc-b98b-659fb1e785e2@github.com> <96E0aveQi3HxE_R8L3aGo0Wy2uY25CtNOYERHDvblrk=.bdb70804-820d-4cfe-acec-1f6045d00a12@github.com> <_1uIoxK8m8Lg6KJtwZ4yEBxeyVq7JI8Cwru bBfD5qxg=.276b68bc-f84c-47c4-a276-a59b5bb57472@github.com> Message-ID: On Mon, 14 Sep 2020 13:09:11 GMT, Severin Gehwolf wrote: >> Add release fence to ClassValueMap constructor. >> >> * Release fence guarantees that cacheArray field will published >> with a non-null value. >> * Without this fix, CacheValueMap.cacheArray can sometimes be >> seen as null. > > @galderz Hmm, sorry. Apparently it's the PR title which makes up the synopsis. Probably has to be changed in the UI > here. I didn't know that :( PR title changed... ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From rrich at openjdk.java.net Mon Sep 14 14:45:23 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 14 Sep 2020 14:45:23 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: <8Lj5TsrafBhGgAbA8-w3VNsexX-mIzxLUOpXtL_5wJ0=.00530c0a-2187-4be6-97c2-5174815191b3@github.com> On Mon, 14 Sep 2020 04:58:47 GMT, David Holmes wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >> >> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >> >> Thanks, Richard. > > src/hotspot/share/compiler/compileBroker.cpp line 844: > >> 842: void DeoptimizeObjectsALotThread::deoptimize_objects_alot_loop_single() { >> 843: HandleMark hm(this); >> 844: while (!this->is_terminated()) { > > The terminated state of a thread is used to communicate to other threads whether this thread has terminated. It isn't > something that can be used to control the work-loop of the thread itself! This is an infinite loop as far as I can see. You're right. Thanks. I'll make it an explicit infinite loop. This should be ok because DeoptimizeObjectsALotThread's as the other threads created in CompileBroker::make_thread() are daemon threads. > src/hotspot/share/compiler/compileBroker.cpp line 862: > >> 860: void DeoptimizeObjectsALotThread::deoptimize_objects_alot_loop_all() { >> 861: HandleMark hm(this); >> 862: while (!is_terminated()) { > > Same comment as above. Same reply :) ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From asemenyuk at openjdk.java.net Mon Sep 14 16:41:26 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 14 Sep 2020 16:41:26 GMT Subject: RFR: JDK-8230652: Improve verbose output In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 18:30:08 GMT, Andy Herrick wrote: > JDK-8230652 > Extracting the commands displayed by verbose output (including commands called thru ToolProvider) , to contain the the > command, it's output, and it's return value on separate lines and formatted in a way that they can be easily cut and > pasted into a script. Looks good ------------- PR: https://git.openjdk.java.net/jdk/pull/141 From naoto at openjdk.java.net Mon Sep 14 16:44:04 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 14 Sep 2020 16:44:04 GMT Subject: RFR: 8223187: Investigate setLocale() call in jpackage native launcher In-Reply-To: References: Message-ID: <2toGhodRxfSJLYkkoX5CCyx7WRrtS5pGlgtLnAaqBPY=.30e7fc6c-d311-441b-997e-a2ed519be9b5@github.com> On Sat, 12 Sep 2020 02:15:29 GMT, Alexander Matveev wrote: > setlocale() affects several C functions. We do not use most of these functions. We only using isspace() and toLower(). > Based on how we use it I do not see any needs for setlocale(). After removing it I retested jpackage by changing > locally on machine and using different language as input parameters for jpackage. No issues found. Although I am curious why the setlocale() call was introduced in the first place, removing it in order to respect the platform default locale is generally considered a welcoming change. Approving the change assuming locale related testing has been done. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/138 From sgehwolf at openjdk.java.net Mon Sep 14 16:39:17 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 14 Sep 2020 16:39:17 GMT Subject: RFR: 8251397: NPE on ClassValue.ClassValueMap.cacheArray [v2] In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> <4qAi85w_bpDAq9acEjisUho22TxE0_TPLkOjxoIFKlI=.ffe87726-9c97-46cc-b98b-659fb1e785e2@github.com> <96E0aveQi3HxE_R8L3aGo0Wy2uY25CtNOYERHDvblrk=.bdb70804-820d-4cfe-acec-1f6045d00a12@github.com> <_1uIoxK8m8Lg6KJtwZ4yEBxeyVq7JI8Cwru bBfD5qxg=.276b68bc-f84c-47c4-a276-a59b5bb57472@github.com> Message-ID: On Mon, 14 Sep 2020 14:33:34 GMT, Galder Zamarre?o wrote: >> @galderz Hmm, sorry. Apparently it's the PR title which makes up the synopsis. Probably has to be changed in the UI >> here. I didn't know that :( > > PR title changed... @galderz OK. Lets try the integrate/sponsor workflow. AFAIK it's integrate from you first and sponsor for me second. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From rriggs at openjdk.java.net Mon Sep 14 20:37:50 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 14 Sep 2020 20:37:50 GMT Subject: RFR: 8252537: Updated @exception with @throws In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 19:29:30 GMT, Vipin Sharma wrote: > Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. > > Open Subtasks part of this fix are: > 1. JDK-8252537 > 2. JDK-8252539 > 3. JDK-8252540 > 4. JDK-8252541 > > Previous conversation on this: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html Please re-indent the @throws lines to add 3 spaces after so that the comments are aligned as they were previously. ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/95 From igraves at openjdk.java.net Mon Sep 14 20:42:32 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 14 Sep 2020 20:42:32 GMT Subject: RFR: 8252730: Ordering modules to guarantee repeatable jlink image writes Message-ID: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Related to [JDK-8252730 jlink does not create reproducible builds on different servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to ensure stable files (and file signatures) across generated JDK images by jlink. ------------- Commit messages: - Ordering module writes to guarantee repeatable jlink image writes Changes: https://git.openjdk.java.net/jdk/pull/156/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252730 Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/156/head:pull/156 PR: https://git.openjdk.java.net/jdk/pull/156 From almatvee at openjdk.java.net Mon Sep 14 20:44:33 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 14 Sep 2020 20:44:33 GMT Subject: Integrated: 8223187: Remove setLocale() call in jpackage native launcher In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 02:15:29 GMT, Alexander Matveev wrote: > setlocale() affects several C functions. We do not use most of these functions. We only using isspace() and toLower(). > Based on how we use it I do not see any needs for setlocale(). After removing it I retested jpackage by changing > locally on machine and using different language as input parameters for jpackage. No issues found. This pull request has now been integrated. Changeset: ac9d1b08 Author: Alexander Matveev URL: https://git.openjdk.java.net/jdk/commit/ac9d1b08 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod 8223187: Remove setLocale() call in jpackage native launcher Reviewed-by: kcr, herrick, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/138 From alexander.matveev at oracle.com Mon Sep 14 21:07:59 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Mon, 14 Sep 2020 14:07:59 -0700 Subject: Fwd: RFR: 8223187: Investigate setLocale() call in jpackage native launcher In-Reply-To: References: Message-ID: Hi Bernd, Not sure if we should enforce English version of error messages on non-English locale. I think user will expect messages in system locale if possible. User can change system locale to English if English version of error messages are required to submit something like bug report. Thanks, Alexander On 9/12/20 6:45 AM, Bernd Eckenfels wrote: > Hello, > > What about system errors (exception messages from strerr?). I mean in case one wants to enforce English version with user.locale for support reasons? > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ________________________________ > Von: core-libs-dev im Auftrag von Alexander Matveev > Gesendet: Saturday, September 12, 2020 4:22:31 AM > An: core-libs-dev at openjdk.java.net > Betreff: RFR: 8223187: Investigate setLocale() call in jpackage native launcher > > setlocale() affects several C functions. We do not use most of these functions. We only using isspace() and toLower(). > Based on how we use it I do not see any needs for setlocale(). After removing it I retested jpackage by changing > locally on machine and using different language as input parameters for jpackage. No issues found. > > ------------- > > Commit messages: > - 8223187: Investigate setLocale() call in jpackage native launcher > > Changes: https://git.openjdk.java.net/jdk/pull/138/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=138&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8223187 > Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod > Patch: https://git.openjdk.java.net/jdk/pull/138.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/138/head:pull/138 > > PR: https://git.openjdk.java.net/jdk/pull/138 From smarks at openjdk.java.net Mon Sep 14 21:34:45 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Mon, 14 Sep 2020 21:34:45 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Mon, 14 Sep 2020 20:35:24 GMT, Ian Graves wrote: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. Sorting the Archive instances makes more sense to me than trying to add hashCode/equals to Archive. I note that the instances added to the ResourcePoolManager are stored in a LinkedHashMap, so the sorted order should be preserved. I'll defer to Alan and Jim as to whether sorting by module name is the right thing. Additional code comments to follow. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java line 274: > 272: e.getResourcePoolEntryName(), e)) > 273: .forEach(resources::add); > 274: }); I'm somewhat allergic to nested forEach plus statement lambdas. I note that the original code mixed an imperative for-loop with a stream, which was kind of odd; converting to a straight nested for-loop might be reasonable. Alternatively, the nested forEaches could be converted to a flatMap as follows: ` archives.stream() .map(Archive::moduleName) .sorted() .flatMap(mn -> entriesForModule.get(mn).stream() .map(e -> new ArchiveEntryResourcePoolEntry(mn, e.getResourcePoolEntryName(), e))) .forEach(resources::add); ` ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From igraves at openjdk.java.net Mon Sep 14 21:41:35 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 14 Sep 2020 21:41:35 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers In-Reply-To: References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Mon, 14 Sep 2020 21:32:19 GMT, Stuart Marks wrote: >> Related to [JDK-8252730 jlink does not create reproducible builds on different >> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to >> ensure stable files (and file signatures) across generated JDK images by jlink. > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java line 274: > >> 272: e.getResourcePoolEntryName(), e)) >> 273: .forEach(resources::add); >> 274: }); > > I'm somewhat allergic to nested forEach plus statement lambdas. I note that the original code mixed an imperative > for-loop with a stream, which was kind of odd; converting to a straight nested for-loop might be reasonable. > Alternatively, the nested forEaches could be converted to a flatMap as follows: > archives.stream() > .map(Archive::moduleName) > .sorted() > .flatMap(mn -> entriesForModule.get(mn).stream() > .map(e -> new ArchiveEntryResourcePoolEntry(mn, > e.getResourcePoolEntryName(), e))) > .forEach(resources::add); This is a good catch. I'm partial to flatMap, but unsure if that gets too clever what we're trying to do here or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From almatvee at openjdk.java.net Mon Sep 14 22:03:15 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 14 Sep 2020 22:03:15 GMT Subject: RFR: JDK-8230652: Improve verbose output In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 18:30:08 GMT, Andy Herrick wrote: > JDK-8230652 > Extracting the commands displayed by verbose output (including commands called thru ToolProvider) , to contain the the > command, it's output, and it's return value on separate lines and formatted in a way that they can be easily cut and > pasted into a script. Looks good. ------------- Marked as reviewed by almatvee (Committer). PR: https://git.openjdk.java.net/jdk/pull/141 From mchung at openjdk.java.net Mon Sep 14 22:05:27 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 14 Sep 2020 22:05:27 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Mon, 14 Sep 2020 20:35:24 GMT, Ian Graves wrote: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. Looks good to me. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/156 From naoto at openjdk.java.net Mon Sep 14 22:24:11 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 14 Sep 2020 22:24:11 GMT Subject: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null Message-ID: Hi, Please review this simple doc fix. ------------- Commit messages: - 8220483: Calendar.setTime(Date date) throws NPE with Date date = null Changes: https://git.openjdk.java.net/jdk/pull/159/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=159&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8220483 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/159.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/159/head:pull/159 PR: https://git.openjdk.java.net/jdk/pull/159 From lancea at openjdk.java.net Mon Sep 14 22:44:37 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 14 Sep 2020 22:44:37 GMT Subject: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 22:18:34 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. Hi Naoto, The change looks fine. I might have created a CSR just to track the doc change. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/159 From joe.darcy at oracle.com Mon Sep 14 22:49:34 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 14 Sep 2020 15:49:34 -0700 Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) In-Reply-To: References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> Message-ID: <516b396c-d5d5-1a66-6605-b31af61c1084@oracle.com> Should issue have a CSR review for the behavior change? -Joe On 9/12/2020 7:25 PM, Jaikiran Pai wrote: > On Sat, 12 Sep 2020 17:38:34 GMT, Lance Andersen wrote: > >>> 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 >> Hi Jaikiran, >> >> The change seems fine an inline with the RFC. I can sponsor this once we have another review. >> >> I have run the JCK tests for Zip/Gzip/Jar and Mach5 JDK tier1, tier2 and tier3 > Thank you Lance for the review and running the tests. I'll wait for another review before initiating the integrate > command. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/130 From joehw at openjdk.java.net Mon Sep 14 22:55:16 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 14 Sep 2020 22:55:16 GMT Subject: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 22:41:55 GMT, Lance Andersen wrote: >> Hi, >> >> Please review this simple doc fix. > > Hi Naoto, > > The change looks fine. I might have created a CSR just to track the doc change. The change looks fine. However, are other methods in the same situation, e.g. void setTimeZone?(TimeZone?value), getInstance?(Locale aLocale), etc.? Or, would it better to add a general statement about passing in null values? ------------- PR: https://git.openjdk.java.net/jdk/pull/159 From LANCE.ANDERSEN at ORACLE.COM Mon Sep 14 22:55:45 2020 From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen) Date: Mon, 14 Sep 2020 18:55:45 -0400 Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) In-Reply-To: <516b396c-d5d5-1a66-6605-b31af61c1084@oracle.com> References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> <516b396c-d5d5-1a66-6605-b31af61c1084@oracle.com> Message-ID: Hi Joe, I guess it could. Given it is not used within the implementation(or defined outside of the spec), I will defer to you preference :-) > On Sep 14, 2020, at 6:49 PM, Joe Darcy wrote: > > Should issue have a CSR review for the behavior change? > > -Joe > > On 9/12/2020 7:25 PM, Jaikiran Pai wrote: >> On Sat, 12 Sep 2020 17:38:34 GMT, Lance Andersen wrote: >> >>>> 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 >>> Hi Jaikiran, >>> >>> The change seems fine an inline with the RFC. I can sponsor this once we have another review. >>> >>> I have run the JCK tests for Zip/Gzip/Jar and Mach5 JDK tier1, tier2 and tier3 >> Thank you Lance for the review and running the tests. I'll wait for another review before initiating the integrate >> command. >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/130 Best Lance ------------------ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From igraves at openjdk.java.net Mon Sep 14 22:57:44 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 14 Sep 2020 22:57:44 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v2] In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: <8hmKqfCkEzZ0_gPVgkZ4hAAC_726PLSgG-HlfbMeCvE=.ce8e743d-76d1-419a-abbf-40d3be3b4d33@github.com> > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Merging streams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/156/files - new: https://git.openjdk.java.net/jdk/pull/156/files/122bbdfc..ef3eacec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/156/head:pull/156 PR: https://git.openjdk.java.net/jdk/pull/156 From igraves at openjdk.java.net Mon Sep 14 22:57:45 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 14 Sep 2020 22:57:45 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v2] In-Reply-To: References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Mon, 14 Sep 2020 22:03:02 GMT, Mandy Chung wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Merging streams > > Looks good to me. Updated to merge streams in line with @stuart-marks suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From joe.darcy at oracle.com Mon Sep 14 23:07:13 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 14 Sep 2020 16:07:13 -0700 Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) In-Reply-To: References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> <516b396c-d5d5-1a66-6605-b31af61c1084@oracle.com> Message-ID: <3f0b8303-eb3e-6a1d-168c-f16081303a68@oracle.com> Hi Lance, I'd prefer to err on the side of having a CSR; thanks, -Joe On 9/14/2020 3:55 PM, Lance Andersen wrote: > Hi Joe, > > I guess it could. ?Given it is not used within the implementation(or > defined outside of the spec), I will defer to you preference ?:-) > >> On Sep 14, 2020, at 6:49 PM, Joe Darcy > > wrote: >> >> Should issue have a CSR review for the behavior change? >> >> -Joe >> >> On 9/12/2020 7:25 PM, Jaikiran Pai wrote: >>> On Sat, 12 Sep 2020 17:38:34 GMT, Lance Andersen >> > wrote: >>> >>>>> 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 >>>> Hi Jaikiran, >>>> >>>> The change seems fine an inline with the RFC. ?I can sponsor this >>>> once we have another review. >>>> >>>> I have run the JCK tests for Zip/Gzip/Jar and Mach5 JDK tier1, >>>> tier2 and tier3 >>> Thank you Lance for the review and running the tests. I'll wait for >>> another review before initiating the integrate >>> command. >>> >>> ------------- >>> >>> PR: https://git.openjdk.java.net/jdk/pull/130 > > > Best > Lance > ------------------ > > > > Lance Andersen| Principal?Member of Technical Staff |?+1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From LANCE.ANDERSEN at ORACLE.COM Mon Sep 14 23:08:49 2020 From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen) Date: Mon, 14 Sep 2020 19:08:49 -0400 Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) In-Reply-To: <3f0b8303-eb3e-6a1d-168c-f16081303a68@oracle.com> References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> <516b396c-d5d5-1a66-6605-b31af61c1084@oracle.com> <3f0b8303-eb3e-6a1d-168c-f16081303a68@oracle.com> Message-ID: <454AE324-2D13-46AB-A481-189BAD388956@ORACLE.COM> Hi Joe, Ok, will create one tomorrow. Best Lance > On Sep 14, 2020, at 7:07 PM, Joe Darcy wrote: > > Hi Lance, > > I'd prefer to err on the side of having a CSR; thanks, > > -Joe > > On 9/14/2020 3:55 PM, Lance Andersen wrote: >> Hi Joe, >> >> I guess it could. Given it is not used within the implementation(or defined outside of the spec), I will defer to you preference :-) >> >>> On Sep 14, 2020, at 6:49 PM, Joe Darcy > wrote: >>> >>> Should issue have a CSR review for the behavior change? >>> >>> -Joe >>> >>> On 9/12/2020 7:25 PM, Jaikiran Pai wrote: >>>> On Sat, 12 Sep 2020 17:38:34 GMT, Lance Andersen > wrote: >>>> >>>>>> 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 >>>>> Hi Jaikiran, >>>>> >>>>> The change seems fine an inline with the RFC. I can sponsor this once we have another review. >>>>> >>>>> I have run the JCK tests for Zip/Gzip/Jar and Mach5 JDK tier1, tier2 and tier3 >>>> Thank you Lance for the review and running the tests. I'll wait for another review before initiating the integrate >>>> command. >>>> >>>> ------------- >>>> >>>> PR: https://git.openjdk.java.net/jdk/pull/130 >> >> >> Best >> Lance >> ------------------ >> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> >> Best Lance ------------------ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto at openjdk.java.net Mon Sep 14 23:17:58 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 14 Sep 2020 23:17:58 GMT Subject: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 23:13:25 GMT, Naoto Sato wrote: >> The change looks fine. However, are other methods in the same situation, e.g. void setTimeZone?(TimeZone?value), >> getInstance?(Locale aLocale), etc.? Or, would it better to add a general statement about passing in null values? > > Thanks, Lance, > >> The change looks fine. I might have created a CSR just to track the doc change. > > Yes, and thanks for the CSR review too! Thanks, Joe. > The change looks fine. However, are other methods in the same situation, e.g. void setTimeZone?(TimeZone?value), > getInstance?(Locale aLocale), etc.? Or, would it better to add a general statement about passing in null values? Those two methods describe the NPE correctly. There are other locations that may have missed the @throws tag, but I would rather fix this specific one this time (for my GitHub training :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/159 From naoto at openjdk.java.net Mon Sep 14 23:17:58 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 14 Sep 2020 23:17:58 GMT Subject: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 22:52:50 GMT, Joe Wang wrote: >> Hi Naoto, >> >> The change looks fine. I might have created a CSR just to track the doc change. > > The change looks fine. However, are other methods in the same situation, e.g. void setTimeZone?(TimeZone?value), > getInstance?(Locale aLocale), etc.? Or, would it better to add a general statement about passing in null values? Thanks, Lance, > The change looks fine. I might have created a CSR just to track the doc change. Yes, and thanks for the CSR review too! ------------- PR: https://git.openjdk.java.net/jdk/pull/159 From joehw at openjdk.java.net Mon Sep 14 23:41:22 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 14 Sep 2020 23:41:22 GMT Subject: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 22:18:34 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/159 From joehw at openjdk.java.net Mon Sep 14 23:41:23 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 14 Sep 2020 23:41:23 GMT Subject: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null In-Reply-To: References: Message-ID: <234r42V_BtfzhAVKcO7e5QeDy0JkC8rZpuNNSEji-Ls=.6fbef8b0-b2b3-4e5f-88f1-8e161e68a5e6@github.com> On Mon, 14 Sep 2020 23:15:10 GMT, Naoto Sato wrote: >> Thanks, Lance, >> >>> The change looks fine. I might have created a CSR just to track the doc change. >> >> Yes, and thanks for the CSR review too! > > Thanks, Joe. > >> The change looks fine. However, are other methods in the same situation, e.g. void setTimeZone?(TimeZone?value), >> getInstance?(Locale aLocale), etc.? Or, would it better to add a general statement about passing in null values? > > Those two methods describe the NPE correctly. There are other locations that may have missed the @throws tag, but I > would rather fix this specific one this time (for my GitHub training :-) That makes sense (good start for the 1st PR ;-)). ------------- PR: https://git.openjdk.java.net/jdk/pull/159 From david.holmes at oracle.com Tue Sep 15 01:35:12 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Sep 2020 11:35:12 +1000 Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: <59VhddIbMR3X24jGMsDpR_wOSWypMFIeXbs5l5rhLYs=.2c5e00e4-8b16-4237-8a7c-4cdceaaebe18@github.com> References: <59VhddIbMR3X24jGMsDpR_wOSWypMFIeXbs5l5rhLYs=.2c5e00e4-8b16-4237-8a7c-4cdceaaebe18@github.com> Message-ID: <1f5d5fb8-7d59-058d-e313-565dede697c3@oracle.com> On 14/09/2020 6:18 pm, Richard Reingruber wrote: > On Mon, 14 Sep 2020 04:57:21 GMT, David Holmes wrote: > >>> Hi, >>> >>> this is the continuation of the review of the implementation for: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8227745 >>> https://bugs.openjdk.java.net/browse/JDK-8233915 >>> >>> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >>> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >>> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >>> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >>> >>> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >>> >>> Thanks, Richard. >> >> src/hotspot/share/compiler/compileBroker.cpp line 831: >> >>> 829: MonitorLocker ml(dt, EscapeBarrier_lock, Mutex::_no_safepoint_check_flag); >>> 830: static int single_thread_count = 0; >>> 831: enter_single_loop = single_thread_count++ < DeoptimizeObjectsALotThreadCountSingle; >> >> The update to `single_thread_count` is not atomic. > > I think it is atomic because it is never accessed without holding EscapeBarrier_lock Doh! My bad. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/119 > From winterhalter at openjdk.java.net Tue Sep 15 04:29:13 2020 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Tue, 15 Sep 2020 04:29:13 GMT Subject: RFR: 8202473: A type variable with multiple bounds does not correctly place type annotation Message-ID: This patch assures that an annotation on a type bound is placed on the correct bound index. ------------- Commit messages: - 8202473: A type variable with multiple bounds does not correctly place type annotation Changes: https://git.openjdk.java.net/jdk/pull/155/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=155&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8202473 Stats: 80 lines in 2 files changed: 77 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/155.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/155/head:pull/155 PR: https://git.openjdk.java.net/jdk/pull/155 From clanger at openjdk.java.net Tue Sep 15 07:55:38 2020 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 15 Sep 2020 07:55:38 GMT Subject: RFR: 8253155: Minor cleanups and Javadoc fixes for LdapDnsProvider of java.naming Message-ID: There are some little flaws in LdapDNSProvider and auxilliary classes, mostly in Javadoc. In detail: src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java: Unnecessary import src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java: typo src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProvider.java: Whitespace src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProviderResult.java: Spelling of "ldap" -> should be capitalized ------------- Commit messages: - JDK-8253155 Changes: https://git.openjdk.java.net/jdk/pull/168/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=168&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253155 Stats: 21 lines in 4 files changed: 3 ins; 7 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/168.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/168/head:pull/168 PR: https://git.openjdk.java.net/jdk/pull/168 From alanb at openjdk.java.net Tue Sep 15 08:09:37 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 15 Sep 2020 08:09:37 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v2] In-Reply-To: References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Mon, 14 Sep 2020 22:54:34 GMT, Ian Graves wrote: >> Looks good to me. > > Updated to merge streams in line with @stuart-marks suggestion. There are several existing jlink tests that check that generated lib/modules is reproducible. Can we do more in these tests or add a new test that would improve the chances of finding issues, e.g. using jlink to create a JDK that includes the jlink tool and the packaged modules, copy it to two locations and run the jlink in both run-time images to see if they produce the same bits. ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From jfranck at openjdk.java.net Tue Sep 15 08:12:43 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Tue, 15 Sep 2020 08:12:43 GMT Subject: RFR: 8202473: A type variable with multiple bounds does not correctly place type annotation In-Reply-To: References: Message-ID: <0Ph01nef-zH908Im8MWHnSIZrjjSE2n2FJwJL2XxPI8=.706ce54d-f991-4dde-9481-d3e01063adfd@github.com> On Mon, 14 Sep 2020 19:49:08 GMT, Rafael Winterhalter wrote: > This patch assures that an annotation on a type bound is placed on the correct bound index. Pre-git review thread here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067049.html ------------- PR: https://git.openjdk.java.net/jdk/pull/155 From vyommani at gmail.com Tue Sep 15 08:54:02 2020 From: vyommani at gmail.com (Vyom Tiwari) Date: Tue, 15 Sep 2020 14:24:02 +0530 Subject: RFR: 8253155: Minor cleanups and Javadoc fixes for LdapDnsProvider of java.naming In-Reply-To: References: Message-ID: Hi Christoph, Changes look ok to me. On Tue, Sep 15, 2020 at 1:26 PM Christoph Langer wrote: > There are some little flaws in LdapDNSProvider and auxilliary classes, > mostly in Javadoc. > > In detail: > src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java: > Unnecessary import > src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java: > typo > src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProvider.java: > Whitespace > src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProviderResult.java: > Spelling of "ldap" -> should be > capitalized > > ------------- > > Commit messages: > - JDK-8253155 > > Changes: https://git.openjdk.java.net/jdk/pull/168/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=168&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8253155 > Stats: 21 lines in 4 files changed: 3 ins; 7 del; 11 mod > Patch: https://git.openjdk.java.net/jdk/pull/168.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/168/head:pull/168 > > PR: https://git.openjdk.java.net/jdk/pull/168 > -- Thanks, Vyom 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 dfuchs at openjdk.java.net Tue Sep 15 09:35:49 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 15 Sep 2020 09:35:49 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v2] In-Reply-To: <8hmKqfCkEzZ0_gPVgkZ4hAAC_726PLSgG-HlfbMeCvE=.ce8e743d-76d1-419a-abbf-40d3be3b4d33@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> <8hmKqfCkEzZ0_gPVgkZ4hAAC_726PLSgG-HlfbMeCvE=.ce8e743d-76d1-419a-abbf-40d3be3b4d33@github.com> Message-ID: On Mon, 14 Sep 2020 22:57:44 GMT, Ian Graves wrote: >> Related to [JDK-8252730 jlink does not create reproducible builds on different >> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to >> ensure stable files (and file signatures) across generated JDK images by jlink. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Merging streams src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java line 41: > 39: import java.util.Objects; > 40: import java.util.Set; > 41: import java.util.Comparator; nit: `Comparator` might no longer be needed? I don't see where it's used. ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From dfuchs at openjdk.java.net Tue Sep 15 09:42:22 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 15 Sep 2020 09:42:22 GMT Subject: RFR: 8253155: Minor cleanups and Javadoc fixes for LdapDnsProvider of java.naming In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 07:47:54 GMT, Christoph Langer wrote: > There are some little flaws in LdapDNSProvider and auxilliary classes, mostly in Javadoc. > > In detail: > src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java: Unnecessary import > src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java: typo > src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProvider.java: Whitespace > src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProviderResult.java: Spelling of "ldap" -> should be > capitalized Hi Christoph, The changes look good to me. best regards, -- daniel ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/168 From aefimov at openjdk.java.net Tue Sep 15 10:01:58 2020 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 15 Sep 2020 10:01:58 GMT Subject: RFR: 8253155: Minor cleanups and Javadoc fixes for LdapDnsProvider of java.naming In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 07:47:54 GMT, Christoph Langer wrote: > There are some little flaws in LdapDNSProvider and auxilliary classes, mostly in Javadoc. > > In detail: > src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java: Unnecessary import > src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java: typo > src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProvider.java: Whitespace > src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProviderResult.java: Spelling of "ldap" -> should be > capitalized Marked as reviewed by aefimov (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/168 From aefimov at openjdk.java.net Tue Sep 15 10:01:58 2020 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 15 Sep 2020 10:01:58 GMT Subject: RFR: 8253155: Minor cleanups and Javadoc fixes for LdapDnsProvider of java.naming In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 09:39:29 GMT, Daniel Fuchs wrote: >> There are some little flaws in LdapDNSProvider and auxilliary classes, mostly in Javadoc. >> >> In detail: >> src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java: Unnecessary import >> src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java: typo >> src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProvider.java: Whitespace >> src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProviderResult.java: Spelling of "ldap" -> should be >> capitalized > > Hi Christoph, > > The changes look good to me. > > best regards, > > -- daniel Hi Christoph, Looks good to me. Kind Regards, Aleksei ------------- PR: https://git.openjdk.java.net/jdk/pull/168 From alanb at openjdk.java.net Tue Sep 15 10:05:13 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 15 Sep 2020 10:05:13 GMT Subject: RFR: 8253155: Minor cleanups and Javadoc fixes for LdapDnsProvider of java.naming In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 07:47:54 GMT, Christoph Langer wrote: > There are some little flaws in LdapDNSProvider and auxilliary classes, mostly in Javadoc. > > In detail: > src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java: Unnecessary import > src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java: typo > src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProvider.java: Whitespace > src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProviderResult.java: Spelling of "ldap" -> should be > capitalized Looks okay, no semantic changes. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/168 From ccleary at openjdk.java.net Tue Sep 15 10:16:59 2020 From: ccleary at openjdk.java.net (Conor Cleary) Date: Tue, 15 Sep 2020 10:16:59 GMT Subject: RFR: 8250859: Address reliance on default constructors in the Accessibility APIs In-Reply-To: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> References: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> Message-ID: On Tue, 15 Sep 2020 10:04:49 GMT, Conor Cleary wrote: > This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The > following classes have had an explicit no-arg constructor added, with a protected access modifier and accompanying API > description: > - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor > - Default ctor on javax.accessibility.AccessibleContext > - Default ctor on javax.accessibility.AccessibleHyperlink > > The following classes have had an explicit no-arg constructor added, with a public access modifier and accompanying API > description: > - Default ctor on javax.accessibility.AccessibleResourceBundle > - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList > - Default ctor on com.sun.java.accessibility.util.EventID > > specdiff: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html bug: > https://bugs.openjdk.java.net/browse/JDK-8250859 Changes require approval of CSR, can't request that requirement myself as I am not a reviewer ------------- PR: https://git.openjdk.java.net/jdk/pull/174 From ccleary at openjdk.java.net Tue Sep 15 10:16:55 2020 From: ccleary at openjdk.java.net (Conor Cleary) Date: Tue, 15 Sep 2020 10:16:55 GMT Subject: RFR: 8250859: Address reliance on default constructors in the Accessibility APIs Message-ID: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The following classes have had an explicit no-arg constructor added, with a protected access modifier and accompanying API description: - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor - Default ctor on javax.accessibility.AccessibleContext - Default ctor on javax.accessibility.AccessibleHyperlink The following classes have had an explicit no-arg constructor added, with a public access modifier and accompanying API description: - Default ctor on javax.accessibility.AccessibleResourceBundle - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList - Default ctor on com.sun.java.accessibility.util.EventID specdiff: http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html bug: https://bugs.openjdk.java.net/browse/JDK-8250859 ------------- Commit messages: - 8250859: Address reliance on default constructors in the Accessibility APIs Changes: https://git.openjdk.java.net/jdk/pull/174/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=174&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250859 Stats: 42 lines in 7 files changed: 35 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/174.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/174/head:pull/174 PR: https://git.openjdk.java.net/jdk/pull/174 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 jfranck at openjdk.java.net Tue Sep 15 11:34:38 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Tue, 15 Sep 2020 11:34:38 GMT Subject: RFR: 8202473: A type variable with multiple bounds does not correctly place type annotation In-Reply-To: <0Ph01nef-zH908Im8MWHnSIZrjjSE2n2FJwJL2XxPI8=.706ce54d-f991-4dde-9481-d3e01063adfd@github.com> References: <0Ph01nef-zH908Im8MWHnSIZrjjSE2n2FJwJL2XxPI8=.706ce54d-f991-4dde-9481-d3e01063adfd@github.com> Message-ID: On Tue, 15 Sep 2020 08:10:00 GMT, Joel Borggr?n-Franck wrote: >> This patch assures that an annotation on a type bound is placed on the correct bound index. > > Pre-git review thread here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067049.html @raphw test is missing imports and doesn't compile, other than that looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/155 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 jpai at openjdk.java.net Tue Sep 15 12:39:11 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 12:39:11 GMT Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v4] 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: Remove unintended file commit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/130/files - new: https://git.openjdk.java.net/jdk/pull/130/files/7679b119..a510dc77 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=130&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=130&range=02-03 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 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:39:11 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 12:39:11 GMT Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v4] In-Reply-To: References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> Message-ID: <0k1y_D_CX-o0Wulo1fO0XQ8J69b0oIQw8Bcr9qwqbSE=.c716838b-3d4b-4f6d-9e40-541a9a205d20@github.com> On Sun, 13 Sep 2020 02:22:54 GMT, Jaikiran Pai wrote: >> Hi Jaikiran, >> >> The change seems fine an inline with the RFC. I can sponsor this once we have another review. >> >> I have run the JCK tests for Zip/Gzip/Jar and Mach5 JDK tier1, tier2 and tier3 > > Thank you Lance for the review and running the tests. I'll wait for another review before initiating the integrate > command. I received some useful suggestions, offline, from Lance and Brent on this change and have updated this PR to include those suggestions. Please ignore the intermediate commits though (I accidentally added an unwanted file to this PR, which I have then removed in a subsequent commit). This is ready for a review now. ------------- PR: https://git.openjdk.java.net/jdk/pull/130 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 igraves at openjdk.java.net Tue Sep 15 13:40:30 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 15 Sep 2020 13:40:30 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v2] In-Reply-To: References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> <8hmKqfCkEzZ0_gPVgkZ4hAAC_726PLSgG-HlfbMeCvE=.ce8e743d-76d1-419a-abbf-40d3be3b4d33@github.com> Message-ID: On Tue, 15 Sep 2020 09:32:33 GMT, Daniel Fuchs wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Merging streams > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java line 41: > >> 39: import java.util.Objects; >> 40: import java.util.Set; >> 41: import java.util.Comparator; > > nit: `Comparator` might no longer be needed? I don't see where it's used. Yep. Looks like it's a leftover. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From igraves at openjdk.java.net Tue Sep 15 13:40:29 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 15 Sep 2020 13:40:29 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v3] In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Comparator cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/156/files - new: https://git.openjdk.java.net/jdk/pull/156/files/ef3eacec..b89d2c4d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/156/head:pull/156 PR: https://git.openjdk.java.net/jdk/pull/156 From clanger at openjdk.java.net Tue Sep 15 13:53:38 2020 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 15 Sep 2020 13:53:38 GMT Subject: Integrated: 8253155: Minor cleanups and Javadoc fixes for LdapDnsProvider of java.naming In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 07:47:54 GMT, Christoph Langer wrote: > There are some little flaws in LdapDNSProvider and auxilliary classes, mostly in Javadoc. > > In detail: > src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java: Unnecessary import > src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java: typo > src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProvider.java: Whitespace > src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProviderResult.java: Spelling of "ldap" -> should be > capitalized This pull request has now been integrated. Changeset: b5620a36 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/b5620a36 Stats: 21 lines in 4 files changed: 7 ins; 3 del; 11 mod 8253155: Minor cleanups and Javadoc fixes for LdapDnsProvider of java.naming Reviewed-by: dfuchs, aefimov, alanb, vtewari ------------- PR: https://git.openjdk.java.net/jdk/pull/168 From alanb at openjdk.java.net Tue Sep 15 14:32:39 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 15 Sep 2020 14:32:39 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v3] In-Reply-To: References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Tue, 15 Sep 2020 13:40:29 GMT, Ian Graves wrote: >> Related to [JDK-8252730 jlink does not create reproducible builds on different >> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to >> ensure stable files (and file signatures) across generated JDK images by jlink. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Comparator cleanup The update using flatMap looks good. I think we need to explore adding more tests if possible. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/156 From jpai at openjdk.java.net Tue Sep 15 15:05:36 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 15:05:36 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect 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-6714834? As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a mention that this can lead to incorrect manifest files ending up in jar files: > can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one > can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the `jdk:tier1` tests locally which hasn't shown any related failures. ------------- Commit messages: - 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect Changes: https://git.openjdk.java.net/jdk/pull/186/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=186&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6714834 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/186.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/186/head:pull/186 PR: https://git.openjdk.java.net/jdk/pull/186 From winterhalter at openjdk.java.net Tue Sep 15 15:18:20 2020 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Tue, 15 Sep 2020 15:18:20 GMT Subject: RFR: 8202473: A type variable with multiple bounds does not correctly place type annotation [v2] In-Reply-To: References: Message-ID: > This patch assures that an annotation on a type bound is placed on the correct bound index. Rafael Winterhalter 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: 8202473: A type variable with multiple bounds does not correctly place type annotation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/155/files - new: https://git.openjdk.java.net/jdk/pull/155/files/6541a83f..775b3630 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=155&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=155&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/155.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/155/head:pull/155 PR: https://git.openjdk.java.net/jdk/pull/155 From alanb at openjdk.java.net Tue Sep 15 15:32:22 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 15 Sep 2020 15:32:22 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 14:59:57 GMT, Jaikiran Pai wrote: > 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-6714834? > As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally > calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it > on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a > `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable > when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a > mention that this can lead to incorrect manifest files ending up in jar files: >> can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one >> can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) > > I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But > my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's > created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store > these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract > and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't > see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in > this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the > nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the > `jdk:tier1` tests locally which hasn't shown any related failures. src/java.base/share/classes/java/util/jar/JarFile.java line 428: > 426: try (final InputStream is = super.getInputStream(manEntry)) { > 427: man = new Manifest(is, getName()); > 428: } There is a cleaner so shouldn't have a leak, even if the JarFile is not explicitly closed. The noisy "final" can be dropped, otherwise looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From dfuchs at openjdk.java.net Tue Sep 15 15:36:55 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 15 Sep 2020 15:36:55 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 14:59:57 GMT, Jaikiran Pai wrote: > 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-6714834? > As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally > calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it > on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a > `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable > when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a > mention that this can lead to incorrect manifest files ending up in jar files: >> can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one >> can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) > > I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But > my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's > created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store > these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract > and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't > see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in > this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the > nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the > `jdk:tier1` tests locally which hasn't shown any related failures. Hi Jaikiran, This is not an area I know too well - so I won't review formally, but the proposed changes look reasonable to me. Closing the stream from within `JarFile` after creating the manifest looks innocuous and should release any resource held by the stream earlier instead of waiting for the `JarFile` to be closed. As long as the input stream `close()` method is idem potent this should be safe, and AFAICS that is the case for the two input stream subclasses that can be returned by `ZipFile::getInputStream`. WRT to the claims in the JBS issue I see that that was logged against Java 6: there was no `Cleanable` at this time and it is possible that the internals of ZipFile/JarFile were quite different. ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From jpai at openjdk.java.net Tue Sep 15 15:40:47 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 15:40:47 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: 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-6714834? > As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally > calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it > on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a > `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable > when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a > mention that this can lead to incorrect manifest files ending up in jar files: >> can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one >> can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) > > I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But > my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's > created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store > these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract > and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't > see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in > this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the > nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the > `jdk:tier1` tests locally which hasn't shown any related failures. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Remove "final" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/186/files - new: https://git.openjdk.java.net/jdk/pull/186/files/e5ab2869..11fa0776 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=186&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=186&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/186.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/186/head:pull/186 PR: https://git.openjdk.java.net/jdk/pull/186 From jpai at openjdk.java.net Tue Sep 15 15:43:23 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 15:43:23 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:29:44 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove "final" > > src/java.base/share/classes/java/util/jar/JarFile.java line 428: > >> 426: try (final InputStream is = super.getInputStream(manEntry)) { >> 427: man = new Manifest(is, getName()); >> 428: } > > There is a cleaner so shouldn't have a leak, even if the JarFile is not explicitly closed. > The noisy "final" can be dropped, otherwise looks good. Thank you for the review Alan. I've updated this PR to remove the `final`. And yes as you note, this doesn't really leak. This change closes the InputStream earlier, as soon as it is done, instead of waiting for the `Cleaner` to kick in. ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From jpai at openjdk.java.net Tue Sep 15 15:47:31 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 15:47:31 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:33:51 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove "final" > > Hi Jaikiran, > > This is not an area I know too well - so I won't review formally, but the proposed changes look reasonable to me. > Closing the stream from within `JarFile` after creating the manifest looks innocuous and should release any resource > held by the stream earlier instead of waiting for the `JarFile` to be closed. As long as the input stream `close()` > method is idem potent this should be safe, and AFAICS that is the case for the two input stream subclasses that can be > returned by `ZipFile::getInputStream`. WRT to the claims in the JBS issue I see that that was logged against Java 6: > there was no `Cleanable` at this time and it is possible that the internals of ZipFile/JarFile were quite different. Thank you for the review Daniel. > WRT to the claims in the JBS issue I see that that was logged against Java 6: there was no Cleanable at this time and > it is possible that the internals of ZipFile/JarFile were quite different. You are right. I hadn't paid attention to that detail. It's likely that it might have been behaving differently at that time. As for this: > As long as the input stream close() method is idem potent this should be safe, and AFAICS that is the case for the two > input stream subclasses that can be returned by ZipFile::getInputStream. I'm curious, in the context of this change, why idempotency would be a necessity. Would there be a "double close" somehow on this `InputStream` instance? ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From winterhalter at openjdk.java.net Tue Sep 15 15:56:48 2020 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Tue, 15 Sep 2020 15:56:48 GMT Subject: RFR: 8202473: A type variable with multiple bounds does not correctly place type annotation In-Reply-To: References: <0Ph01nef-zH908Im8MWHnSIZrjjSE2n2FJwJL2XxPI8=.706ce54d-f991-4dde-9481-d3e01063adfd@github.com> Message-ID: On Tue, 15 Sep 2020 11:31:58 GMT, Joel Borggr?n-Franck wrote: >> Pre-git review thread here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067049.html > > @raphw test is missing imports and doesn't compile, other than that looks good. Bad copy paste. Fixed on the branch. ------------- PR: https://git.openjdk.java.net/jdk/pull/155 From jpai at openjdk.java.net Tue Sep 15 15:57:35 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 15:57:35 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:45:05 GMT, Jaikiran Pai wrote: > As for this: > >> As long as the input stream close() method is idem potent this should be safe, and AFAICS that is the case for the two >> input stream subclasses that can be returned by ZipFile::getInputStream. > > I'm curious, in the context of this change, why idempotency would be a necessity. Would there be a "double close" > somehow on this InputStream instance? I think I understand what you meant. You were perhaps talking about the `JarFile.close` triggering the `Cleanable` to close this `InputStream` in addition to the `try-with-resources` already calling `close` on that stream. Like you rightly note, the implementation of those streams already handles that aspect correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From dfuchs at openjdk.java.net Tue Sep 15 15:57:35 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 15 Sep 2020 15:57:35 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:45:05 GMT, Jaikiran Pai wrote: > I'm curious, in the context of this change, why idempotency would be a necessity. Would there be a "double close" > somehow on this `InputStream` instance? My bad - I hadn't realised closing the input stream would also remove it from the Cleanable resource set, so I thought it might be closed again when the jar file is closed. ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From bchristi at openjdk.java.net Tue Sep 15 16:29:26 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 15 Sep 2020 16:29:26 GMT Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v4] In-Reply-To: References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> Message-ID: <94oW3D85snbzeXr3V2v1z8YXzCzTiMu07liG9U3aw8E=.eec10679-bac6-4144-919d-e53e6e516400@github.com> On Tue, 15 Sep 2020 12:39:11 GMT, Jaikiran Pai wrote: >> 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: > > Remove unintended file commit Reviewed. Thanks for reworking the change into the existing out.write() call. Marked as reviewed by bchristi (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/130 From joehw at openjdk.java.net Tue Sep 15 16:43:00 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 15 Sep 2020 16:43:00 GMT Subject: Integrated: 8251495: Remove the implNote in the DOM package description added by JDK-8249643 In-Reply-To: References: Message-ID: <_GWQhtx-yhsthRZiF0x4Q9IfwzyaCIoPTYqCk6WvKMg=.69c0a352-5eec-486f-a1e4-c37b96798cf3@github.com> On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote: > Revert changes made by JDK-8249643, removing the implNote. This pull request has now been integrated. Changeset: 5191f315 Author: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/5191f315 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod 8251495: Remove the implNote in the DOM package description added by JDK-8249643 Remove the implNote from the package description added by JDK-8249643. Reviewed-by: lancea, smarks, naoto, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/100 From dtitov at openjdk.java.net Tue Sep 15 16:49:31 2020 From: dtitov at openjdk.java.net (Daniil Titov) Date: Tue, 15 Sep 2020 16:49:31 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() Message-ID: The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8241390 Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. ------------- Commit messages: - 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() Changes: https://git.openjdk.java.net/jdk/pull/190/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=190&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241390 Stats: 202 lines in 6 files changed: 193 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/190/head:pull/190 PR: https://git.openjdk.java.net/jdk/pull/190 From lancea at openjdk.java.net Tue Sep 15 16:57:23 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 15 Sep 2020 16:57:23 GMT Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v4] In-Reply-To: References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> Message-ID: On Tue, 15 Sep 2020 12:39:11 GMT, Jaikiran Pai wrote: >> 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: > > Remove unintended file commit Thank you for making the changes that Brent and I suggested. This looks good. I have submitted, a [CSR](https://bugs.openjdk.java.net/browse/JDK-8253142) to track the change. I have also created a [Release Note](https://bugs.openjdk.java.net/browse/JDK-8253185) as well. Once the CSR has been approved, I will sponsor your change ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/130 From lancea at openjdk.java.net Tue Sep 15 17:02:39 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 15 Sep 2020 17:02:39 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:40:47 GMT, Jaikiran Pai wrote: >> 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-6714834? >> As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally >> calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it >> on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a >> `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable >> when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a >> mention that this can lead to incorrect manifest files ending up in jar files: >>> can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one >>> can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) >> >> I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But >> my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's >> created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store >> these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract >> and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't >> see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in >> this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the >> nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the >> `jdk:tier1` tests locally which hasn't shown any related failures. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Remove "final" I am fine with this as well. I will pull over the change and just sanity check it via mach5 and then will sponsor ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/186 From nlisker at gmail.com Mon Sep 14 18:56:27 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 14 Sep 2020 21:56:27 +0300 Subject: 'Find' method for Iterable Message-ID: Hi, This has probably been brought up at some point. When we need to find an item in a collection based on its properties, we can either do it in a loop, testing each item, or in a stream with filter and findFirst/Any. I would think that a method in Iterable be useful, along the lines of: public Optional find(Predicate condition) { Objects.requireNonNull(condition); for (T t : this) { if (condition.test(t)) { return Optional.of(t); } } return Optional.empty(); } With usage: list.find(person -> person.id == 123456); There are a few issues with the method here such as t being null in null-friendly collections and the lack of bound generic types, but this example is just used to explain the intention. It will be an alternative to list.stream().filter(person -> person.id == 123456).findAny/First() (depending on if the collection is ordered or not) which doesn't create a stream, similar to Iterable#forEach vs Stream#forEach. Maybe with pattern matching this would become more appetizing. - Nir From sspitsyn at openjdk.java.net Tue Sep 15 18:17:25 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 15 Sep 2020 18:17:25 GMT Subject: RFR: 8252537: Updated @exception with @throws In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 19:29:30 GMT, Vipin Sharma wrote: > Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. > > Open Subtasks part of this fix are: > 1. JDK-8252537 > 2. JDK-8252539 > 3. JDK-8252540 > 4. JDK-8252541 > > Previous conversation on this: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html I've only looked at the management files. They look good in general. src/java.management/share/classes/java/lang/management/ClassLoadingMXBean.java 108 * @throws java.lang.SecurityException if a security manager 109 * exists and the caller does not have 110 * ManagementPermission("control"). src/java.management/share/classes/java/lang/management/MemoryMXBean.java 286 * @throws java.lang.SecurityException if a security manager 287 * exists and the caller does not have 288 * ManagementPermission("control"). Could you, please, fix the indentation? ------------- Changes requested by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/95 From igraves at openjdk.java.net Tue Sep 15 18:48:11 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 15 Sep 2020 18:48:11 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v4] In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Test updates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/156/files - new: https://git.openjdk.java.net/jdk/pull/156/files/b89d2c4d..860c6096 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=02-03 Stats: 59 lines in 2 files changed: 58 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/156/head:pull/156 PR: https://git.openjdk.java.net/jdk/pull/156 From openjdk at icemanx.nl Tue Sep 15 19:14:11 2020 From: openjdk at icemanx.nl (Rob Spoor) Date: Tue, 15 Sep 2020 21:14:11 +0200 Subject: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode Message-ID: In Java 14 and before, DecimalFormatSymbols had overrides for both equals and hashCode. In Java 15, the override for hashCode has disappeared, and it now inherits hashCode from java.lang.Object. That means it now violates the contract for equals + hashCode: two equal DecimalFormatSymbols instances can have different hash codes. 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 vsharma at openjdk.java.net Tue Sep 15 19:16:22 2020 From: vsharma at openjdk.java.net (Vipin Sharma) Date: Tue, 15 Sep 2020 19:16:22 GMT Subject: RFR: 8252537: Updated @exception with @throws In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 18:14:58 GMT, Serguei Spitsyn wrote: >> Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. >> >> Open Subtasks part of this fix are: >> 1. JDK-8252537 >> 2. JDK-8252539 >> 3. JDK-8252540 >> 4. JDK-8252541 >> >> Previous conversation on this: >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html > > I've only looked at the management files. They look good in general. > > src/java.management/share/classes/java/lang/management/ClassLoadingMXBean.java > > 108 * @throws java.lang.SecurityException if a security manager > 109 * exists and the caller does not have > 110 * ManagementPermission("control"). > > > src/java.management/share/classes/java/lang/management/MemoryMXBean.java > > 286 * @throws java.lang.SecurityException if a security manager > 287 * exists and the caller does not have > 288 * ManagementPermission("control"). > > Could you, please, fix the indentation? @RogerRiggs I understand your point and will update PR with correct indentation. But I think adding 3 spaces after throws may not be right for all cases. For example when 1. Another tag in same method is using only 1 space. 2. In some cases (e.g. free method of Blob.java) we had a mix of throws and exception in the same method both with one space after. Here after adding 3 spaces throws tags will have the different number of spaces and indentation will not be same as before. I will update PR to make sure the indentation looks same as before and there is no change in javadoc. Please tell me in case my understnding is not correct here. ------------- PR: https://git.openjdk.java.net/jdk/pull/95 From rriggs at openjdk.java.net Tue Sep 15 19:21:37 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 15 Sep 2020 19:21:37 GMT Subject: RFR: 8252537: Updated @exception with @throws In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 19:13:55 GMT, Vipin Sharma wrote: >> I've only looked at the management files. They look good in general. >> >> src/java.management/share/classes/java/lang/management/ClassLoadingMXBean.java >> >> 108 * @throws java.lang.SecurityException if a security manager >> 109 * exists and the caller does not have >> 110 * ManagementPermission("control"). >> >> >> src/java.management/share/classes/java/lang/management/MemoryMXBean.java >> >> 286 * @throws java.lang.SecurityException if a security manager >> 287 * exists and the caller does not have >> 288 * ManagementPermission("control"). >> >> Could you, please, fix the indentation? > > @RogerRiggs I understand your point and will update PR with correct indentation. > But I think adding 3 spaces after throws may not be right for all cases. > For example when > 1. Another tag in same method is using only 1 space. > 2. In some cases (e.g. free method of Blob.java) we had a mix of throws and exception in the same method both with one > space after. Here after adding 3 spaces throws tags will have the different number of spaces and indentation will not > be same as before. I will update PR to make sure the indentation looks same as before and there is no change in > javadoc. Please tell me in case my understnding is not correct here. HI Vipin, Correct, a better description is "fix the indentation". I mnetioned 3 because that was the difference in length between "exception" and "throws". Thanks for the followup, Roger On 9/15/20 3:14 PM, Vipin Sharma wrote: > > @RogerRiggs > > I understand your point and will update PR with correct indentation. > But I think adding 3 spaces after throws may not be right for all cases. > For example when > > 1. Another tag in same method is using only 1 space. > 2. In some cases (e.g. free method of Blob.java) we had a mix of > throws and exception in the same method both with one space after. > Here after adding 3 spaces throws tags will have the different > number of spaces and indentation will not be same as before. > > I will update PR to make sure the indentation looks same as before and > there is no change in javadoc. > Please tell me in case my understnding is not correct here. > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > ------------- PR: https://git.openjdk.java.net/jdk/pull/95 From brian.burkhalter at oracle.com Tue Sep 15 19:36:10 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 15 Sep 2020 12:36:10 -0700 Subject: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode In-Reply-To: References: Message-ID: Hello, The override of hashCode() looks like it is still there in JDK 15 [1]. I don?t know however why it does not appear as such in the javadoc [2]. Brian [1] http://hg.openjdk.java.net/jdk/jdk15/file/fb7064dc63f9/src/java.base/share/classes/java/text/DecimalFormatSymbols.java#l760 [2] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/text/DecimalFormatSymbols.html > On Sep 15, 2020, at 12:14 PM, Rob Spoor wrote: > > In Java 14 and before, DecimalFormatSymbols had overrides for both equals and hashCode. In Java 15, the override for hashCode has disappeared, and it now inherits hashCode from java.lang.Object. That means it now violates the contract for equals + hashCode: two equal DecimalFormatSymbols instances can have different hash codes. From kevin.rushforth at oracle.com Tue Sep 15 19:38:51 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Sep 2020 12:38:51 -0700 Subject: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode In-Reply-To: References: Message-ID: I see this in DecimalFormatSymbols: ???? /** ????? * Override hashCode. ????? */ >>> ?? private volatile int hashCode; ???? @Override ???? public int hashCode() { Although, I'm not sure why the intervening private field would prevent javadoc from generating at least a method with an empty doc. -- Kevin On 9/15/2020 12:36 PM, Brian Burkhalter wrote: > Hello, > > The override of hashCode() looks like it is still there in JDK 15 [1]. I don?t know however why it does not appear as such in the javadoc [2]. > > Brian > > [1] http://hg.openjdk.java.net/jdk/jdk15/file/fb7064dc63f9/src/java.base/share/classes/java/text/DecimalFormatSymbols.java#l760 > [2] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/text/DecimalFormatSymbols.html > >> On Sep 15, 2020, at 12:14 PM, Rob Spoor wrote: >> >> In Java 14 and before, DecimalFormatSymbols had overrides for both equals and hashCode. In Java 15, the override for hashCode has disappeared, and it now inherits hashCode from java.lang.Object. That means it now violates the contract for equals + hashCode: two equal DecimalFormatSymbols instances can have different hash codes. From prr at openjdk.java.net Tue Sep 15 19:43:19 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 15 Sep 2020 19:43:19 GMT Subject: RFR: 8250859: Address reliance on default constructors in the Accessibility APIs In-Reply-To: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> References: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> Message-ID: On Tue, 15 Sep 2020 10:04:49 GMT, Conor Cleary wrote: > This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The > following classes have had an explicit no-arg constructor added, with a protected access modifier and accompanying API > description: > - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor > - Default ctor on javax.accessibility.AccessibleContext > - Default ctor on javax.accessibility.AccessibleHyperlink > > The following classes have had an explicit no-arg constructor added, with a public access modifier and accompanying API > description: > - Default ctor on javax.accessibility.AccessibleResourceBundle > - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList > - Default ctor on com.sun.java.accessibility.util.EventID > > specdiff: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html bug: > https://bugs.openjdk.java.net/browse/JDK-8250859 This looks OK but the CSR needs updates first. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/174 From openjdk at icemanx.nl Tue Sep 15 19:43:30 2020 From: openjdk at icemanx.nl (Rob Spoor) Date: Tue, 15 Sep 2020 21:43:30 +0200 Subject: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode In-Reply-To: References: Message-ID: <222adabf-094c-d739-396a-c2c8587fe185@icemanx.nl> Hmm, I could have sworn I checked https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/text/DecimalFormatSymbols.java and didn't find it... I guess it's a false positive then. On 15/09/2020 21:36, Brian Burkhalter wrote: > Hello, > > The override of hashCode() looks like it is still there in JDK 15 [1]. I don?t know however why it does not appear as such in the javadoc [2]. > > Brian > > [1] http://hg.openjdk.java.net/jdk/jdk15/file/fb7064dc63f9/src/java.base/share/classes/java/text/DecimalFormatSymbols.java#l760 > [2] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/text/DecimalFormatSymbols.html > >> On Sep 15, 2020, at 12:14 PM, Rob Spoor wrote: >> >> In Java 14 and before, DecimalFormatSymbols had overrides for both equals and hashCode. In Java 15, the override for hashCode has disappeared, and it now inherits hashCode from java.lang.Object. That means it now violates the contract for equals + hashCode: two equal DecimalFormatSymbols instances can have different hash codes. From lancea at openjdk.java.net Tue Sep 15 19:45:21 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 15 Sep 2020 19:45:21 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 16:59:59 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove "final" > > I am fine with this as well. I will pull over the change and just sanity check it via mach5 and then will sponsor @jaikiran Please go ahead and integrate this and I can then sponsor (has to be done in that order) ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From brian.burkhalter at oracle.com Tue Sep 15 19:50:41 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 15 Sep 2020 12:50:41 -0700 Subject: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode In-Reply-To: <222adabf-094c-d739-396a-c2c8587fe185@icemanx.nl> References: <222adabf-094c-d739-396a-c2c8587fe185@icemanx.nl> Message-ID: <7EE2F402-D21D-4592-B416-ED350A7103AD@oracle.com> > On Sep 15, 2020, at 12:38 PM, Kevin Rushforth wrote: > > I see this in DecimalFormatSymbols: > > > /** > * Override hashCode. > */ > >>> private volatile int hashCode; > @Override > public int hashCode() { > > Although, I'm not sure why the intervening private field would prevent javadoc from generating at least a method with an empty doc. Moving the hashCode private field before the comment block causes the javadoc to be generated as expected. --- a/src/java.base/share/classes/java/text/DecimalFormatSymbols.java +++ b/src/java.base/share/classes/java/text/DecimalFormatSymbols.java @@ -757,10 +757,11 @@ locale.equals(other.locale)); } + private volatile int hashCode; + /** * Override hashCode. */ - private volatile int hashCode; @Override public int hashCode() { if (hashCode == 0) { > On Sep 15, 2020, at 12:43 PM, Rob Spoor wrote: > > Hmm, I could have sworn I checked https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/text/DecimalFormatSymbols.java__;!!GqivPVa7Brio!JJ8ymM95_Eg-fb-IIWGHHAvXTmKEX7h9-vSxyH73DxsjaS_0-bNOJ96Ud_1LMFCR1G0m$ and didn't find it... > > I guess it's a false positive then. In the sense that the hsdhCode() method is not in fact removed, but it is a bug that the javadoc is not generated as one would expect. Thanks, Brian From pavel.rappo at oracle.com Tue Sep 15 20:02:54 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 15 Sep 2020 21:02:54 +0100 Subject: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode In-Reply-To: <7EE2F402-D21D-4592-B416-ED350A7103AD@oracle.com> References: <222adabf-094c-d739-396a-c2c8587fe185@icemanx.nl> <7EE2F402-D21D-4592-B416-ED350A7103AD@oracle.com> Message-ID: <12130176-A6E7-406C-9F80-5702E366901B@oracle.com> > On 15 Sep 2020, at 20:50, Brian Burkhalter wrote: > >> On Sep 15, 2020, at 12:38 PM, Kevin Rushforth wrote: >> >> I see this in DecimalFormatSymbols: >> >> >> /** >> * Override hashCode. >> */ >>>>> private volatile int hashCode; >> @Override >> public int hashCode() { >> >> Although, I'm not sure why the intervening private field would prevent javadoc from generating at least a method with an empty doc https://bugs.openjdk.java.net/browse/JDK-8187386 From coleenp at openjdk.java.net Tue Sep 15 20:04:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Sep 2020 20:04:56 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 16:43:01 GMT, Daniil Titov wrote: > The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle > of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. > [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8241390 > > Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. Changes requested by coleenp (Reviewer). test/jdk/java/lang/instrument/MakeAgentJAR.sh line 1: > 1: #!/bin/sh There are tests in test/hotspot/jtreg/serviceability/jvmti/RedefineClasses that don't use shell scripts that are much better. Can you add this test using that framework instead? src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 159: > 157: if (!cls->contains(def_ik)) { > 158: def_ik->set_is_being_redefined(false); > 159: } Ok, so adding the Klass to the thread local list for each recursion works like ref counting. Can't think of a simpler way to do this. Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/190 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 openjdk at icemanx.nl Tue Sep 15 20:50:55 2020 From: openjdk at icemanx.nl (Rob Spoor) Date: Tue, 15 Sep 2020 22:50:55 +0200 Subject: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode In-Reply-To: <12130176-A6E7-406C-9F80-5702E366901B@oracle.com> References: <222adabf-094c-d739-396a-c2c8587fe185@icemanx.nl> <7EE2F402-D21D-4592-B416-ED350A7103AD@oracle.com> <12130176-A6E7-406C-9F80-5702E366901B@oracle.com> Message-ID: On 15/09/2020 22:02, Pavel Rappo wrote: >> On 15 Sep 2020, at 20:50, Brian Burkhalter wrote: >> >>> On Sep 15, 2020, at 12:38 PM, Kevin Rushforth wrote: >>> >>> I see this in DecimalFormatSymbols: >>> >>> >>> /** >>> * Override hashCode. >>> */ >>>>>> private volatile int hashCode; >>> @Override >>> public int hashCode() { >>> >>> Although, I'm not sure why the intervening private field would prevent javadoc from generating at least a method with an empty doc > > https://bugs.openjdk.java.net/browse/JDK-8187386 > So in this case, the solution would be to remove the superfluous "Override equals." comment from the equals method, right? From joe.darcy at oracle.com Tue Sep 15 21:00:10 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 15 Sep 2020 14:00:10 -0700 Subject: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode In-Reply-To: References: Message-ID: Note that we've had the javac warning about equals and hashCode overriding as a fatal build condition since at least JDK 9. -Joe On 9/15/2020 12:36 PM, Brian Burkhalter wrote: > Hello, > > The override of hashCode() looks like it is still there in JDK 15 [1]. I don?t know however why it does not appear as such in the javadoc [2]. > > Brian > > [1] http://hg.openjdk.java.net/jdk/jdk15/file/fb7064dc63f9/src/java.base/share/classes/java/text/DecimalFormatSymbols.java#l760 > [2] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/text/DecimalFormatSymbols.html > >> On Sep 15, 2020, at 12:14 PM, Rob Spoor wrote: >> >> In Java 14 and before, DecimalFormatSymbols had overrides for both equals and hashCode. In Java 15, the override for hashCode has disappeared, and it now inherits hashCode from java.lang.Object. That means it now violates the contract for equals + hashCode: two equal DecimalFormatSymbols instances can have different hash codes. From naoto at openjdk.java.net Tue Sep 15 22:17:22 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 15 Sep 2020 22:17:22 GMT Subject: Integrated: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 22:18:34 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. This pull request has now been integrated. Changeset: 57f92d23 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/57f92d23 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8220483: Calendar.setTime(Date date) throws NPE with Date date = null Reviewed-by: lancea, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/159 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 alanb at openjdk.java.net Wed Sep 16 06:19:06 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 16 Sep 2020 06:19:06 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:40:47 GMT, Jaikiran Pai wrote: >> 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-6714834? >> As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally >> calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it >> on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a >> `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable >> when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a >> mention that this can lead to incorrect manifest files ending up in jar files: >>> can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one >>> can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) >> >> I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But >> my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's >> created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store >> these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract >> and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't >> see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in >> this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the >> nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the >> `jdk:tier1` tests locally which hasn't shown any related failures. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Remove "final" Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From sspitsyn at openjdk.java.net Wed Sep 16 06:52:16 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 16 Sep 2020 06:52:16 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 20:02:33 GMT, Coleen Phillimore wrote: >> The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle >> of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. >> [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8241390 >> >> Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 159: > >> 157: if (!cls->contains(def_ik)) { >> 158: def_ik->set_is_being_redefined(false); >> 159: } > > Ok, so adding the Klass to the thread local list for each recursion works like ref counting. Can't think of a simpler > way to do this. Looks good. Yes, the same class can be pushed to the list multiple times (not more than once by each recursive redefinition). It'd make sense to add a comment about it as it is not obvious. > test/jdk/java/lang/instrument/MakeAgentJAR.sh line 1: > >> 1: #!/bin/sh > > There are tests in test/hotspot/jtreg/serviceability/jvmti/RedefineClasses that don't use shell scripts that are much > better. Can you add this test using that framework instead? I'm second for this suggestion from Coleen to get rid of the shell script in the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/190 From sspitsyn at openjdk.java.net Wed Sep 16 06:59:02 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 16 Sep 2020 06:59:02 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 20:02:38 GMT, Coleen Phillimore wrote: >> The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle >> of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. >> [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8241390 >> >> Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. > > Changes requested by coleenp (Reviewer). The identifier 'cls' does not reflect the nature of the object and needs to be replaces with something like: classes, redef_classes or classes_list This impacts the files: jvmtiThreadState.hpp and jvmtiRedefineClasses.cpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/190 From jfranck at openjdk.java.net Wed Sep 16 08:27:24 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Wed, 16 Sep 2020 08:27:24 GMT Subject: RFR: 8202473: A type variable with multiple bounds does not correctly place type annotation [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:18:20 GMT, Rafael Winterhalter wrote: >> This patch assures that an annotation on a type bound is placed on the correct bound index. > > Rafael Winterhalter 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 jfranck (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/155 From chegar at openjdk.java.net Wed Sep 16 08:55:40 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 16 Sep 2020 08:55:40 GMT Subject: RFR: 8250859: Address reliance on default constructors in the Accessibility APIs In-Reply-To: References: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> Message-ID: On Tue, 15 Sep 2020 19:40:28 GMT, Phil Race wrote: >> This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The >> following classes have had an explicit no-arg constructor added, with a protected access modifier and accompanying API >> description: >> - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor >> - Default ctor on javax.accessibility.AccessibleContext >> - Default ctor on javax.accessibility.AccessibleHyperlink >> >> The following classes have had an explicit no-arg constructor added, with a public access modifier and accompanying API >> description: >> - Default ctor on javax.accessibility.AccessibleResourceBundle >> - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor >> - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor >> - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList >> - Default ctor on com.sun.java.accessibility.util.EventID >> >> specdiff: >> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html bug: >> https://bugs.openjdk.java.net/browse/JDK-8250859 > > This looks OK but the CSR needs updates first. The CSR lists `com.sun.java.accessibility.util.SwingEventMonitor` as being changed, but I cannot find that class in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/174 From pavel.rappo at oracle.com Wed Sep 16 09:11:24 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 16 Sep 2020 10:11:24 +0100 Subject: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode In-Reply-To: References: <222adabf-094c-d739-396a-c2c8587fe185@icemanx.nl> <7EE2F402-D21D-4592-B416-ED350A7103AD@oracle.com> <12130176-A6E7-406C-9F80-5702E366901B@oracle.com> Message-ID: <171521A1-5C59-44A8-BBCF-5856DEA3A3B6@oracle.com> > On 15 Sep 2020, at 21:50, Rob Spoor wrote: > > On 15/09/2020 22:02, Pavel Rappo wrote: >>> On 15 Sep 2020, at 20:50, Brian Burkhalter wrote: >>> >>>> On Sep 15, 2020, at 12:38 PM, Kevin Rushforth wrote: >>>> >>>> I see this in DecimalFormatSymbols: >>>> >>>> >>>> /** >>>> * Override hashCode. >>>> */ >>>>>>> private volatile int hashCode; >>>> @Override >>>> public int hashCode() { >>>> >>>> Although, I'm not sure why the intervening private field would prevent javadoc from generating at least a method with an empty doc >> https://bugs.openjdk.java.net/browse/JDK-8187386 > > So in this case, the solution would be to remove the superfluous "Override equals." comment from the equals method, right? It depends on what you want to achieve. On the one hand, if you 'remove the superfluous "Override equals."' it will eliminate the discrepancy that you described in your original email. On the other hand, a reader might no longer have a clear indication that equals and hashCode are meaningfully overridden. I would simply return "/** Override hashCode */" to its original place, as it is clearly a bug that affects documentation. -Pavel From jpai at openjdk.java.net Wed Sep 16 11:41:07 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 16 Sep 2020 11:41:07 GMT Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v4] In-Reply-To: References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> Message-ID: On Tue, 15 Sep 2020 16:54:29 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unintended file commit > > Thank you for making the changes that Brent and I suggested. This looks good. I have submitted, a > [CSR](https://bugs.openjdk.java.net/browse/JDK-8253142) to track the change. > I have also created a [Release Note](https://bugs.openjdk.java.net/browse/JDK-8253185) as well. > > Once the CSR has been approved, I will sponsor your change Thank you Lance for taking care of the CSR and the release notes. Given that the CSR has been approved, I'm initating the integrate command. ------------- PR: https://git.openjdk.java.net/jdk/pull/130 From github.com+42573+Sanne at openjdk.java.net Wed Sep 16 12:28:22 2020 From: github.com+42573+Sanne at openjdk.java.net (Sanne Grinovero) Date: Wed, 16 Sep 2020 12:28:22 GMT Subject: RFR: 8251397: NPE on ClassValue.ClassValueMap.cacheArray [v2] In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: On Wed, 9 Sep 2020 12:53:41 GMT, Galder Zamarre?o wrote: >> Ah yes, my bad ????? > > Updated PR. @galderz did you really update the PR? I still see the _storeFence_ before the write. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From naoto.sato at oracle.com Wed Sep 16 13:31:53 2020 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 16 Sep 2020 06:31:53 -0700 Subject: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode In-Reply-To: <171521A1-5C59-44A8-BBCF-5856DEA3A3B6@oracle.com> References: <222adabf-094c-d739-396a-c2c8587fe185@icemanx.nl> <7EE2F402-D21D-4592-B416-ED350A7103AD@oracle.com> <12130176-A6E7-406C-9F80-5702E366901B@oracle.com> <171521A1-5C59-44A8-BBCF-5856DEA3A3B6@oracle.com> Message-ID: I created a JIRA issue for this: https://bugs.openjdk.java.net/browse/JDK-8253240 Naoto On 9/16/20 2:11 AM, Pavel Rappo wrote: > > >> On 15 Sep 2020, at 21:50, Rob Spoor wrote: >> >> On 15/09/2020 22:02, Pavel Rappo wrote: >>>> On 15 Sep 2020, at 20:50, Brian Burkhalter wrote: >>>> >>>>> On Sep 15, 2020, at 12:38 PM, Kevin Rushforth wrote: >>>>> >>>>> I see this in DecimalFormatSymbols: >>>>> >>>>> >>>>> /** >>>>> * Override hashCode. >>>>> */ >>>>>>>> private volatile int hashCode; >>>>> @Override >>>>> public int hashCode() { >>>>> >>>>> Although, I'm not sure why the intervening private field would prevent javadoc from generating at least a method with an empty doc >>> https://bugs.openjdk.java.net/browse/JDK-8187386 >> >> So in this case, the solution would be to remove the superfluous "Override equals." comment from the equals method, right? > > It depends on what you want to achieve. On the one hand, if you 'remove the superfluous "Override equals."' it will eliminate the discrepancy that you described in your original email. On the other hand, a reader might no longer have a clear indication that equals and hashCode are meaningfully overridden. > > I would simply return "/** Override hashCode */" to its original place, as it is clearly a bug that affects documentation. > > -Pavel > From jpai at openjdk.java.net Wed Sep 16 15:13:44 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 16 Sep 2020 15:13:44 GMT Subject: Integrated: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) In-Reply-To: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> Message-ID: On Fri, 11 Sep 2020 14:17:45 GMT, Jaikiran Pai wrote: > 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 This pull request has now been integrated. Changeset: e5866aa7 Author: Jaikiran Pai Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/e5866aa7 Stats: 79 lines in 2 files changed: 0 ins; 77 del; 2 mod 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) Reviewed-by: lancea, bchristi ------------- PR: https://git.openjdk.java.net/jdk/pull/130 From jpai at openjdk.java.net Wed Sep 16 15:16:49 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 16 Sep 2020 15:16:49 GMT Subject: Integrated: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 14:59:57 GMT, Jaikiran Pai wrote: > 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-6714834? > As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally > calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it > on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a > `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable > when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a > mention that this can lead to incorrect manifest files ending up in jar files: >> can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one >> can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) > > I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But > my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's > created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store > these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract > and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't > see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in > this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the > nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the > `jdk:tier1` tests locally which hasn't shown any related failures. This pull request has now been integrated. Changeset: 671dfba8 Author: Jaikiran Pai Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/671dfba8 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect Reviewed-by: lancea, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From alanb at openjdk.java.net Wed Sep 16 15:43:43 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 16 Sep 2020 15:43:43 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v3] In-Reply-To: References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: <-a26y1VJwNJ3C-t-tAdmSbLRrB1V-z3UQJyg9ZsmhsU=.93ed5830-bd6b-4b89-a925-0cdda4a78d52@github.com> On Tue, 15 Sep 2020 14:30:03 GMT, Alan Bateman wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Comparator cleanup > > The update using flatMap looks good. I think we need to explore adding more tests if possible. Thanks for adding a test. What would you think about adding this to JLinkReproducible2Test to avoid duplication. The existing test can be tweaked to do the mismatch check with different sets of modules. In passing, no need to include java.base in the @modules tag. ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From naoto at openjdk.java.net Wed Sep 16 17:35:45 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Sep 2020 17:35:45 GMT Subject: RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode() Message-ID: Hi, Please review the fix to the issue wrt missing hashCode() javadoc, which was recently discussed in core-libs ml. ------------- Commit messages: - 8253240: No javadoc for DecimalFormatSymbols.hashCode() Changes: https://git.openjdk.java.net/jdk/pull/208/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=208&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253240 Stats: 6 lines in 1 file changed: 5 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/208.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/208/head:pull/208 PR: https://git.openjdk.java.net/jdk/pull/208 From rriggs at openjdk.java.net Wed Sep 16 17:50:05 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 16 Sep 2020 17:50:05 GMT Subject: RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode() In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 17:29:52 GMT, Naoto Sato wrote: > Hi, > > Please review the fix to the issue wrt missing hashCode() javadoc, which was recently discussed in core-libs ml. Changes requested by rriggs (Reviewer). src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 1153: > 1151: * Cached hash code > 1152: */ > 1153: private volatile int hashCode; I'm thinking the cached hashcode should be / should have been transient (not serialized). And add a period at the end of the sentence above. ------------- PR: https://git.openjdk.java.net/jdk/pull/208 From lancea at openjdk.java.net Wed Sep 16 17:53:46 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 16 Sep 2020 17:53:46 GMT Subject: RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode() In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 17:29:52 GMT, Naoto Sato wrote: > Hi, > > Please review the fix to the issue wrt missing hashCode() javadoc, which was recently discussed in core-libs ml. Looks in line with the discussion on core-libs. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/208 From naoto at openjdk.java.net Wed Sep 16 18:02:48 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Sep 2020 18:02:48 GMT Subject: RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode() [v2] In-Reply-To: References: Message-ID: <5MQBzJy7R7iathIJxcEpQjc2BL2vn-jOx7lEqN_-q9s=.4fbfa43e-3e81-4b46-b2a5-b216887397ff@github.com> On Wed, 16 Sep 2020 17:47:17 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing Roger's comments. > > src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 1153: > >> 1151: * Cached hash code >> 1152: */ >> 1153: private volatile int hashCode; > > I'm thinking the cached hashcode should be / should have been transient (not serialized). > And add a period at the end of the sentence above. Good point. Addressed both comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/208 From naoto at openjdk.java.net Wed Sep 16 18:02:42 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Sep 2020 18:02:42 GMT Subject: RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode() [v2] In-Reply-To: References: Message-ID: > Hi, > > Please review the fix to the issue wrt missing hashCode() javadoc, which was recently discussed in core-libs ml. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addressing Roger's comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/208/files - new: https://git.openjdk.java.net/jdk/pull/208/files/3276598e..2f9d0c3a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=208&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=208&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/208.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/208/head:pull/208 PR: https://git.openjdk.java.net/jdk/pull/208 From igraves at openjdk.java.net Wed Sep 16 18:15:25 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 16 Sep 2020 18:15:25 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v5] In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Copying test jdk to test consistency ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/156/files - new: https://git.openjdk.java.net/jdk/pull/156/files/860c6096..3e8aaf2d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=03-04 Stats: 122 lines in 1 file changed: 122 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/156/head:pull/156 PR: https://git.openjdk.java.net/jdk/pull/156 From igraves at openjdk.java.net Wed Sep 16 18:44:15 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 16 Sep 2020 18:44:15 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v6] In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: <9TFh9raYlJk1ZQla9C_kEhySwCOuFtmU9WMB_JFaRg0=.064a776d-202b-4ac7-8681-aa9183c21ebb@github.com> > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. Ian Graves has updated the pull request incrementally with two additional commits since the last revision: - Merging two tests and renaming a test - Merging tests and renaming test 4 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/156/files - new: https://git.openjdk.java.net/jdk/pull/156/files/3e8aaf2d..1af70014 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=04-05 Stats: 210 lines in 3 files changed: 78 ins; 124 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/156/head:pull/156 PR: https://git.openjdk.java.net/jdk/pull/156 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 asemenyuk at openjdk.java.net Wed Sep 16 19:37:13 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 16 Sep 2020 19:37:13 GMT Subject: RFR: JDK-8230652: Improve verbose output In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 18:30:08 GMT, Andy Herrick wrote: > JDK-8230652 > Extracting the commands displayed by verbose output (including commands called thru ToolProvider) , to contain the the > command, it's output, and it's return value on separate lines and formatted in a way that they can be easily cut and > pasted into a script. Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/141 From rriggs at openjdk.java.net Wed Sep 16 19:56:21 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 16 Sep 2020 19:56:21 GMT Subject: RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode() [v2] In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 17:51:18 GMT, Lance Andersen wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing Roger's comments. > > Looks in line with the discussion on core-libs. Removing hashcode from the serialized form needs a CSR because it was non-transient in JDK 15. The intent is to not use the serialized value, so the readObject method should zero it out so it can be computed on first use. ------------- PR: https://git.openjdk.java.net/jdk/pull/208 From forax at univ-mlv.fr Wed Sep 16 20:59:26 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Sep 2020 22:59:26 +0200 (CEST) Subject: 'Find' method for Iterable In-Reply-To: References: Message-ID: <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Nir Lisker" > ?: "core-libs-dev" > Envoy?: Lundi 14 Septembre 2020 20:56:27 > Objet: 'Find' method for Iterable > Hi, > > This has probably been brought up at some point. When we need to find an > item in a collection based on its properties, we can either do it in a > loop, testing each item, or in a stream with filter and findFirst/Any. > > I would think that a method in Iterable be useful, along the lines of: > > public Optional find(Predicate condition) { > Objects.requireNonNull(condition); > for (T t : this) { > if (condition.test(t)) { > return Optional.of(t); > } > } > return Optional.empty(); > } > > With usage: > > list.find(person -> person.id == 123456); > > There are a few issues with the method here such as t being null in > null-friendly collections and the lack of bound generic types, but this > example is just used to explain the intention. > > It will be an alternative to > > list.stream().filter(person -> person.id == 123456).findAny/First() > (depending on if the collection is ordered or not) > > which doesn't create a stream, similar to Iterable#forEach vs > Stream#forEach. > > Maybe with pattern matching this would become more appetizing. During the development of Java 8, we first tried to use Iterator/Iterable instead of using a novel interface Stream. But a Stream cleanly separate the lazy side effect free API from the mutable one (Collection) and can be optimized better by the VM (it's a push API instead of being a pull API). The other question is why there is no method find() on Collection, i believe it's because while find() is ok for any DB API, find() is dangerous on a Collection because the execution time is linear, so people may use it instead of using a Map. > > - Nir R?mi From naoto at openjdk.java.net Wed Sep 16 22:05:58 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Sep 2020 22:05:58 GMT Subject: RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode() [v2] In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 19:53:26 GMT, Roger Riggs wrote: >> Looks in line with the discussion on core-libs. > > Removing hashcode from the serialized form needs a CSR because it was non-transient in JDK 15. > The intent is to not use the serialized value, so the readObject method should zero it out > so it can be computed on first use. Drafted a CSR for this PR. Please review. ------------- PR: https://git.openjdk.java.net/jdk/pull/208 From stuart.marks at oracle.com Wed Sep 16 22:31:56 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 16 Sep 2020 15:31:56 -0700 Subject: 'Find' method for Iterable In-Reply-To: <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr> References: <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr> Message-ID: On 9/16/20 1:59 PM, Remi Forax wrote: > ----- Mail original ----- >> De: "Nir Lisker" >> ?: "core-libs-dev" >> Envoy?: Lundi 14 Septembre 2020 20:56:27 >> Objet: 'Find' method for Iterable > >> Hi, >> >> This has probably been brought up at some point. When we need to find an >> item in a collection based on its properties, we can either do it in a >> loop, testing each item, or in a stream with filter and findFirst/Any. >> >> I would think that a method in Iterable be useful, along the lines of: >> >> public Optional find(Predicate condition) { >> Objects.requireNonNull(condition); >> for (T t : this) { >> if (condition.test(t)) { >> return Optional.of(t); >> } >> } >> return Optional.empty(); >> } >> >> With usage: >> >> list.find(person -> person.id == 123456); >> >> There are a few issues with the method here such as t being null in >> null-friendly collections and the lack of bound generic types, but this >> example is just used to explain the intention. >> >> It will be an alternative to >> >> list.stream().filter(person -> person.id == 123456).findAny/First() >> (depending on if the collection is ordered or not) >> >> which doesn't create a stream, similar to Iterable#forEach vs >> Stream#forEach. >> >> Maybe with pattern matching this would become more appetizing. > > During the development of Java 8, we first tried to use Iterator/Iterable instead of using a novel interface Stream. > But a Stream cleanly separate the lazy side effect free API from the mutable one (Collection) and can be optimized better by the VM (it's a push API instead of being a pull API). > > The other question is why there is no method find() on Collection, i believe it's because while find() is ok for any DB API, find() is dangerous on a Collection because the execution time is linear, so people may use it instead of using a Map. Hi Nir, R?mi is correct to point out this distinction between the lazy operations (which appear on Stream) and the eager (and possibly mutating) operations on Collections. I think we want to preserve this distinction. While it might not be difficult to add a find() method to Iterable, why limit it to the find operation, and what about all the other operations available on Stream? Maybe what's necessary is a way to convert an Iterable to a Stream. In fact, this is already possible: StreamSupport.stream(iterable.spliterator(), false) Well, this is mouthful, so maybe there ought to be an easier way to convert an Iterable to a Stream. On the other hand, your examples use a list. The List interface already has methods indexOf/lastIndexOf which search the list for a particular object that's compared using equals(). It seems reasonable to consider similar methods that take a predicate instead of an object. Does either of these sound promising? s'marks 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 felix.yang at huawei.com Thu Sep 17 06:40:56 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 17 Sep 2020 06:40:56 +0000 Subject: [aarch64-port-dev ] RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: <1729f1b1-056d-76c9-c820-d38bd6c1235d@redhat.com> <95965aeb-9d97-3b27-e684-967b6155eb34@redhat.com> Message-ID: Hi all, > -----Original Message----- > From: Sean Mullan [mailto:sean.mullan at oracle.com] > Sent: Wednesday, September 9, 2020 12:16 AM > To: Andrew Haley ; Yangfei (Felix) > ; hotspot-compiler-dev at openjdk.java.net; core- > libs-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net; Stuart Monteith > > Subject: Re: [aarch64-port-dev ] RFR: 8252204: AArch64: Implement SHA3 > accelerator/intrinsic > > Since this change affects security code, please make sure you add security- > dev at openjdk.java.net on any followup code reviews. Thanks for reminding that. I have just switched to github and created a PR for this issue: https://github.com/openjdk/jdk/pull/207 Let's switch to this PR for the followup code reviews. I see security and hotspot labels was automatically added by the bots. I also added labels for core-libs and hotspot-compiler. > > On 9/1/20 10:44 AM, Andrew Haley wrote: > > On 01/09/2020 11:53, Yangfei (Felix) wrote: > >> Sure, I am happy if the original author of the assembly code or someone > else from Linaro could help here. > >> I wasn't aware there was such an requirement here given that assembly > code is licensed under GPL. > > > > There sure is. All code must be contributed by its owner and put on > > the cr.openjdk site. Especially GPL code. I have added ard.biesheuvel at linaro.org to Contributed-by: in the git commit msg. And the newly created PR was Acked-by: Ard Biesheuvel ard.biesheuvel at linaro.org Hope this addresses Andrew's concern. Best regards, Felix From sergei.tsypanov at yandex.ru Thu Sep 17 07:19:24 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Thu, 17 Sep 2020 09:19:24 +0200 Subject: Request for review of JDK-8251548 Message-ID: <408131600326592@mail.yandex.ru> Hello, is it possible to have a code review for the changes proposed in JDK-8251548? Sean Mullan has created an issue and web-review and can sponsor the patch as soos as it gets properly reviewed. As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html > there is never any reason to explicitly initialize fields to 0/0.0/false/null so I believe the patch is harmless. Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ Thanks, Sergey Tsypanov From david.holmes at oracle.com Thu Sep 17 07:22:19 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Sep 2020 17:22:19 +1000 Subject: Request for review of JDK-8251548 In-Reply-To: <408131600326592@mail.yandex.ru> References: <408131600326592@mail.yandex.ru> Message-ID: Hi Sergey, Since OpenJDK has moved to git/github, this needs to reformulated as a Pull Request (PR). Cheers, David On 17/09/2020 5:19 pm, ?????? ??????? wrote: > Hello, > > is it possible to have a code review for the changes proposed in JDK-8251548? > > Sean Mullan has created an issue and web-review and can sponsor the patch > as soos as it gets properly reviewed. > > As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html > >> there is never any reason to explicitly initialize fields to 0/0.0/false/null > > so I believe the patch is harmless. > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 > Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ > > Thanks, > Sergey Tsypanov > From goetz at openjdk.java.net Thu Sep 17 07:48:38 2020 From: goetz at openjdk.java.net (Goetz Lindenmaier) Date: Thu, 17 Sep 2020 07:48:38 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 20:48:23 GMT, Richard Reingruber wrote: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Marked as reviewed by goetz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From goetz at openjdk.java.net Thu Sep 17 07:48:38 2020 From: goetz at openjdk.java.net (Goetz Lindenmaier) Date: Thu, 17 Sep 2020 07:48:38 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 07:44:09 GMT, Goetz Lindenmaier wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >> >> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >> >> Thanks, Richard. > > Marked as reviewed by goetz (Reviewer). Reviewed in the good old hg times :) See also http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041453.html ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From winterhalter at openjdk.java.net Thu Sep 17 07:57:13 2020 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Thu, 17 Sep 2020 07:57:13 GMT Subject: Integrated: 8202473: A type variable with multiple bounds does not correctly place type annotation In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 19:49:08 GMT, Rafael Winterhalter wrote: > This patch assures that an annotation on a type bound is placed on the correct bound index. This pull request has now been integrated. Changeset: 53a4ef26 Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck URL: https://git.openjdk.java.net/jdk/commit/53a4ef26 Stats: 83 lines in 2 files changed: 0 ins; 80 del; 3 mod 8202473: A type variable with multiple bounds does not correctly place type annotation Reviewed-by: jfranck ------------- PR: https://git.openjdk.java.net/jdk/pull/155 From github.com+42573+Sanne at openjdk.java.net Thu Sep 17 08:06:55 2020 From: github.com+42573+Sanne at openjdk.java.net (Sanne Grinovero) Date: Thu, 17 Sep 2020 08:06:55 GMT Subject: RFR: 8251397: NPE on ClassValue.ClassValueMap.cacheArray [v2] In-Reply-To: References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: <0pwFixwcHfaA5Alz3OT3NiEJTdgI6utwzmfjY5zgfF8=.5820532e-8134-4bea-96ed-f1182d90967e@github.com> On Wed, 16 Sep 2020 12:25:05 GMT, Sanne Grinovero wrote: >> Updated PR. > > @galderz did you really update the PR? I still see the _storeFence_ before the write. ah, sorry I got it now. Please ignore my previous comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From sergei.tsypanov at yandex.ru Thu Sep 17 09:24:39 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Thu, 17 Sep 2020 11:24:39 +0200 Subject: Request for review of JDK-8251548 In-Reply-To: References: <408131600326592@mail.yandex.ru> Message-ID: <125311600334485@mail.yandex.ru> Hi David, thanks for pointing this out! I've created a PR there [1], but GitHub for some reason wants me to sign OCA, which I have already signed in 2017. I've redone the procedure and now I'm waiting for verification. Regards, Sergey 1. https://github.com/openjdk/jdk/pull/218 17.09.2020, 09:22, "David Holmes" : > Hi Sergey, > > Since OpenJDK has moved to git/github, this needs to reformulated as a > Pull Request (PR). > > Cheers, > David > > On 17/09/2020 5:19 pm, ?????? ??????? wrote: >> ?Hello, >> >> ?is it possible to have a code review for the changes proposed in JDK-8251548? >> >> ?Sean Mullan has created an issue and web-review and can sponsor the patch >> ?as soos as it gets properly reviewed. >> >> ?As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html >> >>> ?there is never any reason to explicitly initialize fields to 0/0.0/false/null >> >> ?so I believe the patch is harmless. >> >> ?Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 >> ?Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ >> >> ?Thanks, >> ?Sergey Tsypanov From ccleary at openjdk.java.net Thu Sep 17 11:04:11 2020 From: ccleary at openjdk.java.net (Conor Cleary) Date: Thu, 17 Sep 2020 11:04:11 GMT Subject: RFR: 8250859: Address reliance on default constructors in the Accessibility APIs [v2] In-Reply-To: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> References: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> Message-ID: > This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The > following classes have had an explicit no-arg constructor added, with a protected access modifier and accompanying API > description: > - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor > - Default ctor on javax.accessibility.AccessibleContext > - Default ctor on javax.accessibility.AccessibleHyperlink > > The following classes have had an explicit no-arg constructor added, with a public access modifier and accompanying API > description: > - Default ctor on javax.accessibility.AccessibleResourceBundle > - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList > - Default ctor on com.sun.java.accessibility.util.EventID > > specdiff: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html bug: > https://bugs.openjdk.java.net/browse/JDK-8250859 Conor Cleary 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 four additional commits since the last revision: - 8250859: Added no-arg constructor to SwingEventMonitor.java - Merge remote-tracking branch 'origin/master' into JDK-8250859 - Merge remote-tracking branch 'origin/master' into JDK-8250859 - 8250859: Address reliance on default constructors in the Accessibility APIs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/174/files - new: https://git.openjdk.java.net/jdk/pull/174/files/a2946aca..bc02a4de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=174&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=174&range=00-01 Stats: 2012 lines in 47 files changed: 486 ins; 1201 del; 325 mod Patch: https://git.openjdk.java.net/jdk/pull/174.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/174/head:pull/174 PR: https://git.openjdk.java.net/jdk/pull/174 From ccleary at openjdk.java.net Thu Sep 17 11:04:13 2020 From: ccleary at openjdk.java.net (Conor Cleary) Date: Thu, 17 Sep 2020 11:04:13 GMT Subject: RFR: 8250859: Address reliance on default constructors in the Accessibility APIs [v2] In-Reply-To: References: <4KbDKgF93r05pE3zeMc0BeYT-Cb_vBodqnYmF5ya-dk=.77c3d84c-7fd9-4477-a895-2c45116f3b2a@github.com> Message-ID: On Wed, 16 Sep 2020 08:52:35 GMT, Chris Hegarty wrote: > The CSR lists `com.sun.java.accessibility.util.SwingEventMonitor` as being changed, but I cannot find that class in > this PR. Changes to this class were indeed missing. This has now been addressed. Thanks for spotting that! ------------- PR: https://git.openjdk.java.net/jdk/pull/174 From david.holmes at oracle.com Thu Sep 17 12:10:46 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Sep 2020 22:10:46 +1000 Subject: Request for review of JDK-8251548 In-Reply-To: <125311600334485@mail.yandex.ru> References: <408131600326592@mail.yandex.ru> <125311600334485@mail.yandex.ru> Message-ID: On 17/09/2020 7:24 pm, ?????? ??????? wrote: > Hi David, > > thanks for pointing this out! > > I've created a PR there [1], but GitHub for some reason wants me to sign OCA, > which I have already signed in 2017. I've redone the procedure and now I'm waiting > for verification. Did you not follow these instructions to get your github account connected to your OCA record: "If you already are an OpenJDK Author, Committer or Reviewer, please click here[1] to open a new issue so that we can record that fact. Please use "Add GitHub user stsypanov" as summary for the issue." [1] https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1 Cheers, David ----- > Regards, > Sergey > > 1. https://github.com/openjdk/jdk/pull/218 > > 17.09.2020, 09:22, "David Holmes" : >> Hi Sergey, >> >> Since OpenJDK has moved to git/github, this needs to reformulated as a >> Pull Request (PR). >> >> Cheers, >> David >> >> On 17/09/2020 5:19 pm, ?????? ??????? wrote: >>> ?Hello, >>> >>> ?is it possible to have a code review for the changes proposed in JDK-8251548? >>> >>> ?Sean Mullan has created an issue and web-review and can sponsor the patch >>> ?as soos as it gets properly reviewed. >>> >>> ?As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html >>> >>>> ?there is never any reason to explicitly initialize fields to 0/0.0/false/null >>> >>> ?so I believe the patch is harmless. >>> >>> ?Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 >>> ?Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ >>> >>> ?Thanks, >>> ?Sergey Tsypanov From aleonard at openjdk.java.net Thu Sep 17 12:52:44 2020 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Thu, 17 Sep 2020 12:52:44 GMT Subject: RFR: 8253285: Some java/util/StringJoiner tests do not explicitly specify required -XX:+CompactStrings Message-ID: <-XlnrDcY0i9r726gDIU4eoSUxvmFh8Y1AsB8ZtzkrMQ=.1a0fd5e1-59dd-4679-aba1-cabbc874f789@github.com> Signed-off-by: Andrew Leonard ------------- Commit messages: - 8253285: Some java/util/StringJoiner tests do not explicitly specify required -XX:+CompactStrings Changes: https://git.openjdk.java.net/jdk/pull/223/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=223&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253285 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/223.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/223/head:pull/223 PR: https://git.openjdk.java.net/jdk/pull/223 From andrew_m_leonard at uk.ibm.com Thu Sep 17 12:57:23 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 17 Sep 2020 13:57:23 +0100 Subject: RFR: 8253285: Some java/util/StringJoiner tests do not explicitly specify required -XX:+CompactStrings Message-ID: Hi, Please can I request a review of this test fix to explicitly specify -XX:+CompactStrings which is required for the tests in question, specifically for VMs (openj9) that do not default to +CompactStrings, see: PR https://github.com/openjdk/jdk/pull/223 bug https://bugs.openjdk.java.net/browse/JDK-8253285 Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From shade at redhat.com Thu Sep 17 13:01:04 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 17 Sep 2020 15:01:04 +0200 Subject: RFR: 8253285: Some java/util/StringJoiner tests do not explicitly specify required -XX:+CompactStrings In-Reply-To: References: Message-ID: <3d34f6ee-4640-79a2-a34a-30c861b14293@redhat.com> On 9/17/20 2:57 PM, Andrew Leonard wrote: > Hi, > Please can I request a review of this test fix to explicitly specify > -XX:+CompactStrings which is required for the tests in question, > specifically for VMs (openj9) that do not default to +CompactStrings, see: > PR https://github.com/openjdk/jdk/pull/223 > bug https://bugs.openjdk.java.net/browse/JDK-8253285 You don't need to ask for RFRs yourself. Bots do that for you, and post on your behalf, like this: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068879.html -- Thanks, -Aleksey From rriggs at openjdk.java.net Thu Sep 17 13:13:28 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 17 Sep 2020 13:13:28 GMT Subject: RFR: 8253285: Some java/util/StringJoiner tests do not explicitly specify required -XX:+CompactStrings In-Reply-To: <-XlnrDcY0i9r726gDIU4eoSUxvmFh8Y1AsB8ZtzkrMQ=.1a0fd5e1-59dd-4679-aba1-cabbc874f789@github.com> References: <-XlnrDcY0i9r726gDIU4eoSUxvmFh8Y1AsB8ZtzkrMQ=.1a0fd5e1-59dd-4679-aba1-cabbc874f789@github.com> Message-ID: On Thu, 17 Sep 2020 11:30:40 GMT, Andrew Leonard wrote: > Signed-off-by: Andrew Leonard Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/223 From github.com+50187+galderz at openjdk.java.net Thu Sep 17 13:45:20 2020 From: github.com+50187+galderz at openjdk.java.net (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Thu, 17 Sep 2020 13:45:20 GMT Subject: Integrated: 8251397: NPE on ClassValue.ClassValueMap.cacheArray In-Reply-To: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> References: <-fnsj5Nfvf4AVlblqJ6H2uNFVhixnXBeUgarn0bW2dw=.fcf8e55f-e16c-4ed5-8fef-567bc95c3d7c@github.com> Message-ID: On Wed, 9 Sep 2020 12:35:06 GMT, Galder Zamarre?o wrote: > * Release fence guarantees that cacheArray field will published with a non-null value. > * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. > > This is a follow up to @PaulSandoz's feedback > [here](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068248.html) for the first attempt to fix > [JDK-8251397](https://bugs.openjdk.java.net/browse/JDK-8251397). In this update, the fence has been moved to > `initializeMap()` and added Paul's suggested comment. > Annotating `classValueMap` with `@Stable` is outside the scope of this issue. This pull request has now been integrated. Changeset: 81e2cf82 Author: Galder Zamarren?o Committer: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/81e2cf82 Stats: 14 lines in 1 file changed: 0 ins; 12 del; 2 mod 8251397: NPE on ClassValue.ClassValueMap.cacheArray Add release fence to ClassValueMap constructor. * Release fence guarantees that cacheArray field will published with a non-null value. * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. Reviewed-by: shade, psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/94 From andrew_m_leonard at uk.ibm.com Thu Sep 17 14:02:38 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 17 Sep 2020 15:02:38 +0100 Subject: RFR: 8253285: Some java/util/StringJoiner tests do not explicitly specify required -XX:+CompactStrings In-Reply-To: <3d34f6ee-4640-79a2-a34a-30c861b14293@redhat.com> References: <3d34f6ee-4640-79a2-a34a-30c861b14293@redhat.com> Message-ID: > You don't need to ask for RFRs yourself. Bots do that for you, and post on your behalf Yeah, I saw that just after I posted mine, that's cool :-) Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Aleksey Shipilev To: Andrew Leonard , core-libs-dev at openjdk.java.net Date: 17/09/2020 14:01 Subject: [EXTERNAL] Re: RFR: 8253285: Some java/util/StringJoiner tests do not explicitly specify required -XX:+CompactStrings On 9/17/20 2:57 PM, Andrew Leonard wrote: > Hi, > Please can I request a review of this test fix to explicitly specify > -XX:+CompactStrings which is required for the tests in question, > specifically for VMs (openj9) that do not default to +CompactStrings, see: > PR https://github.com/openjdk/jdk/pull/223 > bug https://bugs.openjdk.java.net/browse/JDK-8253285 https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068879.html -- Thanks, -Aleksey 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 aleonard at openjdk.java.net Thu Sep 17 14:08:09 2020 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Thu, 17 Sep 2020 14:08:09 GMT Subject: RFR: 8253285: Some java/util/StringJoiner tests do not explicitly specify required -XX:+CompactStrings In-Reply-To: References: <-XlnrDcY0i9r726gDIU4eoSUxvmFh8Y1AsB8ZtzkrMQ=.1a0fd5e1-59dd-4679-aba1-cabbc874f789@github.com> Message-ID: On Thu, 17 Sep 2020 13:09:09 GMT, Roger Riggs wrote: >> Signed-off-by: Andrew Leonard > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs thanks Roger, please can you Sponsor this PR ? thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/223 From jlaskey at openjdk.java.net Thu Sep 17 14:15:19 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 17 Sep 2020 14:15:19 GMT Subject: RFR: 8253285: Some java/util/StringJoiner tests do not explicitly specify required -XX:+CompactStrings In-Reply-To: <-XlnrDcY0i9r726gDIU4eoSUxvmFh8Y1AsB8ZtzkrMQ=.1a0fd5e1-59dd-4679-aba1-cabbc874f789@github.com> References: <-XlnrDcY0i9r726gDIU4eoSUxvmFh8Y1AsB8ZtzkrMQ=.1a0fd5e1-59dd-4679-aba1-cabbc874f789@github.com> Message-ID: <_I9hY5Xs0hDxJ-3Pe-1ODohAuEJ805puVeDmGa4nSHE=.f26f8079-57ce-4d0b-b858-7a93b3ea958a@github.com> On Thu, 17 Sep 2020 11:30:40 GMT, Andrew Leonard wrote: > Signed-off-by: Andrew Leonard Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/223 From aleonard at openjdk.java.net Thu Sep 17 14:46:57 2020 From: aleonard at openjdk.java.net (Andrew Leonard) Date: Thu, 17 Sep 2020 14:46:57 GMT Subject: Integrated: 8253285: Some java/util/StringJoiner tests do not explicitly specify required -XX:+CompactStrings In-Reply-To: <-XlnrDcY0i9r726gDIU4eoSUxvmFh8Y1AsB8ZtzkrMQ=.1a0fd5e1-59dd-4679-aba1-cabbc874f789@github.com> References: <-XlnrDcY0i9r726gDIU4eoSUxvmFh8Y1AsB8ZtzkrMQ=.1a0fd5e1-59dd-4679-aba1-cabbc874f789@github.com> Message-ID: On Thu, 17 Sep 2020 11:30:40 GMT, Andrew Leonard wrote: > Signed-off-by: Andrew Leonard This pull request has now been integrated. Changeset: 24765e45 Author: Andrew Leonard Committer: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/24765e45 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8253285: Some java/util/StringJoiner tests do not explicitly specify required -XX:+CompactStrings Reviewed-by: rriggs, jlaskey ------------- PR: https://git.openjdk.java.net/jdk/pull/223 From github.com+8448088+ardbiesheuvel at openjdk.java.net Thu Sep 17 15:35:28 2020 From: github.com+8448088+ardbiesheuvel at openjdk.java.net (Ard Biesheuvel) Date: Thu, 17 Sep 2020 15:35:28 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 05:18:28 GMT, Fei Yang wrote: >> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com >> >> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. >> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 >> >> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. >> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. >> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. >> >> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. >> Patch passed jtreg tier1-3 tests with QEMU system emulator. >> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make >> sure that there's no regression. >> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java >> We measured the performance benefit with an aarch64 cycle-accurate simulator. >> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. >> >> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on >> real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is >> detected. > > @ardbiesheuvel : Ard, could you please ack this patch? Thanks. Acked-by: Ard Biesheuvel ------------- PR: https://git.openjdk.java.net/jdk/pull/207 From github.com+69642324+azuev-java at openjdk.java.net Thu Sep 17 15:40:15 2020 From: github.com+69642324+azuev-java at openjdk.java.net (Alexander Zuev) Date: Thu, 17 Sep 2020 15:40:15 GMT Subject: RFR: JDK-8230652: Improve verbose output In-Reply-To: References: Message-ID: <0n7_379-_Y0KEJSL7GS--QmCfGidDvVgNxkADR2UUj4=.02581945-ff1e-45c0-8e55-130668259795@github.com> On Sat, 12 Sep 2020 18:30:08 GMT, Andy Herrick wrote: > JDK-8230652 > Extracting the commands displayed by verbose output (including commands called thru ToolProvider) , to contain the the > command, it's output, and it's return value on separate lines and formatted in a way that they can be easily cut and > pasted into a script. Looks good. ------------- Marked as reviewed by azuev-java at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/141 From github.com+70893615+jasontatton-aws at openjdk.java.net Thu Sep 17 18:22:35 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Thu, 17 Sep 2020 18:22:35 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> On Fri, 11 Sep 2020 23:04:01 GMT, Jason Tatton wrote: >> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for >> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it >> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as >> code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and >> java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 >> >> Details of testing: >> ============ >> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note >> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the >> input String. Hence the test has been designed to cover all these cases. In summary they are: >> - A ?short? string of < 16 characters. >> - A SIMD String of 16 ? 31 characters. >> - A AVX2 SIMD String of 32 characters+. >> >> Hardware used for testing: >> ----------------------------- >> >> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). >> - AWS Graviton 2 (ARM 64 processor). >> >> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. >> >> Possible future enhancements: >> ==================== >> For the x86 implementation there may be two further improvements we can make in order to improve performance of both >> the StringUTF16 and StringLatin1 indexOf(char) intrinsics: >> 1. Make use of AVX-512 instructions. >> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD >> instructions instead of a loop. >> Benchmark results: >> ============ >> **Without** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | >> >> >> **With** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | >> >> >> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 >> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when >> running on ARM. > > Hi Andrew, > > The current indexOf char intrinsics for StringUTF16 and the new one here for StringLatin1 both use the AVX2 ? i.e. 256 > bit instructions, these are also affected by the frequency scaling which affects the AVX-512 instructions you pointed > out. Of course in a world where all the work taking place is AVX instructions this wouldn?t be an issue but in mixed > mode execution this is a problem. However, the compiler does have knowledge of the capability of the CPU upon which > it?s optimizing code for and is able to decide whether to use AVX instructions if they are supported by the CPU AND if > it wouldn?t be detrimental for performance. In fact, there is a flag which one can use to interact with > this: -XX:UseAVX=version. This of course made testing this patch an interesting experience as the AVX2 instructions > were not enabled on the Xeon processors which I had access to at AWS, but in the end I was able to use an i7 on my > corporate macbook to validate the code. From: mlbridge[bot] Sent: 11 September 2020 17:01 > To: openjdk/jdk Cc: Tatton, Jason ; Mention > Subject: Re: [openjdk/jdk] 8173585: Intrinsify StringLatin1.indexOf(char) (#71) > > > Mailing list message from Andrew Haley on hotspot-dev: > > On 11/09/2020 11:23, Jason Tatton wrote: > > For the x86 implementation there may be two further improvements we > can make in order to improve performance of both the StringUTF16 and > StringLatin1 indexOf(char) intrinsics: > > 1. Make use of AVX-512 instructions. > > Is this really a good idea? > > When the processor detects Intel AVX instructions, additional > voltage is applied to the core. With the additional voltage applied, > the processor could run hotter, requiring the operating frequency to > be reduced to maintain operations within the TDP limits. The higher > voltage is maintained for 1 millisecond after the last Intel AVX > instruction completes, and then the voltage returns to the nominal > TDP voltage level. > > https://computing.llnl.gov/tutorials/linux_clusters/intelAVXperformanceWhitePaper.pdf > > So, if StringLatin1.indexOf(char) executes enough to make a difference > to any real-world program, the effect may well be to slow down the clock > for all of the code that does not use AVX. > > 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD > instructions instead of a loop. > > -- > 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 > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or > unsubscribe. Hi everyone, This patch is just missing a couple of reviewers... Please can someone step forward? I think it's a fairly straightforward change. -Jason ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From igraves at openjdk.java.net Thu Sep 17 18:40:45 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Thu, 17 Sep 2020 18:40:45 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v7] In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. Ian Graves has updated the pull request incrementally with two additional commits since the last revision: - Changes to test 3 so correct JDK under test is run - Test 3 to non-tmp directory ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/156/files - new: https://git.openjdk.java.net/jdk/pull/156/files/1af70014..188a7b97 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=05-06 Stats: 75 lines in 1 file changed: 41 ins; 30 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/156/head:pull/156 PR: https://git.openjdk.java.net/jdk/pull/156 From igraves at openjdk.java.net Thu Sep 17 19:38:40 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Thu, 17 Sep 2020 19:38:40 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v8] In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Cleanup extraneous directory ops ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/156/files - new: https://git.openjdk.java.net/jdk/pull/156/files/188a7b97..0fc422df Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/156/head:pull/156 PR: https://git.openjdk.java.net/jdk/pull/156 From github.com+10835776+stsypanov at openjdk.java.net Thu Sep 17 21:45:44 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 17 Sep 2020 21:45:44 GMT Subject: RFR: 8251548 Remove unnecessary explicit initialization of volatile variables in security-libs code Message-ID: Hello, is it possible to have a code review for the changes proposed in JDK-8251548 (originally contributed via https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html)? Sean Mullan has created an issue and web-review and can sponsor the patch as soos as it gets properly reviewed. The issue itself is a continuation of changes merged into java.base before as: - https://bugs.openjdk.java.net/browse/JDK-6736490 - https://bugs.openjdk.java.net/browse/JDK-8035284 - https://bugs.openjdk.java.net/browse/JDK-8145680 As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html > there is never any reason to explicitly initialize fields to 0/0.0/false/null so I believe this patch is harmless as well as previous ones. Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ Thanks, Sergey Tsypanov ------------- Commit messages: - 8251548 Remove unnecessary explicit initialization of volatile variables in security-libs code Changes: https://git.openjdk.java.net/jdk/pull/218/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=218&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 Stats: 17 lines in 8 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/218.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/218/head:pull/218 PR: https://git.openjdk.java.net/jdk/pull/218 From naoto at openjdk.java.net Fri Sep 18 01:56:32 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 18 Sep 2020 01:56:32 GMT Subject: RFR: 8253153: Mentioning of "hour-of-minute" in java.time.temporal.TemporalField JavaDoc Message-ID: <4kK021a4Jr7xCNaCWzzSdnTKQISigN0WCqLb8hWF9y4=.ef3cd288-bf9b-4385-863c-0082b542c131@github.com> Hi, Please review this simple doc fix. ------------- Commit messages: - 8253153: Mentioning of "hour-of-minute" in java.time.temporal.TemporalField JavaDoc Changes: https://git.openjdk.java.net/jdk/pull/234/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=234&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253153 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/234.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/234/head:pull/234 PR: https://git.openjdk.java.net/jdk/pull/234 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 joehw at openjdk.java.net Fri Sep 18 05:00:29 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 18 Sep 2020 05:00:29 GMT Subject: RFR: 8253153: Mentioning of "hour-of-minute" in java.time.temporal.TemporalField JavaDoc In-Reply-To: <4kK021a4Jr7xCNaCWzzSdnTKQISigN0WCqLb8hWF9y4=.ef3cd288-bf9b-4385-863c-0082b542c131@github.com> References: <4kK021a4Jr7xCNaCWzzSdnTKQISigN0WCqLb8hWF9y4=.ef3cd288-bf9b-4385-863c-0082b542c131@github.com> Message-ID: On Fri, 18 Sep 2020 01:49:09 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/234 From sergei.tsypanov at yandex.ru Fri Sep 18 07:15:27 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 18 Sep 2020 09:15:27 +0200 Subject: Request for review of JDK-8251548 In-Reply-To: References: <408131600326592@mail.yandex.ru> <125311600334485@mail.yandex.ru> Message-ID: <260361600412955@mail.yandex.ru> Hi, > Did you not follow these instructions to get your github account > connected to your OCA record: Those are for "OpenJDK Author, Committer or Reviewer", but I'm only a contributor, i.e. I cannot file an issue or commit directly. My previous contributions were shipped as *.patch files in mail attachments. Anyway, OCA was approved again and the PR (https://github.com/openjdk/jdk/pull/218) is ready for review :) Cheers, Sergey 17.09.2020, 14:11, "David Holmes" : > On 17/09/2020 7:24 pm, ?????? ??????? wrote: >> ?Hi David, >> >> ?thanks for pointing this out! >> >> ?I've created a PR there [1], but GitHub for some reason wants me to sign OCA, >> ?which I have already signed in 2017. I've redone the procedure and now I'm waiting >> ?for verification. > > Did you not follow these instructions to get your github account > connected to your OCA record: > > "If you already are an OpenJDK Author, Committer or Reviewer, please > click here[1] to open a new issue so that we can record that fact. > Please use "Add GitHub user stsypanov" as summary for the issue." > > [1] > https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1 > > Cheers, > David > ----- > >> ?Regards, >> ?Sergey >> >> ?1. https://github.com/openjdk/jdk/pull/218 >> >> ?17.09.2020, 09:22, "David Holmes" : >>> ?Hi Sergey, >>> >>> ?Since OpenJDK has moved to git/github, this needs to reformulated as a >>> ?Pull Request (PR). >>> >>> ?Cheers, >>> ?David >>> >>> ?On 17/09/2020 5:19 pm, ?????? ??????? wrote: >>>> ???Hello, >>>> >>>> ???is it possible to have a code review for the changes proposed in JDK-8251548? >>>> >>>> ???Sean Mullan has created an issue and web-review and can sponsor the patch >>>> ???as soos as it gets properly reviewed. >>>> >>>> ???As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html >>>> >>>>> ???there is never any reason to explicitly initialize fields to 0/0.0/false/null >>>> >>>> ???so I believe the patch is harmless. >>>> >>>> ???Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 >>>> ???Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ >>>> >>>> ???Thanks, >>>> ???Sergey Tsypanov From prappo at openjdk.java.net Fri Sep 18 08:36:34 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 18 Sep 2020 08:36:34 GMT Subject: RFR: 8253342: Fix typos in String.transform Message-ID: To confirm that this would not require a CSR I asked Joe Darcy. Joe replied that this would NOT require a CSR. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/238/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=238&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253342 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/238.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/238/head:pull/238 PR: https://git.openjdk.java.net/jdk/pull/238 From adinn at redhat.com Fri Sep 18 08:48:42 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 18 Sep 2020 09:48:42 +0100 Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> Message-ID: On 17/09/2020 19:22, Jason Tatton wrote: > This patch is just missing a couple of reviewers... Please can someone step forward? > > I think it's a fairly straightforward change. I believe you got a review from Andrew Haley -- it was quoted in your follow-up from which I selected the above response. What you did not get was license to proceed and push this change. That's because what is actually missing is the justification he asked for. As Andrew pointed out the change is simple but the reason for implementing it is not. 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 shade at openjdk.java.net Fri Sep 18 08:49:56 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 08:49:56 GMT Subject: RFR: 8253342: Fix typos in String.transform In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 08:27:44 GMT, Pavel Rappo wrote: > To confirm that this would not require a CSR I asked Joe Darcy. Joe replied that this would NOT require a CSR. Changes requested by shade (Reviewer). src/java.base/share/classes/java/lang/String.java line 3186: > 3184: * caller. > 3185: * > 3186: * @param f a function to apply Shouldn't this be "_the_ function to apply"? Grep for other instance of "function to apply" in javadocs :) ------------- PR: https://git.openjdk.java.net/jdk/pull/238 From prappo at openjdk.java.net Fri Sep 18 08:56:49 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 18 Sep 2020 08:56:49 GMT Subject: RFR: 8253342: Fix typos in String.transform In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 08:46:45 GMT, Aleksey Shipilev wrote: >> To confirm that this would not require a CSR I asked Joe Darcy. Joe replied that this would NOT require a CSR. > > src/java.base/share/classes/java/lang/String.java line 3186: > >> 3184: * caller. >> 3185: * >> 3186: * @param f a function to apply > > Shouldn't this be "_the_ function to apply"? Grep for other instance of "function to apply" in javadocs :) I grepped that before pushing and the results were inconclusive. For example, compare the below fragments from the same file: /** ... * @param mapper the mapping function to apply to each element ... */ public static Collector summarizingLong(ToLongFunction mapper) /** ... * @param mapper a mapping function to apply to each element ... */ public static Collector summarizingDouble(ToDoubleFunction mapper) ------------- PR: https://git.openjdk.java.net/jdk/pull/238 From shade at openjdk.java.net Fri Sep 18 09:09:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 09:09:10 GMT Subject: RFR: 8253342: Fix typos in String.transform In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 08:27:44 GMT, Pavel Rappo wrote: > To confirm that this would not require a CSR I asked Joe Darcy. Joe replied that this would NOT require a CSR. Changing the review from "Request Changes" to just "Comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/238 From jlaskey at openjdk.java.net Fri Sep 18 09:09:11 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 18 Sep 2020 09:09:11 GMT Subject: RFR: 8253342: Fix typos in String.transform In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 08:27:44 GMT, Pavel Rappo wrote: > To confirm that this would not require a CSR I asked Joe Darcy. Joe replied that this would NOT require a CSR. Marked as reviewed by jlaskey (Reviewer). Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/238 From shade at openjdk.java.net Fri Sep 18 09:09:14 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 09:09:14 GMT Subject: RFR: 8253342: Fix typos in String.transform In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 08:53:34 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/java/lang/String.java line 3186: >> >>> 3184: * caller. >>> 3185: * >>> 3186: * @param f a function to apply >> >> Shouldn't this be "_the_ function to apply"? Grep for other instance of "function to apply" in javadocs :) > > I grepped that before pushing and the results were inconclusive. For example, compare the below fragments from the same > file: > /** > ... > * @param mapper the mapping function to apply to each element > ... > */ > public static > Collector summarizingLong(ToLongFunction mapper) > /** > ... > * @param mapper a mapping function to apply to each element > ... > */ > public static > Collector summarizingDouble(ToDoubleFunction mapper) Hm! Better to defer to native speakers then... ------------- PR: https://git.openjdk.java.net/jdk/pull/238 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 prappo at openjdk.java.net Fri Sep 18 10:48:39 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 18 Sep 2020 10:48:39 GMT Subject: Integrated: 8253342: Fix typos in String.transform In-Reply-To: References: Message-ID: <7A4TXN-_YE4SglJwSKneIKeIwIZon46-3jhpNjF9k34=.62502e90-c65b-4ae9-8c3e-9ef88c7a6b12@github.com> On Fri, 18 Sep 2020 08:27:44 GMT, Pavel Rappo wrote: > To confirm that this would not require a CSR I asked Joe Darcy. Joe replied that this would NOT require a CSR. This pull request has now been integrated. Changeset: 83b2411f Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/83b2411f Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8253342: Fix typos in String.transform Reviewed-by: jlaskey ------------- PR: https://git.openjdk.java.net/jdk/pull/238 From lancea at openjdk.java.net Fri Sep 18 10:51:29 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 18 Sep 2020 10:51:29 GMT Subject: RFR: 8253153: Mentioning of "hour-of-minute" in java.time.temporal.TemporalField JavaDoc In-Reply-To: <4kK021a4Jr7xCNaCWzzSdnTKQISigN0WCqLb8hWF9y4=.ef3cd288-bf9b-4385-863c-0082b542c131@github.com> References: <4kK021a4Jr7xCNaCWzzSdnTKQISigN0WCqLb8hWF9y4=.ef3cd288-bf9b-4385-863c-0082b542c131@github.com> Message-ID: <6qRTwL0bzx4VxJiVwmrWSDXPADkAmyRu9EtPYcHYBtE=.ac08244f-ce3c-4eab-ad0d-3dd0ab26ea90@github.com> On Fri, 18 Sep 2020 01:49:09 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/234 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+70893615+jasontatton-aws at openjdk.java.net Fri Sep 18 11:06:55 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Fri, 18 Sep 2020 11:06:55 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> Message-ID: <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> On Thu, 17 Sep 2020 18:20:08 GMT, Jason Tatton wrote: >> Hi Andrew, >> >> The current indexOf char intrinsics for StringUTF16 and the new one here for StringLatin1 both use the AVX2 ? i.e. 256 >> bit instructions, these are also affected by the frequency scaling which affects the AVX-512 instructions you pointed >> out. Of course in a world where all the work taking place is AVX instructions this wouldn?t be an issue but in mixed >> mode execution this is a problem. However, the compiler does have knowledge of the capability of the CPU upon which >> it?s optimizing code for and is able to decide whether to use AVX instructions if they are supported by the CPU AND if >> it wouldn?t be detrimental for performance. In fact, there is a flag which one can use to interact with >> this: -XX:UseAVX=version. This of course made testing this patch an interesting experience as the AVX2 instructions >> were not enabled on the Xeon processors which I had access to at AWS, but in the end I was able to use an i7 on my >> corporate macbook to validate the code. From: mlbridge[bot] Sent: 11 September 2020 17:01 >> To: openjdk/jdk Cc: Tatton, Jason ; Mention >> Subject: Re: [openjdk/jdk] 8173585: Intrinsify StringLatin1.indexOf(char) (#71) >> >> >> Mailing list message from Andrew Haley on hotspot-dev: >> >> On 11/09/2020 11:23, Jason Tatton wrote: >> >> For the x86 implementation there may be two further improvements we >> can make in order to improve performance of both the StringUTF16 and >> StringLatin1 indexOf(char) intrinsics: >> >> 1. Make use of AVX-512 instructions. >> >> Is this really a good idea? >> >> When the processor detects Intel AVX instructions, additional >> voltage is applied to the core. With the additional voltage applied, >> the processor could run hotter, requiring the operating frequency to >> be reduced to maintain operations within the TDP limits. The higher >> voltage is maintained for 1 millisecond after the last Intel AVX >> instruction completes, and then the voltage returns to the nominal >> TDP voltage level. >> >> https://computing.llnl.gov/tutorials/linux_clusters/intelAVXperformanceWhitePaper.pdf >> >> So, if StringLatin1.indexOf(char) executes enough to make a difference >> to any real-world program, the effect may well be to slow down the clock >> for all of the code that does not use AVX. >> >> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD >> instructions instead of a loop. >> >> -- >> 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 >> >> ? >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub, or >> unsubscribe. > > Hi everyone, > > This patch is just missing a couple of reviewers... Please can someone step forward? > > I think it's a fairly straightforward change. > > -Jason Hi Andrew, Thanks for coming back to me. Looking on the github [PR](https://github.com/openjdk/jdk/pull/71) nobody is tagged as a reviewer for this (perhaps this is a feature which is not being used). > That's > because what is actually missing is the justification he asked for. As > Andrew pointed out the change is simple but the reason for implementing > it is not. There are two separate things here: 1). Justification for the change itself: -The objective and justification for this patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 indexOf(char) for x86 and ARM64. This solves the problem as raised in [JDK-8173585](https://bugs.openjdk.java.net/browse/JDK-8173585), and also on the [mailing list](http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-January/005539.html). 2). Discussion around future enhancements - concerning potential use of AVX-512 instructions and a more optimal implementation for short strings. -These would be separate JBS's I'm not advocating for/against this, they are just ideas separate from this JBS. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 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 github.com+70893615+jasontatton-aws at openjdk.java.net Fri Sep 18 11:56:09 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Fri, 18 Sep 2020 11:56:09 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v2] In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com> > This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for > x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it > I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as > code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and > java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 > > Details of testing: > ============ > I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note > that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the > input String. Hence the test has been designed to cover all these cases. In summary they are: > - A ?short? string of < 16 characters. > - A SIMD String of 16 ? 31 characters. > - A AVX2 SIMD String of 32 characters+. > > Hardware used for testing: > ----------------------------- > > - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). > - AWS Graviton 2 (ARM 64 processor). > > I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. > > Possible future enhancements: > ==================== > For the x86 implementation there may be two further improvements we can make in order to improve performance of both > the StringUTF16 and StringLatin1 indexOf(char) intrinsics: > 1. Make use of AVX-512 instructions. > 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD > instructions instead of a loop. > Benchmark results: > ============ > **Without** the new StringLatin1 indexOf(char) intrinsic: > > | Benchmark | Mode | Cnt | Score | Error | Units | > | ------------- | ------------- |------------- |------------- |------------- |------------- | > | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | > | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | > > > **With** the new StringLatin1 indexOf(char) intrinsic: > > | Benchmark | Mode | Cnt | Score | Error | Units | > | ------------- | ------------- |------------- |------------- |------------- |------------- | > | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | > | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | > > > The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 > indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when > running on ARM. Jason Tatton has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge master - 8173585: further whitespace changes required by jcheck - JDK-8173585 - whitespace changes required by jcheck - JDK-8173585 ------------- Changes: https://git.openjdk.java.net/jdk/pull/71/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=01 Stats: 523 lines in 16 files changed: 506 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/71/head:pull/71 PR: https://git.openjdk.java.net/jdk/pull/71 From adinn at redhat.com Fri Sep 18 12:42:23 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 18 Sep 2020 13:42:23 +0100 Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> Message-ID: On 18/09/2020 12:06, Jason Tatton wrote: > There are two separate things here: > 1). Justification for the change itself: > -The objective and justification for this patch is to bring the performance of StringLatin1 indexOf(char) in > line with StringUTF16 indexOf(char) for x86 and ARM64. This solves the problem as raised in > [JDK-8173585](https://bugs.openjdk.java.net/browse/JDK-8173585), and also on the [mailing > list](http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-January/005539.html). > 2). Discussion around future enhancements - concerning potential use of AVX-512 instructions and a more optimal > implementation for short strings. > -These would be separate JBS's I'm not advocating for/against this, they are just ideas separate from this JBS. I don't agree that these two things are separable. Andrew's point applies to both. In the first case the problem is that the 'evidence' we have does not testify to the possibility Andrew outlines. Both code examples used to justify the idea StringLatin1.indexOf(char) will perform 'better' with an AVX-based intrinsic are micro-benchmarks that do a lot of intensive String manipulation and nothing else i.e. they won't get hit by the possible cost of ramping up power for AVX because they make extensive use of AVX and then stop. That's very unlikely to happen in a real world case. So, the fact that this change removes the disparity seen with these benchmarks is still not evidence for a general improvement. So, I don't (yet) see a reason to make this change and the possibility still stands that adopting this change may end up making most code that uses StringLatin1.indexOf(char) worse. It might be a good idea to consider finding some way to test whether the cost Andrew has highlighted makes a difference before committing this change. I know the same argument might might be raised aginst the existing intrinsics but surely that's an a fortiori argument for not proceeding. 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 aefimov at openjdk.java.net Fri Sep 18 13:05:08 2020 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Fri, 18 Sep 2020 13:05:08 GMT Subject: RFR: 8251188: Update LDAP tests not to use wildcard addresses Message-ID: <-CMY39b696CBNg4cyddo-t2KEl5vfYR8ACeoJA7p13I=.e1b457e5-5bbc-4ae6-a69a-c44916326abe@github.com> Hi, Please help to review [JDK-8251188](https://bugs.openjdk.java.net/browse/JDK-8251188) fix which helps to improve LDAP tests stability. The list of changes: 1. Usages of wildcard address have been replaced with loopback address. This change includes addition of `LDAPTestUtils.initEnv` method that takes LDAP provider URL as a parameter. 2. `DeadServerTimeoutSSLTest.java` was also updated to fix the intermittent failures reported by [JDK-8152654 ](https://bugs.openjdk.java.net/browse/JDK-8152654) and [JDK-8169942](https://bugs.openjdk.java.net/browse/JDK-8169942). Before the fix the failure rate was 1 out of 4 runs. After the fix it was executed 400+ times alongside to other LDAP tests, and showed no failures, and therefore removed from the problem list. Thank you, Aleksei ------------- Commit messages: - 8251188: Update LDAP tests not to use wildcard addresses Changes: https://git.openjdk.java.net/jdk/pull/252/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=252&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251188 Stats: 149 lines in 5 files changed: 76 ins; 28 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/252.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/252/head:pull/252 PR: https://git.openjdk.java.net/jdk/pull/252 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 rriggs at openjdk.java.net Fri Sep 18 14:23:18 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 18 Sep 2020 14:23:18 GMT Subject: RFR: 8253153: Mentioning of "hour-of-minute" in java.time.temporal.TemporalField JavaDoc In-Reply-To: <4kK021a4Jr7xCNaCWzzSdnTKQISigN0WCqLb8hWF9y4=.ef3cd288-bf9b-4385-863c-0082b542c131@github.com> References: <4kK021a4Jr7xCNaCWzzSdnTKQISigN0WCqLb8hWF9y4=.ef3cd288-bf9b-4385-863c-0082b542c131@github.com> Message-ID: On Fri, 18 Sep 2020 01:49:09 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/234 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 naoto at openjdk.java.net Fri Sep 18 15:43:37 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 18 Sep 2020 15:43:37 GMT Subject: Integrated: 8253153: Mentioning of "hour-of-minute" in java.time.temporal.TemporalField JavaDoc In-Reply-To: <4kK021a4Jr7xCNaCWzzSdnTKQISigN0WCqLb8hWF9y4=.ef3cd288-bf9b-4385-863c-0082b542c131@github.com> References: <4kK021a4Jr7xCNaCWzzSdnTKQISigN0WCqLb8hWF9y4=.ef3cd288-bf9b-4385-863c-0082b542c131@github.com> Message-ID: On Fri, 18 Sep 2020 01:49:09 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. This pull request has now been integrated. Changeset: 89044200 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/89044200 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8253153: Mentioning of "hour-of-minute" in java.time.temporal.TemporalField JavaDoc Reviewed-by: joehw, lancea, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/234 From fyang at openjdk.java.net Fri Sep 18 15:54:57 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Fri, 18 Sep 2020 15:54:57 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v2] In-Reply-To: References: Message-ID: > Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make > sure that there's no regression. > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge master - Fix trailing whitespace issue - 8252204: AArch64: Implement SHA3 accelerator/intrinsic Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com ------------- Changes: https://git.openjdk.java.net/jdk/pull/207/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=01 Stats: 1012 lines in 29 files changed: 940 ins; 13 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207 From mullan at openjdk.java.net Fri Sep 18 15:59:13 2020 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 18 Sep 2020 15:59:13 GMT Subject: RFR: 8251548 Remove unnecessary explicit initialization of volatile variables in security-libs code In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 08:09:31 GMT, ?????? ??????? wrote: > Hello, > > is it possible to have a code review for the changes proposed in JDK-8251548 (originally contributed via > https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html)? > Sean Mullan has created an issue and web-review and can sponsor the patch as soos as it gets properly reviewed. > > The issue itself is a continuation of changes merged into java.base before as: > > - https://bugs.openjdk.java.net/browse/JDK-6736490 > - https://bugs.openjdk.java.net/browse/JDK-8035284 > - https://bugs.openjdk.java.net/browse/JDK-8145680 > > As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html > >> there is never any reason to explicitly initialize fields to 0/0.0/false/null > > so I believe this patch is harmless as well as previous ones. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 > Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ > > Thanks, > Sergey Tsypanov Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/218 From github.com+70893615+jasontatton-aws at openjdk.java.net Fri Sep 18 16:00:00 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Fri, 18 Sep 2020 16:00:00 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> Message-ID: <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> On Fri, 18 Sep 2020 11:04:34 GMT, Jason Tatton wrote: >> Hi everyone, >> >> This patch is just missing a couple of reviewers... Please can someone step forward? >> >> I think it's a fairly straightforward change. >> >> -Jason > > Hi Andrew, > > Thanks for coming back to me. Looking on the github [PR](https://github.com/openjdk/jdk/pull/71) nobody is tagged as a > reviewer for this (perhaps this is a feature which is not being used). >> That's >> because what is actually missing is the justification he asked for. As >> Andrew pointed out the change is simple but the reason for implementing >> it is not. > > There are two separate things here: > 1). Justification for the change itself: > -The objective and justification for this patch is to bring the performance of StringLatin1 indexOf(char) in line with > StringUTF16 indexOf(char) for x86 and ARM64. This solves the problem as raised in > [JDK-8173585](https://bugs.openjdk.java.net/browse/JDK-8173585), and also on the [mailing > list](http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-January/005539.html). > > 2). Discussion around future enhancements - concerning potential use of AVX-512 instructions and a more optimal > implementation for short strings. > -These would be separate JBS's I'm not advocating for/against this, they are just ideas separate from this JBS. The AVX2 code path represents approximately 1/6th of the patch (1/7th including the infrastructure ?code around this). I don?t think we should discard the entire patch because 1/6th of the code may have unintended consequences. This is especially the case when the rest of the code has been benchmarked, with certainty, to show the desired performance improvement has been achieved. ? Additionally, I do not see how those unintended consequences will ever be realised because the JVM has knowledge of the AVX capability of the chip it?s running on and disables the AVX2 code path for chips which suffer from the performance degradation which has been outlined in this discussion. Thus protecting us from unintended consequences. Unless we are asserting that this mechanism to globally control the use of AVX2 instructions is broken or otherwise non functional I see no reason to remove the AVX2 code. And to be consistent we would really need to look at removing all instances of AVX2 code in the JVM (of which there is quite a lot). ? As I see it there are three ways forward: 1. Accept the patch as is. 2. Modify the patch to remove the AVX code path for x86, and/or any other modifications needed. 3. Discard the patch entirely. At this point I am in favour of approach 1 but happy to accept 2 if advised that this is the right thing to do. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From fyang at openjdk.java.net Fri Sep 18 16:05:31 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Fri, 18 Sep 2020 16:05:31 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v3] In-Reply-To: References: Message-ID: <0uUIKwe29qJd177yzRttb-vvIkccG_wV5YuEQG4VmNY=.d2b684c1-e098-4384-9ea6-bba1dded72cf@github.com> > Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make > sure that there's no regression. > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Rebase ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/207/files - new: https://git.openjdk.java.net/jdk/pull/207/files/32f0bdc3..3e155193 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=01-02 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207 From adinn at openjdk.java.net Fri Sep 18 16:34:04 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Fri, 18 Sep 2020 16:34:04 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> Message-ID: On Fri, 18 Sep 2020 15:55:52 GMT, Jason Tatton wrote: >> Hi Andrew, >> >> Thanks for coming back to me. Looking on the github [PR](https://github.com/openjdk/jdk/pull/71) nobody is tagged as a >> reviewer for this (perhaps this is a feature which is not being used). >>> That's >>> because what is actually missing is the justification he asked for. As >>> Andrew pointed out the change is simple but the reason for implementing >>> it is not. >> >> There are two separate things here: >> 1). Justification for the change itself: >> -The objective and justification for this patch is to bring the performance of StringLatin1 indexOf(char) in line with >> StringUTF16 indexOf(char) for x86 and ARM64. This solves the problem as raised in >> [JDK-8173585](https://bugs.openjdk.java.net/browse/JDK-8173585), and also on the [mailing >> list](http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-January/005539.html). >> >> 2). Discussion around future enhancements - concerning potential use of AVX-512 instructions and a more optimal >> implementation for short strings. >> -These would be separate JBS's I'm not advocating for/against this, they are just ideas separate from this JBS. > > The AVX2 code path represents approximately 1/6th of the patch (1/7th including the infrastructure ?code around this). > I don?t think we should discard the entire patch because 1/6th of the code may have unintended consequences. This is > especially the case when the rest of the code has been benchmarked, with certainty, to show the desired performance > improvement has been achieved. ? Additionally, I do not see how those unintended consequences will ever be realised > because the JVM has knowledge of the AVX capability of the chip it?s running on and disables the AVX2 code path for > chips which suffer from the performance degradation which has been outlined in this discussion. Thus protecting us from > unintended consequences. Unless we are asserting that this mechanism to globally control the use of AVX2 instructions > is broken or otherwise non functional I see no reason to remove the AVX2 code. And to be consistent we would really > need to look at removing all instances of AVX2 code in the JVM (of which there is quite a lot). ? As I see it there are > three ways forward: 1. Accept the patch as is. 2. Modify the patch to remove the AVX code path for x86, and/or any > other modifications needed. 3. Discard the patch entirely. At this point I am in favour of approach 1 but happy to > accept 2 if advised that this is the right thing to do. "the JVM has knowledge of the AVX capability of the chip it?s running on and disables the AVX2 code path for chips which suffer from the performance degradation which has been outlined in this discussion" Does it? The white paper Andrew cited doesn't mention this as being specific to only some chips that implement AVX2. Can you explain where this restricted effect is documented? Also, I assume you are referring to the code in vm_version_x86.cpp with this comment // Don't use AVX-512 on older Skylakes unless explicitly requested is that correct? ------------- PR: https://git.openjdk.java.net/jdk/pull/71 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 nlisker at gmail.com Wed Sep 16 21:36:58 2020 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 17 Sep 2020 00:36:58 +0300 Subject: 'Find' method for Iterable In-Reply-To: <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr> References: <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr> Message-ID: > > But a Stream cleanly separate the lazy side effect free API from the > mutable one (Collection) and can be optimized better by the VM (it's a push > API instead of being a pull API). No doubt, but a stream also creates overhead and is more cumbersome to use in the example I gave. Of course, I can create a helper static method `find(Collection, Predicate)`, but it's not much cleaner. (And the implementation can still be through Stream or Iterable,). I can ask about Iterable#forEach - is it there only because it was there to begin with? Would it have been a bad idea to add one if we had streams already? The other question is why there is no method find() on Collection, i > believe it's because while find() is ok for any DB API, find() is dangerous > on a Collection because the execution time is linear, so people may use it > instead of using a Map. I don't see a reason to put it Collection when it extends Iterable anyway, and the method just requires iteration. As for execution time, true, it's faster, but Map uses a lot more memory, so it's a tradeoff. For smaller lists, linear time is acceptable. Currently I'm using Maps actually, but I find that when there are many small maps, having many small lists is better for memory and the search time is similar. Additionally, a Map works only for searching by 1 key, but with a Collection/Iterable I can search by any property, and we're not about to use a Map for every property. So, overall, I don't think Map is a competitor in this market. It's also possible to specify that the complexity is linear in an @implNote to avoid surprises. - Nir On Wed, Sep 16, 2020 at 11:59 PM Remi Forax wrote: > ----- Mail original ----- > > De: "Nir Lisker" > > ?: "core-libs-dev" > > Envoy?: Lundi 14 Septembre 2020 20:56:27 > > Objet: 'Find' method for Iterable > > > Hi, > > > > This has probably been brought up at some point. When we need to find an > > item in a collection based on its properties, we can either do it in a > > loop, testing each item, or in a stream with filter and findFirst/Any. > > > > I would think that a method in Iterable be useful, along the lines of: > > > > public Optional find(Predicate condition) { > > Objects.requireNonNull(condition); > > for (T t : this) { > > if (condition.test(t)) { > > return Optional.of(t); > > } > > } > > return Optional.empty(); > > } > > > > With usage: > > > > list.find(person -> person.id == 123456); > > > > There are a few issues with the method here such as t being null in > > null-friendly collections and the lack of bound generic types, but this > > example is just used to explain the intention. > > > > It will be an alternative to > > > > list.stream().filter(person -> person.id == 123456).findAny/First() > > (depending on if the collection is ordered or not) > > > > which doesn't create a stream, similar to Iterable#forEach vs > > Stream#forEach. > > > > Maybe with pattern matching this would become more appetizing. > > During the development of Java 8, we first tried to use Iterator/Iterable > instead of using a novel interface Stream. > But a Stream cleanly separate the lazy side effect free API from the > mutable one (Collection) and can be optimized better by the VM (it's a push > API instead of being a pull API). > > The other question is why there is no method find() on Collection, i > believe it's because while find() is ok for any DB API, find() is dangerous > on a Collection because the execution time is linear, so people may use it > instead of using a Map. > > > > > - Nir > > R?mi > 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 igraves at openjdk.java.net Fri Sep 18 20:40:28 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 18 Sep 2020 20:40:28 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v9] In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Using File.walk for copy ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/156/files - new: https://git.openjdk.java.net/jdk/pull/156/files/0fc422df..92f1d887 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=07-08 Stats: 48 lines in 1 file changed: 10 ins; 28 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/156/head:pull/156 PR: https://git.openjdk.java.net/jdk/pull/156 From github.com+10835776+stsypanov at openjdk.java.net Fri Sep 18 21:29:45 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 18 Sep 2020 21:29:45 GMT Subject: Integrated: 8251548 Remove unnecessary explicit initialization of volatile variables in security-libs code In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 08:09:31 GMT, ?????? ??????? wrote: > Hello, > > is it possible to have a code review for the changes proposed in JDK-8251548 (originally contributed via > https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html)? > Sean Mullan has created an issue and web-review and can sponsor the patch as soos as it gets properly reviewed. > > The issue itself is a continuation of changes merged into java.base before as: > > - https://bugs.openjdk.java.net/browse/JDK-6736490 > - https://bugs.openjdk.java.net/browse/JDK-8035284 > - https://bugs.openjdk.java.net/browse/JDK-8145680 > > As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html > >> there is never any reason to explicitly initialize fields to 0/0.0/false/null > > so I believe this patch is harmless as well as previous ones. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 > Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ > > Thanks, > Sergey Tsypanov This pull request has now been integrated. Changeset: f55dd9d4 Author: Sergey Tsypanov Committer: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/f55dd9d4 Stats: 17 lines in 8 files changed: 0 ins; 0 del; 17 mod 8251548: Remove unnecessary explicit initialization of volatile variables in security-libs code Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/218 From github.com+70893615+jasontatton-aws at openjdk.java.net Fri Sep 18 23:14:30 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Fri, 18 Sep 2020 23:14:30 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> Message-ID: On Fri, 18 Sep 2020 16:31:23 GMT, Andrew Dinn wrote: > Can you explain where this restricted effect is documented? Certainly! I?ve found that determining the capability of the CPU and whether to enable AVX2 support if the chip supports it is mostly controlled in: [vm_version_x86.cpp]( https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp) specifically: [get_processor_features](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L684-L755) and in [generate_get_cpu_info]( https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L69-L611). In order to test the patch comprehensively I had to track down an Intel Core i7 (I7-9750H) processor which the aforementioned code permitted AVX2 instructions for (maybe this is an error and it should not be enabled for this processor though) as most of the infrastructure I personally use here at AWS runs on Intel Xeon processors - I also tested on a E5-2680 which the JVM does not enable AVX2 for. However, this is just the Intel side of things. When it comes to AMD I read that the AMD Zen 2 architecture, of which the current flagship: Threadripper 3990X, is based, is able to support AVX2 [without the frequency scaling]( https://www.anandtech.com/Show/Index/14525?cPage=7&all=False&sort=0&page=9&slug=amd-zen-2-microarchitecture-analysis-ryzen-3000-and-epyc-rome) which some/all(?) of the Intel chips incur. I personally don?t have access to one of these chips so I cannot confirm how it is classified in the JVM. Also, I found when investigating this that there is actually a JVM flag which can be used to control what level of AVX is enabled: `-XX:UseAVX=version.` ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From naoto at openjdk.java.net Fri Sep 18 23:33:08 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 18 Sep 2020 23:33:08 GMT Subject: RFR: 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode Message-ID: <2-y_g5PvWat4frQ_-6XHFSx2QcZvQns4YzwInyhTemU=.ad69a573-0209-4c9e-b747-60590e3cf798@github.com> Hi, Please review the fix to JDK-8253321. As in the issue, uninitialized (cached) hash code was incorrectly referenced in equals() method. Removing it will correct the problem. Also, unrelated to the issue, I fixed a parameter description in a private method. Naoto ------------- Commit messages: - fixed noeol - Merge branch 'master' into JDK-8253321 - added test case - Merge branch 'master' into JDK-8253321 - 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode Changes: https://git.openjdk.java.net/jdk/pull/260/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=260&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253321 Stats: 51 lines in 2 files changed: 48 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/260.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/260/head:pull/260 PR: https://git.openjdk.java.net/jdk/pull/260 From minqi at openjdk.java.net Fri Sep 18 23:54:11 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 18 Sep 2020 23:54:11 GMT Subject: RFR: 8253208: Move CDS related code to a separate class 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 ------------- Commit messages: - 8253208: Move CDS related code to a separate class - Merge branch 'master' of https://github.com/yminqi/jdk into jdk-8253208 - 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/261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253208 Stats: 196 lines in 20 files changed: 110 ins; 53 del; 33 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 joehw at openjdk.java.net Sat Sep 19 01:14:38 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Sat, 19 Sep 2020 01:14:38 GMT Subject: RFR: 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode In-Reply-To: <2-y_g5PvWat4frQ_-6XHFSx2QcZvQns4YzwInyhTemU=.ad69a573-0209-4c9e-b747-60590e3cf798@github.com> References: <2-y_g5PvWat4frQ_-6XHFSx2QcZvQns4YzwInyhTemU=.ad69a573-0209-4c9e-b747-60590e3cf798@github.com> Message-ID: On Fri, 18 Sep 2020 23:26:39 GMT, Naoto Sato wrote: > Hi, > > Please review the fix to JDK-8253321. As in the issue, uninitialized (cached) hash code was incorrectly referenced in > equals() method. Removing it will correct the problem. Also, unrelated to the issue, I fixed a parameter description in > a private method. Naoto test/jdk/java/util/Locale/LanguageRangeTest.java line 27: > 25: * @bug 8253321 > 26: * @summary test LanguageRange class > 27: * @run testng/othervm LanguageRangeTest Is it necessary to run in othervm? ------------- PR: https://git.openjdk.java.net/jdk/pull/260 From joehw at openjdk.java.net Sat Sep 19 01:21:31 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Sat, 19 Sep 2020 01:21:31 GMT Subject: RFR: 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode In-Reply-To: <2-y_g5PvWat4frQ_-6XHFSx2QcZvQns4YzwInyhTemU=.ad69a573-0209-4c9e-b747-60590e3cf798@github.com> References: <2-y_g5PvWat4frQ_-6XHFSx2QcZvQns4YzwInyhTemU=.ad69a573-0209-4c9e-b747-60590e3cf798@github.com> Message-ID: <1MG0zbbwZ3usNHHZoUVOGfKWdL2-MZ1vdxKlbUrWjQ0=.6e53e445-8a7a-4ee2-b25b-9b71b14c46dd@github.com> On Fri, 18 Sep 2020 23:26:39 GMT, Naoto Sato wrote: > Hi, > > Please review the fix to JDK-8253321. As in the issue, uninitialized (cached) hash code was incorrectly referenced in > equals() method. Removing it will correct the problem. Also, unrelated to the issue, I fixed a parameter description in > a private method. Naoto Marked as reviewed by joehw (Reviewer). Also, copyright year may need to be updated to 2020 for Locale.java. ------------- PR: https://git.openjdk.java.net/jdk/pull/260 From naoto at openjdk.java.net Sat Sep 19 01:36:38 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 19 Sep 2020 01:36:38 GMT Subject: RFR: 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode [v2] In-Reply-To: <2-y_g5PvWat4frQ_-6XHFSx2QcZvQns4YzwInyhTemU=.ad69a573-0209-4c9e-b747-60590e3cf798@github.com> References: <2-y_g5PvWat4frQ_-6XHFSx2QcZvQns4YzwInyhTemU=.ad69a573-0209-4c9e-b747-60590e3cf798@github.com> Message-ID: > Hi, > > Please review the fix to JDK-8253321. As in the issue, uninitialized (cached) hash code was incorrectly referenced in > equals() method. Removing it will correct the problem. Also, unrelated to the issue, I fixed a parameter description in > a private method. Naoto Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addressing Joe's comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/260/files - new: https://git.openjdk.java.net/jdk/pull/260/files/cb594a5e..0bbf58da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=260&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=260&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/260.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/260/head:pull/260 PR: https://git.openjdk.java.net/jdk/pull/260 From naoto at openjdk.java.net Sat Sep 19 01:36:38 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 19 Sep 2020 01:36:38 GMT Subject: RFR: 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode [v2] In-Reply-To: <1MG0zbbwZ3usNHHZoUVOGfKWdL2-MZ1vdxKlbUrWjQ0=.6e53e445-8a7a-4ee2-b25b-9b71b14c46dd@github.com> References: <2-y_g5PvWat4frQ_-6XHFSx2QcZvQns4YzwInyhTemU=.ad69a573-0209-4c9e-b747-60590e3cf798@github.com> <1MG0zbbwZ3usNHHZoUVOGfKWdL2-MZ1vdxKlbUrWjQ0=.6e53e445-8a7a-4ee2-b25b-9b71b14c46dd@github.com> Message-ID: On Sat, 19 Sep 2020 01:19:04 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing Joe's comments > > Marked as reviewed by joehw (Reviewer). > Also, copyright year may need to be updated to 2020 for Locale.java. Thanks, Joe. Updated. > test/jdk/java/util/Locale/LanguageRangeTest.java line 27: > >> 25: * @bug 8253321 >> 26: * @summary test LanguageRange class >> 27: * @run testng/othervm LanguageRangeTest > > Is it necessary to run in othervm? Removed "othervm" ------------- PR: https://git.openjdk.java.net/jdk/pull/260 From almatvee at openjdk.java.net Sat Sep 19 02:49:35 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 19 Sep 2020 02:49:35 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests Message-ID: https://bugs.openjdk.java.net/browse/JDK-8231591 - Added MultiLauncherTwoPhaseTest which uses predefine app image with multiple launcher and tests to make sure installer will create shortcuts for all launchers. - Fixed Linux DesktopIntegration to create shortcuts for additional launcher if we using pre-define app image. ------------- Commit messages: - 8231591: [TESTBUG] Create additional two phase jpackage tests Changes: https://git.openjdk.java.net/jdk/pull/263/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=263&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231591 Stats: 173 lines in 5 files changed: 164 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/263.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/263/head:pull/263 PR: https://git.openjdk.java.net/jdk/pull/263 From joehw at openjdk.java.net Sat Sep 19 03:46:13 2020 From: joehw at openjdk.java.net (Joe Wang) Date: Sat, 19 Sep 2020 03:46:13 GMT Subject: RFR: 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode [v2] In-Reply-To: References: <2-y_g5PvWat4frQ_-6XHFSx2QcZvQns4YzwInyhTemU=.ad69a573-0209-4c9e-b747-60590e3cf798@github.com> Message-ID: On Sat, 19 Sep 2020 01:36:38 GMT, Naoto Sato wrote: >> Hi, >> >> Please review the fix to JDK-8253321. As in the issue, uninitialized (cached) hash code was incorrectly referenced in >> equals() method. Removing it will correct the problem. Also, unrelated to the issue, I fixed a parameter description in >> a private method. Naoto > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Addressing Joe's comments Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/260 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 rriggs at openjdk.java.net Sat Sep 19 14:15:29 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sat, 19 Sep 2020 14:15:29 GMT Subject: RFR: 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode [v2] In-Reply-To: References: <2-y_g5PvWat4frQ_-6XHFSx2QcZvQns4YzwInyhTemU=.ad69a573-0209-4c9e-b747-60590e3cf798@github.com> Message-ID: <9u8Osix3B5HCH7uNSfyHJidACv1HDvtkXAR65a5BXH4=.b245a107-5ed9-41af-9937-7c37b6d2a72e@github.com> On Sat, 19 Sep 2020 01:36:38 GMT, Naoto Sato wrote: >> Hi, >> >> Please review the fix to JDK-8253321. As in the issue, uninitialized (cached) hash code was incorrectly referenced in >> equals() method. Removing it will correct the problem. Also, unrelated to the issue, I fixed a parameter description in >> a private method. Naoto > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Addressing Joe's comments Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/260 From vsharma at openjdk.java.net Sat Sep 19 14:47:55 2020 From: vsharma at openjdk.java.net (Vipin Sharma) Date: Sat, 19 Sep 2020 14:47:55 GMT Subject: RFR: 8252537: Updated @exception with @throws [v2] In-Reply-To: References: Message-ID: > Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. > > Open Subtasks part of this fix are: > 1. JDK-8252537 > 2. JDK-8252539 > 3. JDK-8252540 > 4. JDK-8252541 > > Previous conversation on this: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html Vipin Sharma 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: - JDK-8252537 Updated @exception with @throws - JDK-8252537 Updated @exception with @throws - JDK-8252537 Updated @exception with @throws ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/95/files - new: https://git.openjdk.java.net/jdk/pull/95/files/a84158ac..e9953466 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=95&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=95&range=00-01 Stats: 20314 lines in 606 files changed: 10333 ins; 7230 del; 2751 mod Patch: https://git.openjdk.java.net/jdk/pull/95.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/95/head:pull/95 PR: https://git.openjdk.java.net/jdk/pull/95 From vsharma at openjdk.java.net Sat Sep 19 14:58:03 2020 From: vsharma at openjdk.java.net (Vipin Sharma) Date: Sat, 19 Sep 2020 14:58:03 GMT Subject: RFR: 8252537: Updated @exception with @throws [v2] In-Reply-To: References: Message-ID: <4hYsVn15RmDUAXFMhQXSTt9hgBjr4MkUJRhbNgFIO90=.89b73486-4ee6-41e0-8dc3-c1da78221d38@github.com> On Tue, 15 Sep 2020 19:19:07 GMT, Roger Riggs wrote: >> @RogerRiggs I understand your point and will update PR with correct indentation. >> But I think adding 3 spaces after throws may not be right for all cases. >> For example when >> 1. Another tag in same method is using only 1 space. >> 2. In some cases (e.g. free method of Blob.java) we had a mix of throws and exception in the same method both with one >> space after. Here after adding 3 spaces throws tags will have the different number of spaces and indentation will not >> be same as before. I will update PR to make sure the indentation looks same as before and there is no change in >> javadoc. Please tell me in case my understnding is not correct here. > > HI Vipin, > > Correct, a better description is "fix the indentation". > I mnetioned 3 because that was the difference in length between > "exception" and "throws". > > Thanks for the followup, Roger > > > > On 9/15/20 3:14 PM, Vipin Sharma wrote: >> >> @RogerRiggs >> >> I understand your point and will update PR with correct indentation. >> But I think adding 3 spaces after throws may not be right for all cases. >> For example when >> >> 1. Another tag in same method is using only 1 space. >> 2. In some cases (e.g. free method of Blob.java) we had a mix of >> throws and exception in the same method both with one space after. >> Here after adding 3 spaces throws tags will have the different >> number of spaces and indentation will not be same as before. >> >> I will update PR to make sure the indentation looks same as before and >> there is no change in javadoc. >> Please tell me in case my understnding is not correct here. >> >> ? >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> , >> or unsubscribe >> . >> There was something wrong with the way I updated this PR, please ignore this. I will try to correct this or will close this PR and create a new one. ------------- PR: https://git.openjdk.java.net/jdk/pull/95 From alanb at openjdk.java.net Sat Sep 19 15:54:25 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 19 Sep 2020 15:54:25 GMT Subject: RFR: 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 src/java.base/share/classes/jdk/internal/misc/CDS.java line 42: > 40: public static native void defineArchivedModules(ClassLoader platformLoader, ClassLoader systemLoader); > 41: > 42: public static native long getRandomSeedForCDSDump(); The moving of the archive methods to CDS looks okay but inconsistent to only comment 3 of the 5 methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From alanb at openjdk.java.net Sat Sep 19 16:06:53 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 19 Sep 2020 16:06:53 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v9] In-Reply-To: References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Fri, 18 Sep 2020 20:40:28 GMT, Ian Graves wrote: >> Related to [JDK-8252730 jlink does not create reproducible builds on different >> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to >> ensure stable files (and file signatures) across generated JDK images by jlink. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Using File.walk for copy test/jdk/tools/jlink/JLinkReproducible3Test.java line 112: > 110: } > 111: } > 112: The update to ImageFileCreator looks good. A few nits in JLinkReproducible3Test: 1. Invoking copyJDKs with two destination locations looks a bit strange. I think would be easier for future maintainers if it does one copy and is called twice. 2. Files.copy will create a directory, no need for Files.createDirectories. 3. Are you sure that bin/jlink is executable, I just wonder if the test runs with the patch have ended up depending the umask at the time. It is possible to specify COPY_ATTRIBUTES to the copy method and it will attempt to copy the permissions. 4. The variable naming is more like C style, so a bit inconsistent with the naming usually used in Java programs. ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From vsharma at openjdk.java.net Sat Sep 19 20:24:14 2020 From: vsharma at openjdk.java.net (Vipin Sharma) Date: Sat, 19 Sep 2020 20:24:14 GMT Subject: RFR: 8252537: Updated @exception with @throws [v3] In-Reply-To: References: Message-ID: > Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. > > Open Subtasks part of this fix are: > 1. JDK-8252537 > 2. JDK-8252539 > 3. JDK-8252540 > 4. JDK-8252541 > > Previous conversation on this: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html Vipin Sharma has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: JDK-8252537 Updated @exception with @throws, implemented review comments ------------- Changes: https://git.openjdk.java.net/jdk/pull/95/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=95&range=02 Stats: 1690 lines in 86 files changed: 0 ins; 0 del; 1690 mod Patch: https://git.openjdk.java.net/jdk/pull/95.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/95/head:pull/95 PR: https://git.openjdk.java.net/jdk/pull/95 From nlisker at gmail.com Sat Sep 19 22:27:57 2020 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 20 Sep 2020 01:27:57 +0300 Subject: 'Find' method for Iterable In-Reply-To: References: <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr> Message-ID: > > While it might not be difficult to add a find() method to Iterable, why > limit it to > the find operation, and what about all the other operations available on > Stream? Good question. I would say it's a matter of how much it is used and what it takes to implement it. The find operation is a lot more common than reduce from what I observe, for example, so I wouldn't suggest reduce to be added..A map(Function) operation would require creating a new collection/iterable internally, and that can be messy (you could preemptively create and pass your own, but then I doubt the worthiness of it). forEach already exists. I just don't see anything enticing. Maybe what's necessary is a way to convert an Iterable to a Stream. Most Iterables are Collections and arrays, and these are easy to convert, so I'm not sure if that really helps. Besides,the idea is to avoid Stream, as I've mentioned, due to the cumbersomeness and the overhead of creating a stream. If I need to do iterable.stream().filter(person -> person.id == 123456).findAny/First() then I didn't really solve my problem. On the other hand, your examples use a list. The List interface already has > methods > indexOf/lastIndexOf which search the list for a particular object that's > compared > using equals(). It seems reasonable to consider similar methods that take a > predicate instead of an object. I could have used a Set just as well. As for indexOf(Predicate), I would say that it is useful (but personally, I hardly ever need the index of an object, I need the object itself). Interestingly, removeIf(Predicate) exists, but remove(Predicate) doesn't. I would think twice before suggesting to add it though. Ultimately, you have access to a lot of analytics and codebase scans. If you know which patterns are used a lot more than others it would be a good guide. If there are a lot of iterations in order to find an object, its index, or to remove it (or something else), perhaps it's worth supplying these methods. After all, forEach(Consumer) exists and it iterates while calling accept(t) - not that different from iterating with test(t). P.S. lastIndexOf I find odd in the sense that it's the only method I found that iterates backwards, We don't have, removeLast, removeIfBackwards, forEachBackwards, a backwards for-each loop, or addLast (the latter is add(list.size()-1, e); ). - Nir On Thu, Sep 17, 2020 at 1:32 AM Stuart Marks wrote: > > > On 9/16/20 1:59 PM, Remi Forax wrote: > > ----- Mail original ----- > >> De: "Nir Lisker" > >> ?: "core-libs-dev" > >> Envoy?: Lundi 14 Septembre 2020 20:56:27 > >> Objet: 'Find' method for Iterable > > > >> Hi, > >> > >> This has probably been brought up at some point. When we need to find an > >> item in a collection based on its properties, we can either do it in a > >> loop, testing each item, or in a stream with filter and findFirst/Any. > >> > >> I would think that a method in Iterable be useful, along the lines > of: > >> > >> public Optional find(Predicate condition) { > >> Objects.requireNonNull(condition); > >> for (T t : this) { > >> if (condition.test(t)) { > >> return Optional.of(t); > >> } > >> } > >> return Optional.empty(); > >> } > >> > >> With usage: > >> > >> list.find(person -> person.id == 123456); > >> > >> There are a few issues with the method here such as t being null in > >> null-friendly collections and the lack of bound generic types, but this > >> example is just used to explain the intention. > >> > >> It will be an alternative to > >> > >> list.stream().filter(person -> person.id == 123456).findAny/First() > >> (depending on if the collection is ordered or not) > >> > >> which doesn't create a stream, similar to Iterable#forEach vs > >> Stream#forEach. > >> > >> Maybe with pattern matching this would become more appetizing. > > > > During the development of Java 8, we first tried to use > Iterator/Iterable instead of using a novel interface Stream. > > But a Stream cleanly separate the lazy side effect free API from the > mutable one (Collection) and can be optimized better by the VM (it's a push > API instead of being a pull API). > > > > The other question is why there is no method find() on Collection, i > believe it's because while find() is ok for any DB API, find() is dangerous > on a Collection because the execution time is linear, so people may use it > instead of using a Map. > > > Hi Nir, > > R?mi is correct to point out this distinction between the lazy operations > (which > appear on Stream) and the eager (and possibly mutating) operations on > Collections. I > think we want to preserve this distinction. > > While it might not be difficult to add a find() method to Iterable, why > limit it to > the find operation, and what about all the other operations available on > Stream? > Maybe what's necessary is a way to convert an Iterable to a Stream. In > fact, this is > already possible: > > StreamSupport.stream(iterable.spliterator(), false) > > Well, this is mouthful, so maybe there ought to be an easier way to > convert an > Iterable to a Stream. > > On the other hand, your examples use a list. The List interface already > has methods > indexOf/lastIndexOf which search the list for a particular object that's > compared > using equals(). It seems reasonable to consider similar methods that take > a > predicate instead of an object. > > Does either of these sound promising? > > s'marks > From iklam at openjdk.java.net Sun Sep 20 06:13:47 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Sun, 20 Sep 2020 06:13:47 GMT Subject: RFR: 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 src/java.base/share/classes/jdk/internal/misc/CDS.java line 52: > 50: * Check if CDS sharing is enabled by via the UseSharedSpaces flag. > 51: */ > 52: public static native boolean isCDSSharingEnabled(); I think the word CDS is redundant in the method names. How about getRandomSeedForCDSDump() -> getRandomSeedForDumping() isCDSDumpingEnabled() -> isDynamicDumpingEnabled() // doesn't return true if we're doing a static dump isCDSSharingEnabled() -> isSharingEnabled() 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) ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From fyang at openjdk.java.net Sun Sep 20 13:53:00 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Sun, 20 Sep 2020 13:53:00 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v4] In-Reply-To: References: Message-ID: > Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make > sure that there's no regression. > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/207/files - new: https://git.openjdk.java.net/jdk/pull/207/files/3e155193..04bdb42e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=02-03 Stats: 474 lines in 2 files changed: 61 ins; 9 del; 404 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207 From rriggs at openjdk.java.net Sun Sep 20 14:01:41 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sun, 20 Sep 2020 14:01:41 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter Message-ID: # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter Debugging functions that utilize ASN.1, DER, and BER encoded streams is difficult without test utilities to show the contents. The ASN.1 formatter reads a stream and produces annotated output of the tags, values, and structures. When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized with the hex formatted output. Small changes to HexPrinter are included to improve the output readability. Example decoding of a .pem certificate: SEQUENCE [910] SEQUENCE [630] CONTEXT cons 0 [3] BYTE 2, BYTE 3, SEQUENCE [13] OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) NULL SEQUENCE [76] SET [11] SEQUENCE [9] OBJECT ID [3] 2.5.4.6 (CountryName) 'IN' ... SET [16] SEQUENCE [14] OBJECT ID [3] 2.5.4.3 (CommonName) Client1 SEQUENCE [30] UTCTIME [13] '150526221718Z' UTCTIME [13] '250523221718Z' ... SEQUENCE [290] SEQUENCE [13] OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) NULL BIT STRING [271] CONTEXT cons 3 [123] SEQUENCE [121] SEQUENCE [9] OBJECT ID [3] 2.5.29.19 (BasicConstraints) OCTET STRING [2] SEQUENCE [44] OBJECT ID [9] 2.16.840.1.113730.1.13 OCTET STRING [31] '..OpenSSL Generated Certificate' SEQUENCE [29] OBJECT ID [3] 2.5.29.14 (SubjectKeyID) OCTET STRING [22] SEQUENCE [31] OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) OCTET STRING [24] SEQUENCE [13] OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) NULL BIT STRING [257] When used with the HexPrinter test utility, the formatting of the hexadecimal values is selected with the parameters to HexPrinter. 0000: 30 82 03 8e ; SEQUENCE [910] 0004: 30 82 02 76 ; SEQUENCE [630] 0008: a0 03 ; CONTEXT cons 0 [3] 000a: 02 01 02 ; BYTE 2, 000d: 02 01 03 ; BYTE 3, 0010: 30 0d ; SEQUENCE [13] 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) 001d: 05 00 ; NULL 001f: 30 ; SEQUENCE [76] 0020: 4c ; 0021: 31 0b ; SET [11] 0023: 30 09 ; SEQUENCE [9] 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) 002a: 13 02 49 4e ; 'IN' ... ... 005b: 31 10 ; SET [16] 005d: 30 0e ; SEQUENCE [14] 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) 0060: 03 55 04 03 ; 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 006d: 30 1e ; SEQUENCE [30] 006f: 17 ; UTCTIME [13] '150526221718Z' 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; 007e: 17 0d ; UTCTIME [13] '250523221718Z' 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; ... ... 00db: 30 82 01 22 ; SEQUENCE [290] 00df: 30 ; SEQUENCE [13] 00e0: 0d ; 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) 00ec: 05 00 ; NULL 00ee: 03 82 ; BIT STRING [271] 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; ... 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; 0200: 01 ; 0201: a3 7b ; CONTEXT cons 3 [123] 0203: 30 79 ; SEQUENCE [121] 0205: 30 09 ; SEQUENCE [9] 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) 020c: 04 02 30 00 ; OCTET STRING [2] 0210: 30 2c ; SEQUENCE [44] 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; 023e: 30 1d ; SEQUENCE [29] 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; 025d: 30 1f ; SEQUENCE [31] 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) 0260: 03 55 1d 23 ; 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; 027e: 30 0d ; SEQUENCE [13] 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) 028b: 05 00 ; NULL 028d: 03 82 01 ; BIT STRING [257] 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; ... 0390: 6d 94 ; ------------- Commit messages: - Add ASN1 Formatter to work with HexPrinter Changes: https://git.openjdk.java.net/jdk/pull/268/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252523 Stats: 737 lines in 5 files changed: 727 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/268/head:pull/268 PR: https://git.openjdk.java.net/jdk/pull/268 From rriggs at openjdk.java.net Sun Sep 20 14:14:51 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sun, 20 Sep 2020 14:14:51 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: > # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1 formatter reads a stream and produces annotated output of the > tags, values, and structures. > When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized > with the hex formatted output. > > Small changes to HexPrinter are included to improve the output readability. > > > Example decoding of a .pem certificate: > SEQUENCE [910] > SEQUENCE [630] > CONTEXT cons 0 [3] > BYTE 2, > BYTE 3, > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > SEQUENCE [76] > SET [11] > SEQUENCE [9] > OBJECT ID [3] 2.5.4.6 (CountryName) > 'IN' > ... > SET [16] > SEQUENCE [14] > OBJECT ID [3] 2.5.4.3 (CommonName) > Client1 > SEQUENCE [30] > UTCTIME [13] '150526221718Z' > UTCTIME [13] '250523221718Z' > ... > SEQUENCE [290] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > NULL > BIT STRING [271] > CONTEXT cons 3 [123] > SEQUENCE [121] > SEQUENCE [9] > OBJECT ID [3] 2.5.29.19 (BasicConstraints) > OCTET STRING [2] > SEQUENCE [44] > OBJECT ID [9] 2.16.840.1.113730.1.13 > OCTET STRING [31] '..OpenSSL Generated Certificate' > SEQUENCE [29] > OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > OCTET STRING [22] > SEQUENCE [31] > OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > OCTET STRING [24] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > BIT STRING [257] > When used with the HexPrinter test utility, the formatting of the > hexadecimal values is selected with the parameters to HexPrinter. > > 0000: 30 82 03 8e ; SEQUENCE [910] > 0004: 30 82 02 76 ; SEQUENCE [630] > 0008: a0 03 ; CONTEXT cons 0 [3] > 000a: 02 01 02 ; BYTE 2, > 000d: 02 01 03 ; BYTE 3, > 0010: 30 0d ; SEQUENCE [13] > 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 001d: 05 00 ; NULL > 001f: 30 ; SEQUENCE [76] > 0020: 4c ; > 0021: 31 0b ; SET [11] > 0023: 30 09 ; SEQUENCE [9] > 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) > 002a: 13 02 49 4e ; 'IN' > > ... ... > > 005b: 31 10 ; SET [16] > 005d: 30 0e ; SEQUENCE [14] > 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) > 0060: 03 55 04 03 ; > 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 > 006d: 30 1e ; SEQUENCE [30] > 006f: 17 ; UTCTIME [13] '150526221718Z' > 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; > 007e: 17 0d ; UTCTIME [13] '250523221718Z' > 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; > > ... ... > > 00db: 30 82 01 22 ; SEQUENCE [290] > 00df: 30 ; SEQUENCE [13] > 00e0: 0d ; > 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > 00ec: 05 00 ; NULL > 00ee: 03 82 ; BIT STRING [271] > 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; > > ... > > 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; > 0200: 01 ; > 0201: a3 7b ; CONTEXT cons 3 [123] > 0203: 30 79 ; SEQUENCE [121] > 0205: 30 09 ; SEQUENCE [9] > 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) > 020c: 04 02 30 00 ; OCTET STRING [2] > 0210: 30 2c ; SEQUENCE [44] > 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 > 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated > Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; > 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; > 023e: 30 1d ; SEQUENCE [29] > 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] > 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; > 025d: 30 1f ; SEQUENCE [31] > 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > 0260: 03 55 1d 23 ; > 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] > 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ; NULL > 028d: 03 82 01 ; BIT STRING [257] > 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; > > ... > > 0390: 6d 94 ; Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Small cleanups to javadoc and code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/268/files - new: https://git.openjdk.java.net/jdk/pull/268/files/67df141f..915dfe7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=00-01 Stats: 31 lines in 2 files changed: 12 ins; 5 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/268/head:pull/268 PR: https://git.openjdk.java.net/jdk/pull/268 From lancea at openjdk.java.net Sun Sep 20 18:14:59 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 20 Sep 2020 18:14:59 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary Message-ID: Hi all, Please review the fix for JDK-8252739 which addresses an issue introduced by https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by Deflater.setDictionary. Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and java/util/jar JCK tests. ------------- Commit messages: - Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary Changes: https://git.openjdk.java.net/jdk/pull/269/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=269&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252739 Stats: 186 lines in 2 files changed: 185 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/269.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/269/head:pull/269 PR: https://git.openjdk.java.net/jdk/pull/269 From uschindler at apache.org Sun Sep 20 18:31:10 2020 From: uschindler at apache.org (Uwe Schindler) Date: Sun, 20 Sep 2020 18:31:10 +0000 Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary In-Reply-To: References: Message-ID: Hi, I left some comments on the PR. The tests with ByteBuffers are not testing the bug correctly. Uwe Am September 20, 2020 6:14:59 PM UTC schrieb Lance Andersen : >Hi all, > >Please review the fix for JDK-8252739 which addresses an issue >introduced by >https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c >ignored the offset specified by >Deflater.setDictionary. > >Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the >java/util/zip and java/util/jar JCK tests. > >------------- > >Commit messages: >- Deflater.setDictionary(byte[], int off, int len) ignores the starting >offset for the dictionary > >Changes: https://git.openjdk.java.net/jdk/pull/269/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=269&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8252739 > Stats: 186 lines in 2 files changed: 185 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jdk/pull/269.diff >Fetch: git fetch https://git.openjdk.java.net/jdk >pull/269/head:pull/269 > >PR: https://git.openjdk.java.net/jdk/pull/269 From github.com+1005388+uschindler at openjdk.java.net Sun Sep 20 18:32:17 2020 From: github.com+1005388+uschindler at openjdk.java.net (Uwe Schindler) Date: Sun, 20 Sep 2020 18:32:17 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary In-Reply-To: References: Message-ID: On Sun, 20 Sep 2020 18:03:02 GMT, Lance Andersen wrote: > Hi all, > > Please review the fix for JDK-8252739 which addresses an issue introduced by > https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by > Deflater.setDictionary. Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and > java/util/jar JCK tests. The tests with byte buffers (direct and heap) are not using offsets (arrayOffset=0). The direct buffer test uses just a series of 0-bytes, so incorrect offsets won't change result. There should be real data copied into the direct buffer. test/jdk/java/util/zip/DeflaterDictionaryTests.java line 105: > 103: byte[] output = new byte[RESULT_SIZE]; > 104: // Compress the bytes > 105: ByteBuffer dictDef = ByteBuffer.wrap(DICTIONARY.getBytes(UTF_8)); This should use a slice of the byte buffer, so array offset is not 0. This can be done with offset and size on the wrap() call. test/jdk/java/util/zip/DeflaterDictionaryTests.java line 150: > 148: byte[] output = new byte[RESULT_SIZE]; > 149: // Compress the bytes > 150: ByteBuffer dictDef = ByteBuffer.allocateDirect(DICTIONARY.length()); This creates an empty dictionary with only 0 bytes. Maybe copy some real data into the buffer. Also a slice should be used. ------------- Changes requested by uschindler at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/269 From lancea at openjdk.java.net Sun Sep 20 20:42:34 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 20 Sep 2020 20:42:34 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v2] In-Reply-To: References: Message-ID: <585GLQ6OZPyvvc-Rj-ZeyrToGkHrf7-pZzNfinKMS5g=.5a0ecd24-f334-4d8b-bed6-b53b6df9ebb3@github.com> > Hi all, > > Please review the fix for JDK-8252739 which addresses an issue introduced by > https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by > Deflater.setDictionary. Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and > java/util/jar JCK tests. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Additional updates to DeflaterDictionaryTests.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/269/files - new: https://git.openjdk.java.net/jdk/pull/269/files/7f3fd5dc..eaf0be8c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=269&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=269&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/269.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/269/head:pull/269 PR: https://git.openjdk.java.net/jdk/pull/269 From lancea at openjdk.java.net Sun Sep 20 20:42:34 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 20 Sep 2020 20:42:34 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v2] In-Reply-To: References: Message-ID: <2aAkiIC_6nx2jqhDrJ-Mt1PzqvKYepn_mnkRMoO2Uvk=.08a69444-7f2a-4783-b3fc-2d1d517b34e8@github.com> On Sun, 20 Sep 2020 18:29:20 GMT, Uwe Schindler wrote: >> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: >> >> Additional updates to DeflaterDictionaryTests.java > > The tests with byte buffers (direct and heap) are not using offsets (arrayOffset=0). The direct buffer test uses just a > series of 0-bytes, so incorrect offsets won't change result. There should be real data copied into the direct buffer. Minor updates have been made to the tests ------------- PR: https://git.openjdk.java.net/jdk/pull/269 From herrick at openjdk.java.net Sun Sep 20 21:31:30 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Sun, 20 Sep 2020 21:31:30 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= Message-ID: 8253149: Building an installer from invalid app image fails on Windows and Linux When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a warning message, and then complete the package anyway. ------------- Commit messages: - 8253149: Building an installer from invalid app image fails on Windows and Linux Changes: https://git.openjdk.java.net/jdk/pull/271/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=271&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253149 Stats: 77 lines in 11 files changed: 69 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/271.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/271/head:pull/271 PR: https://git.openjdk.java.net/jdk/pull/271 From github.com+1005388+uschindler at openjdk.java.net Sun Sep 20 22:22:48 2020 From: github.com+1005388+uschindler at openjdk.java.net (Uwe Schindler) Date: Sun, 20 Sep 2020 22:22:48 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v3] In-Reply-To: <2aAkiIC_6nx2jqhDrJ-Mt1PzqvKYepn_mnkRMoO2Uvk=.08a69444-7f2a-4783-b3fc-2d1d517b34e8@github.com> References: <2aAkiIC_6nx2jqhDrJ-Mt1PzqvKYepn_mnkRMoO2Uvk=.08a69444-7f2a-4783-b3fc-2d1d517b34e8@github.com> Message-ID: On Sun, 20 Sep 2020 20:38:59 GMT, Lance Andersen wrote: >> The tests with byte buffers (direct and heap) are not using offsets (arrayOffset=0). The direct buffer test uses just a >> series of 0-bytes, so incorrect offsets won't change result. There should be real data copied into the direct buffer. > > Minor updates have been made to the tests Ok much better for the heap buffers. Many thanks. The direct buffers have now contents, but I think it should copy the whole heap array into the byte buffer. After that set position and limit and then call slice(). After that you have a slice of the original direct buffer with offset. ------------- PR: https://git.openjdk.java.net/jdk/pull/269 From lancea at openjdk.java.net Sun Sep 20 22:22:49 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 20 Sep 2020 22:22:49 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v3] In-Reply-To: References: <2aAkiIC_6nx2jqhDrJ-Mt1PzqvKYepn_mnkRMoO2Uvk=.08a69444-7f2a-4783-b3fc-2d1d517b34e8@github.com> Message-ID: On Sun, 20 Sep 2020 20:42:30 GMT, Uwe Schindler wrote: >> Minor updates have been made to the tests > > Ok much better for the heap buffers. Many thanks. > > The direct buffers have now contents, but I think it should copy the whole heap array into the byte buffer. After that > set position and limit and then call slice(). After that you have a slice of the original direct buffer with offset. I have made additional updates to testByteBufferDirect to incorporate your suggestions ------------- PR: https://git.openjdk.java.net/jdk/pull/269 From lancea at openjdk.java.net Sun Sep 20 22:22:47 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 20 Sep 2020 22:22:47 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v3] In-Reply-To: References: Message-ID: > Hi all, > > Please review the fix for JDK-8252739 which addresses an issue introduced by > https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by > Deflater.setDictionary. Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and > java/util/jar JCK tests. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: More updates to testByteBufferDirect in DeflaterDictionaryTests.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/269/files - new: https://git.openjdk.java.net/jdk/pull/269/files/eaf0be8c..aac03e3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=269&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=269&range=01-02 Stats: 15 lines in 1 file changed: 7 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/269.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/269/head:pull/269 PR: https://git.openjdk.java.net/jdk/pull/269 From github.com+1005388+uschindler at openjdk.java.net Sun Sep 20 22:26:11 2020 From: github.com+1005388+uschindler at openjdk.java.net (Uwe Schindler) Date: Sun, 20 Sep 2020 22:26:11 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v3] In-Reply-To: References: Message-ID: On Sun, 20 Sep 2020 22:22:47 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for JDK-8252739 which addresses an issue introduced by >> https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by >> Deflater.setDictionary. Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and >> java/util/jar JCK tests. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > More updates to testByteBufferDirect in DeflaterDictionaryTests.java Looks fine to me. ------------- Marked as reviewed by uschindler at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/269 From sspitsyn at openjdk.java.net Sun Sep 20 22:39:32 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sun, 20 Sep 2020 22:39:32 GMT Subject: RFR: 8252537: Updated @exception with @throws [v3] In-Reply-To: References: Message-ID: On Sat, 19 Sep 2020 20:24:14 GMT, Vipin Sharma wrote: >> Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. >> >> Open Subtasks part of this fix are: >> 1. JDK-8252537 >> 2. JDK-8252539 >> 3. JDK-8252540 >> 4. JDK-8252541 >> >> Previous conversation on this: >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html > > Vipin Sharma has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains one commit: > JDK-8252537 Updated @exception with @throws, implemented review comments I've reviewed the management files only. They look good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/95 From mik3hall at gmail.com Mon Sep 21 00:40:13 2020 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 20 Sep 2020 19:40:13 -0500 Subject: Jpackage file assocations OS X Message-ID: Are there any examples or further information on how the file association property file should work? It is not entirely clear to me from the command help. From felix.yang at huawei.com Mon Sep 21 02:59:47 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 21 Sep 2020 02:59:47 +0000 Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: <28d501ee-0f96-48e0-bfc4-230721018968@redhat.com> References: <28d501ee-0f96-48e0-bfc4-230721018968@redhat.com> Message-ID: Hi, > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-retn at openjdk.java.net] On Behalf > Of Andrew Haley > Sent: Friday, September 18, 2020 9:48 PM > To: Fei Yang ; hotspot-dev at openjdk.java.net; > security-dev at openjdk.java.net > Subject: Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic > > On 17/09/2020 05:26, Fei Yang wrote: > > For now, this feature will not be enabled automatically for aarch64. > > We can auto-enable this when it is fully tested on real hardware. But > > for the above testing purposes, this is auto-enabled when the > corresponding hardware feature is detected. > > Given that there's no real hardware, it's extra-important to add the new > instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in > assembler_aarch64.cc:asm_check. I have added on commit in PR resolving this: https://github.com/openjdk/jdk/pull/207/commits/04bdb42e971aa1c2f78bb5c916db62910e167053?file-filters%5B%5D= I grouped SHA512SIMDOp, SHA3SIMDOp and SVEVectorOp after the # ARMv8.2A comment. So anticipate more changes in file assembler_aarch64.cpp. BTW: If this feature is not auto-enabled when the SHA3 hardware feature is there, we will have one failure for the following test: test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java 15 #-----testresult----- 16 description=file\:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java 17 elapsed=31546 0\:00\:31.546 18 end=Mon Sep 21 10\:27\:58 CST 2020 19 environment=regtest 20 execStatus=Failed. Execution failed\: `main' threw exception\: java.lang.AssertionError\: Option 'UseSHA3Intrinsics' is expected to have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default Any suggestions for this? Thanks, Felix From david.holmes at oracle.com Mon Sep 21 03:11:16 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Sep 2020 13:11:16 +1000 Subject: Request for review of JDK-8251548 In-Reply-To: <260361600412955@mail.yandex.ru> References: <408131600326592@mail.yandex.ru> <125311600334485@mail.yandex.ru> <260361600412955@mail.yandex.ru> Message-ID: <1793e736-fc94-06f4-828c-9c75252ee2cc@oracle.com> On 18/09/2020 5:15 pm, ?????? ??????? wrote: > Hi, > >> Did you not follow these instructions to get your github account >> connected to your OCA record: > > Those are for "OpenJDK Author, Committer or Reviewer", but I'm only a contributor, > i.e. I cannot file an issue or commit directly. My previous contributions were shipped as *.patch > files in mail attachments. Ah sorry I overlooked that bit. > Anyway, OCA was approved again and the PR (https://github.com/openjdk/jdk/pull/218) is ready for review :) It wasn't necessary to re-do the OCA, but glad it is now sorted. David ----- > Cheers, > Sergey > > 17.09.2020, 14:11, "David Holmes" : >> On 17/09/2020 7:24 pm, ?????? ??????? wrote: >>> ?Hi David, >>> >>> ?thanks for pointing this out! >>> >>> ?I've created a PR there [1], but GitHub for some reason wants me to sign OCA, >>> ?which I have already signed in 2017. I've redone the procedure and now I'm waiting >>> ?for verification. >> >> Did you not follow these instructions to get your github account >> connected to your OCA record: >> >> "If you already are an OpenJDK Author, Committer or Reviewer, please >> click here[1] to open a new issue so that we can record that fact. >> Please use "Add GitHub user stsypanov" as summary for the issue." >> >> [1] >> https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1 >> >> Cheers, >> David >> ----- >> >>> ?Regards, >>> ?Sergey >>> >>> ?1. https://github.com/openjdk/jdk/pull/218 >>> >>> ?17.09.2020, 09:22, "David Holmes" : >>>> ?Hi Sergey, >>>> >>>> ?Since OpenJDK has moved to git/github, this needs to reformulated as a >>>> ?Pull Request (PR). >>>> >>>> ?Cheers, >>>> ?David >>>> >>>> ?On 17/09/2020 5:19 pm, ?????? ??????? wrote: >>>>> ???Hello, >>>>> >>>>> ???is it possible to have a code review for the changes proposed in JDK-8251548? >>>>> >>>>> ???Sean Mullan has created an issue and web-review and can sponsor the patch >>>>> ???as soos as it gets properly reviewed. >>>>> >>>>> ???As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html >>>>> >>>>>> ???there is never any reason to explicitly initialize fields to 0/0.0/false/null >>>>> >>>>> ???so I believe the patch is harmless. >>>>> >>>>> ???Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 >>>>> ???Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ >>>>> >>>>> ???Thanks, >>>>> ???Sergey Tsypanov From kizune at openjdk.java.net Mon Sep 21 04:06:54 2020 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 21 Sep 2020 04:06:54 GMT Subject: RFR: JDK-8230652: Improve verbose output In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 18:30:08 GMT, Andy Herrick wrote: > JDK-8230652 > Extracting the commands displayed by verbose output (including commands called thru ToolProvider) , to contain the the > command, it's output, and it's return value on separate lines and formatted in a way that they can be easily cut and > pasted into a script. Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/141 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 jdk at fiolino.de Mon Sep 21 08:08:27 2020 From: jdk at fiolino.de (Michael Kuhlmann) Date: Mon, 21 Sep 2020 10:08:27 +0200 Subject: 'Find' method for Iterable In-Reply-To: References: <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr> Message-ID: <54f82257-b5c5-287f-5c99-8b922d597eb3@fiolino.de> Hi Nir, at first I thought "Wow, it would be really cool to have that method in Iterable! Why isn't it there already?" But after thinking about it, I'm now convinced that it would be a bad idea. Because it extends the scope of this small, tiny Iterable interface to something bigger which it shouldn't be. When some class implements Iterable, it just says "you can iterate over my something which I call elements". Nothing more. Now when Iterable implements find() by default, then automatically all classes which just want to enable users to iterate over elements also tell them that there can be something useful found in these elements, which is not necessarily the case. For example, BitSet could immplements Iterable. That doesn't make much practical sense, but from the definition of a BitSet it's understandable: A BitSet can be seen as a set of integer values, why shouldn't someone iterate over them. But now, when you add find() to Iterable, it immediately tells users: Hey, you can find integers in me, and when you found one, you get it returned. Which is beyond the use case of a BitSet. forEach() is different, because forEach just iterates over the elements and nothing more, which is in the scope of an Iterable. A second argument against adding find() is that such a generic method could conflict with more specialized methods in subinterfaces or classes. I like the idea of having indexOf(Predicate) in List interface, but having both of them would be redundant. And a third argument is that it can break existing code. An implementor of Iterable could already define a find() method, but return the index of the element instead of the element itself, or throw some checked exception. This code wouldn't compile any more. So while the idea of having find() in Iterable is great, the arguments against are heavier from my point of view. -Michael On 9/16/20 11:36 PM, Nir Lisker wrote: > I don't see a reason to put it Collection when it extends Iterable anyway, > and the method just requires iteration. As for execution time, true, it's > faster, but Map uses a lot more memory, so it's a tradeoff. For smaller > lists, linear time is acceptable. Currently I'm using Maps actually, but I > find that when there are many small maps, having many small lists is better > for memory and the search time is similar. Additionally, a Map works only > for searching by 1 key, but with a Collection/Iterable I can search by any > property, and we're not about to use a Map for every property. So, overall, > I don't think Map is a competitor in this market. It's also possible to > specify that the complexity is linear in an @implNote to avoid surprises. > > - Nir > > On Wed, Sep 16, 2020 at 11:59 PM Remi Forax wrote: > >> ----- Mail original ----- >>> De: "Nir Lisker" >>> ?: "core-libs-dev" >>> Envoy?: Lundi 14 Septembre 2020 20:56:27 >>> Objet: 'Find' method for Iterable >> >>> Hi, >>> >>> This has probably been brought up at some point. When we need to find an >>> item in a collection based on its properties, we can either do it in a >>> loop, testing each item, or in a stream with filter and findFirst/Any. >>> >>> I would think that a method in Iterable be useful, along the lines of: >>> >>> public Optional find(Predicate condition) { >>> Objects.requireNonNull(condition); >>> for (T t : this) { >>> if (condition.test(t)) { >>> return Optional.of(t); >>> } >>> } >>> return Optional.empty(); >>> } >>> >>> With usage: >>> >>> list.find(person -> person.id == 123456); >>> >>> There are a few issues with the method here such as t being null in >>> null-friendly collections and the lack of bound generic types, but this >>> example is just used to explain the intention. >>> >>> It will be an alternative to >>> >>> list.stream().filter(person -> person.id == 123456).findAny/First() >>> (depending on if the collection is ordered or not) >>> >>> which doesn't create a stream, similar to Iterable#forEach vs >>> Stream#forEach. >>> >>> Maybe with pattern matching this would become more appetizing. >> >> During the development of Java 8, we first tried to use Iterator/Iterable >> instead of using a novel interface Stream. >> But a Stream cleanly separate the lazy side effect free API from the >> mutable one (Collection) and can be optimized better by the VM (it's a push >> API instead of being a pull API). >> >> The other question is why there is no method find() on Collection, i >> believe it's because while find() is ok for any DB API, find() is dangerous >> on a Collection because the execution time is linear, so people may use it >> instead of using a Map. >> >>> >>> - Nir >> >> R?mi >> 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 abakhtin at openjdk.java.net Mon Sep 21 08:26:04 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Mon, 21 Sep 2020 08:26:04 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos Message-ID: Hi, Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is "tls-server-end-point" CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 Thank you Alexey ------------- Commit messages: - 8245527: LDAP Channel Binding support for Java GSS/Kerberos Changes: https://git.openjdk.java.net/jdk/pull/278/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=278&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245527 Stats: 536 lines in 10 files changed: 524 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/278.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/278/head:pull/278 PR: https://git.openjdk.java.net/jdk/pull/278 From justin.dekeyser at gmail.com Mon Sep 21 08:31:00 2020 From: justin.dekeyser at gmail.com (Justin Dekeyser) Date: Mon, 21 Sep 2020 10:31:00 +0200 Subject: 'Find' method for Iterable In-Reply-To: <54f82257-b5c5-287f-5c99-8b922d597eb3@fiolino.de> References: <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr> <54f82257-b5c5-287f-5c99-8b922d597eb3@fiolino.de> Message-ID: Hi all, Correct me if I'm wrong, but isn't the goal of Iterable be used as argument in a enhanced for-loop, that is: just allow a enhanced syntax. (Similarly, AUtoCloseable is what allows the try-with-resource syntax; Throwable is what allows the throw syntax) As such, isn't it out of scope of Iterable to implement this famous find method? Since it's scope should just be to allow enhanced for-loop ? It's more like a general question in the Java programming language design actually: is one expected to code with those interfaces in a business-way, or implement them to allow a specific syntax ? Regards, Justin Dekeyser On Mon, Sep 21, 2020 at 10:08 AM Michael Kuhlmann wrote: > > Hi Nir, > > at first I thought "Wow, it would be really cool to have that method in > Iterable! Why isn't it there already?" > > But after thinking about it, I'm now convinced that it would be a bad > idea. Because it extends the scope of this small, tiny Iterable > interface to something bigger which it shouldn't be. > > When some class implements Iterable, it just says "you can iterate over > my something which I call elements". Nothing more. Now when Iterable > implements find() by default, then automatically all classes which just > want to enable users to iterate over elements also tell them that there > can be something useful found in these elements, which is not > necessarily the case. > > For example, BitSet could immplements Iterable. That doesn't > make much practical sense, but from the definition of a BitSet it's > understandable: A BitSet can be seen as a set of integer values, why > shouldn't someone iterate over them. But now, when you add find() to > Iterable, it immediately tells users: Hey, you can find integers in me, > and when you found one, you get it returned. Which is beyond the use > case of a BitSet. > > forEach() is different, because forEach just iterates over the elements > and nothing more, which is in the scope of an Iterable. > > A second argument against adding find() is that such a generic method > could conflict with more specialized methods in subinterfaces or > classes. I like the idea of having indexOf(Predicate) in List > interface, but having both of them would be redundant. > > And a third argument is that it can break existing code. An implementor > of Iterable could already define a find() method, but return the index > of the element instead of the element itself, or throw some checked > exception. This code wouldn't compile any more. > > So while the idea of having find() in Iterable is great, the arguments > against are heavier from my point of view. > > -Michael > > > On 9/16/20 11:36 PM, Nir Lisker wrote: > > I don't see a reason to put it Collection when it extends Iterable anyway, > > and the method just requires iteration. As for execution time, true, it's > > faster, but Map uses a lot more memory, so it's a tradeoff. For smaller > > lists, linear time is acceptable. Currently I'm using Maps actually, but I > > find that when there are many small maps, having many small lists is better > > for memory and the search time is similar. Additionally, a Map works only > > for searching by 1 key, but with a Collection/Iterable I can search by any > > property, and we're not about to use a Map for every property. So, overall, > > I don't think Map is a competitor in this market. It's also possible to > > specify that the complexity is linear in an @implNote to avoid surprises. > > > > - Nir > > > > On Wed, Sep 16, 2020 at 11:59 PM Remi Forax wrote: > > > >> ----- Mail original ----- > >>> De: "Nir Lisker" > >>> ?: "core-libs-dev" > >>> Envoy?: Lundi 14 Septembre 2020 20:56:27 > >>> Objet: 'Find' method for Iterable > >> > >>> Hi, > >>> > >>> This has probably been brought up at some point. When we need to find an > >>> item in a collection based on its properties, we can either do it in a > >>> loop, testing each item, or in a stream with filter and findFirst/Any. > >>> > >>> I would think that a method in Iterable be useful, along the lines of: > >>> > >>> public Optional find(Predicate condition) { > >>> Objects.requireNonNull(condition); > >>> for (T t : this) { > >>> if (condition.test(t)) { > >>> return Optional.of(t); > >>> } > >>> } > >>> return Optional.empty(); > >>> } > >>> > >>> With usage: > >>> > >>> list.find(person -> person.id == 123456); > >>> > >>> There are a few issues with the method here such as t being null in > >>> null-friendly collections and the lack of bound generic types, but this > >>> example is just used to explain the intention. > >>> > >>> It will be an alternative to > >>> > >>> list.stream().filter(person -> person.id == 123456).findAny/First() > >>> (depending on if the collection is ordered or not) > >>> > >>> which doesn't create a stream, similar to Iterable#forEach vs > >>> Stream#forEach. > >>> > >>> Maybe with pattern matching this would become more appetizing. > >> > >> During the development of Java 8, we first tried to use Iterator/Iterable > >> instead of using a novel interface Stream. > >> But a Stream cleanly separate the lazy side effect free API from the > >> mutable one (Collection) and can be optimized better by the VM (it's a push > >> API instead of being a pull API). > >> > >> The other question is why there is no method find() on Collection, i > >> believe it's because while find() is ok for any DB API, find() is dangerous > >> on a Collection because the execution time is linear, so people may use it > >> instead of using a Map. > >> > >>> > >>> - Nir > >> > >> R?mi > >> From justin.dekeyser at gmail.com Mon Sep 21 09:21:20 2020 From: justin.dekeyser at gmail.com (Justin Dekeyser) Date: Mon, 21 Sep 2020 11:21:20 +0200 Subject: 'Find' method for Iterable In-Reply-To: References: <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr> <54f82257-b5c5-287f-5c99-8b922d597eb3@fiolino.de> Message-ID: I'm also thinking about something: If `T find()` gets implemented on `Iterable` with the contract that this method always ends, this implies that the amount of elements available in the Iterable is finite, which makes it possible to define a `int size()` by providing a trivial predicate. This would in fact turn `Iterable` to a redundant interface with `Collection`, as the only operations a collection could supply to enrich Iterable are just the add/remove operations, which are all optional by contract. This would sound a bit weird. Iterable will just turn to a readonly collection, and I think this was not the purpose (from a previous long post there were in this newsletter, about splitting the List interface in two interfaces, readonly and write-only). Regards, Justin Dekeyser On Mon, Sep 21, 2020 at 10:31 AM Justin Dekeyser wrote: > > Hi all, > > Correct me if I'm wrong, but isn't the goal of Iterable be used as > argument in a enhanced for-loop, that is: just allow a enhanced > syntax. > (Similarly, AUtoCloseable is what allows the try-with-resource syntax; > Throwable is what allows the throw syntax) > > As such, isn't it out of scope of Iterable to implement this famous find method? > Since it's scope should just be to allow enhanced for-loop ? > > It's more like a general question in the Java programming language > design actually: is one expected to code with those interfaces in a > business-way, > or implement them to allow a specific syntax ? > > Regards, > > Justin Dekeyser > > On Mon, Sep 21, 2020 at 10:08 AM Michael Kuhlmann wrote: > > > > Hi Nir, > > > > at first I thought "Wow, it would be really cool to have that method in > > Iterable! Why isn't it there already?" > > > > But after thinking about it, I'm now convinced that it would be a bad > > idea. Because it extends the scope of this small, tiny Iterable > > interface to something bigger which it shouldn't be. > > > > When some class implements Iterable, it just says "you can iterate over > > my something which I call elements". Nothing more. Now when Iterable > > implements find() by default, then automatically all classes which just > > want to enable users to iterate over elements also tell them that there > > can be something useful found in these elements, which is not > > necessarily the case. > > > > For example, BitSet could immplements Iterable. That doesn't > > make much practical sense, but from the definition of a BitSet it's > > understandable: A BitSet can be seen as a set of integer values, why > > shouldn't someone iterate over them. But now, when you add find() to > > Iterable, it immediately tells users: Hey, you can find integers in me, > > and when you found one, you get it returned. Which is beyond the use > > case of a BitSet. > > > > forEach() is different, because forEach just iterates over the elements > > and nothing more, which is in the scope of an Iterable. > > > > A second argument against adding find() is that such a generic method > > could conflict with more specialized methods in subinterfaces or > > classes. I like the idea of having indexOf(Predicate) in List > > interface, but having both of them would be redundant. > > > > And a third argument is that it can break existing code. An implementor > > of Iterable could already define a find() method, but return the index > > of the element instead of the element itself, or throw some checked > > exception. This code wouldn't compile any more. > > > > So while the idea of having find() in Iterable is great, the arguments > > against are heavier from my point of view. > > > > -Michael > > > > > > On 9/16/20 11:36 PM, Nir Lisker wrote: > > > I don't see a reason to put it Collection when it extends Iterable anyway, > > > and the method just requires iteration. As for execution time, true, it's > > > faster, but Map uses a lot more memory, so it's a tradeoff. For smaller > > > lists, linear time is acceptable. Currently I'm using Maps actually, but I > > > find that when there are many small maps, having many small lists is better > > > for memory and the search time is similar. Additionally, a Map works only > > > for searching by 1 key, but with a Collection/Iterable I can search by any > > > property, and we're not about to use a Map for every property. So, overall, > > > I don't think Map is a competitor in this market. It's also possible to > > > specify that the complexity is linear in an @implNote to avoid surprises. > > > > > > - Nir > > > > > > On Wed, Sep 16, 2020 at 11:59 PM Remi Forax wrote: > > > > > >> ----- Mail original ----- > > >>> De: "Nir Lisker" > > >>> ?: "core-libs-dev" > > >>> Envoy?: Lundi 14 Septembre 2020 20:56:27 > > >>> Objet: 'Find' method for Iterable > > >> > > >>> Hi, > > >>> > > >>> This has probably been brought up at some point. When we need to find an > > >>> item in a collection based on its properties, we can either do it in a > > >>> loop, testing each item, or in a stream with filter and findFirst/Any. > > >>> > > >>> I would think that a method in Iterable be useful, along the lines of: > > >>> > > >>> public Optional find(Predicate condition) { > > >>> Objects.requireNonNull(condition); > > >>> for (T t : this) { > > >>> if (condition.test(t)) { > > >>> return Optional.of(t); > > >>> } > > >>> } > > >>> return Optional.empty(); > > >>> } > > >>> > > >>> With usage: > > >>> > > >>> list.find(person -> person.id == 123456); > > >>> > > >>> There are a few issues with the method here such as t being null in > > >>> null-friendly collections and the lack of bound generic types, but this > > >>> example is just used to explain the intention. > > >>> > > >>> It will be an alternative to > > >>> > > >>> list.stream().filter(person -> person.id == 123456).findAny/First() > > >>> (depending on if the collection is ordered or not) > > >>> > > >>> which doesn't create a stream, similar to Iterable#forEach vs > > >>> Stream#forEach. > > >>> > > >>> Maybe with pattern matching this would become more appetizing. > > >> > > >> During the development of Java 8, we first tried to use Iterator/Iterable > > >> instead of using a novel interface Stream. > > >> But a Stream cleanly separate the lazy side effect free API from the > > >> mutable one (Collection) and can be optimized better by the VM (it's a push > > >> API instead of being a pull API). > > >> > > >> The other question is why there is no method find() on Collection, i > > >> believe it's because while find() is ok for any DB API, find() is dangerous > > >> on a Collection because the execution time is linear, so people may use it > > >> instead of using a Map. > > >> > > >>> > > >>> - Nir > > >> > > >> R?mi > > >> From adinn at openjdk.java.net Mon Sep 21 09:23:26 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Mon, 21 Sep 2020 09:23:26 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> Message-ID: On Fri, 18 Sep 2020 23:11:46 GMT, Jason Tatton wrote: > > Can you explain where this restricted effect is documented? > Certainly! I?ve found that determining the capability of the CPU and whether to enable AVX2 support if the chip > supports it is mostly controlled in: vm_version_x86.cpp specifically: get_processor_features and in > generate_get_cpu_info. Yes, I can see what the code does. I was asking where the cpu behaviour is documented independent of the code. > In order to test the patch comprehensively I had to track down an Intel Core i7 (I7-9750H) processor which the > aforementioned code permitted AVX2 instructions for (maybe this is an error and it should not be enabled for this > processor though) as most of the infrastructure I personally use here at AWS runs on Intel Xeon processors - I also > tested on a E5-2680 which the JVM does not enable AVX2 for. 'maybe'? The documentation Andrew provided mentioned Xeon E5 v3 which I believe is a Skylake design. However, the code I pointed you at in vm_version_x86 which claims to detect 'early Skylake' designs is only disabling AVX512 support. It still enables AVX2. Similarly, the code generates machine code to check the processor capabilities has a special check if use_evex is set (i.e. AVX3 is requested) for Skylake which disables AVX512 but does nto disable AVX2 support. However, this is just the Intel side of things. When it comes to AMD I read that the AMD Zen 2 architecture, of which the current flagship: Threadripper 3990X, is based, is able to support AVX2 without the frequency scaling which some/all(?) of the Intel chips incur. I personally don?t have access to one of these chips so I cannot confirm how it is classified in the JVM. Also, I found when investigating this that there is actually a JVM flag which can be used to control what level of AVX is enabled: -XX:UseAVX=version. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 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 simonis at openjdk.java.net Mon Sep 21 10:00:30 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 21 Sep 2020 10:00:30 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v2] In-Reply-To: <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com> Message-ID: <7DJmBVYGzIaMRYO0Ad5UumqLK3_ehORlOFTAtX_aSP0=.e020152a-a2a0-4db5-ac82-dc17736975a9@github.com> On Fri, 18 Sep 2020 11:56:09 GMT, Jason Tatton wrote: >> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for >> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it >> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as >> code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and >> java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 >> >> Details of testing: >> ============ >> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note >> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the >> input String. Hence the test has been designed to cover all these cases. In summary they are: >> - A ?short? string of < 16 characters. >> - A SIMD String of 16 ? 31 characters. >> - A AVX2 SIMD String of 32 characters+. >> >> Hardware used for testing: >> ----------------------------- >> >> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). >> - AWS Graviton 2 (ARM 64 processor). >> >> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. >> >> Possible future enhancements: >> ==================== >> For the x86 implementation there may be two further improvements we can make in order to improve performance of both >> the StringUTF16 and StringLatin1 indexOf(char) intrinsics: >> 1. Make use of AVX-512 instructions. >> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD >> instructions instead of a loop. >> Benchmark results: >> ============ >> **Without** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | >> >> >> **With** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | >> >> >> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 >> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when >> running on ARM. > > Jason Tatton has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains four commits: > - Merge master > - 8173585: further whitespace changes required by jcheck > - JDK-8173585 - whitespace changes required by jcheck > - JDK-8173585 src/hotspot/share/classfile/vmSymbols.cpp line 295: > 293: if (symbol == NULL) return NO_SID; > 294: return find_sid(symbol); > 295: } I think it is common sense to have a newline at the end of a file. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 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 alanb at openjdk.java.net Mon Sep 21 12:20:58 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 21 Sep 2020 12:20:58 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v3] In-Reply-To: References: Message-ID: <1UQRZ_pUR3pXgA7L0pfbBTxQ3X-WRgSwjB5gnk3tPX0=.7d73d858-6bbc-4f1d-9249-d8ca24b502ad@github.com> On Sun, 20 Sep 2020 22:22:47 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for JDK-8252739 which addresses an issue introduced by >> https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by >> Deflater.setDictionary. Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and >> java/util/jar JCK tests. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > More updates to testByteBufferDirect in DeflaterDictionaryTests.java Update to Deflater.c looks good. DeflaterDictionaryTests looks like is a shaping up to be a good test for setDictionary. Are there other assertions that should be checked, e.g. setDictionary(ByteBuffer) is specified to consume all bytes and it would be good to check that the position is set to the limit. Also can the 2-arg setDictionary be tests, also corner cases such no bytes remaining or invoked with null. The naming of the tests is a bit inconsistent, e.g. ByteArrayTest vs. testByteBufferDirect. In the naming then I would use "Heap" instead of "Wrap", as in testHeapByteBuffer. In passing: The tests can use try-finally to ensure that Deflater::end is invoked even when the test fails. String repeat(int) could be used to avoid duplicating "Welcome to Us Open;". Missing space in several "if(...)" usages. ------------- PR: https://git.openjdk.java.net/jdk/pull/269 From naoto at openjdk.java.net Mon Sep 21 12:37:14 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 21 Sep 2020 12:37:14 GMT Subject: Integrated: 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode In-Reply-To: <2-y_g5PvWat4frQ_-6XHFSx2QcZvQns4YzwInyhTemU=.ad69a573-0209-4c9e-b747-60590e3cf798@github.com> References: <2-y_g5PvWat4frQ_-6XHFSx2QcZvQns4YzwInyhTemU=.ad69a573-0209-4c9e-b747-60590e3cf798@github.com> Message-ID: <29smkrDc7arlhkemAvvViCKV85MyG7-T_eBj8Si9atM=.de0af37d-0d02-4892-ad20-92e125d8fa21@github.com> On Fri, 18 Sep 2020 23:26:39 GMT, Naoto Sato wrote: > Hi, > > Please review the fix to JDK-8253321. As in the issue, uninitialized (cached) hash code was incorrectly referenced in > equals() method. Removing it will correct the problem. Also, unrelated to the issue, I fixed a parameter description in > a private method. Naoto This pull request has now been integrated. Changeset: dad6edbf Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/dad6edbf Stats: 52 lines in 2 files changed: 1 ins; 48 del; 3 mod 8253321: java.util.Locale.LanguageRange#equals is inconsistent after calling hashCode Reviewed-by: joehw, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/260 From github.com+70893615+jasontatton-aws at openjdk.java.net Mon Sep 21 12:45:55 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Mon, 21 Sep 2020 12:45:55 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v3] In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: > This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for > x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it > I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as > code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and > java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 > > Details of testing: > ============ > I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note > that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the > input String. Hence the test has been designed to cover all these cases. In summary they are: > - A ?short? string of < 16 characters. > - A SIMD String of 16 ? 31 characters. > - A AVX2 SIMD String of 32 characters+. > > Hardware used for testing: > ----------------------------- > > - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). > - AWS Graviton 2 (ARM 64 processor). > > I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. > > Possible future enhancements: > ==================== > For the x86 implementation there may be two further improvements we can make in order to improve performance of both > the StringUTF16 and StringLatin1 indexOf(char) intrinsics: > 1. Make use of AVX-512 instructions. > 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD > instructions instead of a loop. > Benchmark results: > ============ > **Without** the new StringLatin1 indexOf(char) intrinsic: > > | Benchmark | Mode | Cnt | Score | Error | Units | > | ------------- | ------------- |------------- |------------- |------------- |------------- | > | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | > | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | > > > **With** the new StringLatin1 indexOf(char) intrinsic: > > | Benchmark | Mode | Cnt | Score | Error | Units | > | ------------- | ------------- |------------- |------------- |------------- |------------- | > | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | > | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | > > > The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 > indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when > running on ARM. Jason Tatton has updated the pull request incrementally with one additional commit since the last revision: Add missing newline to end of vmSymbols.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/71/files - new: https://git.openjdk.java.net/jdk/pull/71/files/b85a7fb4..c8cc441e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/71/head:pull/71 PR: https://git.openjdk.java.net/jdk/pull/71 From herrick at openjdk.java.net Mon Sep 21 13:11:10 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 21 Sep 2020 13:11:10 GMT Subject: Integrated: JDK-8230652: Improve verbose output In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 18:30:08 GMT, Andy Herrick wrote: > JDK-8230652 > Extracting the commands displayed by verbose output (including commands called thru ToolProvider) , to contain the the > command, it's output, and it's return value on separate lines and formatted in a way that they can be easily cut and > pasted into a script. This pull request has now been integrated. Changeset: 43be5a3c Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/43be5a3c Stats: 78 lines in 9 files changed: 25 ins; 42 del; 11 mod 8230652: Improve verbose output Reviewed-by: almatvee, asemenyuk, kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/141 From asemenyuk at openjdk.java.net Mon Sep 21 13:52:32 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 21 Sep 2020 13:52:32 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= In-Reply-To: References: Message-ID: On Sun, 20 Sep 2020 21:23:17 GMT, Andy Herrick wrote: > 8253149: Building an installer from invalid app image fails on Windows and Linux > When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a > warning message, and then complete the package anyway. test/jdk/tools/jpackage/share/AppImagePackageTest.java line 73: > 71: final String name = "EmptyAppImagePackageTest"; > 72: final String imageName = name + (TKit.isOSX() ? ".app" : ""); > 73: Path appImageDir = TKit.workDir().resolve(imageName); I'd suggest to use Tkit.createTempDirectory() to create temp directory. The function will create unique directory every time it is called allowing to run the test multiple times and have fresh empty directory in every run. test/jdk/tools/jpackage/share/AppImagePackageTest.java line 81: > 79: Path readme = Files.createFile(libdir.resolve("README")); > 80: try (BufferedWriter bw = Files.newBufferedWriter(readme)) { > 81: bw.write("This is some arbitrary ext for the README file\n"); All these lines can be replaced with a single call `TKit.createTextFile(List.of("This is some arbitrary text for the README file"));` This statement will add log statements, so no manual logging is required. Also there is no need for try/catch block test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java line 275: > 273: actualCriticalRuntimePaths); > 274: } else { > 275: // AppImagePackageTest.testEmpty() will no dependencied, Looks like a typo src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/resources/MainResources.properties line 77: > 75: > 76: warning.no.jdk.modules.found=Warning: No JDK Modules found > 77: warning.forign-app-image=Warning: app-image dir ({0}) not generated by jpackage. Should the id be named "foreign" instead of "forign"? ------------- PR: https://git.openjdk.java.net/jdk/pull/271 From weijun at openjdk.java.net Mon Sep 21 14:07:48 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 21 Sep 2020 14:07:48 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: On Sun, 20 Sep 2020 14:14:51 GMT, Roger Riggs wrote: >> # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter >> >> Debugging functions that utilize ASN.1, DER, and BER encoded streams is >> difficult without test utilities to show the contents. >> The ASN.1 formatter reads a stream and produces annotated output of the >> tags, values, and structures. >> When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized >> with the hex formatted output. >> >> Small changes to HexPrinter are included to improve the output readability. >> >> >> Example decoding of a .pem certificate: >> SEQUENCE [910] >> SEQUENCE [630] >> CONTEXT cons 0 [3] >> BYTE 2, >> BYTE 3, >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> NULL >> SEQUENCE [76] >> SET [11] >> SEQUENCE [9] >> OBJECT ID [3] 2.5.4.6 (CountryName) >> 'IN' >> ... >> SET [16] >> SEQUENCE [14] >> OBJECT ID [3] 2.5.4.3 (CommonName) >> Client1 >> SEQUENCE [30] >> UTCTIME [13] '150526221718Z' >> UTCTIME [13] '250523221718Z' >> ... >> SEQUENCE [290] >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) >> NULL >> BIT STRING [271] >> CONTEXT cons 3 [123] >> SEQUENCE [121] >> SEQUENCE [9] >> OBJECT ID [3] 2.5.29.19 (BasicConstraints) >> OCTET STRING [2] >> SEQUENCE [44] >> OBJECT ID [9] 2.16.840.1.113730.1.13 >> OCTET STRING [31] '..OpenSSL Generated Certificate' >> SEQUENCE [29] >> OBJECT ID [3] 2.5.29.14 (SubjectKeyID) >> OCTET STRING [22] >> SEQUENCE [31] >> OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) >> OCTET STRING [24] >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> NULL >> BIT STRING [257] >> When used with the HexPrinter test utility, the formatting of the >> hexadecimal values is selected with the parameters to HexPrinter. >> >> 0000: 30 82 03 8e ; SEQUENCE [910] >> 0004: 30 82 02 76 ; SEQUENCE [630] >> 0008: a0 03 ; CONTEXT cons 0 [3] >> 000a: 02 01 02 ; BYTE 2, >> 000d: 02 01 03 ; BYTE 3, >> 0010: 30 0d ; SEQUENCE [13] >> 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> 001d: 05 00 ; NULL >> 001f: 30 ; SEQUENCE [76] >> 0020: 4c ; >> 0021: 31 0b ; SET [11] >> 0023: 30 09 ; SEQUENCE [9] >> 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) >> 002a: 13 02 49 4e ; 'IN' >> >> ... ... >> >> 005b: 31 10 ; SET [16] >> 005d: 30 0e ; SEQUENCE [14] >> 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) >> 0060: 03 55 04 03 ; >> 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 >> 006d: 30 1e ; SEQUENCE [30] >> 006f: 17 ; UTCTIME [13] '150526221718Z' >> 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; >> 007e: 17 0d ; UTCTIME [13] '250523221718Z' >> 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; >> >> ... ... >> >> 00db: 30 82 01 22 ; SEQUENCE [290] >> 00df: 30 ; SEQUENCE [13] >> 00e0: 0d ; >> 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) >> 00ec: 05 00 ; NULL >> 00ee: 03 82 ; BIT STRING [271] >> 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; >> >> ... >> >> 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; >> 0200: 01 ; >> 0201: a3 7b ; CONTEXT cons 3 [123] >> 0203: 30 79 ; SEQUENCE [121] >> 0205: 30 09 ; SEQUENCE [9] >> 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) >> 020c: 04 02 30 00 ; OCTET STRING [2] >> 0210: 30 2c ; SEQUENCE [44] >> 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 >> 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated >> Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; >> 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; >> 023e: 30 1d ; SEQUENCE [29] >> 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) >> 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] >> 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; >> 025d: 30 1f ; SEQUENCE [31] >> 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) >> 0260: 03 55 1d 23 ; >> 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] >> 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; >> 027e: 30 0d ; SEQUENCE [13] >> 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> 028b: 05 00 ; NULL >> 028d: 03 82 01 ; BIT STRING [257] >> 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; >> >> ... >> >> 0390: 6d 94 ; > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Small cleanups to javadoc and code Just some comments based on the output example. test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 228: > 226: break; > 227: > 228: case TAG_OctetString: I'd rather print nothing for OCTET STRING. My understanding of it is opaque octets and not meant to be printable. test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 362: > 360: switch (tag & 0xc0) { > 361: case TAG_APPLICATION: > 362: return "APPLICATION " + cons + (tag & 0x1f); I am not sure how important it is to print out "cons". Also, the tag here is usually shown as "[1]" in ASN.1 definition. Of course, if you choose this style, you might want to avoid using brackets for length. test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 355: > 353: String cons = isConstructed(tag) ? "cons " : ""; > 354: if (tag > 0 && tag < tagNames.length) > 355: return tagNames[tag] + " " + cons; Extra space when cons is "". ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From igraves at openjdk.java.net Mon Sep 21 14:20:23 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 21 Sep 2020 14:20:23 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v9] In-Reply-To: References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Sat, 19 Sep 2020 16:04:36 GMT, Alan Bateman wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Using File.walk for copy > > test/jdk/tools/jlink/JLinkReproducible3Test.java line 112: > >> 110: } >> 111: } >> 112: > > The update to ImageFileCreator looks good. > > A few nits in JLinkReproducible3Test: > 1. Invoking copyJDKs with two destination locations looks a bit strange. I think would be easier for future maintainers > if it does one copy and is called twice. 2. Files.copy will create a directory, no need for Files.createDirectories. > 3. Are you sure that bin/jlink is executable, I just wonder if the test runs with the patch have ended up depending the > umask at the time. It is possible to specify COPY_ATTRIBUTES to the copy method and it will attempt to copy the > permissions. 4. The variable naming is more like C style, so a bit inconsistent with the naming usually used in Java > programs. 1. I agree that it's awkward and I'm not a huge fan. I'm okay doing it this way, but this is recreating the reproducer for https://bugs.openjdk.java.net/browse/JDK-8252730 which is two identical JDK's in different directories. I can document this in the test further or we can change it. 2-4: Noted. Will clean these up and loop back. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From asemenyuk at openjdk.java.net Mon Sep 21 14:41:56 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 21 Sep 2020 14:41:56 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests In-Reply-To: References: Message-ID: On Sat, 19 Sep 2020 02:42:27 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8231591 > > - Added MultiLauncherTwoPhaseTest which uses predefine app image with multiple launcher and tests to make sure installer > will create shortcuts for all launchers. > - Fixed Linux DesktopIntegration to create shortcuts for additional launcher if we using pre-define app image. How about testing of other jpackage command line options in two phase mode? Like "--name", "--version"? Any plans to add them? src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/DesktopIntegration.java line 549: > 547: private final List associations; > 548: > 549: private static boolean initAppImageLaunchers = true; What is the logic behind static variable? test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 140: > 138: cmd.verifyIsOfType(PackageType.WINDOWS); > 139: this.cmd = cmd; > 140: this.name = name; I'd suggest to have the following initialization of "name" field: `this.name = (name == null ? cmd.name() : name)` This will help to avoid multiple `(name == null ? cmd.name() : name)` in the code. test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java line 54: > 52: public class MultiLauncherTwoPhaseTest { > 53: > 54: public static void main(String[] args) throws Exception { Please replace main() function with dedicated test function. You can use SimplePackageTest as a template, This would give better control on how to run the test in debug mode. test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java line 94: > 92: launcher2.verify(cmd); > 93: launcher2.verifyPackageInstalled(cmd); > 94: }); Looks like a duplicate of verify logic added with the preceding addInstallVerifier() call. test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java line 80: > 78: }) > 79: .addInstallVerifier(cmd -> { > 80: launcher1.verify(cmd); There is no need in explicit call to AdditionalLauncher.verify() as this function is scheduled for the call from AdditionalLauncher.applyTo() call. Thus there is no need to change access to this function from "private" to "public" in your patch to AdditionalLauncher.java. test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java line 56: > 54: public static void main(String[] args) throws Exception { > 55: TKit.run(args, () -> { > 56: Path appimageOutput = TKit.workDir().resolve("appimage"); Please use TKit.createTempDirectory() to create directories for intermediate data of test runs. This allows clean multiple runs of the test in the same work directory. test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line 271: > 269: } else { > 270: TKit.assertPathExists(appInstallDir, false); > 271: } I don't understand what is going on here and why branching is required. Also seems like verifyPackageUninstalled() function is never called. test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java line 559: > 557: && !cmd.isPackageUnpacked( > 558: "Not verifying desktop integration")) { > 559: new WindowsHelper.DesktopIntegrationVerifier(cmd, null); I'd rather add a loop calling DesktopIntegrationVerifier() for all launchers than copy/paste the code in AdditionalLauncher.java ------------- Changes requested by asemenyuk (Committer). PR: https://git.openjdk.java.net/jdk/pull/263 From michaelm at openjdk.java.net Mon Sep 21 14:51:31 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 21 Sep 2020 14:51:31 GMT Subject: RFR: 8245194: Unix domain socket channel implementation [v5] In-Reply-To: References: Message-ID: > Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >>> think of that. >>> >>> There is a fair bit of other refactoring and simplification done also. Next version is at: >>> >>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >>> >> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the >> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved >> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a >> number points that require clarification to fully understand how this will work with relative, directly relative and >> drive relative paths. >> > > Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That > would leave WindowsPath unchanged. >> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >> to get the file path in bytes. >> > > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to > be useful by other components. >> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its >> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main >> issue is that class is that it means we end up with two classes with static factory methods doing the same thing). > > Okay, that does simplify it a bit. > > Thanks, > Michael. > >> -Alan. >> >> >> >> >> >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: unixdomainchannels: updates after comments sent by Alan 14 Sept ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/52/files - new: https://git.openjdk.java.net/jdk/pull/52/files/22f37a82..36695095 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=03-04 Stats: 1344 lines in 17 files changed: 604 ins; 704 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk/pull/52 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 alanb at openjdk.java.net Mon Sep 21 15:55:16 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 21 Sep 2020 15:55:16 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v9] In-Reply-To: References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Mon, 21 Sep 2020 14:17:18 GMT, Ian Graves wrote: >> test/jdk/tools/jlink/JLinkReproducible3Test.java line 112: >> >>> 110: } >>> 111: } >>> 112: >> >> The update to ImageFileCreator looks good. >> >> A few nits in JLinkReproducible3Test: >> 1. Invoking copyJDKs with two destination locations looks a bit strange. I think would be easier for future maintainers >> if it does one copy and is called twice. 2. Files.copy will create a directory, no need for Files.createDirectories. >> 3. Are you sure that bin/jlink is executable, I just wonder if the test runs with the patch have ended up depending the >> umask at the time. It is possible to specify COPY_ATTRIBUTES to the copy method and it will attempt to copy the >> permissions. 4. The variable naming is more like C style, so a bit inconsistent with the naming usually used in Java >> programs. > > 1. I agree that it's awkward and I'm not a huge fan. I'm okay doing it this way, but this is recreating the reproducer > for https://bugs.openjdk.java.net/browse/JDK-8252730 which is two identical JDK's in different directories. I can > document this in the test further or we can change it. 2-4: Noted. Will clean these up and loop back. Thanks! Whatever is easiest but 2 x copy tree would be simpler and the result should be two identical JDKs as reported in JDK-8252730. ------------- PR: https://git.openjdk.java.net/jdk/pull/156 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 lancea at openjdk.java.net Mon Sep 21 19:06:44 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 21 Sep 2020 19:06:44 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v4] In-Reply-To: References: Message-ID: > Hi all, > > Please review the fix for JDK-8252739 which addresses an issue introduced by > https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by > Deflater.setDictionary. Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and > java/util/jar JCK tests. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: More updates to testByteBufferDirect in DeflaterDictionaryTests.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/269/files - new: https://git.openjdk.java.net/jdk/pull/269/files/aac03e3e..f34a6702 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=269&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=269&range=02-03 Stats: 172 lines in 1 file changed: 72 ins; 69 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/269.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/269/head:pull/269 PR: https://git.openjdk.java.net/jdk/pull/269 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 lancea at openjdk.java.net Mon Sep 21 19:09:46 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 21 Sep 2020 19:09:46 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v3] In-Reply-To: <1UQRZ_pUR3pXgA7L0pfbBTxQ3X-WRgSwjB5gnk3tPX0=.7d73d858-6bbc-4f1d-9249-d8ca24b502ad@github.com> References: <1UQRZ_pUR3pXgA7L0pfbBTxQ3X-WRgSwjB5gnk3tPX0=.7d73d858-6bbc-4f1d-9249-d8ca24b502ad@github.com> Message-ID: <3b2JKgMDNyM_6bmOjRQHy6rYbmYU4HaLQ4zWsUxkI6g=.d8906f3d-a6d9-492c-a0de-e3d8f73e540c@github.com> On Mon, 21 Sep 2020 12:18:40 GMT, Alan Bateman wrote: > Update to Deflater.c looks good. > > DeflaterDictionaryTests looks like is a shaping up to be a good test for setDictionary. Are there other assertions that > should be checked, e.g. setDictionary(ByteBuffer) is specified to consume all bytes and it would be good to check that > the position is set to the limit. Also can the 2-arg setDictionary be tests, also corner cases such no bytes remaining > or invoked with null. I have logged JDK-8253444 to add more coverage for setDictionary. I would prefer to put this change back to address the offset not being used and improve the coverage afterwards. > The naming of the tests is a bit inconsistent, e.g. ByteArrayTest vs. testByteBufferDirect. In the naming then I would > use "Heap" instead of "Wrap", as in testHeapByteBuffer. I updated the test name(s). > > In passing: The tests can use try-finally to ensure that Deflater::end is invoked even when the test fails. String > repeat(int) could be used to avoid duplicating "Welcome to Us Open;". Missing space in several "if(...)" usages. Addressed the issues above. I have pushed the updated changes for review to the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/269 From herrick at openjdk.java.net Mon Sep 21 19:36:03 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 21 Sep 2020 19:36:03 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= [v2] In-Reply-To: References: Message-ID: > 8253149: Building an installer from invalid app image fails on Windows and Linux > When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a > warning message, and then complete the package anyway. Andy Herrick 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: - 8253149: Building an installer from invalid app image fails (revision 1) - Merge branch 'master' into JDK-8253149 - 8253149: Building an installer from invalid app image fails on Windows and Linux ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/271/files - new: https://git.openjdk.java.net/jdk/pull/271/files/6c089a95..e3f8a8fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=271&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=271&range=00-01 Stats: 12895 lines in 400 files changed: 7857 ins; 3987 del; 1051 mod Patch: https://git.openjdk.java.net/jdk/pull/271.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/271/head:pull/271 PR: https://git.openjdk.java.net/jdk/pull/271 From igraves at openjdk.java.net Mon Sep 21 20:05:00 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 21 Sep 2020 20:05:00 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v10] In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Using File.walk for copy - Cleanup extraneous directory ops - Changes to test 3 so correct JDK under test is run - Test 3 to non-tmp directory - Merging two tests and renaming a test - Merging tests and renaming test 4 - Copying test jdk to test consistency - Test updates - Comparator cleanup - Merging streams - ... and 1 more: https://git.openjdk.java.net/jdk/compare/2e30ff61...8faf1fda ------------- Changes: https://git.openjdk.java.net/jdk/pull/156/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=09 Stats: 134 lines in 3 files changed: 126 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/156/head:pull/156 PR: https://git.openjdk.java.net/jdk/pull/156 From vromero at openjdk.java.net Mon Sep 21 21:39:18 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 21 Sep 2020 21:39:18 GMT Subject: RFR: 8246774: Record Classes (final) implementation Message-ID: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Jonathan Gibbons Co-authored-by: Brian Goetz Co-authored-by: Maurizio Cimadamore Co-authored-by: Joe Darcy Co-authored-by: Chris Hegarty Co-authored-by: Jan Lahoda ------------- Commit messages: - 8246774: Record Classes (final) implementation Changes: https://git.openjdk.java.net/jdk/pull/290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246774 Stats: 495 lines in 95 files changed: 23 ins; 362 del; 110 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Mon Sep 21 21:39:18 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 21 Sep 2020 21:39:18 GMT Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Mon, 21 Sep 2020 21:30:51 GMT, Vicente Romero wrote: > Co-authored-by: Vicente Romero > Co-authored-by: Harold Seigel > Co-authored-by: Jonathan Gibbons > Co-authored-by: Brian Goetz > Co-authored-by: Maurizio Cimadamore > Co-authored-by: Joe Darcy > Co-authored-by: Chris Hegarty > Co-authored-by: Jan Lahoda Please review the fix for [1]. The intention of this patch is to make records final removing the need to use --enable-preview in order to be able to include a record declaration in a source or for the VM to execute code compiled from record classes, Thanks [1] https://bugs.openjdk.java.net/browse/JDK-8246774 ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From darcy at openjdk.java.net Mon Sep 21 21:56:01 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 21 Sep 2020 21:56:01 GMT Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Mon, 21 Sep 2020 21:36:39 GMT, Vicente Romero wrote: >> Co-authored-by: Vicente Romero >> Co-authored-by: Harold Seigel >> Co-authored-by: Jonathan Gibbons >> Co-authored-by: Brian Goetz >> Co-authored-by: Maurizio Cimadamore >> Co-authored-by: Joe Darcy >> Co-authored-by: Chris Hegarty >> Co-authored-by: Jan Lahoda > > Please review the fix for [1]. The intention of this patch is to make records final removing the need to > use --enable-preview in order to be able to include a record declaration in a source or for the VM to execute code > compiled from record classes, Thanks > > [1] https://bugs.openjdk.java.net/browse/JDK-8246774 Hi Vicente, Please file a separate subtask for the javax.lang.model changes. This helps with the JSR 269 MR paperwork. Thanks, -Joe ------------- PR: https://git.openjdk.java.net/jdk/pull/290 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 asemenyuk at openjdk.java.net Mon Sep 21 23:23:35 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 21 Sep 2020 23:23:35 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= [v2] In-Reply-To: References: Message-ID: <9WDWY1qu012SNOW5PFJKd1W4ruE5jHB0dwxaZRLi4T0=.b19690f2-70ad-4d6f-90d1-8e6c606bfdf3@github.com> On Mon, 21 Sep 2020 19:36:03 GMT, Andy Herrick wrote: >> 8253149: Building an installer from invalid app image fails on Windows and Linux >> When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a >> warning message, and then complete the package anyway. > > Andy Herrick 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: > - 8253149: Building an installer from invalid app image fails (revision 1) > - Merge branch 'master' into JDK-8253149 > - 8253149: Building an installer from invalid app image fails on Windows and Linux test/jdk/tools/jpackage/share/AppImagePackageTest.java line 26: > 24: import java.nio.file.Path; > 25: import java.nio.file.Files; > 26: import java.io.BufferedWriter; Seems like this import is not needed any more. src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/resources/LinuxResources.properties line 64: > 62: message.rpm-ldd-not-available.advice=Install "glibc-common" RPM package to get ldd. > 63: > 64: warning.forign-app-image=Warning: app-image dir not generated by jpackage. Should it be "foreign" instead of "forign"? ------------- PR: https://git.openjdk.java.net/jdk/pull/271 From vromero at openjdk.java.net Mon Sep 21 23:24:57 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 21 Sep 2020 23:24:57 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v2] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <_6qw2pA7HDrTWsZPIpQOAjSE14-9iULneDMN_o9ixNw=.0a72cfba-bb8c-454e-bfc7-44553f11bbe1@github.com> > Co-authored-by: Vicente Romero > Co-authored-by: Harold Seigel > Co-authored-by: Jonathan Gibbons > Co-authored-by: Brian Goetz > Co-authored-by: Maurizio Cimadamore > Co-authored-by: Joe Darcy > Co-authored-by: Chris Hegarty > Co-authored-by: Jan Lahoda Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing the javax.lang.model related code to be moved to a separate bug ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/9eedb3ab..543e5054 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=00-01 Stats: 134 lines in 12 files changed: 130 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Mon Sep 21 23:24:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 21 Sep 2020 23:24:58 GMT Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Mon, 21 Sep 2020 21:53:05 GMT, Joe Darcy wrote: >> Please review the fix for [1]. The intention of this patch is to make records final removing the need to >> use --enable-preview in order to be able to include a record declaration in a source or for the VM to execute code >> compiled from record classes, Thanks >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8246774 > > Hi Vicente, > Please file a separate subtask for the javax.lang.model changes. This helps with the JSR 269 MR paperwork. > Thanks, > -Joe note: I have removed from the original patch the code related to javax.lang.model, I will publish them in a separate PR ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From almatvee at openjdk.java.net Mon Sep 21 23:41:25 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 21 Sep 2020 23:41:25 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 14:05:08 GMT, Alexey Semenyuk wrote: >> https://bugs.openjdk.java.net/browse/JDK-8231591 >> >> - Added MultiLauncherTwoPhaseTest which uses predefine app image with multiple launcher and tests to make sure installer >> will create shortcuts for all launchers. >> - Fixed Linux DesktopIntegration to create shortcuts for additional launcher if we using pre-define app image. > > src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/DesktopIntegration.java line 549: > >> 547: private final List associations; >> 548: >> 549: private static boolean initAppImageLaunchers = true; > > What is the logic behind static variable? It is used to avoid infinite calls in DesktopIntegration(). I modified it by removing PREDEFINED_APP_IMAGE from launcherParams. ------------- PR: https://git.openjdk.java.net/jdk/pull/263 From sspitsyn at openjdk.java.net Tue Sep 22 00:41:05 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 22 Sep 2020 00:41:05 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 07:45:52 GMT, Goetz Lindenmaier wrote: >> Marked as reviewed by goetz (Reviewer). > > Reviewed in the good old hg times :) > See also http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041453.html src/hotspot/share/opto/macro.cpp: @@ -1091,11 +1091,11 @@ bool PhaseMacroExpand::eliminate_allocate_node(AllocateNode *alloc) { // Don't do scalar replacement if the frame can be popped by JVMTI: // if reallocation fails during deoptimization we'll pop all // interpreter frames for this compiled frame and that won't play // nice with JVMTI popframe. - if (!EliminateAllocations || JvmtiExport::can_pop_frame() || !alloc->_is_non_escaping) { + if (!EliminateAllocations || !alloc->_is_non_escaping) { return false; } I wonder if the comment is still correct after you removed the check for JvmtiExport::can_pop_frame(). ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From igraves at openjdk.java.net Tue Sep 22 01:25:16 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 22 Sep 2020 01:25:16 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v11] In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Cleanup on Test 3 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/156/files - new: https://git.openjdk.java.net/jdk/pull/156/files/8faf1fda..3cf1498e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=156&range=09-10 Stats: 37 lines in 1 file changed: 6 ins; 17 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/156/head:pull/156 PR: https://git.openjdk.java.net/jdk/pull/156 From igraves at openjdk.java.net Tue Sep 22 01:25:17 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 22 Sep 2020 01:25:17 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v9] In-Reply-To: References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Mon, 21 Sep 2020 15:52:15 GMT, Alan Bateman wrote: >> 1. I agree that it's awkward and I'm not a huge fan. I'm okay doing it this way, but this is recreating the reproducer >> for https://bugs.openjdk.java.net/browse/JDK-8252730 which is two identical JDK's in different directories. I can >> document this in the test further or we can change it. 2-4: Noted. Will clean these up and loop back. Thanks! > > Whatever is easiest but 2 x copy tree would be simpler and the result should be two identical JDKs as reported in > JDK-8252730. I misunderstood what you meant when I read it earlier today, apologies! The new changes should address these enumerated issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From sspitsyn at openjdk.java.net Tue Sep 22 01:37:23 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 22 Sep 2020 01:37:23 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 00:38:43 GMT, Serguei Spitsyn wrote: >> Reviewed in the good old hg times :) >> See also http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041453.html > > Hi Richard, > > Could you consider to place the classes EscapeBarrier and JvmtiDeferredUpdates into theyr own .hpp/.cpp files? The > class JvmtiDeferredUpdates would be better to put into the folder 'prims' then. > src/hotspot/share/opto/macro.cpp: > @@ -1091,11 +1091,11 @@ > bool PhaseMacroExpand::eliminate_allocate_node(AllocateNode *alloc) { > // Don't do scalar replacement if the frame can be popped by JVMTI: > // if reallocation fails during deoptimization we'll pop all > // interpreter frames for this compiled frame and that won't play > // nice with JVMTI popframe. > - if (!EliminateAllocations || JvmtiExport::can_pop_frame() || !alloc->_is_non_escaping) { > + if (!EliminateAllocations || !alloc->_is_non_escaping) { > return false; > } > > I wonder if the comment is still correct after you removed the check for JvmtiExport::can_pop_frame(). > > src/hotspot/share/runtime/deoptimization.hpp: > > + EscapeBarrier(JavaThread* calling_thread, JavaThread* deoptee_thread, bool barrier_active) > + : _calling_thread(calling_thread), _deoptee_thread(deoptee_thread), > + _barrier_active(barrier_active && (JVMCI_ONLY(UseJVMCICompiler) NOT_JVMCI(false) > + COMPILER2_PRESENT(|| DoEscapeAnalysis))) > . . . . . . . . . > + > + // Revert ea based optimizations for all java threads > + EscapeBarrier(JavaThread* calling_thread, bool barrier_active) > + : _calling_thread(calling_thread), _deoptee_thread(NULL), > > Nit: would better to make the parameter deoptee_thread to be the 3rd to better mach the seconf constructor. > > + bool all_threads() const { return _deoptee_thread == NULL; } // Should revert optimizations for all > threads. + bool self_deopt() const { return _calling_thread == _deoptee_thread; } // Current thread deoptimizes > its own objects. + bool barrier_active() const { return _barrier_active; } // Inactive barriers are > created if no local objects can escape. > I'd suggest to put comments in a line before function definitions as it is done for other declarations/definitions. src/hotspot/share/runtime/deoptimization.cpp: @@ -349,12 +408,12 @@ // Now that the vframeArray has been created if we have any deferred local writes // added by jvmti then we can free up that structure as the data is now in the // vframeArray - if (thread->deferred_locals() != NULL) { - GrowableArray* list = thread->deferred_locals(); + if (JvmtiDeferredUpdates::deferred_locals(thread) != NULL) { + GrowableArray* list = JvmtiDeferredUpdates::deferred_locals(thread); int i = 0; do { // Because of inlining we could have multiple vframes for a single frame // and several of the vframes could have deferred writes. Find them all. if (list->at(i)->id() == array->original().id()) { @@ -365,13 +424,14 @@ } else { i++; } } while ( i < list->length() ); if (list->length() == 0) { - thread->set_deferred_locals(NULL); - // free the list and elements back to C heap. - delete list; + JvmtiDeferredUpdates* updates = thread->deferred_updates(); + thread->set_deferred_updates(NULL); + // free deferred updates. + delete updates; } It is not clear why the 'list' is not deleted anymore. If it is intentional then could you, please, add a comment with an explanation? ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From kvn at openjdk.java.net Tue Sep 22 02:34:04 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 22 Sep 2020 02:34:04 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> Message-ID: On Mon, 21 Sep 2020 09:20:56 GMT, Andrew Dinn wrote: >>> Can you explain where this restricted effect is documented? >> >> Certainly! I?ve found that determining the capability of the CPU and whether to enable AVX2 support if the chip >> supports it is mostly controlled in: [vm_version_x86.cpp]( >> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp) specifically: >> [get_processor_features](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L684-L755) >> and in [generate_get_cpu_info]( >> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L69-L611). In order to test the >> patch comprehensively I had to track down an Intel Core i7 (I7-9750H) processor which the aforementioned code permitted >> AVX2 instructions for (maybe this is an error and it should not be enabled for this processor though) as most of the >> infrastructure I personally use here at AWS runs on Intel Xeon processors - I also tested on a E5-2680 which the JVM >> does not enable AVX2 for. However, this is just the Intel side of things. When it comes to AMD I read that the AMD Zen >> 2 architecture, of which the current flagship: Threadripper 3990X, is based, is able to support AVX2 [without the >> frequency scaling]( >> https://www.anandtech.com/Show/Index/14525?cPage=7&all=False&sort=0&page=9&slug=amd-zen-2-microarchitecture-analysis-ryzen-3000-and-epyc-rome) >> which some/all(?) of the Intel chips incur. I personally don?t have access to one of these chips so I cannot confirm >> how it is classified in the JVM. Also, I found when investigating this that there is actually a JVM flag which can be >> used to control what level of AVX is enabled: `-XX:UseAVX=version.` > >> > Can you explain where this restricted effect is documented? > >> Certainly! I?ve found that determining the capability of the CPU and whether to enable AVX2 support if the chip >> supports it is mostly controlled in: vm_version_x86.cpp specifically: get_processor_features and in >> generate_get_cpu_info. > > Yes, I can see what the code does. I was asking where the cpu behaviour is documented independent of the code. > >> In order to test the patch comprehensively I had to track down an Intel Core i7 (I7-9750H) processor which the >> aforementioned code permitted AVX2 instructions for (maybe this is an error and it should not be enabled for this >> processor though) as most of the infrastructure I personally use here at AWS runs on Intel Xeon processors - I also >> tested on a E5-2680 which the JVM does not enable AVX2 for. > > 'maybe'? The documentation Andrew provided mentioned Xeon E5 v3 which I believe is a Skylake design. However, the code > I pointed you at in vm_version_x86 which claims to detect 'early Skylake' designs is only disabling AVX512 support. It > still enables AVX2. Similarly, the code that generates machine code to check the processor capabilities has a special > check if use_evex is set (i.e. AVX3 is requested) which disables AVX512 for Skylake but does not disable AVX2 support. >> However, this is just the Intel side of things. When it comes to AMD I read that the AMD Zen 2 architecture, of which >> the current flagship: Threadripper 3990X, is based, is able to support AVX2 without the frequency scaling which >> some/all(?) of the Intel chips incur. I personally don?t have access to one of these chips so I cannot confirm how it >> is classified in the JVM. > > Well, it would be good to know where you read that and to see if that confirms thar the code is avoiding the issue > Andrew raised. >> Also, I found when investigating this that there is actually a JVM flag which can be used to control what level of AVX >> is enabled: -XX:UseAVX=version. > > Yes, indeed. However, what I am trying to understand is whether the current code is bypassing the problem Andrew > brought up in the cases where that problem actually exists. It doesn't look like it so far given that the problem > applies to AVX2 and only AVX512 support is being disabled and, even then only for some (Skylake) processors. Without > some clear documentation of what processors suffer from this power surge problem it will not be possible to decide > whether this patch is doing the right thing or not. Based on comment by @jatin-bhateja (Intel) frequency level switchover pointed by @theRealAph is sensitive to vector size https://github.com/openjdk/jdk/pull/144#issuecomment-692044896 By keeping vector size less or equal to 32 bytes we should avoid it. And as I can see this intrinsic code is using 32 bytes (chars) and 16 bytes vectors: `pbroadcastb(vec1, vec1, Assembler::AVX_256bit);` Also we never had issues with AVX2. only with AVX512 regarding performance hit: https://bugs.openjdk.java.net/browse/JDK-8221092 I would like to see performance numbers for for all values of UseAVX flag : 0, 1, 2, 3 The usage is guarded UseSSE42Intrinsics in UseSSE42Intrinsics predicate in .ad file. Make sure to test with UseAVX=0 to make sure that some avx instructions are not mixed into non avx code. And also with UseSSE=2 (for example) to make sure shared code correctly recognize that intrinsics is not supported. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From almatvee at openjdk.java.net Tue Sep 22 02:52:52 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 22 Sep 2020 02:52:52 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 14:39:33 GMT, Alexey Semenyuk wrote: > How about testing of other jpackage command line options in two phase mode? Like "--name", "--version"? Any plans to > add them? Plan was to file separate bugs for any additional options. I do not think we should put everything in one issue. This issue for desktop integration for additional launchers. > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 140: > >> 138: cmd.verifyIsOfType(PackageType.WINDOWS); >> 139: this.cmd = cmd; >> 140: this.name = name; > > I'd suggest to have the following initialization of "name" field: > `this.name = (name == null ? cmd.name() : name)` > This will help to avoid multiple `(name == null ? cmd.name() : name)` in the code. Fixed. > test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java line 54: > >> 52: public class MultiLauncherTwoPhaseTest { >> 53: >> 54: public static void main(String[] args) throws Exception { > > Please replace main() function with dedicated test function. You can use SimplePackageTest as a template, This would > give better control on how to run the test in debug mode. Fixed. > test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java line 56: > >> 54: public static void main(String[] args) throws Exception { >> 55: TKit.run(args, () -> { >> 56: Path appimageOutput = TKit.workDir().resolve("appimage"); > > Please use TKit.createTempDirectory() to create directories for intermediate data of test runs. This allows clean > multiple runs of the test in the same work directory. Fixed. > test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java line 80: > >> 78: }) >> 79: .addInstallVerifier(cmd -> { >> 80: launcher1.verify(cmd); > > There is no need in explicit call to AdditionalLauncher.verify() as this function is scheduled for the call from > AdditionalLauncher.applyTo() call. Thus there is no need to change access to this function from "private" to "public" > in your patch to AdditionalLauncher.java. Fixed. > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java line 559: > >> 557: && !cmd.isPackageUnpacked( >> 558: "Not verifying desktop integration")) { >> 559: new WindowsHelper.DesktopIntegrationVerifier(cmd, null); > > I'd rather add a loop calling DesktopIntegrationVerifier() for all launchers than copy/paste the code in > AdditionalLauncher.java Fixed. I also removed code from AdditionalLaunchers. ------------- PR: https://git.openjdk.java.net/jdk/pull/263 From almatvee at openjdk.java.net Tue Sep 22 03:03:44 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 22 Sep 2020 03:03:44 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests [v2] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8231591 > > - Added MultiLauncherTwoPhaseTest which uses predefine app image with multiple launcher and tests to make sure installer > will create shortcuts for all launchers. > - Fixed Linux DesktopIntegration to create shortcuts for additional launcher if we using pre-define app image. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8231591: [TESTBUG] Create additional two phase jpackage tests (revision 1) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/263/files - new: https://git.openjdk.java.net/jdk/pull/263/files/e5254d22..5303fcc0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=263&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=263&range=00-01 Stats: 107 lines in 5 files changed: 20 ins; 52 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/263.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/263/head:pull/263 PR: https://git.openjdk.java.net/jdk/pull/263 From mbalao at redhat.com Tue Sep 22 04:48:44 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 22 Sep 2020 01:48:44 -0300 Subject: RFR 8253451: Performance regression in java.util.Scanner after 8236201 Message-ID: <14a6a9f7-0ee3-e2af-45b4-6a5c39bdfe0b@redhat.com> Hi, I'd like to propose a fix for JDK-8253451 [1] performance regression. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8253451/8253451.webrev.00 As explained in [1], the idea for the fix is to optimize the regexp string for the most common group and decimal separator characters across locales. Please note that there are a few locales where the proposed optimization does not apply and the slower -but safe- regexp introduced by 8236201 is used. Testing: * No regressions observed in jdk/java/util/Scanner (5/5 passed) * Verified performance improvement back to what it was before 8236201 (on my Americas locale). Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8253451 From github.com+35809+mknjc at openjdk.java.net Tue Sep 22 04:56:09 2020 From: github.com+35809+mknjc at openjdk.java.net (mknjc) Date: Tue, 22 Sep 2020 04:56:09 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> Message-ID: On Fri, 18 Sep 2020 23:11:46 GMT, Jason Tatton wrote: >> "the JVM has knowledge of the AVX capability of the chip it?s running on and disables the AVX2 code path for chips >> which suffer from the performance degradation which has been outlined in this discussion" >> Does it? The white paper Andrew cited doesn't mention this as being specific to only some chips that implement AVX2. >> Can you explain where this restricted effect is documented? >> Also, I assume you are referring to the code in vm_version_x86.cpp with this comment >> >> // Don't use AVX-512 on older Skylakes unless explicitly requested >> >> is that correct? > >> Can you explain where this restricted effect is documented? > > Certainly! I?ve found that determining the capability of the CPU and whether to enable AVX2 support if the chip > supports it is mostly controlled in: [vm_version_x86.cpp]( > https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp) specifically: > [get_processor_features](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L684-L755) > and in [generate_get_cpu_info]( > https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L69-L611). In order to test the > patch comprehensively I had to track down an Intel Core i7 (I7-9750H) processor which the aforementioned code permitted > AVX2 instructions for (maybe this is an error and it should not be enabled for this processor though) as most of the > infrastructure I personally use here at AWS runs on Intel Xeon processors - I also tested on a E5-2680 which the JVM > does not enable AVX2 for. However, this is just the Intel side of things. When it comes to AMD I read that the AMD Zen > 2 architecture, of which the current flagship: Threadripper 3990X, is based, is able to support AVX2 [without the > frequency scaling]( > https://www.anandtech.com/Show/Index/14525?cPage=7&all=False&sort=0&page=9&slug=amd-zen-2-microarchitecture-analysis-ryzen-3000-and-epyc-rome) > which some/all(?) of the Intel chips incur. I personally don?t have access to one of these chips so I cannot confirm > how it is classified in the JVM. Also, I found when investigating this that there is actually a JVM flag which can be > used to control what level of AVX is enabled: `-XX:UseAVX=version.` I really don't see the problem with using AVX for this? As long as the used instructions all only activate license l0 the cpu don't scale the frequency at all. For AVX2 these are most of all instructions which don't use the FMA or floating point ports. Additionally the cpu doesn't instant scale down the frequency but runs the 256 bit instructions with reduced throughput but full cpu clock until enough instructions use the avx command set. For more information see https://stackoverflow.com/a/56861355/130541 So as long the 512bit width instructions aren't used there should no frequency scaling happening. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 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 kustos at gmx.net Tue Sep 22 05:57:45 2020 From: kustos at gmx.net (Philippe Marschall) Date: Tue, 22 Sep 2020 07:57:45 +0200 Subject: Looking for a sponsor for JDK-8138732 Message-ID: <17d66481-a8d2-8f37-857e-9e1e9707b700@gmx.net> Hello I am looking for a sponsor for JDK-8138732 [1]. The ready to integrate PR is here [2]. Changes between the current code and the reviewed code: - I removed the jdk.internal export to jdk.jfr, that was a review comment. - I had to rebase and resolve a merge conflict with JDK-8243066. [1] https://bugs.openjdk.java.net/browse/JDK-8138732 [2] https://github.com/openjdk/jdk/pull/45 Cheers Philippe From david.holmes at oracle.com Tue Sep 22 06:31:05 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Sep 2020 16:31:05 +1000 Subject: Looking for a sponsor for JDK-8138732 In-Reply-To: <17d66481-a8d2-8f37-857e-9e1e9707b700@gmx.net> References: <17d66481-a8d2-8f37-857e-9e1e9707b700@gmx.net> Message-ID: <60472904-3987-b87d-1112-23ea77e0bc87@oracle.com> Hi Philippe, On 22/09/2020 3:57 pm, Philippe Marschall wrote: > Hello > > I am looking for a sponsor for JDK-8138732 [1]. The ready to integrate > PR is here [2]. Sorry I can't volunteer to sponsor this. > Changes between the current code and the reviewed code: > > - I removed the jdk.internal export to jdk.jfr, that was a review comment. > - I had to rebase and resolve a merge conflict with JDK-8243066. @marschall marschall force-pushed the marschall:JDK-8138732 branch from 1c9dd9d to 5c49560 1 hour ago 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. Thanks, David ----- > ?[1] https://bugs.openjdk.java.net/browse/JDK-8138732 > ?[2] https://github.com/openjdk/jdk/pull/45 > > Cheers > Philippe From alanb at openjdk.java.net Tue Sep 22 07:24:39 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 22 Sep 2020 07:24:39 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v11] In-Reply-To: References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Tue, 22 Sep 2020 01:25:16 GMT, Ian Graves wrote: >> Related to [JDK-8252730 jlink does not create reproducible builds on different >> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to >> ensure stable files (and file signatures) across generated JDK images by jlink. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup on Test 3 Marked as reviewed by alanb (Reviewer). test/jdk/tools/jlink/JLinkReproducible3Test.java line 67: > 65: > 66: Path copiedJlink1 = Optional.of( > 67: Paths.get(copyJdk1Dir.toString(), "bin", "jlink")) Could use copyJDk1Dir.resolve("bin").resolve("jlink") here to avoid going to strings and back. ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From alanb at openjdk.java.net Tue Sep 22 07:24:39 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 22 Sep 2020 07:24:39 GMT Subject: RFR: 8252730: jlink does not create reproducible builds on different servers [v9] In-Reply-To: References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Tue, 22 Sep 2020 01:22:03 GMT, Ian Graves wrote: >> Whatever is easiest but 2 x copy tree would be simpler and the result should be two identical JDKs as reported in >> JDK-8252730. > > I misunderstood what you meant when I read it earlier today, apologies! The new changes should address these enumerated > issues. The updated test looks okay, I can sponsor if you need it. ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From alanb at openjdk.java.net Tue Sep 22 07:31:30 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 22 Sep 2020 07:31:30 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v4] In-Reply-To: References: Message-ID: <6TrvHmNuobAHdUK6UP1KgBje0n0noCPbEGc8p5Bskx4=.8ab6de86-394a-4739-bcac-3e03b83ae2ce@github.com> On Mon, 21 Sep 2020 19:06:44 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for JDK-8252739 which addresses an issue introduced by >> https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by >> Deflater.setDictionary. Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and >> java/util/jar JCK tests. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > More updates to testByteBufferDirect in DeflaterDictionaryTests.java Given that the offset handling is buggy then I think the test should at least cover the cases where the offset is 0 or out of bounds. No problem separating out further test coverage for the other setDictionary methods into a separate issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/269 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 adinn at openjdk.java.net Tue Sep 22 09:01:22 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 22 Sep 2020 09:01:22 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> Message-ID: On Tue, 22 Sep 2020 02:31:14 GMT, Vladimir Kozlov wrote: >>> > Can you explain where this restricted effect is documented? >> >>> Certainly! I?ve found that determining the capability of the CPU and whether to enable AVX2 support if the chip >>> supports it is mostly controlled in: vm_version_x86.cpp specifically: get_processor_features and in >>> generate_get_cpu_info. >> >> Yes, I can see what the code does. I was asking where the cpu behaviour is documented independent of the code. >> >>> In order to test the patch comprehensively I had to track down an Intel Core i7 (I7-9750H) processor which the >>> aforementioned code permitted AVX2 instructions for (maybe this is an error and it should not be enabled for this >>> processor though) as most of the infrastructure I personally use here at AWS runs on Intel Xeon processors - I also >>> tested on a E5-2680 which the JVM does not enable AVX2 for. >> >> 'maybe'? The documentation Andrew provided mentioned Xeon E5 v3 which I believe is a Skylake design. However, the code >> I pointed you at in vm_version_x86 which claims to detect 'early Skylake' designs is only disabling AVX512 support. It >> still enables AVX2. Similarly, the code that generates machine code to check the processor capabilities has a special >> check if use_evex is set (i.e. AVX3 is requested) which disables AVX512 for Skylake but does not disable AVX2 support. >>> However, this is just the Intel side of things. When it comes to AMD I read that the AMD Zen 2 architecture, of which >>> the current flagship: Threadripper 3990X, is based, is able to support AVX2 without the frequency scaling which >>> some/all(?) of the Intel chips incur. I personally don?t have access to one of these chips so I cannot confirm how it >>> is classified in the JVM. >> >> Well, it would be good to know where you read that and to see if that confirms thar the code is avoiding the issue >> Andrew raised. >>> Also, I found when investigating this that there is actually a JVM flag which can be used to control what level of AVX >>> is enabled: -XX:UseAVX=version. >> >> Yes, indeed. However, what I am trying to understand is whether the current code is bypassing the problem Andrew >> brought up in the cases where that problem actually exists. It doesn't look like it so far given that the problem >> applies to AVX2 and only AVX512 support is being disabled and, even then only for some (Skylake) processors. Without >> some clear documentation of what processors suffer from this power surge problem it will not be possible to decide >> whether this patch is doing the right thing or not. > > Based on comment by @jatin-bhateja (Intel) frequency level switchover pointed by @theRealAph is sensitive to vector > size https://github.com/openjdk/jdk/pull/144#issuecomment-692044896 > > By keeping vector size less or equal to 32 bytes we should avoid it. And as I can see this intrinsic code is using 32 > bytes (chars) and 16 bytes vectors: `pbroadcastb(vec1, vec1, Assembler::AVX_256bit);` > Also we never had issues with AVX2. only with AVX512 regarding performance hit: > https://bugs.openjdk.java.net/browse/JDK-8221092 > > I would like to see performance numbers for for all values of UseAVX flag : 0, 1, 2, 3 > > The usage is guarded UseSSE42Intrinsics in UseSSE42Intrinsics predicate in .ad file. Make sure to test with UseAVX=0 to > make sure that some avx instructions are not mixed into non avx code. And also with UseSSE=2 (for example) to make sure > shared code correctly recognize that intrinsics is not supported. @vnkozlov @mknjc @jatin-bhateja Thanks for providing the relevant details. I'm now quite content that this patch avoids any potential frequency scaling problem. I'm also glad that an explanation of why this is so is now available -- although it's not perfect that we are relying on a stackoverflow post for the full details. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From almatvee at openjdk.java.net Tue Sep 22 09:20:33 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 22 Sep 2020 09:20:33 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests [v3] In-Reply-To: References: Message-ID: <-ImMqcEBQNXF3cpNKUZfynd2-u4epkNveyXmw9yjpT0=.6fcf5ecb-53ee-473b-b720-864c224bd313@github.com> > https://bugs.openjdk.java.net/browse/JDK-8231591 > > - Added MultiLauncherTwoPhaseTest which uses predefine app image with multiple launcher and tests to make sure installer > will create shortcuts for all launchers. > - Fixed Linux DesktopIntegration to create shortcuts for additional launcher if we using pre-define app image. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8231591: [TESTBUG] Create additional two phase jpackage tests (revision 2) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/263/files - new: https://git.openjdk.java.net/jdk/pull/263/files/5303fcc0..650cf21e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=263&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=263&range=01-02 Stats: 20 lines in 1 file changed: 10 ins; 9 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/263.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/263/head:pull/263 PR: https://git.openjdk.java.net/jdk/pull/263 From chegar at openjdk.java.net Tue Sep 22 09:51:59 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 22 Sep 2020 09:51:59 GMT Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Mon, 21 Sep 2020 23:21:18 GMT, Vicente Romero wrote: >> Hi Vicente, >> Please file a separate subtask for the javax.lang.model changes. This helps with the JSR 269 MR paperwork. >> Thanks, >> -Joe > > note: I have removed from the original patch the code related to javax.lang.model, I will publish them in a separate PR @vicente-romero-oracle I noticed that we can also remove the preview args from the record serialization tests and ObjectMethodsTest. I opened a PR against the branch in your fork. You should be able to just merge in the changes. See https://github.com/vicente-romero-oracle/jdk/pull/1 ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From andreas at ahlenstorf.ch Tue Sep 22 10:30:42 2020 From: andreas at ahlenstorf.ch (Andreas Ahlenstorf) Date: Tue, 22 Sep 2020 12:30:42 +0200 Subject: Math.exp() yields different results on 32 bit systems Message-ID: Hi! According to a bug report at AdoptOpenJDK [1] Math.exp(10_000.0) yields different results on 32 bit systems than on 64 bit systems. public class Test { public static void main(String[] args) { System.out.println(Math.exp(10_000.0)); } } On 64 bit systems the code above prints Infinity. On 32 bit systems the result is 0.0. I think that's wrong, but I'm far from an expert in floating point arithmetics. Affected versions: * OpenJDK 9.0.1 * OpenJDK 11.0.8 * OpenJDK 15 Not affected: * OpenJDK 8u265 We tested both with AdoptOpenJDK and Azul Zulu on Windows and Linux on x86 and x64. If we disable intrinsics (-XX:+UnlockDiagnosticVMOptions -XX:-UseLibmIntrinsic), Infinity is printed on x86 systems, too. Is this expected behavior? Best, Andreas [1] https://github.com/AdoptOpenJDK/openjdk-support/issues/182 From herrick at openjdk.java.net Tue Sep 22 11:53:14 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 22 Sep 2020 11:53:14 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= [v3] In-Reply-To: References: Message-ID: > 8253149: Building an installer from invalid app image fails on Windows and Linux > When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a > warning message, and then complete the package anyway. Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: 8253149: Building an installer from invalid app image fails (revision 2) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/271/files - new: https://git.openjdk.java.net/jdk/pull/271/files/e3f8a8fa..48001605 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=271&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=271&range=01-02 Stats: 5 lines in 5 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/271.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/271/head:pull/271 PR: https://git.openjdk.java.net/jdk/pull/271 From dfuchs at openjdk.java.net Tue Sep 22 12:36:09 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 22 Sep 2020 12:36:09 GMT Subject: RFR: 8251188: Update LDAP tests not to use wildcard addresses In-Reply-To: <-CMY39b696CBNg4cyddo-t2KEl5vfYR8ACeoJA7p13I=.e1b457e5-5bbc-4ae6-a69a-c44916326abe@github.com> References: <-CMY39b696CBNg4cyddo-t2KEl5vfYR8ACeoJA7p13I=.e1b457e5-5bbc-4ae6-a69a-c44916326abe@github.com> Message-ID: On Fri, 18 Sep 2020 12:59:07 GMT, Aleksei Efimov wrote: > Hi, > > Please help to review [JDK-8251188](https://bugs.openjdk.java.net/browse/JDK-8251188) fix which helps to improve LDAP > tests stability. The list of changes: 1. Usages of wildcard address have been replaced with loopback address. This > change includes addition of `LDAPTestUtils.initEnv` method that takes LDAP provider URL as a parameter. 2. > `DeadServerTimeoutSSLTest.java` was also updated to fix the intermittent failures reported by [JDK-8152654 > ](https://bugs.openjdk.java.net/browse/JDK-8152654) and > [JDK-8169942](https://bugs.openjdk.java.net/browse/JDK-8169942). Before the fix the failure rate was 1 out of 4 runs. > After the fix it was executed 400+ times alongside to other LDAP tests, and showed no failures, and therefore removed > from the problem list. Thank you, Aleksei Very good and thorough fix Aleksei! This looks mostly very good to me - and I have only one doubt, which I commented on in the code. test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java line 171: > 169: System.err.println("Server socket. Failure to accept connection:"); > 170: e.printStackTrace(); > 171: } I wonder if removing the while (true) loop will make the test more susceptible of failing in timeout if the server ever receives a connection request from an unexpected client (we've seen that happening in the past with networking tests). Is there anyway the server could attempt to verify that the accepted socket is from the expected client, and close it and go back to accepting if it's not? Maybe by looking at the accepted socket remote address & port? ------------- PR: https://git.openjdk.java.net/jdk/pull/252 From aefimov at openjdk.java.net Tue Sep 22 13:42:12 2020 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 22 Sep 2020 13:42:12 GMT Subject: RFR: 8251188: Update LDAP tests not to use wildcard addresses In-Reply-To: References: <-CMY39b696CBNg4cyddo-t2KEl5vfYR8ACeoJA7p13I=.e1b457e5-5bbc-4ae6-a69a-c44916326abe@github.com> Message-ID: <5pZnmegkI2FKIfpiCD7jOeEdP1ibz7kD9_J0lZoQLug=.ebb94eff-c276-4974-a3a7-2a334ee871b2@github.com> On Tue, 22 Sep 2020 12:30:47 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please help to review [JDK-8251188](https://bugs.openjdk.java.net/browse/JDK-8251188) fix which helps to improve LDAP >> tests stability. The list of changes: 1. Usages of wildcard address have been replaced with loopback address. This >> change includes addition of `LDAPTestUtils.initEnv` method that takes LDAP provider URL as a parameter. 2. >> `DeadServerTimeoutSSLTest.java` was also updated to fix the intermittent failures reported by [JDK-8152654 >> ](https://bugs.openjdk.java.net/browse/JDK-8152654) and >> [JDK-8169942](https://bugs.openjdk.java.net/browse/JDK-8169942). Before the fix the failure rate was 1 out of 4 runs. >> After the fix it was executed 400+ times alongside to other LDAP tests, and showed no failures, and therefore removed >> from the problem list. Thank you, Aleksei > > test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java line 171: > >> 169: System.err.println("Server socket. Failure to accept connection:"); >> 170: e.printStackTrace(); >> 171: } > > I wonder if removing the while (true) loop will make the test more susceptible of failing in timeout if the server ever > receives a connection request from an unexpected client (we've seen that happening in the past with networking tests). > Is there anyway the server could attempt to verify that the accepted socket is from the expected client, and close it > and go back to accepting if it's not? Maybe by looking at the accepted socket remote address & port? Thanks for the good suggestion Daniel. I will modify it to look at the remote socket's address and port. ------------- PR: https://git.openjdk.java.net/jdk/pull/252 From dfuchs at openjdk.java.net Tue Sep 22 14:29:07 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 22 Sep 2020 14:29:07 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote: > Hi, > > Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. > Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html > This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is > "tls-server-end-point" > CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 > > Thank you > Alexey Thanks for the PR Alexey! Let me run a last round of testing - and if that comes back clean I'll approve. Please don't integrate until you get a reviewer from security-libs too. best regards, -- daniel ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From herrick at openjdk.java.net Tue Sep 22 14:47:48 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 22 Sep 2020 14:47:48 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests [v3] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 02:49:50 GMT, Alexander Matveev wrote: > > > > How about testing of other jpackage command line options in two phase mode? Like "--name", "--version"? Any plans to > > add them? > > Plan was to file separate bugs for any additional options. I do not think we should put everything in one issue. This > issue for desktop integration for additional launchers. Agree that separate bugs can be filed for additional options, can you file them ? I am testing in conjunction with https://github.com/openjdk/jdk/pull/271 ------------- PR: https://git.openjdk.java.net/jdk/pull/263 From dfuchs at openjdk.java.net Tue Sep 22 14:53:34 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 22 Sep 2020 14:53:34 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote: > Hi, > > Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. > Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html > This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is > "tls-server-end-point" > CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 > > Thank you > Alexey src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 994: > 992: } > 993: > 994: private CompletableFuture tlsHandshakeCompleted = Should be `final`? src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 63: > 61: * Channel binding on the basis of TLS Finished message > 62: */ > 63: TLS_UNIQUE("tls-unique"), Is that still used? If not maybe it should be removed? ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From abakhtin at openjdk.java.net Tue Sep 22 15:01:20 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 22 Sep 2020 15:01:20 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 14:41:57 GMT, Daniel Fuchs wrote: >> Hi, >> >> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. >> Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html >> This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is >> "tls-server-end-point" >> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 >> >> Thank you >> Alexey > > src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 994: > >> 992: } >> 993: >> 994: private CompletableFuture tlsHandshakeCompleted = > > Should be `final`? Thank you. Agree. It should be final. ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From abakhtin at openjdk.java.net Tue Sep 22 15:20:07 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 22 Sep 2020 15:20:07 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 14:47:35 GMT, Daniel Fuchs wrote: >> Hi, >> >> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. >> Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html >> This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is >> "tls-server-end-point" >> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 >> >> Thank you >> Alexey > > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 63: > >> 61: * Channel binding on the basis of TLS Finished message >> 62: */ >> 63: TLS_UNIQUE("tls-unique"), > > Is that still used? If not maybe it should be removed? No, It is not used. However, I'd like to leave it as is (it is mentioned in the documentation as unsupported value). Otherwise, TlsChannelBindingType enum will have one element only and should be simplified/removed in all places. In this case, it would be double work to add TlsChannelBindingType enum back in the future if "tls-unique" required. If required I can remove TLS_UNIQUE item, but not remove TlsChannelBindingType enum ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From simonis at openjdk.java.net Tue Sep 22 15:21:58 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 22 Sep 2020 15:21:58 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v3] In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: On Mon, 21 Sep 2020 12:45:55 GMT, Jason Tatton wrote: >> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for >> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it >> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as >> code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and >> java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 >> >> Details of testing: >> ============ >> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note >> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the >> input String. Hence the test has been designed to cover all these cases. In summary they are: >> - A ?short? string of < 16 characters. >> - A SIMD String of 16 ? 31 characters. >> - A AVX2 SIMD String of 32 characters+. >> >> Hardware used for testing: >> ----------------------------- >> >> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). >> - AWS Graviton 2 (ARM 64 processor). >> >> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. >> >> Possible future enhancements: >> ==================== >> For the x86 implementation there may be two further improvements we can make in order to improve performance of both >> the StringUTF16 and StringLatin1 indexOf(char) intrinsics: >> 1. Make use of AVX-512 instructions. >> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD >> instructions instead of a loop. >> Benchmark results: >> ============ >> **Without** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | >> >> >> **With** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | >> >> >> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 >> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when >> running on ARM. > > Jason Tatton has updated the pull request incrementally with one additional commit since the last revision: > > Add missing newline to end of vmSymbols.cpp src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1889: > 1887: bind(SCAN_TO_32_CHAR_LOOP); > 1888: vmovdqu(vec3, Address(result, 0)); > 1889: vpcmpeqb(vec3, vec3, vec1, 1); Using `Assembler::AVX_256bit` instead of `1` will make this easier to understand. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From simonis at openjdk.java.net Tue Sep 22 15:21:56 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 22 Sep 2020 15:21:56 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v2] In-Reply-To: <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com> Message-ID: On Fri, 18 Sep 2020 11:56:09 GMT, Jason Tatton wrote: >> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for >> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it >> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as >> code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and >> java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 >> >> Details of testing: >> ============ >> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note >> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the >> input String. Hence the test has been designed to cover all these cases. In summary they are: >> - A ?short? string of < 16 characters. >> - A SIMD String of 16 ? 31 characters. >> - A AVX2 SIMD String of 32 characters+. >> >> Hardware used for testing: >> ----------------------------- >> >> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). >> - AWS Graviton 2 (ARM 64 processor). >> >> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. >> >> Possible future enhancements: >> ==================== >> For the x86 implementation there may be two further improvements we can make in order to improve performance of both >> the StringUTF16 and StringLatin1 indexOf(char) intrinsics: >> 1. Make use of AVX-512 instructions. >> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD >> instructions instead of a loop. >> Benchmark results: >> ============ >> **Without** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | >> >> >> **With** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | >> >> >> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 >> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when >> running on ARM. > > Jason Tatton has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains four commits: > - Merge master > - 8173585: further whitespace changes required by jcheck > - JDK-8173585 - whitespace changes required by jcheck > - JDK-8173585 Hi Jason, thanks for bringing String.indexOf() for latin strings up to date with the Unicode version. Your changes look good except a few minor issues I've commented on right in the code. I'd only like to ask you if you could possibly improve your test a little bit. As far as I understand, your search text is a consecutive sequence of "abc" characters, so you'll always find the character your searching for within the next three characters of the source text. This won't exercise the loops of your intrinsic. Maybe you can also add some test versions where the search character will be found beyond the first 32/64 characters after "fromIndex"? test/hotspot/jtreg/compiler/intrinsics/string/TestStringLatin1IndexOfChar.java line 24: > 22: > 23: public static void main(String[] args) throws Exception { > 24: for (int i = 0; i < 100_0; ++i) {//repeat such that we enter into C2 code... The placement of the underscore looks strange to me. I'd expect it to separate thousands (like 1_000) if at all but not sure if id use it for one thousand at all as that's really not such a big number that it is hard to read.. Also, the Tier4InvocationThreshold is 5000 so I'm not sure youre reaching C2? src/hotspot/share/classfile/vmSymbols.cpp line 295: > 293: if (symbol == NULL) return NO_SID; > 294: return find_sid(symbol); > 295: } I think it is common sense to have a newline at the end of a file. test/hotspot/jtreg/compiler/intrinsics/string/TestStringLatin1IndexOfChar.java line 84: > 82: } > 83: > 84: } Please put an EOL at the end of the file. test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java line 199: > 197: return ret; > 198: } > 199: } Please put an EOL at the end of the file. ------------- Changes requested by simonis (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/71 From dfuchs at openjdk.java.net Tue Sep 22 15:38:52 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 22 Sep 2020 15:38:52 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 15:17:23 GMT, Alexey Bakhtin wrote: >> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 63: >> >>> 61: * Channel binding on the basis of TLS Finished message >>> 62: */ >>> 63: TLS_UNIQUE("tls-unique"), >> >> Is that still used? If not maybe it should be removed? > > No, It is not used. > However, I'd like to leave it as is (it is mentioned in the documentation as unsupported value). > Otherwise, TlsChannelBindingType enum will have one element only and should be simplified/removed in all places. In > this case, it would be double work to add TlsChannelBindingType enum back in the future if "tls-unique" required. If > required I can remove TLS_UNIQUE item, but not remove TlsChannelBindingType enum OK ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From weijun at openjdk.java.net Tue Sep 22 15:43:56 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 22 Sep 2020 15:43:56 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote: > Hi, > > Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. > Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html > This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is > "tls-server-end-point" > CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 > > Thank you > Alexey I'm mostly OK with the SASL/JGSS part, except for the small nits in this comment. I'm not an expert on HandshakeCompletedListener. src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java line 156: > 154: if (props != null) { > 155: // TLS Channel Binding > 156: byte[] tlsCB = (byte[])props.get("jdk.internal.sasl.tlschannelbinding"); You can say the name is defined in another class in another module. If we really want to rename it one day we will know where it's from. src/java.security.jgss/share/classes/sun/security/jgss/krb5/InitialToken.java line 389: > 387: int acceptorAddressType = getAddrType(acceptorAddress, > 388: (channelBinding instanceof TlsChannelBindingImpl)? > 389: CHANNEL_BINDING_AF_UNSPEC:CHANNEL_BINDING_AF_NULL_ADDR); Normally we put a white space around "?" and ":". src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 82: > 80: /** > 81: * Parse value of "com.sun.jndi.ldap.tls.cbtype" property > 82: * @param cbType Please add a `@return` here, esp, about null. src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 137: > 135: public TlsChannelBindingType getType() { > 136: return cbType; > 137: } Add a new line here. ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From jbhateja at openjdk.java.net Tue Sep 22 15:47:29 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 22 Sep 2020 15:47:29 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy [v4] In-Reply-To: References: Message-ID: > Summary: > > 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. > 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. > 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop > copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block > and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. > 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user > sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy > sizes above 4096 bytes. JMH Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() > WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8252847: Review comments resolution; code reorganized to cover arraycopy for reference types. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/61/files - new: https://git.openjdk.java.net/jdk/pull/61/files/271b6457..fadd3687 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=02-03 Stats: 691 lines in 5 files changed: 340 ins; 198 del; 153 mod Patch: https://git.openjdk.java.net/jdk/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk/pull/61 From jbhateja at openjdk.java.net Tue Sep 22 15:55:11 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 22 Sep 2020 15:55:11 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy [v5] In-Reply-To: References: Message-ID: > Summary: > > 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. > 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. > 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop > copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block > and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. > 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user > sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy > sizes above 4096 bytes. JMH Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() > WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8252847 : Modifying file permission to resolve jcheck failure. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/61/files - new: https://git.openjdk.java.net/jdk/pull/61/files/fadd3687..78c4fe73 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=03-04 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk/pull/61 From hseigel at openjdk.java.net Tue Sep 22 15:59:35 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 22 Sep 2020 15:59:35 GMT Subject: RFR: 8253476: TestUseContainerSupport.java fails on some Linux kernels =?UTF-8?B?dy9v4oCm?= Message-ID: Please review this small change to remove "--memory 200m" option from TestUseContainerSupport.java. This can cause test failures on systems where swap accounting is disabled. ------------- Commit messages: - 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities Changes: https://git.openjdk.java.net/jdk/pull/303/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=303&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253476 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/303.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/303/head:pull/303 PR: https://git.openjdk.java.net/jdk/pull/303 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 jbhateja at openjdk.java.net Tue Sep 22 16:38:56 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 22 Sep 2020 16:38:56 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v3] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 03:34:37 GMT, Vladimir Kozlov wrote: > @jatin-bhateja Can you put summary of performance improvement into JBS? yes, I have added the summary in JBS. ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From jbhateja at openjdk.java.net Tue Sep 22 16:41:48 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 22 Sep 2020 16:41:48 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v3] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 03:34:37 GMT, Vladimir Kozlov wrote: > @jatin-bhateja Can you put summary of performance improvement into JBS? Yes, I have added the summary to JBS ------------- PR: https://git.openjdk.java.net/jdk/pull/61 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 igraves at openjdk.java.net Tue Sep 22 17:57:45 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 22 Sep 2020 17:57:45 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy Message-ID: These changes update the jlink plugin command line documentation to tidy them up into a more canonical form. The output generated by jlink from this change appears as follows: > build/macosx-x64/images/jdk/bin/jlink --list-plugins List of available plugins: --strip-debug Strip debug information from the output image --strip-java-debug-attributes Strip Java debug attributes from classes in the output image --exclude-resources Specify resources to exclude. e.g.: **.jcov,glob:**/META-INF/** --exclude-files Specify files to exclude. e.g.: **.java,glob:/java.base/lib/client/** --exclude-jmod-section Specify a JMOD section to exclude. Where is "man" or "headers". --dedup-legal-notices [error-if-not-same-content] De-duplicate all legal notices. If error-if-not-same-content is specified then it will be an error if two files of the same filename are different. --system-modules retainModuleTarget Fast loading of module descriptors (always enabled) --strip-native-commands Exclude native commands (such as java/java.exe) from the image --order-resources Order resources. e.g.: **/module-info.class, at classlist,/java.base/java/lang/** --compress <0|1|2>[:filter=] Compress all resources in the output image. Level 0: No compression Level 1: Constant string sharing Level 2: ZIP. An optional filter can be specified to list the pattern of files to be included. --vm Select the HotSpot VM in the output image. Default is all --include-locales [,]* BCP 47 language tags separated by a comma, allowing locale matching defined in RFC 4647. e.g.: en,ja,*-IN --generate-jli-classes @filename Specify a file listing the java.lang.invoke classes to pre-generate. By default, this plugin may use a builtin list of classes to pre-generate. If this plugin runs on a different runtime version than the image being created then code generation will be disabled by default to guarantee correctness add ignore-version=true to override this. --release-info |add:=:=:...|del: option is to load release properties from the supplied file. add: is to add properties to the release file. Any number of = pairs can be passed. del: is to delete the list of keys in release file. --add-options Prepend the specified string, which may include whitespace, before any other options when invoking the virtual machine in the resulting image. --vendor-bug-url Override the vendor bug URL baked into the build. The value of the system property "java.vendor.url.bug" will be . --vendor-vm-bug-url Override the vendor VM bug URL baked into the build. The URL displayed in VM error logs will be . --vendor-version Override the vendor version string baked into the build, if any. The value of the system property "java.vendor.version" will be . For options requiring a , the value will be a comma separated list of elements each using one the following forms: glob: regex: @ where filename is the name of a file containing patterns to be used, one pattern per line ------------- Commit messages: - Tidying up plugins Changes: https://git.openjdk.java.net/jdk/pull/305/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=305&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8218685 Stats: 233 lines in 25 files changed: 204 ins; 5 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/305/head:pull/305 PR: https://git.openjdk.java.net/jdk/pull/305 From gdub at openjdk.java.net Tue Sep 22 18:03:37 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Tue, 22 Sep 2020 18:03:37 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v4] In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. Gilles Duboscq 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: - Move LambdaEagerInitTest to test/jdk/java/lang/invoke/lambda - Include capturing case test, use jdk.test.lib.Assert - Remove disableEagerInitialization concerns from BridgeMethod.java - Remove extra field test from LambdaTest6 - Wrap long lines - Add dedicated test in the jdk tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/93/files - new: https://git.openjdk.java.net/jdk/pull/93/files/625feb94..5525f217 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=02-03 Stats: 164 lines in 2 files changed: 91 ins; 73 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/93/head:pull/93 PR: https://git.openjdk.java.net/jdk/pull/93 From minqi at openjdk.java.net Tue Sep 22 18:12:09 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 22 Sep 2020 18:12:09 GMT Subject: RFR: 8253492: Miss comma after second copyright year in FDBigInteger.java Message-ID: In patch for jdk-8253208, a comma missed after copyright year in src/java.base/share/classes/jdk/internal/math/FDBigInteger.java. Also changed "@return" to "Returns" in the comment for CDS.getRandomSeedForDumping to keep consistent with others. ------------- Commit messages: - 8253492: Miss comma after second copyright year in FDBigInteger.java Changes: https://git.openjdk.java.net/jdk/pull/306/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=306&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253492 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/306.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/306/head:pull/306 PR: https://git.openjdk.java.net/jdk/pull/306 From ccheung at openjdk.java.net Tue Sep 22 18:17:33 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 22 Sep 2020 18:17:33 GMT Subject: RFR: 8253492: Miss comma after second copyright year in FDBigInteger.java In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 18:06:40 GMT, Yumin Qi wrote: > In patch for jdk-8253208, a comma missed after copyright year in > src/java.base/share/classes/jdk/internal/math/FDBigInteger.java. Also changed "@return" to "Returns" in the comment for > CDS.getRandomSeedForDumping to keep consistent with others. Looks good and trivial. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/306 From mchung at openjdk.java.net Tue Sep 22 18:20:22 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Sep 2020 18:20:22 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v4] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Tue, 22 Sep 2020 18:03:37 GMT, Gilles Duboscq wrote: >> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the >> jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda >> classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the >> context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of >> non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas >> are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely >> _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and >> ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance >> behaviour of lambdas in either direction. > > Gilles Duboscq 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. Looks good. Thanks for the update. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/93 From minqi at openjdk.java.net Tue Sep 22 18:22:23 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 22 Sep 2020 18:22:23 GMT Subject: Integrated: 8253492: Miss comma after second copyright year in FDBigInteger.java In-Reply-To: References: Message-ID: <75NdIAz0htV1GcADhUL6fN-ZoO6dlA9xjtwm-eW40Kc=.399e7547-9d80-4f2d-8f57-3f2ba4f9d365@github.com> On Tue, 22 Sep 2020 18:06:40 GMT, Yumin Qi wrote: > In patch for jdk-8253208, a comma missed after copyright year in > src/java.base/share/classes/jdk/internal/math/FDBigInteger.java. Also changed "@return" to "Returns" in the comment for > CDS.getRandomSeedForDumping to keep consistent with others. This pull request has now been integrated. Changeset: 7b860120 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/7b860120 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8253492: Miss comma after second copyright year in FDBigInteger.java Reviewed-by: ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/306 From gdub at openjdk.java.net Tue Sep 22 18:26:31 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Tue, 22 Sep 2020 18:26:31 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v4] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Tue, 22 Sep 2020 18:17:49 GMT, Mandy Chung wrote: >> Gilles Duboscq 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: >> - Move LambdaEagerInitTest to test/jdk/java/lang/invoke/lambda >> - Include capturing case test, use jdk.test.lib.Assert >> - Remove disableEagerInitialization concerns from BridgeMethod.java >> - Remove extra field test from LambdaTest6 >> - Wrap long lines >> - Add dedicated test in the jdk tests > > Looks good. Thanks for the update. Thanks @mlchung. Do I need a second review? ------------- PR: https://git.openjdk.java.net/jdk/pull/93 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 mchung at openjdk.java.net Tue Sep 22 18:39:49 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Sep 2020 18:39:49 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v4] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Tue, 22 Sep 2020 18:24:02 GMT, Gilles Duboscq wrote: > Thanks @mlchung. Do I need a second review? No need. You can integrate once you run the regression tests (I usually run tier1-tier3). ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From andy.herrick at oracle.com Tue Sep 22 18:47:14 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 22 Sep 2020 14:47:14 -0400 Subject: Jpackage file assocations OS X In-Reply-To: References: Message-ID: Alexander: Can you explain the mechanism by which a macosx application is expected to retrieve the path to the selected file when the app is invoked via a file association ? On mac, the path to the associated file is not passed as an argument (as it is on Linux and Windows). /Andy On 9/20/2020 8:40 PM, Michael Hall wrote: > Are there any examples or further information on how the file association property file should work? > It is not entirely clear to me from the command help. > > From mik3hall at gmail.com Tue Sep 22 19:00:25 2020 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 22 Sep 2020 14:00:25 -0500 Subject: Jpackage file assocations OS X In-Reply-To: References: Message-ID: > On Sep 22, 2020, at 1:47 PM, Andy Herrick wrote: > > Alexander: > > Can you explain the mechanism by which a macosx application is expected to retrieve the path to the selected file when the app is invoked via a file association ? > > On mac, the path to the associated file is not passed as an argument (as it is on Linux and Windows). > > /Andy > > On 9/20/2020 8:40 PM, Michael Hall wrote: >> Are there any examples or further information on how the file association property file should work? >> It is not entirely clear to me from the command help. >> >> Is this currently not intended to be supported on OS X at this time? As I remember you have the extensions and what role they have for the application and things like that. These being entries in the Info.plist. It wasn?t clear to me how that would be applied in a properties file. From 165053593 at qq.com Mon Sep 21 15:51:55 2020 From: 165053593 at qq.com (=?gb18030?B?zfzG78/zsbM=?=) Date: Mon, 21 Sep 2020 23:51:55 +0800 Subject: Maybe a new container: Sieve Message-ID: Dear all, Thank you for your great job about the openjdk. I have an idea about a new container, Sieve(I give it the name). The java file is something like this: package com.heyifei.studyandshare.utils; /** * @author: ???(heyifei) * @email: heyifei88 at foxmail.com * @address: zhangjiang, pudong new district, shanghai, china * @date: 2020/9/21 * @description: */ import java.io.Serializable; import java.util.ArrayList; import java.util.List; import java.util.function.Predicate; /** * Container:Sieve */ public class Sieve implements Serializable { private static final long serialVersionUID = 8621987070720161207L; /** * items in the sieve. */ final List References: Message-ID: <9q8q70FXeg-Nd4ym4zvOsTwT4pg60kSaQIQUR3sPcgc=.fcab4d54-793d-4a0a-a307-682132156154@github.com> > # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1 formatter reads a stream and produces annotated output of the > tags, values, and structures. > When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized > with the hex formatted output. > > Small changes to HexPrinter are included to improve the output readability. > > > Example decoding of a .pem certificate: > SEQUENCE [910] > SEQUENCE [630] > CONTEXT cons 0 [3] > BYTE 2, > BYTE 3, > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > SEQUENCE [76] > SET [11] > SEQUENCE [9] > OBJECT ID [3] 2.5.4.6 (CountryName) > 'IN' > ... > SET [16] > SEQUENCE [14] > OBJECT ID [3] 2.5.4.3 (CommonName) > Client1 > SEQUENCE [30] > UTCTIME [13] '150526221718Z' > UTCTIME [13] '250523221718Z' > ... > SEQUENCE [290] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > NULL > BIT STRING [271] > CONTEXT cons 3 [123] > SEQUENCE [121] > SEQUENCE [9] > OBJECT ID [3] 2.5.29.19 (BasicConstraints) > OCTET STRING [2] > SEQUENCE [44] > OBJECT ID [9] 2.16.840.1.113730.1.13 > OCTET STRING [31] '..OpenSSL Generated Certificate' > SEQUENCE [29] > OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > OCTET STRING [22] > SEQUENCE [31] > OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > OCTET STRING [24] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > BIT STRING [257] > When used with the HexPrinter test utility, the formatting of the > hexadecimal values is selected with the parameters to HexPrinter. > > 0000: 30 82 03 8e ; SEQUENCE [910] > 0004: 30 82 02 76 ; SEQUENCE [630] > 0008: a0 03 ; CONTEXT cons 0 [3] > 000a: 02 01 02 ; BYTE 2, > 000d: 02 01 03 ; BYTE 3, > 0010: 30 0d ; SEQUENCE [13] > 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 001d: 05 00 ; NULL > 001f: 30 ; SEQUENCE [76] > 0020: 4c ; > 0021: 31 0b ; SET [11] > 0023: 30 09 ; SEQUENCE [9] > 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) > 002a: 13 02 49 4e ; 'IN' > > ... ... > > 005b: 31 10 ; SET [16] > 005d: 30 0e ; SEQUENCE [14] > 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) > 0060: 03 55 04 03 ; > 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 > 006d: 30 1e ; SEQUENCE [30] > 006f: 17 ; UTCTIME [13] '150526221718Z' > 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; > 007e: 17 0d ; UTCTIME [13] '250523221718Z' > 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; > > ... ... > > 00db: 30 82 01 22 ; SEQUENCE [290] > 00df: 30 ; SEQUENCE [13] > 00e0: 0d ; > 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > 00ec: 05 00 ; NULL > 00ee: 03 82 ; BIT STRING [271] > 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; > > ... > > 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; > 0200: 01 ; > 0201: a3 7b ; CONTEXT cons 3 [123] > 0203: 30 79 ; SEQUENCE [121] > 0205: 30 09 ; SEQUENCE [9] > 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) > 020c: 04 02 30 00 ; OCTET STRING [2] > 0210: 30 2c ; SEQUENCE [44] > 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 > 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated > Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; > 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; > 023e: 30 1d ; SEQUENCE [29] > 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] > 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; > 025d: 30 1f ; SEQUENCE [31] > 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > 0260: 03 55 1d 23 ; > 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] > 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ; NULL > 028d: 03 82 01 ; BIT STRING [257] > 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; > > ... > > 0390: 6d 94 ; Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: For octet strings, dropped output of bytes; improved tag output for constructed tags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/268/files - new: https://git.openjdk.java.net/jdk/pull/268/files/915dfe7e..d56007bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=01-02 Stats: 24 lines in 2 files changed: 7 ins; 9 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/268/head:pull/268 PR: https://git.openjdk.java.net/jdk/pull/268 From iklam at openjdk.java.net Tue Sep 22 19:57:51 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 22 Sep 2020 19:57:51 GMT Subject: RFR: 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class Message-ID: Please review this BACKOUT for tier-1 failures. I have tested all CDS tests locally on Linux-x64, including the failed DeterministicDump.java. I would like to apply for the "trivial" rule since this is a simple backout for tier-1 failures. I executed the command: git revert c1df13b855984dc2197c0561f7a50c7a5a731dd9 and them manually fixed the conflict with 7b860120e130c13de8ba543a8706c9ecdeab468b. ------------- Commit messages: - [BACKOUT] JDK-8253208 Move CDS related code to a separate class Changes: https://git.openjdk.java.net/jdk/pull/308/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=308&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253496 Stats: 156 lines in 22 files changed: 53 ins; 57 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/308.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/308/head:pull/308 PR: https://git.openjdk.java.net/jdk/pull/308 From dcubed at openjdk.java.net Tue Sep 22 20:09:17 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Sep 2020 20:09:17 GMT Subject: RFR: 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 19:48:33 GMT, Ioi Lam wrote: > Please review this BACKOUT for tier-1 failures. I have tested all CDS tests locally on Linux-x64, including the failed > DeterministicDump.java. > I would like to apply for the "trivial" rule since this is a simple backout for tier-1 failures. > > I executed the command: > > git revert c1df13b855984dc2197c0561f7a50c7a5a731dd9 > > and them manually fixed the conflict with 7b860120e130c13de8ba543a8706c9ecdeab468b. I compared the full webrev patch for this fix with the full webrev patch for JDK-8253208. This looks like a proper backout/revert. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/308 From eosterlund at openjdk.java.net Tue Sep 22 20:09:17 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 22 Sep 2020 20:09:17 GMT Subject: RFR: 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 19:48:33 GMT, Ioi Lam wrote: > Please review this BACKOUT for tier-1 failures. I have tested all CDS tests locally on Linux-x64, including the failed > DeterministicDump.java. > I would like to apply for the "trivial" rule since this is a simple backout for tier-1 failures. > > I executed the command: > > git revert c1df13b855984dc2197c0561f7a50c7a5a731dd9 > > and them manually fixed the conflict with 7b860120e130c13de8ba543a8706c9ecdeab468b. Marked as reviewed by eosterlund (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/308 From iklam at openjdk.java.net Tue Sep 22 20:17:41 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 22 Sep 2020 20:17:41 GMT Subject: Integrated: 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 19:48:33 GMT, Ioi Lam wrote: > Please review this BACKOUT for tier-1 failures. I have tested all CDS tests locally on Linux-x64, including the failed > DeterministicDump.java. > I would like to apply for the "trivial" rule since this is a simple backout for tier-1 failures. > > I executed the command: > > git revert c1df13b855984dc2197c0561f7a50c7a5a731dd9 > > and them manually fixed the conflict with 7b860120e130c13de8ba543a8706c9ecdeab468b. This pull request has now been integrated. Changeset: 65af8373 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/65af8373 Stats: 156 lines in 22 files changed: 57 ins; 53 del; 46 mod 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class Reviewed-by: eosterlund, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/308 From abakhtin at openjdk.java.net Tue Sep 22 20:19:21 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 22 Sep 2020 20:19:21 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: References: Message-ID: > Hi, > > Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. > Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html > This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is > "tls-server-end-point" > CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 > > Thank you > Alexey Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: 8245527: version.01 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/278/files - new: https://git.openjdk.java.net/jdk/pull/278/files/3f4ae08c..8b135f48 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=278&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=278&range=00-01 Stats: 15 lines in 4 files changed: 7 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/278.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/278/head:pull/278 PR: https://git.openjdk.java.net/jdk/pull/278 From abakhtin at openjdk.java.net Tue Sep 22 20:19:22 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 22 Sep 2020 20:19:22 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: References: Message-ID: <5_WchmlW1dR-XMytqx__iZ0ZMcWSy7vo6X6S7knzvBQ=.b9751c22-81db-4ef1-ae06-3261a9e5036a@github.com> On Tue, 22 Sep 2020 15:36:24 GMT, Daniel Fuchs wrote: >> No, It is not used. >> However, I'd like to leave it as is (it is mentioned in the documentation as unsupported value). >> Otherwise, TlsChannelBindingType enum will have one element only and should be simplified/removed in all places. In >> this case, it would be double work to add TlsChannelBindingType enum back in the future if "tls-unique" required. If >> required I can remove TLS_UNIQUE item, but not remove TlsChannelBindingType enum > > I was suggesting to keep TlsChannelBindingType but remove TLS_UNIQUE; However, I'm OK to keep things as is: this is an > internal API. I wonder if it would deserve a comment: > /** > * Channel binding on the basis of TLS Finished message > */ > // TLS_UNIQUE is defined by RFC 5929 but is not supported by the current LDAP stack. > TLS_UNIQUE("tls-unique"), Thank you. Added suggested comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From abakhtin at openjdk.java.net Tue Sep 22 20:19:25 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 22 Sep 2020 20:19:25 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: References: Message-ID: <-GwI0o39ByGxRTf5tsgTzuPxjxz_M0Q8XQKqJprkK4g=.1da6ca12-db0b-4693-95a8-e9b11a64ce71@github.com> On Tue, 22 Sep 2020 15:11:57 GMT, Weijun Wang wrote: >> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: >> >> 8245527: version.01 > > src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java line 156: > >> 154: if (props != null) { >> 155: // TLS Channel Binding >> 156: byte[] tlsCB = (byte[])props.get("jdk.internal.sasl.tlschannelbinding"); > > You can say the name is defined in another class in another module. If we really want to rename it one day we will know > where it's from. Thank you. Comment is added > src/java.security.jgss/share/classes/sun/security/jgss/krb5/InitialToken.java line 389: > >> 387: int acceptorAddressType = getAddrType(acceptorAddress, >> 388: (channelBinding instanceof TlsChannelBindingImpl)? >> 389: CHANNEL_BINDING_AF_UNSPEC:CHANNEL_BINDING_AF_NULL_ADDR); > > Normally we put a white space around "?" and ":". Thank you. Fixed. > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 82: > >> 80: /** >> 81: * Parse value of "com.sun.jndi.ldap.tls.cbtype" property >> 82: * @param cbType > > Please add a `@return` here, esp, about null. Added @return with comments > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 137: > >> 135: public TlsChannelBindingType getType() { >> 136: return cbType; >> 137: } > > Add a new line here. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From lancea at openjdk.java.net Tue Sep 22 20:57:00 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 22 Sep 2020 20:57:00 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v5] In-Reply-To: References: Message-ID: <3BKhS_NN1EXxRvrGzrA7Y8XMuBCEW9KuHO3p-wCBATM=.3ec5f474-6206-46b3-9ede-088a18f6be62@github.com> > Hi all, > > Please review the fix for JDK-8252739 which addresses an issue introduced by > https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by > Deflater.setDictionary. Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and > java/util/jar JCK tests. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Add additional offset test cases in DeflaterDictionaryTests.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/269/files - new: https://git.openjdk.java.net/jdk/pull/269/files/f34a6702..a37d9d28 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=269&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=269&range=03-04 Stats: 59 lines in 1 file changed: 55 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/269.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/269/head:pull/269 PR: https://git.openjdk.java.net/jdk/pull/269 From lancea at openjdk.java.net Tue Sep 22 20:57:01 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 22 Sep 2020 20:57:01 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v4] In-Reply-To: <6TrvHmNuobAHdUK6UP1KgBje0n0noCPbEGc8p5Bskx4=.8ab6de86-394a-4739-bcac-3e03b83ae2ce@github.com> References: <6TrvHmNuobAHdUK6UP1KgBje0n0noCPbEGc8p5Bskx4=.8ab6de86-394a-4739-bcac-3e03b83ae2ce@github.com> Message-ID: On Tue, 22 Sep 2020 07:28:42 GMT, Alan Bateman wrote: > Given that the offset handling is buggy then I think the test should at least cover the cases where the offset is 0 or > out of bounds. No problem separating out further test coverage for the other setDictionary methods into a separate > issue. I updated the test to include an offset test for 0 and to add a test for out of range offsets. I have updated the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/269 From rriggs at openjdk.java.net Tue Sep 22 21:27:40 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 22 Sep 2020 21:27:40 GMT Subject: RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode() [v2] In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 18:02:42 GMT, Naoto Sato wrote: >> Hi, >> >> Please review the fix to the issue wrt missing hashCode() javadoc, which was recently discussed in core-libs ml. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Addressing Roger's comments. Looks fine. Thanks ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/208 From joe.darcy at oracle.com Tue Sep 22 21:56:31 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 22 Sep 2020 14:56:31 -0700 Subject: Math.exp() yields different results on 32 bit systems In-Reply-To: References: Message-ID: Hello, Per the spec https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Math.html#exp(double) the result of exp has to be within one ulp of the exact result and the value of e^(10_000) is (much) larger than Double.MAX_VALUE so positive infinity is the correct answer. Therefore, it looks like the intrinsic on 32-bit systems is buggy. HTH, -Joe On 9/22/2020 3:30 AM, Andreas Ahlenstorf wrote: > Hi! > > According to a bug report at AdoptOpenJDK [1] Math.exp(10_000.0) yields different results on 32 bit systems than on 64 bit systems. > > public class Test { > public static void main(String[] args) { > System.out.println(Math.exp(10_000.0)); > } > } > > On 64 bit systems the code above prints Infinity. On 32 bit systems the result is 0.0. I think that's wrong, but I'm far from an expert in floating point arithmetics. > > Affected versions: > > * OpenJDK 9.0.1 > * OpenJDK 11.0.8 > * OpenJDK 15 > > Not affected: > > * OpenJDK 8u265 > > We tested both with AdoptOpenJDK and Azul Zulu on Windows and Linux on x86 and x64. If we disable intrinsics (-XX:+UnlockDiagnosticVMOptions -XX:-UseLibmIntrinsic), Infinity is printed on x86 systems, too. > > Is this expected behavior? > > Best, > Andreas > > [1] https://github.com/AdoptOpenJDK/openjdk-support/issues/182 From stuart.marks at oracle.com Tue Sep 22 22:18:49 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 22 Sep 2020 15:18:49 -0700 Subject: RFR 8253451: Performance regression in java.util.Scanner after 8236201 In-Reply-To: <14a6a9f7-0ee3-e2af-45b4-6a5c39bdfe0b@redhat.com> References: <14a6a9f7-0ee3-e2af-45b4-6a5c39bdfe0b@redhat.com> Message-ID: Hi Martin, Overall it seems reasonable to replace the \x{HH} construct with a simpler escape sequence. I'm a bit surprised to see the performance impact, but you noticed it, so I'll buy that it's significant. > // These must be literalized to avoid collision with regex > // metacharacters such as dot or parenthesis > - groupSeparator = "\\x{" + Integer.toHexString(dfs.getGroupingSeparator()) + "}"; > - decimalSeparator = "\\x{" + Integer.toHexString(dfs.getDecimalSeparator()) + "}"; > + char newSep; > + groupSeparator = ((newSep = dfs.getGroupingSeparator()) == ',' || > + newSep == '.' || newSep == ' ' ? "\\" + newSep : > + "\\x{" + Integer.toHexString(newSep) + "}" ); > + decimalSeparator = ((newSep = dfs.getDecimalSeparator()) == '.' || > + newSep == ',' ? "\\" + newSep : "\\x{" + > + Integer.toHexString(newSep) + "}" ); Fundamentally it's simple, but there's rather a lot going on here: - reuse of a local variable - assignment within a logical expression - odd line breaking - ternary operator These factors make the code rather difficult to read, unnecessarily so in my opinion. (The collections and concurrency libraries sometimes put assignments within other expressions, but usually to avoid unnecessary initialization of a local variable. I don't think that applies here.) More to the semantics of the operations, the two cases seem oddly different: the group separator tests for ',' and '.' and ' ', but the decimal separator tests for '.' and ','. Why are they testing for different things, and in the opposite order? I looked through the 810 locales available in Oracle JDK 15, and here's what I found: Decimal Separators: U+002c 359 U+002e 400 U+066b 51 Grouping Separators: U+002c 378 U+002e 167 U+00a0 158 U+066c 51 U+2019 12 U+202f 44 I don't see a space used as a gropuing separator, but note that U+00a0 is no-break space. Does that occur often enough to special-case? (Note that these numbers don't take into account how often each locale is used, nor are the 810 locales in the JDK the universe of all possible locales. However, it seems likely that any other locales would not appear frequently enough to bother with a special case.) I also see that the group separator code tests for ',' first whereas the decimal separator code tests for '.' first. I suppose this might be a femto-optimization that slightly favors English-speaking locales, but it seems gratuitous to me. (If you can come up with a benchmark that illustrates the difference, be my guest!) :-) I'm wondering if it might be nicer to extract this computation into a little utility method nearby: > // Escapes a separator character to prevent it from being > // interpreted as a regex metacharacter. > static String escapeSeparator(char ch) { > if (ch == ',' || ch == '.') { > return "\\" + ch; > } else { > return "\\x{" + Integer.toHexString(ch) + "}"; > } > } (Note that I rewrote the comment that already existed above the lines you changed, as it seemed misleading.) The calling code would then be changed to: > groupSeparator = escapeSeparator(dfs.getGroupingSeparator()); > decimalSeparator = escapeSeparator(dfs.getDecimalSeparator()); I haven't benchmarked this. However, this would be called from within useLocale(), which is a low-frequency operation compared to the cases you benchmarked. Also, given that U+00a0 occurs relatively frequently among locales, it might be worthwhile also to special-case for it, but I don't have a strong opinion on that. This case would likely never occur for the decimal separator, but it doesn't bother me. I don't think it adds much value to have different special cases for the different separators. ** Finally, can this be converted into a github PR? It'll have to be made into a PR sooner or later in order to be integrated into the JDK mainline. (Though I guess the update releases are still using the current email+webrev process for now, sorry.) s'marks On 9/21/20 9:48 PM, Martin Balao wrote: > Hi, > > I'd like to propose a fix for JDK-8253451 [1] performance regression. > > Webrev.00: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8253451/8253451.webrev.00 > > As explained in [1], the idea for the fix is to optimize the regexp > string for the most common group and decimal separator characters across > locales. Please note that there are a few locales where the proposed > optimization does not apply and the slower -but safe- regexp introduced > by 8236201 is used. > > Testing: > > * No regressions observed in jdk/java/util/Scanner (5/5 passed) > > * Verified performance improvement back to what it was before 8236201 > (on my Americas locale). > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8253451 > From almatvee at openjdk.java.net Tue Sep 22 22:32:41 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 22 Sep 2020 22:32:41 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= [v3] In-Reply-To: References: Message-ID: <7soMN2w3vrILGNJ87mc3OMSf_tYY5Qy6AepHpG34FVI=.8973bc48-7b86-4ef9-bfa9-b5b4b9e07e05@github.com> On Tue, 22 Sep 2020 11:53:14 GMT, Andy Herrick wrote: >> 8253149: Building an installer from invalid app image fails on Windows and Linux >> When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a >> warning message, and then complete the package anyway. > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > 8253149: Building an installer from invalid app image fails (revision 2) src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/resources/LinuxResources.properties line 64: > 62: message.rpm-ldd-not-available.advice=Install "glibc-common" RPM package to get ldd. > 63: > 64: warning.foerign-app-image=Warning: app-image dir not generated by jpackage. I think it is misspelled again. ------------- PR: https://git.openjdk.java.net/jdk/pull/271 From almatvee at openjdk.java.net Tue Sep 22 22:38:54 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 22 Sep 2020 22:38:54 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= [v3] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 11:53:14 GMT, Andy Herrick wrote: >> 8253149: Building an installer from invalid app image fails on Windows and Linux >> When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a >> warning message, and then complete the package anyway. > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > 8253149: Building an installer from invalid app image fails (revision 2) test/jdk/tools/jpackage/share/AppImagePackageTest.java line 87: > 85: > 86: // on mac, with --app-image and without --mac-package-identifier, > 87: // we will try to infer it from the image, so forign image needs it. forign -> foreign. Same at line 92. ------------- PR: https://git.openjdk.java.net/jdk/pull/271 From naoto at openjdk.java.net Tue Sep 22 23:01:46 2020 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 22 Sep 2020 23:01:46 GMT Subject: Integrated: 8253240: No javadoc for DecimalFormatSymbols.hashCode() In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 17:29:52 GMT, Naoto Sato wrote: > Hi, > > Please review the fix to the issue wrt missing hashCode() javadoc, which was recently discussed in core-libs ml. This pull request has now been integrated. Changeset: bddb8225 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/bddb8225 Stats: 6 lines in 1 file changed: 1 ins; 5 del; 0 mod 8253240: No javadoc for DecimalFormatSymbols.hashCode() Reviewed-by: rriggs, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/208 From herrick at openjdk.java.net Tue Sep 22 23:32:10 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 22 Sep 2020 23:32:10 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= In-Reply-To: References: Message-ID: On Sun, 20 Sep 2020 21:23:17 GMT, Andy Herrick wrote: > 8253149: Building an installer from invalid app image fails on Windows and Linux > When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a > warning message, and then complete the package anyway. OK - I spelled foreign with a different wrong spelling (and missed a place in comments of test) will fix them all in the morning. ------------- PR: https://git.openjdk.java.net/jdk/pull/271 From alexander.matveev at oracle.com Wed Sep 23 00:35:07 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Tue, 22 Sep 2020 17:35:07 -0700 Subject: Jpackage file assocations OS X In-Reply-To: References: Message-ID: <7dc0e6eb-000f-c709-ab40-cc1b1ba1609c@oracle.com> Hi Michael, For file association you will need to create property file and pass it to jpackage via --file-associations. Example property file: mime-type=text/plain extension=txt description=Text file See following documentation: https://docs.oracle.com/en/java/javase/15/jpackage/support-application-features.html#GUID-8668A806-8A80-435F-970F-7B2BF65863E4 To retrieve associated file(s) when application is invoked by clicking associated file in Finder use OpenFilesHandler from AWT. See https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/Desktop.html#setOpenFileHandler(java.awt.desktop.OpenFilesHandler) Also, for example on how to use above APIs you can refer to test app we using for jpackage: https://github.com/openjdk/jdk/blob/master/test/jdk/tools/jpackage/apps/image/Hello.java We also support CFBundleDocumentTypes from https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundledocumenttypes?language=objc just add then to property file mac.key=value with key one of CFBundleDocumentTypes key and correct value from above doc. Example: mime-type=text/plain extension=txt description=Text file mac.CFBundleTypeRole=Viewer mac.LSHandlerRank=Default mac.NSDocumentClass=SomeClass mac.LSTypeIsPackage=true mac.LSSupportsOpeningDocumentsInPlace=false mac.UISupportsDocumentBrowser=false mac.NSExportableTypes=public.png, public.jpg mac.UTTypeConformsTo=public.image, public.data CFBundleDocumentTypes was added with https://bugs.openjdk.java.net/browse/JDK-8233215 Thanks, Alexander On 9/22/20 12:00 PM, Michael Hall wrote: > >> On Sep 22, 2020, at 1:47 PM, Andy Herrick wrote: >> >> Alexander: >> >> Can you explain the mechanism by which a macosx application is expected to retrieve the path to the selected file when the app is invoked via a file association ? >> >> On mac, the path to the associated file is not passed as an argument (as it is on Linux and Windows). >> >> /Andy >> >> On 9/20/2020 8:40 PM, Michael Hall wrote: >>> Are there any examples or further information on how the file association property file should work? >>> It is not entirely clear to me from the command help. >>> >>> > Is this currently not intended to be supported on OS X at this time? As I remember you have the extensions and what role they have for the application and things like that. These being entries in the Info.plist. It wasn?t clear to me how that would be applied in a properties file. > > From mchung at openjdk.java.net Wed Sep 23 00:40:44 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 23 Sep 2020 00:40:44 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 17:52:00 GMT, Ian Graves wrote: > These changes update the jlink plugin command line documentation to tidy them up into a more canonical form. > > The output generated by jlink from this change appears as follows: > >> build/macosx-x64/images/jdk/bin/jlink --list-plugins > > List of available plugins: > --strip-debug Strip debug information from the output image > --strip-java-debug-attributes > Strip Java debug attributes from classes in the output image > --exclude-resources > Specify resources to exclude. > e.g.: **.jcov,glob:**/META-INF/** > --exclude-files > Specify files to exclude. > e.g.: **.java,glob:/java.base/lib/client/** > --exclude-jmod-section > Specify a JMOD section to exclude. > Where is "man" or "headers". > --dedup-legal-notices [error-if-not-same-content] > De-duplicate all legal notices. > If error-if-not-same-content is specified then > it will be an error if two files of the same > filename are different. > --system-modules retainModuleTarget > Fast loading of module descriptors (always enabled) > --strip-native-commands Exclude native commands (such as java/java.exe) from the image > --order-resources > Order resources. > e.g.: **/module-info.class, at classlist,/java.base/java/lang/** > --compress <0|1|2>[:filter=] > Compress all resources in the output image. > Level 0: No compression > Level 1: Constant string sharing > Level 2: ZIP. > An optional filter can be > specified to list the pattern of files to be included. > --vm > Select the HotSpot VM in the output image. Default is all > --include-locales [,]* > BCP 47 language tags separated by a comma, allowing > locale matching defined in RFC 4647. e.g.: en,ja,*-IN > --generate-jli-classes @filename > Specify a file listing the java.lang.invoke classes > to pre-generate. By default, this plugin may use a > builtin list of classes to pre-generate. If this plugin > runs on a different runtime version than the image being > created then code generation will be disabled by > default to guarantee correctness > add ignore-version=true to override this. > --release-info |add:=:=:...|del: > option is to load release properties from the supplied file. > add: is to add properties to the release file. > Any number of = pairs can be passed. > del: is to delete the list of keys in release file. > --add-options Prepend the specified string, which may > include whitespace, before any other options when > invoking the virtual machine in the resulting image. > --vendor-bug-url > Override the vendor bug URL baked into the build. > The value of the system property > "java.vendor.url.bug" will be . > --vendor-vm-bug-url > Override the vendor VM bug URL baked into the build. > The URL displayed in VM error logs will be . > --vendor-version > Override the vendor version string baked into the build, > if any. The value of the system property > "java.vendor.version" will be . > > For options requiring a , the value will be a comma separated > list of elements each using one the following forms: > > glob: > regex: > @ where filename is the name of a file containing patterns to be > used, one pattern per line The output looks much better. Have you considered to sort them in alphabetical order of the plugin name? ------------- PR: https://git.openjdk.java.net/jdk/pull/305 From mik3hall at gmail.com Wed Sep 23 01:24:14 2020 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 22 Sep 2020 20:24:14 -0500 Subject: Jpackage file assocations OS X In-Reply-To: <7dc0e6eb-000f-c709-ab40-cc1b1ba1609c@oracle.com> References: <7dc0e6eb-000f-c709-ab40-cc1b1ba1609c@oracle.com> Message-ID: > On Sep 22, 2020, at 7:35 PM, alexander.matveev at oracle.com wrote: > > Hi Michael, > > For file association you will need to create property file and pass it to jpackage via --file-associations. Thanks for the detailed reply. I will look closer at it later. I had found the test class. I was looking in the incubator directory and not tool previously. Between your reply and that should be able to understand how it should work OS X. From igraves at openjdk.java.net Wed Sep 23 01:41:54 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 23 Sep 2020 01:41:54 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 00:37:18 GMT, Mandy Chung wrote: >> These changes update the jlink plugin command line documentation to tidy them up into a more canonical form. >> >> The output generated by jlink from this change appears as follows: >> >>> build/macosx-x64/images/jdk/bin/jlink --list-plugins >> >> List of available plugins: >> --strip-debug Strip debug information from the output image >> --strip-java-debug-attributes >> Strip Java debug attributes from classes in the output image >> --exclude-resources >> Specify resources to exclude. >> e.g.: **.jcov,glob:**/META-INF/** >> --exclude-files >> Specify files to exclude. >> e.g.: **.java,glob:/java.base/lib/client/** >> --exclude-jmod-section >> Specify a JMOD section to exclude. >> Where is "man" or "headers". >> --dedup-legal-notices [error-if-not-same-content] >> De-duplicate all legal notices. >> If error-if-not-same-content is specified then >> it will be an error if two files of the same >> filename are different. >> --system-modules retainModuleTarget >> Fast loading of module descriptors (always enabled) >> --strip-native-commands Exclude native commands (such as java/java.exe) from the image >> --order-resources >> Order resources. >> e.g.: **/module-info.class, at classlist,/java.base/java/lang/** >> --compress <0|1|2>[:filter=] >> Compress all resources in the output image. >> Level 0: No compression >> Level 1: Constant string sharing >> Level 2: ZIP. >> An optional filter can be >> specified to list the pattern of files to be included. >> --vm >> Select the HotSpot VM in the output image. Default is all >> --include-locales [,]* >> BCP 47 language tags separated by a comma, allowing >> locale matching defined in RFC 4647. e.g.: en,ja,*-IN >> --generate-jli-classes @filename >> Specify a file listing the java.lang.invoke classes >> to pre-generate. By default, this plugin may use a >> builtin list of classes to pre-generate. If this plugin >> runs on a different runtime version than the image being >> created then code generation will be disabled by >> default to guarantee correctness >> add ignore-version=true to override this. >> --release-info |add:=:=:...|del: >> option is to load release properties from the supplied file. >> add: is to add properties to the release file. >> Any number of = pairs can be passed. >> del: is to delete the list of keys in release file. >> --add-options Prepend the specified string, which may >> include whitespace, before any other options when >> invoking the virtual machine in the resulting image. >> --vendor-bug-url >> Override the vendor bug URL baked into the build. >> The value of the system property >> "java.vendor.url.bug" will be . >> --vendor-vm-bug-url >> Override the vendor VM bug URL baked into the build. >> The URL displayed in VM error logs will be . >> --vendor-version >> Override the vendor version string baked into the build, >> if any. The value of the system property >> "java.vendor.version" will be . >> >> For options requiring a , the value will be a comma separated >> list of elements each using one the following forms: >> >> glob: >> regex: >> @ where filename is the name of a file containing patterns to be >> used, one pattern per line > > The output looks much better. Have you considered to sort them in alphabetical order of the plugin name? Yes! I had intended to but it looks like I got hung up making sure non-documented plugins came last. Will push a change for this. ------------- PR: https://git.openjdk.java.net/jdk/pull/305 From igraves at openjdk.java.net Wed Sep 23 02:16:33 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 23 Sep 2020 02:16:33 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy [v2] In-Reply-To: References: Message-ID: > These changes update the jlink plugin command line documentation to tidy them up into a more canonical form. > > The output generated by jlink from this change appears as follows: > >> build/macosx-x64/images/jdk/bin/jlink --list-plugins > > List of available plugins: > --strip-debug Strip debug information from the output image > --strip-java-debug-attributes > Strip Java debug attributes from classes in the output image > --exclude-resources > Specify resources to exclude. > e.g.: **.jcov,glob:**/META-INF/** > --exclude-files > Specify files to exclude. > e.g.: **.java,glob:/java.base/lib/client/** > --exclude-jmod-section > Specify a JMOD section to exclude. > Where is "man" or "headers". > --dedup-legal-notices [error-if-not-same-content] > De-duplicate all legal notices. > If error-if-not-same-content is specified then > it will be an error if two files of the same > filename are different. > --system-modules retainModuleTarget > Fast loading of module descriptors (always enabled) > --strip-native-commands Exclude native commands (such as java/java.exe) from the image > --order-resources > Order resources. > e.g.: **/module-info.class, at classlist,/java.base/java/lang/** > --compress <0|1|2>[:filter=] > Compress all resources in the output image. > Level 0: No compression > Level 1: Constant string sharing > Level 2: ZIP. > An optional filter can be > specified to list the pattern of files to be included. > --vm > Select the HotSpot VM in the output image. Default is all > --include-locales [,]* > BCP 47 language tags separated by a comma, allowing > locale matching defined in RFC 4647. e.g.: en,ja,*-IN > --generate-jli-classes @filename > Specify a file listing the java.lang.invoke classes > to pre-generate. By default, this plugin may use a > builtin list of classes to pre-generate. If this plugin > runs on a different runtime version than the image being > created then code generation will be disabled by > default to guarantee correctness > add ignore-version=true to override this. > --release-info |add:=:=:...|del: > option is to load release properties from the supplied file. > add: is to add properties to the release file. > Any number of = pairs can be passed. > del: is to delete the list of keys in release file. > --add-options Prepend the specified string, which may > include whitespace, before any other options when > invoking the virtual machine in the resulting image. > --vendor-bug-url > Override the vendor bug URL baked into the build. > The value of the system property > "java.vendor.url.bug" will be . > --vendor-vm-bug-url > Override the vendor VM bug URL baked into the build. > The URL displayed in VM error logs will be . > --vendor-version > Override the vendor version string baked into the build, > if any. The value of the system property > "java.vendor.version" will be . > > For options requiring a , the value will be a comma separated > list of elements each using one the following forms: > > glob: > regex: > @ where filename is the name of a file containing patterns to be > used, one pattern per line Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Fixing up ordering ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/305/files - new: https://git.openjdk.java.net/jdk/pull/305/files/4add876d..a94a16bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=305&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=305&range=00-01 Stats: 15 lines in 1 file changed: 3 ins; 10 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/305/head:pull/305 PR: https://git.openjdk.java.net/jdk/pull/305 From vicente.romero at oracle.com Wed Sep 23 03:30:13 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 22 Sep 2020 23:30:13 -0400 Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: good catch Chris, thanks for the patch, Vicente On 9/22/20 5:51 AM, Chris Hegarty wrote: > On Mon, 21 Sep 2020 23:21:18 GMT, Vicente Romero wrote: > >>> Hi Vicente, >>> Please file a separate subtask for the javax.lang.model changes. This helps with the JSR 269 MR paperwork. >>> Thanks, >>> -Joe >> note: I have removed from the original patch the code related to javax.lang.model, I will publish them in a separate PR > @vicente-romero-oracle I noticed that we can also remove the preview args from the record serialization tests and > ObjectMethodsTest. I opened a PR against the branch in your fork. You should be able to just merge in the changes. See > https://github.com/vicente-romero-oracle/jdk/pull/1 > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Wed Sep 23 03:34:29 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 23 Sep 2020 03:34:29 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v3] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > Co-authored-by: Vicente Romero > Co-authored-by: Harold Seigel > Co-authored-by: Jonathan Gibbons > Co-authored-by: Brian Goetz > Co-authored-by: Maurizio Cimadamore > Co-authored-by: Joe Darcy > Co-authored-by: Chris Hegarty > Co-authored-by: Jan Lahoda Vicente Romero has updated the pull request incrementally with three additional commits since the last revision: - Merge pull request #1 from ChrisHegarty/record-serial-tests Remove preview args from JDK tests - Remove preview args from ObjectMethodsTest - Remove preview args from record serialization tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/543e5054..26b80775 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=01-02 Stats: 95 lines in 21 files changed: 0 ins; 35 del; 60 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 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 eric.c.liu at arm.com Wed Sep 23 06:10:07 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Wed, 23 Sep 2020 06:10:07 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> , <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com>, Message-ID: Hi Kim,? Sorry for the delay. This patch removes a redundant string copy in NetworkInterface.c to avoid string-truncation warning. Other warnings we talked before, which are unable to completely fix in different version of gcc, I have to use pragma to suppress them as a workaround. This patch now could compile with gcc-7, gcc-8, gcc-9, gcc-10 both with or without asan. [TESTS] Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. No new failure found. http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8252407 Thanks, Eric From alanb at openjdk.java.net Wed Sep 23 07:03:14 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 23 Sep 2020 07:03:14 GMT Subject: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v5] In-Reply-To: <3BKhS_NN1EXxRvrGzrA7Y8XMuBCEW9KuHO3p-wCBATM=.3ec5f474-6206-46b3-9ede-088a18f6be62@github.com> References: <3BKhS_NN1EXxRvrGzrA7Y8XMuBCEW9KuHO3p-wCBATM=.3ec5f474-6206-46b3-9ede-088a18f6be62@github.com> Message-ID: <-lQkYwrzfVQM-cSDSBidxzoIcszRMRt-EBotMwa9gzw=.77e40a08-cf10-4148-9d8a-774795752897@github.com> On Tue, 22 Sep 2020 20:57:00 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for JDK-8252739 which addresses an issue introduced by >> https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by >> Deflater.setDictionary. Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and >> java/util/jar JCK tests. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Add additional offset test cases in DeflaterDictionaryTests.java Thanks for update to cover the offset 0 and out of bound cases. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/269 From aph at redhat.com Wed Sep 23 09:32:53 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Sep 2020 10:32:53 +0100 Subject: Math.exp() yields different results on 32 bit systems In-Reply-To: References: Message-ID: On 22/09/2020 22:56, Joe Darcy wrote: > > Per the spec > > https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Math.html#exp(double) > > the result of exp has to be within one ulp of the exact result and the > value of e^(10_000) is (much) larger than Double.MAX_VALUE so positive > infinity is the correct answer. Therefore, it looks like the intrinsic > on 32-bit systems is buggy. Indeed it does. It's going to be painful to fix because, as the comment says, the intrinsic was generated by "Intel C compiler for LIBM library" and is almost completely uncommented assembly code. The sensible thing to do would be to go back to Intel and ask for a fix. Alternatively, if someone wants to step through and find where it all goes wrong... Or we could just go back to the slightly-slower-but-correct libm version. -- 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 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 jlahoda at openjdk.java.net Wed Sep 23 11:38:33 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 23 Sep 2020 11:38:33 GMT Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release [v3] In-Reply-To: References: Message-ID: > Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements > across all modules in the module graph, and only return a value when they find exactly one element. This is > troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from > any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that > these unqualified methods would first look for elements visible from the root modules, and would search the internals > of other modules only if nothing would be found in the first round. The draft of the corresponding CSR is here: > https://bugs.openjdk.java.net/browse/JDK-8253168. Jan Lahoda 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 four additional commits since the last revision: - Linking to root and all modules definition. - Merge branch 'master' into JDK-8236842 - Reflecting review comments - improving javadoc, avoid repeated search of modules that have already been searched. - 8253168: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/200/files - new: https://git.openjdk.java.net/jdk/pull/200/files/3eb2c0bd..33ca56ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=200&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=200&range=01-02 Stats: 12332 lines in 424 files changed: 6792 ins; 4409 del; 1131 mod Patch: https://git.openjdk.java.net/jdk/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/200/head:pull/200 PR: https://git.openjdk.java.net/jdk/pull/200 From jlahoda at openjdk.java.net Wed Sep 23 11:45:04 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 23 Sep 2020 11:45:04 GMT Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release [v2] In-Reply-To: <-47nRGIapv-HMACTNXfIZ5ec414XoC0zkUH6KxQDtg8=.f3b75456-976d-4e6b-9c41-8945021941b3@github.com> References: <3GADCQt6iTp29t9XUAsAge_5ePwsI6W0lI_Vc2abfQo=.68369e62-fb3a-481c-a586-6ec1bdfb6b98@github.com> <-47nRGIapv-HMACTNXfIZ5ec414XoC0zkUH6KxQDtg8=.f3b75456-976d-4e6b-9c41-8945021941b3@github.com> Message-ID: On Wed, 23 Sep 2020 02:32:46 GMT, Joe Darcy wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflecting review comments - improving javadoc, avoid repeated search of modules that have already been searched. > > src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 62: > >> 60: *
  • find non-empty packages with the given name returned by >> 61: * {@link #getPackageElement(ModuleElement, CharSequence)}, >> 62: * where the provided ModuleSymbol is any root module, > > Does "root module" mean one of the modules in the result of Elements.getAllModuleElements? If so, I suggest making > "root module" a link to the method. Root module is meant in the java.lang.module sense, i.e. the set of modules that are being compiled. In a new revision, I added a link to the appropriate package javadoc in java.lang.module; and a link to getAllModules for "all modules" in the next point. Does this make sense? I've generated the javadoc for convenience here: http://cr.openjdk.java.net/~jlahoda/8236842/docsv2/api/java.compiler/javax/lang/model/util/Elements.html#getTypeElement(java.lang.CharSequence) http://cr.openjdk.java.net/~jlahoda/8236842/docsv2/api/java.compiler/javax/lang/model/util/Elements.html#getPackageElement(java.lang.CharSequence) ------------- PR: https://git.openjdk.java.net/jdk/pull/200 From dfuchs at openjdk.java.net Wed Sep 23 11:52:27 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 23 Sep 2020 11:52:27 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: References: Message-ID: <0P4iJvOu6L8Itu3gKZyIE_0sGLCJC2SseA3LJsO2PCQ=.69fc69db-b9c4-4ee3-a9fc-6445f42cb450@github.com> On Tue, 22 Sep 2020 20:19:21 GMT, Alexey Bakhtin wrote: >> Hi, >> >> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. >> Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html >> This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is >> "tls-server-end-point" >> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 >> >> Thank you >> Alexey > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > 8245527: version.01 Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From aefimov at openjdk.java.net Wed Sep 23 12:21:02 2020 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Wed, 23 Sep 2020 12:21:02 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 20:19:21 GMT, Alexey Bakhtin wrote: >> Hi, >> >> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. >> Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html >> This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is >> "tls-server-end-point" >> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 >> >> Thank you >> Alexey > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > 8245527: version.01 Hi Alexey, The latest changes looks good to me. ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/278 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 herrick at openjdk.java.net Wed Sep 23 13:59:25 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Wed, 23 Sep 2020 13:59:25 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= [v4] In-Reply-To: References: Message-ID: > 8253149: Building an installer from invalid app image fails on Windows and Linux > When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a > warning message, and then complete the package anyway. Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: 8253149: Building an installer from invalid app image fails (revision ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/271/files - new: https://git.openjdk.java.net/jdk/pull/271/files/48001605..7cc98b2a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=271&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=271&range=02-03 Stats: 6 lines in 5 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/271.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/271/head:pull/271 PR: https://git.openjdk.java.net/jdk/pull/271 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 lancea at openjdk.java.net Wed Sep 23 14:25:23 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 23 Sep 2020 14:25:23 GMT Subject: Integrated: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary In-Reply-To: References: Message-ID: On Sun, 20 Sep 2020 18:03:02 GMT, Lance Andersen wrote: > Hi all, > > Please review the fix for JDK-8252739 which addresses an issue introduced by > https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by > Deflater.setDictionary. Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and > java/util/jar JCK tests. This pull request has now been integrated. Changeset: 812b39f5 Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/812b39f5 Stats: 253 lines in 2 files changed: 0 ins; 252 del; 1 mod 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary Reviewed-by: uschindler, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/269 From weijun at openjdk.java.net Wed Sep 23 14:49:26 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 23 Sep 2020 14:49:26 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA Message-ID: Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature algorithms - A new JarSigner property "directsign" - Updating the jarsigner tool doc Major code changes: - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed ------------- Commit messages: - 8242068: Signed JAR support for RSASSA-PSS and EdDSA Changes: https://git.openjdk.java.net/jdk/pull/322/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242068 Stats: 1641 lines in 20 files changed: 930 ins; 548 del; 163 mod Patch: https://git.openjdk.java.net/jdk/pull/322.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/322/head:pull/322 PR: https://git.openjdk.java.net/jdk/pull/322 From alanb at openjdk.java.net Wed Sep 23 15:13:02 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 23 Sep 2020 15:13:02 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 01:39:35 GMT, Ian Graves wrote: >> The output looks much better. Have you considered to sort them in alphabetical order of the plugin name? > > Yes! I had intended to but it looks like I got hung up making sure non-documented plugins came last. Will push a change > for this. Can we put a base abstract class in jdk.tools.jlink.internal.plugins that implements getUsage. That would avoid needing to have the same getUsage method in all the plugins. The text in the value of some of the .usage keys looks like it will wrap significantly, can the values of release-info.usage and strip-native-debug-symbols.usage be re-formatted so that the usage is readable with a default terminal? ------------- PR: https://git.openjdk.java.net/jdk/pull/305 From jpai at openjdk.java.net Wed Sep 23 15:42:06 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 23 Sep 2020 15:42:06 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException In-Reply-To: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: On Wed, 23 Sep 2020 15:06:55 GMT, Jaikiran Pai wrote: > Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? > > As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds > the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This > is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is > larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the > `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent > this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the > necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which > reproduces the issue and verifies the fix. I had created a copy of this branch in my personal fork and included the `submit.yml` workflow as noted in this recent mail here[1] to try and run the `tier1` testing for this change. But it looks like that has failed for unrelated reasons[2]. So I'll go ahead and trigger the `tier1` tests locally instead. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] https://github.com/jaikiran/jdk/actions/runs/268948812 test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 60: > 58: final OutOfMemoryError oome = Assert.expectThrows(OutOfMemoryError.class, () -> jar.getManifest()); > 59: // additionally verify that the OOM was for the right/expected reason > 60: if (!"Required array size too large".equals(oome.getMessage())) { I wasn't too sure if I should add this additional check on the message of the `OutOfMemoryError`, but decided to do it anyway, given that from what I remember there were some discussions in the `core-libs-dev` list a while back on the exact messages that such OOMs should throw. So I guessed that it might be OK to rely on those messages in the tests within this project. However, I am open to removing specific check if it's considered unnecessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/323 From jpai at openjdk.java.net Wed Sep 23 15:42:06 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 23 Sep 2020 15:42:06 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException Message-ID: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which reproduces the issue and verifies the fix. ------------- Commit messages: - 8242882: opening jar file with large manifest might throw NegativeArraySizeException Changes: https://git.openjdk.java.net/jdk/pull/323/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=323&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242882 Stats: 88 lines in 2 files changed: 86 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/323.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/323/head:pull/323 PR: https://git.openjdk.java.net/jdk/pull/323 From igraves at openjdk.java.net Wed Sep 23 15:51:08 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 23 Sep 2020 15:51:08 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 15:04:08 GMT, Alan Bateman wrote: >> Yes! I had intended to but it looks like I got hung up making sure non-documented plugins came last. Will push a change >> for this. > > Can we put a base abstract class in jdk.tools.jlink.internal.plugins that implements getUsage. That would avoid needing > to have the same getUsage method in all the plugins. > The text in the value of some of the .usage keys looks like it will wrap significantly, can the values of > release-info.usage and strip-native-debug-symbols.usage be re-formatted so that the usage is readable with a default > terminal? I'll shrink narrow those descriptions down to 80 characters. As to the abstract class, I think it'd make sense to have that implement getUsage, getName, and getDescription -- essentially combine all of those very similar things in the same place. ------------- PR: https://git.openjdk.java.net/jdk/pull/305 From bchristi at openjdk.java.net Wed Sep 23 16:51:46 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 23 Sep 2020 16:51:46 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException In-Reply-To: References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: On Wed, 23 Sep 2020 15:12:58 GMT, Jaikiran Pai wrote: >> Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? >> >> As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds >> the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This >> is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is >> larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the >> `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent >> this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the >> necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which >> reproduces the issue and verifies the fix. > > I had created a copy of this branch in my personal fork and included the `submit.yml` workflow as noted in this recent > mail here[1] to try and run the `tier1` testing for this change. But it looks like that has failed for unrelated > reasons[2]. So I'll go ahead and trigger the `tier1` tests locally instead. [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/jaikiran/jdk/actions/runs/268948812 Hi, Jaikiran. I can sponsor this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/323 From igraves at openjdk.java.net Wed Sep 23 17:26:44 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 23 Sep 2020 17:26:44 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy [v3] In-Reply-To: References: Message-ID: <9j82Rc3ez1J-mKbA3-LhV8Kql9wR1swvEGd4hkT275A=.6d6d241f-3f83-4c08-9e77-52b1f6388dd4@github.com> > These changes update the jlink plugin command line documentation to tidy them up into a more canonical form. > > The output generated by jlink from this change appears as follows: > >> build/macosx-x64/images/jdk/bin/jlink --list-plugins > > List of available plugins: > --strip-debug Strip debug information from the output image > --strip-java-debug-attributes > Strip Java debug attributes from classes in the output image > --exclude-resources > Specify resources to exclude. > e.g.: **.jcov,glob:**/META-INF/** > --exclude-files > Specify files to exclude. > e.g.: **.java,glob:/java.base/lib/client/** > --exclude-jmod-section > Specify a JMOD section to exclude. > Where is "man" or "headers". > --dedup-legal-notices [error-if-not-same-content] > De-duplicate all legal notices. > If error-if-not-same-content is specified then > it will be an error if two files of the same > filename are different. > --system-modules retainModuleTarget > Fast loading of module descriptors (always enabled) > --strip-native-commands Exclude native commands (such as java/java.exe) from the image > --order-resources > Order resources. > e.g.: **/module-info.class, at classlist,/java.base/java/lang/** > --compress <0|1|2>[:filter=] > Compress all resources in the output image. > Level 0: No compression > Level 1: Constant string sharing > Level 2: ZIP. > An optional filter can be > specified to list the pattern of files to be included. > --vm > Select the HotSpot VM in the output image. Default is all > --include-locales [,]* > BCP 47 language tags separated by a comma, allowing > locale matching defined in RFC 4647. e.g.: en,ja,*-IN > --generate-jli-classes @filename > Specify a file listing the java.lang.invoke classes > to pre-generate. By default, this plugin may use a > builtin list of classes to pre-generate. If this plugin > runs on a different runtime version than the image being > created then code generation will be disabled by > default to guarantee correctness > add ignore-version=true to override this. > --release-info |add:=:=:...|del: > option is to load release properties from the supplied file. > add: is to add properties to the release file. > Any number of = pairs can be passed. > del: is to delete the list of keys in release file. > --add-options Prepend the specified string, which may > include whitespace, before any other options when > invoking the virtual machine in the resulting image. > --vendor-bug-url > Override the vendor bug URL baked into the build. > The value of the system property > "java.vendor.url.bug" will be . > --vendor-vm-bug-url > Override the vendor VM bug URL baked into the build. > The URL displayed in VM error logs will be . > --vendor-version > Override the vendor version string baked into the build, > if any. The value of the system property > "java.vendor.version" will be . > > For options requiring a , the value will be a comma separated > list of elements each using one the following forms: > > glob: > regex: > @ where filename is the name of a file containing patterns to be > used, one pattern per line Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Consolidate documentation methods to abstract base class DocumentPlugin ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/305/files - new: https://git.openjdk.java.net/jdk/pull/305/files/a94a16bd..4deaa4bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=305&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=305&range=01-02 Stats: 294 lines in 21 files changed: 42 ins; 200 del; 52 mod Patch: https://git.openjdk.java.net/jdk/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/305/head:pull/305 PR: https://git.openjdk.java.net/jdk/pull/305 From asemenyuk at openjdk.java.net Wed Sep 23 17:35:33 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 23 Sep 2020 17:35:33 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= [v4] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 13:59:25 GMT, Andy Herrick wrote: >> 8253149: Building an installer from invalid app image fails on Windows and Linux >> When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a >> warning message, and then complete the package anyway. > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > 8253149: Building an installer from invalid app image fails (revision Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/271 From igraves at openjdk.java.net Wed Sep 23 17:44:09 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 23 Sep 2020 17:44:09 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy In-Reply-To: References: Message-ID: <-XxIsA1NUfKe2wq3U91KkpBDgLqYj8wX1smB__ehogc=.e42a6e01-7ba2-431f-aed0-c7a964ef96ac@github.com> On Wed, 23 Sep 2020 15:48:46 GMT, Ian Graves wrote: >> Can we put a base abstract class in jdk.tools.jlink.internal.plugins that implements getUsage. That would avoid needing >> to have the same getUsage method in all the plugins. >> The text in the value of some of the .usage keys looks like it will wrap significantly, can the values of >> release-info.usage and strip-native-debug-symbols.usage be re-formatted so that the usage is readable with a default >> terminal? > > I'll shrink narrow those descriptions down to 80 characters. > > As to the abstract class, I think it'd make sense to have that implement getUsage, getName, and getDescription -- > essentially combine all of those very similar things in the same place. Updated to consolidate documentation/resource-related methods into an abstract base class and shortened the mentioned usage bodies to 80 chars or less. ------------- PR: https://git.openjdk.java.net/jdk/pull/305 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 asemenyuk at openjdk.java.net Wed Sep 23 18:11:52 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 23 Sep 2020 18:11:52 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests [v3] In-Reply-To: <-ImMqcEBQNXF3cpNKUZfynd2-u4epkNveyXmw9yjpT0=.6fcf5ecb-53ee-473b-b720-864c224bd313@github.com> References: <-ImMqcEBQNXF3cpNKUZfynd2-u4epkNveyXmw9yjpT0=.6fcf5ecb-53ee-473b-b720-864c224bd313@github.com> Message-ID: <_T9-3L82NWAt2TlPBRatlSH0Q1bsDbdAvbCAQESn_GM=.c1fd52f5-048e-48f3-b255-5e5c361b1ba5@github.com> On Tue, 22 Sep 2020 09:20:33 GMT, Alexander Matveev wrote: >> https://bugs.openjdk.java.net/browse/JDK-8231591 >> >> - Added MultiLauncherTwoPhaseTest which uses predefine app image with multiple launcher and tests to make sure installer >> will create shortcuts for all launchers. >> - Fixed Linux DesktopIntegration to create shortcuts for additional launcher if we using pre-define app image. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8231591: [TESTBUG] Create additional two phase jpackage tests (revision 2) test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java line 636: > 634: private Set namedInitializers; > 635: private Map packageHandlers; > 636: private final List launchersName = new ArrayList(); Would the variable name "launcherNames" be more accurate? test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java line 320: > 318: } > 319: > 320: public PackageTest addLauncherName(String name) { There is no need to make this function public and explicitly call it from tests. It would be better to add call to this function from AdditionalLauncher.applyTo(PackageTest). ------------- PR: https://git.openjdk.java.net/jdk/pull/263 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 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 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 From rriggs at openjdk.java.net Wed Sep 23 18:46:07 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 23 Sep 2020 18:46:07 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v4] In-Reply-To: References: Message-ID: > # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1 formatter reads a stream and produces annotated output of the > tags, values, and structures. > When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized > with the hex formatted output. > > Small changes to HexPrinter are included to improve the output readability. > > > Example decoding of a .pem certificate: > SEQUENCE [910] > SEQUENCE [630] > CONTEXT cons 0 [3] > BYTE 2, > BYTE 3, > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > SEQUENCE [76] > SET [11] > SEQUENCE [9] > OBJECT ID [3] 2.5.4.6 (CountryName) > 'IN' > ... > SET [16] > SEQUENCE [14] > OBJECT ID [3] 2.5.4.3 (CommonName) > Client1 > SEQUENCE [30] > UTCTIME [13] '150526221718Z' > UTCTIME [13] '250523221718Z' > ... > SEQUENCE [290] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > NULL > BIT STRING [271] > CONTEXT cons 3 [123] > SEQUENCE [121] > SEQUENCE [9] > OBJECT ID [3] 2.5.29.19 (BasicConstraints) > OCTET STRING [2] > SEQUENCE [44] > OBJECT ID [9] 2.16.840.1.113730.1.13 > OCTET STRING [31] '..OpenSSL Generated Certificate' > SEQUENCE [29] > OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > OCTET STRING [22] > SEQUENCE [31] > OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > OCTET STRING [24] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > BIT STRING [257] > When used with the HexPrinter test utility, the formatting of the > hexadecimal values is selected with the parameters to HexPrinter. > > 0000: 30 82 03 8e ; SEQUENCE [910] > 0004: 30 82 02 76 ; SEQUENCE [630] > 0008: a0 03 ; CONTEXT cons 0 [3] > 000a: 02 01 02 ; BYTE 2, > 000d: 02 01 03 ; BYTE 3, > 0010: 30 0d ; SEQUENCE [13] > 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 001d: 05 00 ; NULL > 001f: 30 ; SEQUENCE [76] > 0020: 4c ; > 0021: 31 0b ; SET [11] > 0023: 30 09 ; SEQUENCE [9] > 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) > 002a: 13 02 49 4e ; 'IN' > > ... ... > > 005b: 31 10 ; SET [16] > 005d: 30 0e ; SEQUENCE [14] > 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) > 0060: 03 55 04 03 ; > 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 > 006d: 30 1e ; SEQUENCE [30] > 006f: 17 ; UTCTIME [13] '150526221718Z' > 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; > 007e: 17 0d ; UTCTIME [13] '250523221718Z' > 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; > > ... ... > > 00db: 30 82 01 22 ; SEQUENCE [290] > 00df: 30 ; SEQUENCE [13] > 00e0: 0d ; > 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > 00ec: 05 00 ; NULL > 00ee: 03 82 ; BIT STRING [271] > 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; > > ... > > 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; > 0200: 01 ; > 0201: a3 7b ; CONTEXT cons 3 [123] > 0203: 30 79 ; SEQUENCE [121] > 0205: 30 09 ; SEQUENCE [9] > 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) > 020c: 04 02 30 00 ; OCTET STRING [2] > 0210: 30 2c ; SEQUENCE [44] > 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 > 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated > Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; > 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; > 023e: 30 1d ; SEQUENCE [29] > 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] > 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; > 025d: 30 1f ; SEQUENCE [31] > 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > 0260: 03 55 1d 23 ; > 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] > 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ; NULL > 028d: 03 82 01 ; BIT STRING [257] > 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; > > ... > > 0390: 6d 94 ; Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Cleanup of indeterminate length tag values and correct skipping of large tag-values. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/268/files - new: https://git.openjdk.java.net/jdk/pull/268/files/d56007bc..25115595 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=02-03 Stats: 50 lines in 1 file changed: 20 ins; 4 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/268/head:pull/268 PR: https://git.openjdk.java.net/jdk/pull/268 From rriggs at openjdk.java.net Wed Sep 23 18:51:22 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 23 Sep 2020 18:51:22 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 00:19:53 GMT, Weijun Wang wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Small cleanups to javadoc and code > > test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 228: > >> 226: break; >> 227: >> 228: case TAG_OctetString: > > I'd rather print nothing for OCTET STRING. My understanding of it is opaque octets and not meant to be printable. Octet Strings can may contain printable strings and it is useful to print them. A heuristic is used to determine if they are printable and the length is limited to avoid spewing garbage. > test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 362: > >> 360: switch (tag & 0xc0) { >> 361: case TAG_APPLICATION: >> 362: return "APPLICATION " + cons + (tag & 0x1f); > > I am not sure how important it is to print out "cons". Also, the tag here is usually shown as "[1]" in ASN.1 > definition. Of course, if you choose this style, you might want to avoid using brackets for length. It provides a more complete info on the tag even though the application may not have publicly defined its values. ------------- PR: https://git.openjdk.java.net/jdk/pull/268 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 almatvee at openjdk.java.net Wed Sep 23 22:23:20 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 23 Sep 2020 22:23:20 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= [v4] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 13:59:25 GMT, Andy Herrick wrote: >> 8253149: Building an installer from invalid app image fails on Windows and Linux >> When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a >> warning message, and then complete the package anyway. > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > 8253149: Building an installer from invalid app image fails (revision Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/271 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 mchung at openjdk.java.net Wed Sep 23 23:03:35 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 23 Sep 2020 23:03:35 GMT Subject: RFR: 8159746: (proxy) Support for default methods Message-ID: This proposes a new static `Proxy::invokeDefaultMethod` method to invoke the given default method on the given proxy instance. The implementation looks up a method handle for `invokespecial` instruction as if called from with the proxy class as the caller, equivalent to calling `X.super::m` where `X` is a proxy interface of the proxy class and `X.super::m` will resolve to the specified default method. The implementation will call a private static `proxyClassLookup(Lookup caller)` method of the proxy class to obtain its private Lookup. This private method in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class with full privilege access to use, or else `IllegalAccessException` will be thrown. This patch also proposes to define a proxy class in an unnamed module to a dynamic module to strengthen encapsulation such that they are only unconditionally exported from a named module but not open for deep reflective access. This only applies to the case if all the proxy interfaces are public and in a package that is exported or open. One dynamic module is created for each class loader that defines proxies. The change changes the dynamic module to contain another package (same name as the module) that is unconditionally exported and is opened to `java.base` only. There is no change to the package and module of the proxy class for the following cases: - if at least one proxy interface is non-public, then the proxy class is defined in the package and module of the non-public interfaces - if at least one proxy is in a package that is non-exported and non-open, if all proxy interfaces are public, then the proxy class is defined in a non-exported, non-open package of a dynamic module. The spec change is that a proxy class used to be defined in an unnamed module, i.e. in a exported and open package, is defined in an unconditionally exported but non-open package. Programs that assume it to be open unconditionally will be affected and cannot do deep reflection on such proxy classes. Peter Levart contributed an initial prototype [1] (thanks Peter). I think the exceptions could be simplified as more checking should be done prior to the invocation of the method handle like checking the types of the arguments with the method type. This approach avoids defining a public API `protected Proxy::$$proxyClassLookup$$` method. Instead it defines a private static method that is restricted for Proxy class to use (by taking a caller parameter to ensure it's a private lookup on Proxy class). javadoc/specdiff: http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/ http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/ [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html ------------- Commit messages: - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method - fix regression tests due to proxy name change - minor bug fix - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method - generate private accessor method to obtain private lookup - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method - more clean up - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method - Revise the API to take a default method - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3320fc0f...c311a744 Changes: https://git.openjdk.java.net/jdk/pull/313/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8159746 Stats: 896 lines in 19 files changed: 810 ins; 27 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/313.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/313/head:pull/313 PR: https://git.openjdk.java.net/jdk/pull/313 From almatvee at openjdk.java.net Wed Sep 23 23:08:06 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 23 Sep 2020 23:08:06 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests [v3] In-Reply-To: <_T9-3L82NWAt2TlPBRatlSH0Q1bsDbdAvbCAQESn_GM=.c1fd52f5-048e-48f3-b255-5e5c361b1ba5@github.com> References: <-ImMqcEBQNXF3cpNKUZfynd2-u4epkNveyXmw9yjpT0=.6fcf5ecb-53ee-473b-b720-864c224bd313@github.com> <_T9-3L82NWAt2TlPBRatlSH0Q1bsDbdAvbCAQESn_GM=.c1fd52f5-048e-48f3-b255-5e5c361b1ba5@github.com> Message-ID: On Wed, 23 Sep 2020 18:07:18 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8231591: [TESTBUG] Create additional two phase jpackage tests (revision 2) > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java line 320: > >> 318: } >> 319: >> 320: public PackageTest addLauncherName(String name) { > > There is no need to make this function public and explicitly call it from tests. > It would be better to add call to this function from AdditionalLauncher.applyTo(PackageTest). But test calls AdditionalLauncher.applyTo(JPackageCommand cmd), which does not have reference to PackageTest. Do you know why we need two applyTo()? ------------- PR: https://git.openjdk.java.net/jdk/pull/263 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 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 mchung at openjdk.java.net Thu Sep 24 00:26:11 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 24 Sep 2020 00:26:11 GMT Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Tue, 22 Sep 2020 09:49:12 GMT, Chris Hegarty wrote: >> note: I have removed from the original patch the code related to javax.lang.model, I will publish them in a separate PR > > @vicente-romero-oracle I noticed that we can also remove the preview args from the record serialization tests and > ObjectMethodsTest. I opened a PR against the branch in your fork. You should be able to just merge in the changes. See > https://github.com/vicente-romero-oracle/jdk/pull/1 What is the policy of `@since` release value when a preview API becomes final. I would expect `@since` should be updated from 14 to 16 because 16 is the Java SE release these APIs are added?? ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From alex.buckley at oracle.com Thu Sep 24 00:40:11 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 23 Sep 2020 17:40:11 -0700 Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <495cc1e9-41ad-3f9a-c91d-93b0d0d6c3f9@oracle.com> On 9/23/2020 5:26 PM, Mandy Chung wrote: > What is the policy of `@since` release value when a preview API > becomes final. I would expect `@since` should be updated from 14 > to 16 because 16 is the Java SE release these APIs are added?? Yes. Per http://openjdk.java.net/jeps/12#Specifications-of-Preview-Features : In particular, all elements of a preview API must have the following tags: ... An @since tag that indicates the release when [the API element] was first added. *If the API element is eventually made final and permanent in Java SE $N, then the @since tag must be changed to indicate the $N release (the element's history prior to $N is not of long-term interest).* Alex From mchung at openjdk.java.net Thu Sep 24 00:55:22 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 24 Sep 2020 00:55:22 GMT Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Thu, 24 Sep 2020 00:23:13 GMT, Mandy Chung wrote: >> @vicente-romero-oracle I noticed that we can also remove the preview args from the record serialization tests and >> ObjectMethodsTest. I opened a PR against the branch in your fork. You should be able to just merge in the changes. See >> https://github.com/vicente-romero-oracle/jdk/pull/1 > > What is the policy of `@since` release value when a preview API becomes final. I would expect `@since` should be > updated from 14 to 16 because 16 is the Java SE release these APIs are added?? Thanks Alex. @vicente-romero-oracle `@since` needs to be changed. ------------- PR: https://git.openjdk.java.net/jdk/pull/290 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: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 jai.forums2013 at gmail.com Thu Sep 24 07:04:57 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 24 Sep 2020 12:34:57 +0530 Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException In-Reply-To: References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: Hello Brent, Thank you for sponsoring this change. In the meantime, I triggered the pre-submit GitHub action job to run the "tier1" tests for a duplicate branch of this PR. That completed successfully https://github.com/jaikiran/jdk/actions/runs/269960940. I'll wait for the reviews, before initiating any /integrate command. -Jaikiran On 23/09/20 10:21 pm, Brent Christian wrote: > On Wed, 23 Sep 2020 15:12:58 GMT, Jaikiran Pai wrote: > >>> Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? >>> >>> As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds >>> the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This >>> is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is >>> larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the >>> `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent >>> this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the >>> necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which >>> reproduces the issue and verifies the fix. >> I had created a copy of this branch in my personal fork and included the `submit.yml` workflow as noted in this recent >> mail here[1] to try and run the `tier1` testing for this change. But it looks like that has failed for unrelated >> reasons[2]. So I'll go ahead and trigger the `tier1` tests locally instead. [1] >> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] >> https://github.com/jaikiran/jdk/actions/runs/268948812 > Hi, Jaikiran. I can sponsor this change. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/323 From shade at openjdk.java.net Thu Sep 24 08:42:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 24 Sep 2020 08:42:58 GMT Subject: RFR: 8253583: java/util/StringJoiner tests failing on 32-bit VMs after JDK-8246697 Message-ID: JDK-8246697 added -Xmx4g to test configurations. 32-bit VMs cannot do it. @requires tests the OS RAM size, but you can easily have the x86_32 host with more than 4G ram, yet JVM would fail to acquire that heap size. Need to check for bitness explicitly. Testing: - [x] java/util/StringJoiner on x86_64 (still run) - [x] java/util/StringJoiner on x86_32 (skipped now) ------------- Commit messages: - 8253583: java/util/StringJoiner tests failing on 32-bit VMs after JDK-8246697 Changes: https://git.openjdk.java.net/jdk/pull/331/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=331&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253583 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/331.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/331/head:pull/331 PR: https://git.openjdk.java.net/jdk/pull/331 From kim.barrett at oracle.com Thu Sep 24 08:59:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 24 Sep 2020 04:59:15 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> Message-ID: <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> > On Sep 23, 2020, at 2:10 AM, Eric Liu wrote: > > Hi Kim, > > Sorry for the delay. > > This patch removes a redundant string copy in NetworkInterface.c to avoid string-truncation > warning. Other warnings we talked before, which are unable to completely fix in different version > of gcc, I have to use pragma to suppress them as a workaround. > > This patch now could compile with gcc-7, gcc-8, gcc-9, gcc-10 both with or without asan. > > [TESTS] > Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. > No new failure found. > > http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8252407 If possible, my preference would be to avoid the pragma cruft and write the code in such a way that gcc8/9 without asan doesn't warn, and gcc10 doesn't warn with or without asan. I've kind of lost track in the discussion of all the variants whether that's actually feasible. From alanb at openjdk.java.net Thu Sep 24 09:30:54 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 24 Sep 2020 09:30:54 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy In-Reply-To: <-XxIsA1NUfKe2wq3U91KkpBDgLqYj8wX1smB__ehogc=.e42a6e01-7ba2-431f-aed0-c7a964ef96ac@github.com> References: <-XxIsA1NUfKe2wq3U91KkpBDgLqYj8wX1smB__ehogc=.e42a6e01-7ba2-431f-aed0-c7a964ef96ac@github.com> Message-ID: On Wed, 23 Sep 2020 17:41:49 GMT, Ian Graves wrote: >> I'll shrink narrow those descriptions down to 80 characters. >> >> As to the abstract class, I think it'd make sense to have that implement getUsage, getName, and getDescription -- >> essentially combine all of those very similar things in the same place. > > Updated to consolidate documentation/resource-related methods into an abstract base class and shortened the mentioned > usage bodies to 80 chars or less. AbstractPlugin might be a better name for the abstract class as it will likely define methods beyond access to name, description and usage. It also needs a copyright header. StripNativeDebugSymbolsPlugin may have been missed in the update, it can extend the abstract class too. AddResourcePlugin: the name field can be removed, also should be good to rename "n" to "name" so it's a bit clearer. TaskHelper - the IDE may have messed up the imports when it was edited. ------------- PR: https://git.openjdk.java.net/jdk/pull/305 From Alan.Bateman at oracle.com Thu Sep 24 09:32:05 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Sep 2020 10:32:05 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> Message-ID: On 24/09/2020 09:59, Kim Barrett wrote: > If possible, my preference would be to avoid the pragma cruft and write the > code in such a way that gcc8/9 without asan doesn't warn, and gcc10 doesn't > warn with or without asan. I've kind of lost track in the discussion of all > the variants whether that's actually feasible. > > I agree, the program cruft in NetworkInterface.c is unmaintainable and not the right place for it. -Alan. From alanb at openjdk.java.net Thu Sep 24 09:35:53 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 24 Sep 2020 09:35:53 GMT Subject: RFR: 8253583: java/util/StringJoiner tests failing on 32-bit VMs after JDK-8246697 In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 08:35:24 GMT, Aleksey Shipilev wrote: > JDK-8246697 added -Xmx4g to test configurations. 32-bit VMs cannot do it. @requires tests the OS RAM size, but you can > easily have the x86_32 host with more than 4G ram, yet JVM would fail to acquire that heap size. Need to check for > bitness explicitly. Testing: > - [x] java/util/StringJoiner on x86_64 (still run) > - [x] java/util/StringJoiner on x86_32 (skipped now) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/331 From tschatzl at openjdk.java.net Thu Sep 24 09:51:37 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 24 Sep 2020 09:51:37 GMT Subject: RFR: 8253583: java/util/StringJoiner tests failing on 32-bit VMs after JDK-8246697 In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 08:35:24 GMT, Aleksey Shipilev wrote: > JDK-8246697 added -Xmx4g to test configurations. 32-bit VMs cannot do it. @requires tests the OS RAM size, but you can > easily have the x86_32 host with more than 4G ram, yet JVM would fail to acquire that heap size. Need to check for > bitness explicitly. Testing: > - [x] java/util/StringJoiner on x86_64 (still run) > - [x] java/util/StringJoiner on x86_32 (skipped now) Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/331 From shade at openjdk.java.net Thu Sep 24 10:04:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 24 Sep 2020 10:04:58 GMT Subject: RFR: 8253583: java/util/StringJoiner tests failing on 32-bit VMs after JDK-8246697 In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 09:48:55 GMT, Thomas Schatzl wrote: >> JDK-8246697 added -Xmx4g to test configurations. 32-bit VMs cannot do it. @requires tests the OS RAM size, but you can >> easily have the x86_32 host with more than 4G ram, yet JVM would fail to acquire that heap size. Need to check for >> bitness explicitly. Testing: >> - [x] java/util/StringJoiner on x86_64 (still run) >> - [x] java/util/StringJoiner on x86_32 (skipped now) > > Lgtm. Trivial, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/331 From tschatzl at openjdk.java.net Thu Sep 24 10:26:29 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 24 Sep 2020 10:26:29 GMT Subject: RFR: 8253583: java/util/StringJoiner tests failing on 32-bit VMs after JDK-8246697 In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 10:02:13 GMT, Aleksey Shipilev wrote: >> Lgtm. > > Trivial, right? Trivial. ------------- PR: https://git.openjdk.java.net/jdk/pull/331 From shade at openjdk.java.net Thu Sep 24 10:41:08 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 24 Sep 2020 10:41:08 GMT Subject: Integrated: 8253583: java/util/StringJoiner tests failing on 32-bit VMs after JDK-8246697 In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 08:35:24 GMT, Aleksey Shipilev wrote: > JDK-8246697 added -Xmx4g to test configurations. 32-bit VMs cannot do it. @requires tests the OS RAM size, but you can > easily have the x86_32 host with more than 4G ram, yet JVM would fail to acquire that heap size. Need to check for > bitness explicitly. Testing: > - [x] java/util/StringJoiner on x86_64 (still run) > - [x] java/util/StringJoiner on x86_32 (skipped now) This pull request has now been integrated. Changeset: dd2c456e Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/dd2c456e Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8253583: java/util/StringJoiner tests failing on 32-bit VMs after JDK-8246697 Reviewed-by: alanb, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/331 From michaelm at openjdk.java.net Thu Sep 24 10:51:53 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 24 Sep 2020 10:51:53 GMT Subject: RFR: 8245194: Unix domain socket channel implementation [v6] In-Reply-To: References: Message-ID: > Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >>> think of that. >>> >>> There is a fair bit of other refactoring and simplification done also. Next version is at: >>> >>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >>> >> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the >> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved >> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a >> number points that require clarification to fully understand how this will work with relative, directly relative and >> drive relative paths. >> > > Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That > would leave WindowsPath unchanged. >> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >> to get the file path in bytes. >> > > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to > be useful by other components. >> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its >> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main >> issue is that class is that it means we end up with two classes with static factory methods doing the same thing). > > Okay, that does simplify it a bit. > > Thanks, > Michael. > >> -Alan. >> >> >> >> >> >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: unixdomainchannels: some tests were failing on Windows version prior to 10/2019 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/52/files - new: https://git.openjdk.java.net/jdk/pull/52/files/36695095..d29e8cc2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=04-05 Stats: 11 lines in 3 files changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk/pull/52 From michaelm at openjdk.java.net Thu Sep 24 12:17:52 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 24 Sep 2020 12:17:52 GMT Subject: RFR: 8245194: Unix domain socket channel implementation [v7] In-Reply-To: References: Message-ID: > Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >>> think of that. >>> >>> There is a fair bit of other refactoring and simplification done also. Next version is at: >>> >>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >>> >> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the >> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved >> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a >> number points that require clarification to fully understand how this will work with relative, directly relative and >> drive relative paths. >> > > Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That > would leave WindowsPath unchanged. >> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >> to get the file path in bytes. >> > > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to > be useful by other components. >> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its >> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main >> issue is that class is that it means we end up with two classes with static factory methods doing the same thing). > > Okay, that does simplify it a bit. > > Thanks, > Michael. > >> -Alan. >> >> >> >> >> >> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into unixdomainchannels - unixdomainchannels: some tests were failing on Windows version prior to 10/2019 - unixdomainchannels: updates after comments sent by Alan 14 Sept - unixdomainchannels: updates from review of Sept 11 2020 - Merge branch 'master' into unixdomainchannels - Made some changes relating to selection of the local directory where automatically bound server sockets are created. After this change it is no longer necessary to specify the location in individual tests. - unixdomainchannels: fixing compile error on Windows and Alan's review comment this morning - unixdomainchannels: initial commit from hg sandbox with changes from Alan's email 06/09/2020 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/52/files - new: https://git.openjdk.java.net/jdk/pull/52/files/d29e8cc2..a08186d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=05-06 Stats: 15223 lines in 623 files changed: 7434 ins; 6123 del; 1666 mod Patch: https://git.openjdk.java.net/jdk/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk/pull/52 From coleenp at openjdk.java.net Thu Sep 24 12:27:14 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 24 Sep 2020 12:27:14 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Wed, 23 Sep 2020 03:34:29 GMT, Vicente Romero wrote: >> Co-authored-by: Vicente Romero >> Co-authored-by: Harold Seigel >> Co-authored-by: Jonathan Gibbons >> Co-authored-by: Brian Goetz >> Co-authored-by: Maurizio Cimadamore >> Co-authored-by: Joe Darcy >> Co-authored-by: Chris Hegarty >> Co-authored-by: Jan Lahoda > > Vicente Romero has updated the pull request incrementally with three additional commits since the last revision: > > - Merge pull request #1 from ChrisHegarty/record-serial-tests > > Remove preview args from JDK tests > - Remove preview args from ObjectMethodsTest > - Remove preview args from record serialization tests The classfile parser changes look good to me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/290 From asemenyuk at openjdk.java.net Thu Sep 24 13:52:31 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 24 Sep 2020 13:52:31 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests [v3] In-Reply-To: References: <-ImMqcEBQNXF3cpNKUZfynd2-u4epkNveyXmw9yjpT0=.6fcf5ecb-53ee-473b-b720-864c224bd313@github.com> <_T9-3L82NWAt2TlPBRatlSH0Q1bsDbdAvbCAQESn_GM=.c1fd52f5-048e-48f3-b255-5e5c361b1ba5@github.com> Message-ID: On Wed, 23 Sep 2020 23:05:06 GMT, Alexander Matveev wrote: >> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java line 320: >> >>> 318: } >>> 319: >>> 320: public PackageTest addLauncherName(String name) { >> >> There is no need to make this function public and explicitly call it from tests. >> It would be better to add call to this function from AdditionalLauncher.applyTo(PackageTest). > > But test calls AdditionalLauncher.applyTo(JPackageCommand cmd), which does not have reference to PackageTest. Do you > know why we need two applyTo()? Just change the test code to call AdditionalLauncher.applyTo(PackageTest): `launcher1.applyTo(packageTest); launcher2.applyTo(packageTest)` AdditionalLauncher.applyTo(JPackageCommand) is for non-packaging tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/263 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 rrich at openjdk.java.net Thu Sep 24 14:17:10 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 24 Sep 2020 14:17:10 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v2] In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 05:02:42 GMT, David Holmes wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes based on dholmes' feedback. >> >> EscapeBarrier::sync_and_suspend_all(): >> >> - Set suspend flags before handshake because then the setting will be visible >> after leaving the _thread_blocked state in JavaThread::wait_for_object_deoptimization() >> >> JavaThread::wait_for_object_deoptimization() >> >> - Reuse SpinYield instead of new custom spinning code. >> >> - Do safepoint check after the loop. This is possible because the >> set_obj_deopt_flag is done before the handshake. >> >> - Don't set_suspend_equivalent() anymore for more simplicity. It's just an >> optimization (that won't pay off here). >> >> Added/updated source code comments. >> >> Additional smaller enhancements. > > src/hotspot/share/opto/macro.cpp line 1096: > >> 1094: // interpreter frames for this compiled frame and that won't play >> 1095: // nice with JVMTI popframe. >> 1096: if (!EliminateAllocations || !alloc->_is_non_escaping) { > > The comment needs to be updated to match the new code. Done. > src/hotspot/share/runtime/thread.cpp line 1926: > >> 1924: delete dlv; >> 1925: } while (deferred->length() != 0); >> 1926: delete deferred_updates(); > > This looks suspect - we delete what is pointed to but we don't NULL the field. Fixed. > src/hotspot/share/runtime/thread.cpp line 2640: > >> 2638: } >> 2639: >> 2640: void JavaThread::wait_for_object_deoptimization() { > > I find this method very complex, and the fact it needs to recheck many of the conditions already checked in the calling > code, suggests to me that the structure here is not quite right. Perhaps > JavaThread::handle_special_runtime_exit_condition should be the place where we loop over each of the potential > conditions, instead of calling per-condition code that then loops and potentially rechecks other conditions. For now I reshaped and hopefully also simplified the method. It should resemble its model java_suspend_self_with_safepoint_check() very much now. With this similarity I'd see the added complexity to be small. In fact wait_for_object_deoptimization() could be a drop-in replacement for java_suspend_self_with_safepoint_check(). Well, the condition in the callers would have to be adapted. > src/hotspot/share/runtime/thread.cpp line 2647: > >> 2645: bool should_spin_wait = true; >> 2646: do { >> 2647: set_thread_state(_thread_blocked); > > It isn't obvious that this raw thread state change is safe. I added a comment explaining it before the method definition. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Thu Sep 24 14:17:00 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 24 Sep 2020 14:17:00 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v2] In-Reply-To: References: Message-ID: <9JlQSgv11V9HkT3GQn61Lux-NcHNfAXCT2JhhrxmWFE=.820921fe-6440-41a7-acab-377de2bfb423@github.com> > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Changes based on dholmes' feedback. EscapeBarrier::sync_and_suspend_all(): - Set suspend flags before handshake because then the setting will be visible after leaving the _thread_blocked state in JavaThread::wait_for_object_deoptimization() JavaThread::wait_for_object_deoptimization() - Reuse SpinYield instead of new custom spinning code. - Do safepoint check after the loop. This is possible because the set_obj_deopt_flag is done before the handshake. - Don't set_suspend_equivalent() anymore for more simplicity. It's just an optimization (that won't pay off here). Added/updated source code comments. Additional smaller enhancements. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/119/files - new: https://git.openjdk.java.net/jdk/pull/119/files/79f5b823..18dd54b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=00-01 Stats: 109 lines in 6 files changed: 54 ins; 36 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Thu Sep 24 14:20:54 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 24 Sep 2020 14:20:54 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v2] In-Reply-To: References: Message-ID: <52tEGYwfin4D77BRSb_uhGxutsKKz0Fyeus9ODCnrO4=.31222347-5829-442c-9ad0-93a2901dc86c@github.com> On Mon, 14 Sep 2020 05:08:39 GMT, David Holmes wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes based on dholmes' feedback. >> >> EscapeBarrier::sync_and_suspend_all(): >> >> - Set suspend flags before handshake because then the setting will be visible >> after leaving the _thread_blocked state in JavaThread::wait_for_object_deoptimization() >> >> JavaThread::wait_for_object_deoptimization() >> >> - Reuse SpinYield instead of new custom spinning code. >> >> - Do safepoint check after the loop. This is possible because the >> set_obj_deopt_flag is done before the handshake. >> >> - Don't set_suspend_equivalent() anymore for more simplicity. It's just an >> optimization (that won't pay off here). >> >> Added/updated source code comments. >> >> Additional smaller enhancements. > > src/hotspot/share/prims/whitebox.cpp line 884: > >> 882: >> 883: WB_ENTRY(jboolean, WB_IsFrameDeoptimized(JNIEnv* env, jobject o, jint depth)) >> 884: JavaThread* t = JavaThread::current(); > > A WB_ENTRY is a JNI_ENTRY which means the current JavaThread is already available via the `thread` variable. Done. > src/hotspot/share/runtime/thread.cpp line 2660: > >> 2658: // showed 5% better performance when spinning. >> 2659: if (should_spin_wait) { >> 2660: // Inspired by HandshakeSpinYield > > Can we not reuse any existing spinning code in the VM? Good point. I wasn't aware of SpinYield. I use it now for the spinning. I use 10 * SpinYield::default_spin_limit as spin limit based on microbenchmarking: http://cr.openjdk.java.net/~rrich/webrevs/8227745/pr116v2.microbenchmark/ ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From herrick at openjdk.java.net Thu Sep 24 14:22:17 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 24 Sep 2020 14:22:17 GMT Subject: RFR: 8253379: [windows] Several jpackage tests failed with error code 1638 Message-ID: 8253379: [windows] Several jpackage tests failed with error code 1638 two windows specific test fixes in WindowsHelper: 1.) do not test that the parent directory of a windows menu shortcut is empty after shortcut is uninstalled (there may be other shortcuts using that directory) 2.) do not programmatically install windows exe installers (since we have no way of programmatically uninstalling them) ------------- Commit messages: - 8253379: [windows] Several jpackage tests failed with error code 1638 Changes: https://git.openjdk.java.net/jdk/pull/337/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=337&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253379 Stats: 9 lines in 1 file changed: 2 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/337.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/337/head:pull/337 PR: https://git.openjdk.java.net/jdk/pull/337 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 github.com+70726043+rgiulietti at openjdk.java.net Thu Sep 24 15:35:29 2020 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Thu, 24 Sep 2020 15:35:29 GMT Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) [v2] In-Reply-To: References: <1afMfHAUJEnM5nUkl-LbkSxjYOZwjKgWu2NDIfhbc5U=.bbeab3f9-1278-4103-b5b3-dd9a2ae745a8@github.com> Message-ID: <_0eIOqisk_pEhQy1ekXy-I2-YxtB9Vs-4kjLrzBevKk=.dbe46c8a-d0f4-4919-87ec-7fa1ab74b8ce@github.com> On Wed, 9 Sep 2020 07:38:38 GMT, Raffaello Giulietti wrote: >> Since this patch does not involve adding the intrinsic, maybe drop "(Needs to be intrinsic)" from the synopsis? > > @shipilev I agree, but that's the title chosen by the reporter of the JBS issue. Not sure I can edit it without > impacting bots and tools. Hello this is a gentle reminder that this issue still needs a more formal review. Greetings Raffaello ------------- PR: https://git.openjdk.java.net/jdk/pull/31 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 vromero at openjdk.java.net Thu Sep 24 15:49:52 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 24 Sep 2020 15:49:52 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v4] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > Co-authored-by: Vicente Romero > Co-authored-by: Harold Seigel > Co-authored-by: Jonathan Gibbons > Co-authored-by: Brian Goetz > Co-authored-by: Maurizio Cimadamore > Co-authored-by: Joe Darcy > Co-authored-by: Chris Hegarty > Co-authored-by: Jan Lahoda Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: modifiying @since from 14 to 16 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/26b80775..514b0a80 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=02-03 Stats: 8 lines in 7 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Thu Sep 24 15:49:52 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 24 Sep 2020 15:49:52 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <0H-sMIm0mwGW2f2OxwAwMGBtxDf2BUf7ds3tGEgYXrc=.849aab2b-4cf3-49f7-8e49-ad1df75cb0bb@github.com> On Thu, 24 Sep 2020 12:23:13 GMT, Coleen Phillimore wrote: >> Vicente Romero has updated the pull request incrementally with three additional commits since the last revision: >> >> - Merge pull request #1 from ChrisHegarty/record-serial-tests >> >> Remove preview args from JDK tests >> - Remove preview args from ObjectMethodsTest >> - Remove preview args from record serialization tests > > The classfile parser changes look good to me. I have modified the `@since`: 14 -> 16 ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Thu Sep 24 15:54:57 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 24 Sep 2020 15:54:57 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v5] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <1mJrr-6f-CRtIrhQqH7VlpzuNZdR0dzdDiLnacBx32I=.a0823203-fc37-4fc7-a104-6031c580fd21@github.com> > Co-authored-by: Vicente Romero > Co-authored-by: Harold Seigel > Co-authored-by: Jonathan Gibbons > Co-authored-by: Brian Goetz > Co-authored-by: Maurizio Cimadamore > Co-authored-by: Joe Darcy > Co-authored-by: Chris Hegarty > Co-authored-by: Jan Lahoda Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into JDK-8246774 - modifiying @since from 14 to 16 - Merge pull request #1 from ChrisHegarty/record-serial-tests Remove preview args from JDK tests - Remove preview args from ObjectMethodsTest - Remove preview args from record serialization tests - removing the javax.lang.model related code to be moved to a separate bug - 8246774: Record Classes (final) implementation Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Jonathan Gibbons Co-authored-by: Brian Goetz Co-authored-by: Maurizio Cimadamore Co-authored-by: Joe Darcy Co-authored-by: Chris Hegarty Co-authored-by: Jan Lahoda ------------- Changes: https://git.openjdk.java.net/jdk/pull/290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=04 Stats: 464 lines in 104 files changed: 23 ins; 267 del; 174 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From bchristi at openjdk.java.net Thu Sep 24 16:40:36 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Thu, 24 Sep 2020 16:40:36 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException In-Reply-To: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: On Wed, 23 Sep 2020 15:06:55 GMT, Jaikiran Pai wrote: > Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? > > As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds > the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This > is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is > larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the > `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent > this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the > necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which > reproduces the issue and verifies the fix. Changes requested by bchristi (Reviewer). src/java.base/share/classes/java/util/jar/JarFile.java line 791: > 789: private byte[] getBytes(ZipEntry ze) throws IOException { > 790: try (InputStream is = super.getInputStream(ze)) { > 791: int len = (int)ze.getSize(); I think the main issue is the casting of the 'long' value from ZipEntry.getSize() into an 'int'. I think checking if the size is > the maximum array size and throwing an OOME here might be a sufficient fix on its own. ------------- PR: https://git.openjdk.java.net/jdk/pull/323 From rrich at openjdk.java.net Thu Sep 24 16:59:03 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 24 Sep 2020 16:59:03 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber 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: - Merge branch 'master' into JDK-8227745 - Changes based on dholmes' feedback. EscapeBarrier::sync_and_suspend_all(): - Set suspend flags before handshake because then the setting will be visible after leaving the _thread_blocked state in JavaThread::wait_for_object_deoptimization() JavaThread::wait_for_object_deoptimization() - Reuse SpinYield instead of new custom spinning code. - Do safepoint check after the loop. This is possible because the set_obj_deopt_flag is done before the handshake. - Don't set_suspend_equivalent() anymore for more simplicity. It's just an optimization (that won't pay off here). Added/updated source code comments. Additional smaller enhancements. - 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/119/files - new: https://git.openjdk.java.net/jdk/pull/119/files/18dd54b4..5bf631ba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=01-02 Stats: 26592 lines in 830 files changed: 13744 ins; 9718 del; 3130 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From serb at openjdk.java.net Thu Sep 24 17:15:15 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 24 Sep 2020 17:15:15 GMT Subject: RFR: 8253606: Need to add missed constructor to the SwingEventMonitor Message-ID: The javadoc for this class was added, but the constructor itsef is missed...... ------------- Commit messages: - Update SwingEventMonitor.java Changes: https://git.openjdk.java.net/jdk/pull/340/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=340&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253606 Stats: 9 lines in 1 file changed: 5 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/340.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/340/head:pull/340 PR: https://git.openjdk.java.net/jdk/pull/340 From lancea at openjdk.java.net Thu Sep 24 17:33:47 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 24 Sep 2020 17:33:47 GMT Subject: RFR: 8252537: Updated @exception with @throws [v3] In-Reply-To: References: Message-ID: On Sat, 19 Sep 2020 20:24:14 GMT, Vipin Sharma wrote: >> Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. >> >> Open Subtasks part of this fix are: >> 1. JDK-8252537 >> 2. JDK-8252539 >> 3. JDK-8252540 >> 4. JDK-8252541 >> >> Previous conversation on this: >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html > > Vipin Sharma has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains one commit: > JDK-8252537 Updated @exception with @throws, implemented review comments Overall the changes look OK. in the java.sql set of classes, please updated the modified statements to also use {@code} src/java.sql/share/classes/java/sql/CallableStatement.java line 131: > 129: * a ARRAY, BLOB, CLOB, > 130: * DATALINK, JAVA_OBJECT, NCHAR, > 131: * NCLOB, NVARCHAR, LONGNVARCHAR, Please change to use {@code) as part of the update src/java.sql/share/classes/java/sql/CallableStatement.java line 613: > 611: * a ARRAY, BLOB, CLOB, > 612: * DATALINK, JAVA_OBJECT, NCHAR, > 613: * NCLOB, NVARCHAR, LONGNVARCHAR, Same comment regarding {@code} ------------- Changes requested by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/95 From vsharma at openjdk.java.net Thu Sep 24 18:23:17 2020 From: vsharma at openjdk.java.net (Vipin Sharma) Date: Thu, 24 Sep 2020 18:23:17 GMT Subject: RFR: 8252537: Updated @exception with @throws [v3] In-Reply-To: References: Message-ID: <7rt0V2i3MYuy_gFMS3Ulg82kzxzRPsVxmPjZVjNfKAU=.4e219af7-ed22-406c-a810-ef8db5055cf3@github.com> On Thu, 24 Sep 2020 17:30:52 GMT, Lance Andersen wrote: > Overall the changes look OK. in the java.sql set of classes, please updated the modified statements to also use {@code} Hi @LanceAndersen, it was suggested by @RogerRiggs also. I have created a separate bug JDK-8253612 to fix this for all java.sql and all other core-libs classes. Following is earlier discussion on this. https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068510.html ------------- PR: https://git.openjdk.java.net/jdk/pull/95 From lancea at openjdk.java.net Thu Sep 24 18:30:50 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 24 Sep 2020 18:30:50 GMT Subject: RFR: 8252537: Updated @exception with @throws [v3] In-Reply-To: <7rt0V2i3MYuy_gFMS3Ulg82kzxzRPsVxmPjZVjNfKAU=.4e219af7-ed22-406c-a810-ef8db5055cf3@github.com> References: <7rt0V2i3MYuy_gFMS3Ulg82kzxzRPsVxmPjZVjNfKAU=.4e219af7-ed22-406c-a810-ef8db5055cf3@github.com> Message-ID: On Thu, 24 Sep 2020 18:20:15 GMT, Vipin Sharma wrote: > > Overall the changes look OK. in the java.sql set of classes, please updated the modified statements to also use {@code} > > Hi @LanceAndersen, it was suggested by @RogerRiggs also. I have created a separate bug JDK-8253612 to fix this for all > java.sql and all other core-libs classes. Following is earlier discussion on this. > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068510.html Hi Vipin, I agree overall that to replace all of places in the JDK with {@code} where needed should be a separate task with an umbrella issue with a subtask for each module. Unless there are a large number of other exceptions that are being modified and require updates for {@code} I would prefer to have it done as part of this set of changes ------------- PR: https://git.openjdk.java.net/jdk/pull/95 From herrick at openjdk.java.net Thu Sep 24 20:33:09 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 24 Sep 2020 20:33:09 GMT Subject: RFR: 8253426: jpackage is unable to generate working EXE for add-launcher =?UTF-8?B?4oCm?= Message-ID: 8253426: jpackage is unable to generate working EXE for add-launcher configurations. secondary launchers ignored module, main-jar, and main-class in launcher properties file because the LAUNCHER_DATA param was not removed from the set of params for each new add-module. testcase added in AddLauncherTest,java ------------- Commit messages: - 8253426: jpackage is unable to generate working EXE for add-launcher configurations Changes: https://git.openjdk.java.net/jdk/pull/347/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=347&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253426 Stats: 36 lines in 3 files changed: 33 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/347.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/347/head:pull/347 PR: https://git.openjdk.java.net/jdk/pull/347 From asemenyuk at openjdk.java.net Thu Sep 24 21:56:16 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 24 Sep 2020 21:56:16 GMT Subject: RFR: 8253426: jpackage is unable to generate working EXE for add-launcher =?UTF-8?B?4oCm?= In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 20:25:27 GMT, Andy Herrick wrote: > 8253426: jpackage is unable to generate working EXE for add-launcher configurations. > secondary launchers ignored module, main-jar, and main-class in launcher properties file because the LAUNCHER_DATA > param was not removed from the set of params for each new add-module. testcase added in AddLauncherTest,java test/jdk/tools/jpackage/share/AddLauncherTest.java line 215: > 213: TKit.assertEquals(moduleValue, JavaAppDesc.parse( > 214: modularAppDesc.toString()).setBundleFileName(null).toString(), > 215: "app.mainmodule value in cfg file not as expected"); I'd suggest to change comment to neutral "Check value of app.mainmodule in cfg file". test/jdk/tools/jpackage/share/AddLauncherTest.java line 213: > 211: String mainClass = null; > 212: String classpath = null; > 213: TKit.assertEquals(moduleValue, JavaAppDesc.parse( The first parameter of TKit.assertEquals() function should be expected value which I assume is the value obtained with the call to JavaAppDesc.parse(...) and the second parameter is actual value that seems to be the value of moduleValue variable. So the first two parameters of TKit.assertEquals() call should be swapped. test/jdk/tools/jpackage/share/AddLauncherTest.java line 218: > 216: > 217: TKit.trace("moduleValue: " + moduleValue + " mainClass: " + mainClass > 218: + " classpath: " + classpath); `classpath` variable is `null` at this point. What is the point to log its value? The whole log statement is excessive because `classpath` variable is `null` and value of `moduleValue` variable is logged implicitly in TKit.assertEquals() call. test/jdk/tools/jpackage/share/AddLauncherTest.java line 224: > 222: mainClass = cfg.getValue("Application", "app.mainclass"); > 223: classpath = cfg.getValue("Application", "app.classpath"); > 224: TKit.assertEquals(mainClass, nonModularAppDesc.className(), Two first parameters of TKit.assertEquals() call need to be swapped as the first parameter should be expected and the second actual value. test/jdk/tools/jpackage/share/AddLauncherTest.java line 225: > 223: classpath = cfg.getValue("Application", "app.classpath"); > 224: TKit.assertEquals(mainClass, nonModularAppDesc.className(), > 225: "app.mainclass value in NonModularAppLauncher cfg file"); I'd insert log "Check" word at the beginning of the log comment to keep it aligned with other log statements. test/jdk/tools/jpackage/share/AddLauncherTest.java line 228: > 226: TKit.assertTrue(classpath.startsWith("$APPDIR" + File.separator > 227: + nonModularAppDesc.jarFileName()), > 228: "app.classpath value in ModularAppLauncher cfg file"); Changing log comment to `String.format("Check value of app.classpath=[%s] in ModularAppLauncher cfg file is as expected", classpath)` would output value of "app.classpath" property in test log and eliminate need for separate TKit.trace(...) call. ------------- PR: https://git.openjdk.java.net/jdk/pull/347 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 almatvee at openjdk.java.net Thu Sep 24 22:08:11 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 24 Sep 2020 22:08:11 GMT Subject: RFR: 8253379: [windows] Several jpackage tests failed with error code 1638 In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 14:14:54 GMT, Andy Herrick wrote: > 8253379: [windows] Several jpackage tests failed with error code 1638 > two windows specific test fixes in WindowsHelper: > 1.) do not test that the parent directory of a windows menu shortcut is empty after shortcut is uninstalled (there may > be other shortcuts using that directory) 2.) do not programmatically install windows exe installers (since we have no > way of programmatically uninstalling them) According to msiexec help, msiexec supports ProductCode for uninstall "/x | Package|ProductCode". Do you know if it would be possible to use such options? ------------- PR: https://git.openjdk.java.net/jdk/pull/337 From herrick at openjdk.java.net Thu Sep 24 22:45:01 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 24 Sep 2020 22:45:01 GMT Subject: RFR: 8253426: jpackage is unable to generate working EXE for add-launcher =?UTF-8?B?4oCm?= [v2] In-Reply-To: References: Message-ID: > 8253426: jpackage is unable to generate working EXE for add-launcher configurations. > secondary launchers ignored module, main-jar, and main-class in launcher properties file because the LAUNCHER_DATA > param was not removed from the set of params for each new add-module. testcase added in AddLauncherTest,java Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: 8253426: jpackage is unable to generate working EXE for add-launcher configurations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/347/files - new: https://git.openjdk.java.net/jdk/pull/347/files/87f62165..01e12871 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=347&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=347&range=00-01 Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/347.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/347/head:pull/347 PR: https://git.openjdk.java.net/jdk/pull/347 From github.com+51754783+CoreyAshford at openjdk.java.net Thu Sep 24 22:52:34 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Thu, 24 Sep 2020 22:52:34 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: <3EH-0UK3nZW6J1A59XZ6im798XUPkN6OyJgC_Ptyp-Q=.9321be76-0004-40f2-ac74-366123d1fceb@github.com> On Tue, 22 Sep 2020 02:45:36 GMT, CoreyAshford wrote: > This patch set encompasses the following commits: > > - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for > the intrinsic. The API is similar to the existing encodeBlock intrinsic. > - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic > implementation > - Adds a Power64LE-specific implementation of the decodeBlock intrinsic. > - Adds a JMH microbenchmark for both Base64 encoding and encoding. > - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding. This work is covered by an existing IBM <-> Oracle agreement ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From github.com+51754783+CoreyAshford at openjdk.java.net Thu Sep 24 22:52:34 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Thu, 24 Sep 2020 22:52:34 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding Message-ID: This patch set encompasses the following commits: - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic. The API is similar to the existing encodeBlock intrinsic. - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation - Adds a Power64LE-specific implementation of the decodeBlock intrinsic. - Adds a JMH microbenchmark for both Base64 encoding and encoding. - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding. ------------- Commit messages: - Expand the Base64 intrinsic regression test to cover decodeBlock - Add JMH benchmark for Base64 variable length buffer decoding - Add Power9+ intrinsic implementation for Base64 decoding - Add HotSpot code to implement Base64 decodeBlock API - Add HotSpotIntrinsicCandidate and API for Base64 decoding Changes: https://git.openjdk.java.net/jdk/pull/293/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248188 Stats: 1925 lines in 24 files changed: 1899 ins; 4 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/293.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293 PR: https://git.openjdk.java.net/jdk/pull/293 From asemenyuk at openjdk.java.net Thu Sep 24 23:10:25 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 24 Sep 2020 23:10:25 GMT Subject: RFR: 8253379: [windows] Several jpackage tests failed with error code 1638 In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 22:05:34 GMT, Alexander Matveev wrote: >> 8253379: [windows] Several jpackage tests failed with error code 1638 >> two windows specific test fixes in WindowsHelper: >> 1.) do not test that the parent directory of a windows menu shortcut is empty after shortcut is uninstalled (there may >> be other shortcuts using that directory) 2.) do not programmatically install windows exe installers (since we have no >> way of programmatically uninstalling them) > > According to msiexec help, msiexec supports ProductCode for uninstall "/x | Package|ProductCode". Do you know if it > would be possible to use such options? Currently msi wrapper unconditionally adds "/i" on msiexec command line. So passing "/x" option to exe installer would not work. I think we need to rework msi wrapper to only support one command line option - "--uninstall" instead of passing all command line parameters to nested msiexec invocation. ------------- PR: https://git.openjdk.java.net/jdk/pull/337 From mchung at openjdk.java.net Thu Sep 24 23:27:40 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 24 Sep 2020 23:27:40 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy [v3] In-Reply-To: <9j82Rc3ez1J-mKbA3-LhV8Kql9wR1swvEGd4hkT275A=.6d6d241f-3f83-4c08-9e77-52b1f6388dd4@github.com> References: <9j82Rc3ez1J-mKbA3-LhV8Kql9wR1swvEGd4hkT275A=.6d6d241f-3f83-4c08-9e77-52b1f6388dd4@github.com> Message-ID: <_RqH3T86CVYrs8n7-7I7kp6GSAZwvEA52xhldzfZ0o4=.ac5502c4-462e-4574-9e75-89eef74667f4@github.com> On Wed, 23 Sep 2020 17:26:44 GMT, Ian Graves wrote: >> These changes update the jlink plugin command line documentation to tidy them up into a more canonical form. >> >> The output generated by jlink from this change appears as follows: >> >>> build/macosx-x64/images/jdk/bin/jlink --list-plugins >> >> List of available plugins: >> --strip-debug Strip debug information from the output image >> --strip-java-debug-attributes >> Strip Java debug attributes from classes in the output image >> --exclude-resources >> Specify resources to exclude. >> e.g.: **.jcov,glob:**/META-INF/** >> --exclude-files >> Specify files to exclude. >> e.g.: **.java,glob:/java.base/lib/client/** >> --exclude-jmod-section >> Specify a JMOD section to exclude. >> Where is "man" or "headers". >> --dedup-legal-notices [error-if-not-same-content] >> De-duplicate all legal notices. >> If error-if-not-same-content is specified then >> it will be an error if two files of the same >> filename are different. >> --system-modules retainModuleTarget >> Fast loading of module descriptors (always enabled) >> --strip-native-commands Exclude native commands (such as java/java.exe) from the image >> --order-resources >> Order resources. >> e.g.: **/module-info.class, at classlist,/java.base/java/lang/** >> --compress <0|1|2>[:filter=] >> Compress all resources in the output image. >> Level 0: No compression >> Level 1: Constant string sharing >> Level 2: ZIP. >> An optional filter can be >> specified to list the pattern of files to be included. >> --vm >> Select the HotSpot VM in the output image. Default is all >> --include-locales [,]* >> BCP 47 language tags separated by a comma, allowing >> locale matching defined in RFC 4647. e.g.: en,ja,*-IN >> --generate-jli-classes @filename >> Specify a file listing the java.lang.invoke classes >> to pre-generate. By default, this plugin may use a >> builtin list of classes to pre-generate. If this plugin >> runs on a different runtime version than the image being >> created then code generation will be disabled by >> default to guarantee correctness >> add ignore-version=true to override this. >> --release-info |add:=:=:...|del: >> option is to load release properties from the supplied file. >> add: is to add properties to the release file. >> Any number of = pairs can be passed. >> del: is to delete the list of keys in release file. >> --add-options Prepend the specified string, which may >> include whitespace, before any other options when >> invoking the virtual machine in the resulting image. >> --vendor-bug-url >> Override the vendor bug URL baked into the build. >> The value of the system property >> "java.vendor.url.bug" will be . >> --vendor-vm-bug-url >> Override the vendor VM bug URL baked into the build. >> The URL displayed in VM error logs will be . >> --vendor-version >> Override the vendor version string baked into the build, >> if any. The value of the system property >> "java.vendor.version" will be . >> >> For options requiring a , the value will be a comma separated >> list of elements each using one the following forms: >> >> glob: >> regex: >> @ where filename is the name of a file containing patterns to be >> used, one pattern per line > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Consolidate documentation methods to abstract base class DocumentPlugin I suggest to update the PR description with the new `jlink --show-plugins` output. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java line 33: > 31: import java.nio.file.Paths; > 32: import java.text.MessageFormat; > 33: import java.util.*; I assume this change is unintentional. Probably IDE converted the single-class imports to this. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DocumentedPlugin.java line 5: > 3: import jdk.tools.jlink.plugin.Plugin; > 4: > 5: public abstract class DocumentedPlugin implements Plugin { I agree with Alan that `AbstractPlugin` is better. This should also provide the default implementation of `getArgumentsDescription()` such that the plugins don't need to implement. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DocumentedPlugin.java line 7: > 5: public abstract class DocumentedPlugin implements Plugin { > 6: > 7: private final String NAME; Nit: use lowercase for final instance field name. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/OrderResourcesPlugin.java line 50: > 48: */ > 49: public final class OrderResourcesPlugin extends DocumentedPlugin { > 50: public static final String NAME = "order-resources"; This is not related to your change. It can be private static final field. In my past observation, this static final NAME field is defined in every plugin which isn't really a need for it (at least in the current implementation). It might be good to consider the clean up to remove this static final field and instead call `getName()` to get the name. Just a thought. ------------- PR: https://git.openjdk.java.net/jdk/pull/305 From almatvee at openjdk.java.net Thu Sep 24 23:37:46 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 24 Sep 2020 23:37:46 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests [v3] In-Reply-To: References: <-ImMqcEBQNXF3cpNKUZfynd2-u4epkNveyXmw9yjpT0=.6fcf5ecb-53ee-473b-b720-864c224bd313@github.com> <_T9-3L82NWAt2TlPBRatlSH0Q1bsDbdAvbCAQESn_GM=.c1fd52f5-048e-48f3-b255-5e5c361b1ba5@github.com> Message-ID: On Thu, 24 Sep 2020 13:50:07 GMT, Alexey Semenyuk wrote: >> But test calls AdditionalLauncher.applyTo(JPackageCommand cmd), which does not have reference to PackageTest. Do you >> know why we need two applyTo()? > > Just change the test code to call AdditionalLauncher.applyTo(PackageTest): > `launcher1.applyTo(packageTest); > launcher2.applyTo(packageTest)` > > AdditionalLauncher.applyTo(JPackageCommand) is for non-packaging tests. Actually it will not work. I am running appImageCmd command before test executes to generate app image. If I add it to packageTest, jpackage will fail when trying to run command with app-image and launchers. ------------- PR: https://git.openjdk.java.net/jdk/pull/263 From almatvee at openjdk.java.net Thu Sep 24 23:42:50 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 24 Sep 2020 23:42:50 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests [v3] In-Reply-To: References: <-ImMqcEBQNXF3cpNKUZfynd2-u4epkNveyXmw9yjpT0=.6fcf5ecb-53ee-473b-b720-864c224bd313@github.com> <_T9-3L82NWAt2TlPBRatlSH0Q1bsDbdAvbCAQESn_GM=.c1fd52f5-048e-48f3-b255-5e5c361b1ba5@github.com> Message-ID: On Thu, 24 Sep 2020 23:35:15 GMT, Alexander Matveev wrote: >> Just change the test code to call AdditionalLauncher.applyTo(PackageTest): >> `launcher1.applyTo(packageTest); >> launcher2.applyTo(packageTest)` >> >> AdditionalLauncher.applyTo(JPackageCommand) is for non-packaging tests. > > Actually it will not work. I am running appImageCmd command before test executes to generate app image. If I add it to > packageTest, jpackage will fail when trying to run command with app-image and launchers. I will keep addLauncherName() inside test to add launchers manually and will also call it in applyTo(PackageTest) for future tests, that might use such functionality. ------------- PR: https://git.openjdk.java.net/jdk/pull/263 From aefimov at openjdk.java.net Thu Sep 24 23:46:47 2020 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 24 Sep 2020 23:46:47 GMT Subject: RFR: 8251188: Update LDAP tests not to use wildcard addresses [v2] In-Reply-To: <-CMY39b696CBNg4cyddo-t2KEl5vfYR8ACeoJA7p13I=.e1b457e5-5bbc-4ae6-a69a-c44916326abe@github.com> References: <-CMY39b696CBNg4cyddo-t2KEl5vfYR8ACeoJA7p13I=.e1b457e5-5bbc-4ae6-a69a-c44916326abe@github.com> Message-ID: > Hi, > > Please help to review [JDK-8251188](https://bugs.openjdk.java.net/browse/JDK-8251188) fix which helps to improve LDAP > tests stability. The list of changes: 1. Usages of wildcard address have been replaced with loopback address. This > change includes addition of `LDAPTestUtils.initEnv` method that takes LDAP provider URL as a parameter. 2. > `DeadServerTimeoutSSLTest.java` was also updated to fix the intermittent failures reported by [JDK-8152654 > ](https://bugs.openjdk.java.net/browse/JDK-8152654) and > [JDK-8169942](https://bugs.openjdk.java.net/browse/JDK-8169942). Before the fix the failure rate was 1 out of 4 runs. > After the fix it was executed 400+ times alongside to other LDAP tests, and showed no failures, and therefore removed > from the problem list. Thank you, Aleksei Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: Update DeadServerTimeoutSSLTest to track and analyze client connections ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/252/files - new: https://git.openjdk.java.net/jdk/pull/252/files/606c24a8..81fe70b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=252&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=252&range=00-01 Stats: 152 lines in 2 files changed: 140 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/252.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/252/head:pull/252 PR: https://git.openjdk.java.net/jdk/pull/252 From aefimov at openjdk.java.net Thu Sep 24 23:48:38 2020 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 24 Sep 2020 23:48:38 GMT Subject: RFR: 8251188: Update LDAP tests not to use wildcard addresses [v2] In-Reply-To: <5pZnmegkI2FKIfpiCD7jOeEdP1ibz7kD9_J0lZoQLug=.ebb94eff-c276-4974-a3a7-2a334ee871b2@github.com> References: <-CMY39b696CBNg4cyddo-t2KEl5vfYR8ACeoJA7p13I=.e1b457e5-5bbc-4ae6-a69a-c44916326abe@github.com> <5pZnmegkI2FKIfpiCD7jOeEdP1ibz7kD9_J0lZoQLug=.ebb94eff-c276-4974-a3a7-2a334ee871b2@github.com> Message-ID: On Tue, 22 Sep 2020 13:39:38 GMT, Aleksei Efimov wrote: >> test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java line 171: >> >>> 169: System.err.println("Server socket. Failure to accept connection:"); >>> 170: e.printStackTrace(); >>> 171: } >> >> I wonder if removing the while (true) loop will make the test more susceptible of failing in timeout if the server ever >> receives a connection request from an unexpected client (we've seen that happening in the past with networking tests). >> Is there anyway the server could attempt to verify that the accepted socket is from the expected client, and close it >> and go back to accepting if it's not? Maybe by looking at the accepted socket remote address & port? > > Thanks for the good suggestion Daniel. I will modify it to look at the remote socket's address. Hi Daniel, Could you please take a look at the new version of DeadSSLLdapTimeoutTest.java with the following modifications: **DeadServerTimeoutSSLTest** test was modified to use custom **SocketFactory** (**DeadSSLSocketFactory**) which tracks the first opened socket on LDAP client side. This socket is later used on server side to check if the connection initiated by test's LDAP client. If the connection was not established by LDAP client then new accept attempt is performed. The test was never seen to fail during 200+ concurrent LDAP tests runs. ------------- PR: https://git.openjdk.java.net/jdk/pull/252 From vromero at openjdk.java.net Fri Sep 25 00:41:47 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 25 Sep 2020 00:41:47 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v6] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > Co-authored-by: Vicente Romero > Co-authored-by: Harold Seigel > Co-authored-by: Jonathan Gibbons > Co-authored-by: Brian Goetz > Co-authored-by: Maurizio Cimadamore > Co-authored-by: Joe Darcy > Co-authored-by: Chris Hegarty > Co-authored-by: Jan Lahoda Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: adding missing changes to some tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/89f7cc54..915b67e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=04-05 Stats: 71 lines in 5 files changed: 9 ins; 11 del; 51 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From almatvee at openjdk.java.net Fri Sep 25 01:08:52 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 25 Sep 2020 01:08:52 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests [v4] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8231591 > > - Added MultiLauncherTwoPhaseTest which uses predefine app image with multiple launcher and tests to make sure installer > will create shortcuts for all launchers. > - Fixed Linux DesktopIntegration to create shortcuts for additional launcher if we using pre-define app image. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8231591: [TESTBUG] Create additional two phase jpackage tests (revision 3) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/263/files - new: https://git.openjdk.java.net/jdk/pull/263/files/650cf21e..da929c98 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=263&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=263&range=02-03 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/263.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/263/head:pull/263 PR: https://git.openjdk.java.net/jdk/pull/263 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 vromero at openjdk.java.net Fri Sep 25 02:40:47 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 25 Sep 2020 02:40:47 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v3] In-Reply-To: <0H-sMIm0mwGW2f2OxwAwMGBtxDf2BUf7ds3tGEgYXrc=.849aab2b-4cf3-49f7-8e49-ad1df75cb0bb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> <0H-sMIm0mwGW2f2OxwAwMGBtxDf2BUf7ds3tGEgYXrc=.849aab2b-4cf3-49f7-8e49-ad1df75cb0bb@github.com> Message-ID: On Thu, 24 Sep 2020 15:45:22 GMT, Vicente Romero wrote: >> The classfile parser changes look good to me. > > I have modified the `@since`: 14 -> 16 [CSR: Record Classes](https://bugs.openjdk.java.net/browse/JDK-8253605) ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From asemenyuk at openjdk.java.net Fri Sep 25 02:49:17 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 25 Sep 2020 02:49:17 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests [v3] In-Reply-To: References: <-ImMqcEBQNXF3cpNKUZfynd2-u4epkNveyXmw9yjpT0=.6fcf5ecb-53ee-473b-b720-864c224bd313@github.com> <_T9-3L82NWAt2TlPBRatlSH0Q1bsDbdAvbCAQESn_GM=.c1fd52f5-048e-48f3-b255-5e5c361b1ba5@github.com> Message-ID: <18Zjp4uQFkuCr5KrKZ7XSlCwGrDhUS_wuLUzPxVq09M=.b9edfb57-b632-45f8-a697-373ef70f9405@github.com> On Thu, 24 Sep 2020 23:39:51 GMT, Alexander Matveev wrote: >> Actually it will not work. I am running appImageCmd command before test executes to generate app image. If I add it to >> packageTest, jpackage will fail when trying to run command with app-image and launchers. > > I will keep addLauncherName() inside test to add launchers manually and will also call it in applyTo(PackageTest) for > future tests, that might use such functionality. Can you have applyTo() called for `appImageCmd` and for `packageTest`? ------------- PR: https://git.openjdk.java.net/jdk/pull/263 From asemenyuk at openjdk.java.net Fri Sep 25 02:53:28 2020 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 25 Sep 2020 02:53:28 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests [v4] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 01:08:52 GMT, Alexander Matveev wrote: >> https://bugs.openjdk.java.net/browse/JDK-8231591 >> >> - Added MultiLauncherTwoPhaseTest which uses predefine app image with multiple launcher and tests to make sure installer >> will create shortcuts for all launchers. >> - Fixed Linux DesktopIntegration to create shortcuts for additional launcher if we using pre-define app image. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8231591: [TESTBUG] Create additional two phase jpackage tests (revision 3) Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/263 From kizune at openjdk.java.net Fri Sep 25 06:22:03 2020 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 25 Sep 2020 06:22:03 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= [v4] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 13:59:25 GMT, Andy Herrick wrote: >> 8253149: Building an installer from invalid app image fails on Windows and Linux >> When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a >> warning message, and then complete the package anyway. > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > 8253149: Building an installer from invalid app image fails (revision Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/271 From kizune at openjdk.java.net Fri Sep 25 06:22:04 2020 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 25 Sep 2020 06:22:04 GMT Subject: RFR: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= [v4] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 22:20:17 GMT, Alexander Matveev wrote: >> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: >> >> 8253149: Building an installer from invalid app image fails (revision > > Marked as reviewed by almatvee (Committer). Looks fine to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/271 From abakhtin at openjdk.java.net Fri Sep 25 07:29:32 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Fri, 25 Sep 2020 07:29:32 GMT Subject: Integrated: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote: > Hi, > > Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. > Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html > This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is > "tls-server-end-point" > CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 > > Thank you > Alexey This pull request has now been integrated. Changeset: cfa3f749 Author: Alexey Bakhtin URL: https://git.openjdk.java.net/jdk/commit/cfa3f749 Stats: 543 lines in 10 files changed: 531 ins; 0 del; 12 mod 8245527: LDAP Channel Binding support for Java GSS/Kerberos Reviewed-by: dfuchs, aefimov, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From cjashfor at linux.ibm.com Fri Sep 25 09:06:17 2020 From: cjashfor at linux.ibm.com (Corey Ashford) Date: Fri, 25 Sep 2020 02:06:17 -0700 Subject: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: <11ca749f-3015-c004-aa6b-3194e1dfe4eb@linux.ibm.com> <5ac1ac19-af1c-4ee6-b478-873031710081@linux.ibm.com> Message-ID: <7eec7c4d-2402-3fc6-55ad-aec2980ff77d@linux.ibm.com> Due to the switchover to Git from Mercurial, this patch set got a new thread on the mailing lists on 9/24, but it has the same title. as this thread. - Corey On 9/7/20 3:08 AM, Doerr, Martin wrote: > Hi Corey, > > thanks for investigating. > > Note that we use xlclang++ on AIX. It may possibly understand the directives as gcc on linux. > Gcc 7.3.1 is the minimum for BE linux. > But if you protect your code by #ifdef VM_LITTLE_ENDIAN no compiler except gcc >= 7.4.0 should ever look at it. > > Best regards, > Martin > > >> -----Original Message----- >> From: Corey Ashford >> Sent: Dienstag, 1. September 2020 02:17 >> To: Doerr, Martin >> Cc: Michihiro Horie ; hotspot-compiler- >> dev at openjdk.java.net; core-libs-dev ; >> Kazunori Ogata ; joserz at br.ibm.com >> Subject: Re: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and >> API for Base64 decoding >> >> On 8/27/20 8:07 AM, Doerr, Martin wrote: >>>>> I will use __attribute__ ((align(16))) instead of __vector, and make >>>> them arrays of 16 unsigned char. >>> Maybe __vectors works as expected, too, now. Whatever we use, I'd >> appreciate to double-check the alignment e.g. by using gdb. >>> I don't remember what we had tried and why it didn't work as desired. >> >> >> I just now tried on gcc-7.5.0, declaring a __vector at 1, 2, 3, 8, 9, >> and 15 byte offsets in a struct, trying to force a misalignment, but the >> compiler realigned all of them on 16-byte boundaries. >> >> If someone decides to make the intrinsic work on AIX (big endian), and >> compiles with 7.3.1, I don't know what will happen w.r.t. alignment, so >> to be on the safe side, I will make the declarations 16-byte unsigned >> char arrays with an align attribute. >> >> Looking a bit deeper, I see that the __vector type comes out of the C >> preprocessor as: __attribute__((altivec(vector__))). It's part of the >> compiler's basic set of predefined macros, and can be seen using this >> command: >> >> % gcc -dM -E - < /dev/null | grep __vector >> >> #define __vector __attribute__((altivec(vector__))) >> >> Some information here: >> https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Type-Attributes.html >> >> I don't know if this is helpful or not, but it might answer part of your >> question about the meaning of __vector. >> >> Regards, >> >> - Corey From cjashfor at linux.ibm.com Fri Sep 25 09:07:10 2020 From: cjashfor at linux.ibm.com (Corey Ashford) Date: Fri, 25 Sep 2020 02:07:10 -0700 Subject: [EXTERNAL] Re: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: <91b1717e-f9f4-0b5c-d410-e25507206812@linux.ibm.com> References: <11ca749f-3015-c004-aa6b-3194e1dfe4eb@linux.ibm.com> <8ece8d2e-fd99-b734-211e-a32b534a7dc8@linux.ibm.com> <8d53dcf8-635a-11e2-4f6a-39b70e2c3b8b@oracle.com> <65ed7919-86fc-adfa-3cd5-58dd96a3487f@linux.ibm.com> <4bc83479-1ed9-8cd8-22a0-1f19f315df7e@oracle.com> <196a4e58-0710-2f3e-6d1b-e78ab03a185d@oracle.com> <91b1717e-f9f4-0b5c-d410-e25507206812@linux.ibm.com> Message-ID: <3cdec280-a4aa-1791-5eb5-b9102a642256@linux.ibm.com> Note, this patch set is now on a new thread in the mailing list, due to the switchover from Mercurial to Git. Regards, - Corey On 9/9/20 4:32 PM, Corey Ashford wrote: > On 9/9/20 2:04 PM, Roger Riggs wrote: >> Hi Corey, >> >> Right,? the continue was so it would go back and check if the >> conversion was >> complete.? An alternative would be to repeat the check and return if >> there was >> no bytes left to process. > > Another issue I just discovered is that the way the loop is structured, > decodeBlock could be called multiple times in the event that isMIME is > true, and in that case, decodeBlock will try to write into dst[] > starting at offset 0 again. > > My original intention was for the intrinsic to be called a single time > because it never attempted process bytes in the isMIME==true case, and > because of that, the offset into the destination buffer would always be > zero.? With this loop, on the second and later calls, the offset into > dst[] should be non-zero.? This means that I also need to pass dp into > decodeBlock.? That necessitates a change in the parameter passing down > to the intrinsic.? Not a big deal, but it is a ripple. > > I'll get working on it. > > The upside of this change is that it makes the decode and encode > intrinsics closely mirror each other, and handles the isMIME==true case > as a happy side-effect.? With the overhead of the call to the intrinsic, > it's not clear there will be a performance gain when isMIME==true, but a > benchmark should make that clear.? I'm guessing maybe 1.5X to 2X is > about the best that could be expected when linemax is the default 76. > > - Corey > >> >> Thanks, Roger >> >> On 9/9/20 3:13 PM, Corey Ashford wrote: >>> On 9/4/20 8:07 AM, Roger Riggs wrote: >>>> Hi Corey, >>>> >>>> The idea I had in mind is refactoring the fast path into the method >>>> you call decodeBlock. >>>> Base64: lines 751-768. >>>> >>>> It leaves all the unknown/illegal character handling to the Java code. >>>> And yes, it does not need to handle MIME, except to return on >>>> illegal characters. >>>> >>>> The patch is attached. >>> >>> Ah, I see what you mean now, and thanks for the patch!? The patch as >>> presented doesn't work, however, because the intrinsic processes >>> fewer bytes than are in the src buffer, and then executes a >>> "continue;", which then proceeds to loop infinitely because the >>> intrinsic won't process any more bytes after that. >>> >>> I tried dropping the continue, but that doesn't work because the Java >>> (non-intrinsic) code processes all of the bytes, and the line of code >>> following the loop accesses one byte after the end of the src buffer >>> causing an array bounds error. >>> >>> So this needs to be re-thought a little, but it shouldn't be too >>> difficult.? I will work on it. >>> >>> Regards, >>> >>> - Corey >>> >>>> >>>> Regards, Roger >>>> >>>> >>>> >>>> On 8/31/20 6:22 PM, Corey Ashford wrote: >>>>> On 8/29/20 1:19 PM, Corey Ashford wrote: >>>>>> Hi Roger, >>>>>> >>>>>> Thanks for your reply and thoughts!? Comments interspersed below: >>>>>> >>>>>> On 8/28/20 10:54 AM, Roger Riggs wrote: >>>>> ... >>>>>>> Comparing with the way that the Base64 encoder was intrinsified, the >>>>>>> method that is intrinsified should have a method body that does >>>>>>> the same function, so it is interchangable.? That likely will >>>>>>> just shift >>>>>>> the "fast path" code into the decodeBlock method. >>>>>>> Keeping the symmetry between encoder and decoder will >>>>>>> make it easier to maintain the code. >>>>>> >>>>>> Good point.? I'll investigate what this looks like in terms of the >>>>>> actual code, and will report back (perhaps in a new webrev). >>>>>> >>>>> >>>>> Having looked at this again, I don't think it makes sense. One >>>>> thing that differs significantly from the encodeBlock intrinsic is >>>>> that the decodeBlock intrinsic only needs to process a prefix of >>>>> the data, and so it can leave virtually any amount of data at the >>>>> end of the src buffer unprocessed, where as with the encodeBlock >>>>> intrinsic, if it exists, it must process the entire buffer. >>>>> >>>>> In the (common) case where the decodeBlock intrinsic returns not >>>>> having processed everything, it still needs to call the Java code, >>>>> and if that Java code is "replaced" by the intrinsic, it's >>>>> inaccessible. >>>>> >>>>> Is there something I'm overlooking here?? Basically I want the >>>>> decode API to behave differently than the encode API, mostly to >>>>> make the arch-specific intrinsic easier to implement. If that's not >>>>> acceptable, then I need to rethink the API, and also figure out how >>>>> to deal with the illegal character case. The latter could perhaps >>>>> be done by throwing an exception from the intrinsic, or maybe by >>>>> returning a negative length that specifies the index of the illegal >>>>> src byte, and then have the Java code throw the exception). >>>>> >>>>> Regards, >>>>> >>>>> - Corey >>>>> >>>> >>> >> > From dfuchs at openjdk.java.net Fri Sep 25 09:25:16 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 25 Sep 2020 09:25:16 GMT Subject: RFR: 8251188: Update LDAP tests not to use wildcard addresses [v2] In-Reply-To: References: <-CMY39b696CBNg4cyddo-t2KEl5vfYR8ACeoJA7p13I=.e1b457e5-5bbc-4ae6-a69a-c44916326abe@github.com> Message-ID: <6F5VAEj013qZ2RKDXhldfIqg4Z9kSbDtdrTQ6Rzg0RM=.28e5070e-6200-4ac4-8679-c129cd34aa45@github.com> On Thu, 24 Sep 2020 23:46:47 GMT, Aleksei Efimov wrote: >> Hi, >> >> Please help to review [JDK-8251188](https://bugs.openjdk.java.net/browse/JDK-8251188) fix which helps to improve LDAP >> tests stability. The list of changes: 1. Usages of wildcard address have been replaced with loopback address. This >> change includes addition of `LDAPTestUtils.initEnv` method that takes LDAP provider URL as a parameter. 2. >> `DeadServerTimeoutSSLTest.java` was also updated to fix the intermittent failures reported by [JDK-8152654 >> ](https://bugs.openjdk.java.net/browse/JDK-8152654) and >> [JDK-8169942](https://bugs.openjdk.java.net/browse/JDK-8169942). Before the fix the failure rate was 1 out of 4 runs. >> After the fix it was executed 400+ times alongside to other LDAP tests, and showed no failures, and therefore removed >> from the problem list. Thank you, Aleksei > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > Update DeadServerTimeoutSSLTest to track and analyze client connections Marked as reviewed by dfuchs (Reviewer). test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java line 193: > 191: if (acceptedSocket.getLocalPort() == clientSideSocket.getPort() && > 192: acceptedSocket.getPort() == clientSideSocket.getLocalPort() && > 193: acceptedSocket.getInetAddress().equals(clientSideSocket.getLocalAddress())) { Oh - sorry about that - I didn't realize checking the client socket would be so complex. This is not obvious, but of course the socket on the server side could be accepted before the connect() call from the client side returns. And anyway the LDAP stack can/will create an unconnected socket and connect it later, so placing a trigger (CountDownLatch) in the custom socket factory might not work as it might trigger too early. Hence the waiting loop :-( ... Good job here - I wish there had been a simpler way to do this! ------------- PR: https://git.openjdk.java.net/jdk/pull/252 From gdub at openjdk.java.net Fri Sep 25 10:13:23 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Fri, 25 Sep 2020 10:13:23 GMT Subject: Integrated: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. This pull request has now been integrated. Changeset: 1b79326c Author: Gilles Duboscq URL: https://git.openjdk.java.net/jdk/commit/1b79326c Stats: 194 lines in 4 files changed: 137 ins; 29 del; 28 mod 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From mdoerr at openjdk.java.net Fri Sep 25 10:28:29 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 25 Sep 2020 10:28:29 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: <3EH-0UK3nZW6J1A59XZ6im798XUPkN6OyJgC_Ptyp-Q=.9321be76-0004-40f2-ac74-366123d1fceb@github.com> References: <3EH-0UK3nZW6J1A59XZ6im798XUPkN6OyJgC_Ptyp-Q=.9321be76-0004-40f2-ac74-366123d1fceb@github.com> Message-ID: On Wed, 23 Sep 2020 22:28:38 GMT, CoreyAshford wrote: >> This patch set encompasses the following commits: >> >> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for >> the intrinsic. The API is similar to the existing encodeBlock intrinsic. >> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic >> implementation >> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic. >> - Adds a JMH microbenchmark for both Base64 encoding and encoding. >> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding. > > This work is covered by an existing IBM <-> Oracle agreement Hi Corey, thanks for refactoring the Java code such that it matches the intrinsic implementation. That's a better design. I'm now looking at the PPC64 platform code. The algorithm looks fine. I can see you're using clrldi to clear the upper bits of the parameters. But seems like it clears one bit too few. You can also use cmpwi for the boolean one. I wonder about the loop unrolling. It doesn't look beneficial because the loop body is large. Did you measure performance gain by this unrolling? I think for agressive tuning we'd have to apply techniques like modulo scheduling, but that's much more work. So please only use unrolling as far as a benefit is measurable. But you may want to align the loop start to help instruction fetch. We'll test it, but we don't have Power 10. You guys need to cover that. Best regards, Martin ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From dholmes at openjdk.java.net Fri Sep 25 10:47:17 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 25 Sep 2020 10:47:17 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 16:59:03 GMT, Richard Reingruber wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >> >> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >> >> Thanks, Richard. > > Richard Reingruber 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: > - Merge branch 'master' into JDK-8227745 > - Changes based on dholmes' feedback. > > EscapeBarrier::sync_and_suspend_all(): > > - Set suspend flags before handshake because then the setting will be visible > after leaving the _thread_blocked state in JavaThread::wait_for_object_deoptimization() > > JavaThread::wait_for_object_deoptimization() > > - Reuse SpinYield instead of new custom spinning code. > > - Do safepoint check after the loop. This is possible because the > set_obj_deopt_flag is done before the handshake. > > - Don't set_suspend_equivalent() anymore for more simplicity. It's just an > optimization (that won't pay off here). > > Added/updated source code comments. > > Additional smaller enhancements. > - 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents The minor updates in response to my comments are fine. The more major updates ... I can't really comment on. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Fri Sep 25 12:31:30 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 25 Sep 2020 12:31:30 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 10:44:53 GMT, David Holmes wrote: > > > The minor updates in response to my comments are fine. > > The more major updates ... I can't really comment on. Thanks for looking at the changes and for giving feedback. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 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 aefimov at openjdk.java.net Fri Sep 25 12:49:12 2020 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Fri, 25 Sep 2020 12:49:12 GMT Subject: Integrated: 8251188: Update LDAP tests not to use wildcard addresses In-Reply-To: <-CMY39b696CBNg4cyddo-t2KEl5vfYR8ACeoJA7p13I=.e1b457e5-5bbc-4ae6-a69a-c44916326abe@github.com> References: <-CMY39b696CBNg4cyddo-t2KEl5vfYR8ACeoJA7p13I=.e1b457e5-5bbc-4ae6-a69a-c44916326abe@github.com> Message-ID: On Fri, 18 Sep 2020 12:59:07 GMT, Aleksei Efimov wrote: > Hi, > > Please help to review [JDK-8251188](https://bugs.openjdk.java.net/browse/JDK-8251188) fix which helps to improve LDAP > tests stability. The list of changes: 1. Usages of wildcard address have been replaced with loopback address. This > change includes addition of `LDAPTestUtils.initEnv` method that takes LDAP provider URL as a parameter. 2. > `DeadServerTimeoutSSLTest.java` was also updated to fix the intermittent failures reported by [JDK-8152654 > ](https://bugs.openjdk.java.net/browse/JDK-8152654) and > [JDK-8169942](https://bugs.openjdk.java.net/browse/JDK-8169942). Before the fix the failure rate was 1 out of 4 runs. > After the fix it was executed 400+ times alongside to other LDAP tests, and showed no failures, and therefore removed > from the problem list. Thank you, Aleksei This pull request has now been integrated. Changeset: a75edc29 Author: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/a75edc29 Stats: 287 lines in 6 files changed: 216 ins; 29 del; 42 mod 8251188: Update LDAP tests not to use wildcard addresses Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/252 From jbhateja at openjdk.java.net Fri Sep 25 13:10:32 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 25 Sep 2020 13:10:32 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v3] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 16:39:15 GMT, Jatin Bhateja wrote: > @jatin-bhateja Can you put summary of performance improvement into JBS? Hi @vnkozlov , @neliasso Kindly let me know your feedback, If there are no more comments is it ok to integrate this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From sergei.tsypanov at yandex.ru Fri Sep 25 14:08:08 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 25 Sep 2020 16:08:08 +0200 Subject: [PATCH] AbstractStringBuilder.insert(int dstOffset, CharSequence s, int start, int end) is missing fast-path for String Message-ID: <279111601034428@mail.yandex.ru> Hello, while working with StringBuilder.insert() I've spotted that its delegate AbstractStringBuilder.insert() is missing a fast-path for the most frequent case when its argument is String. Previously they did similart optimization for StirngBuilder.append(CharSequence, int, int), see https://bugs.openjdk.java.net/browse/JDK-8224986 I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1 and inserted String is Latin1 as well. I cannot file the issue for that so can I create a PR on GitHub without issue number? If not please create one (if the change is relevant of course). To measure improvement I've used simple benchmark: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class StringBuilderInsertBenchmark { @Benchmark public StringBuilder insert(Data data) { String string = data.string; return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1); } @State(Scope.Thread) public static class Data { String string; @Param({"true", "false"}) private boolean latin; @Param({"8", "64", "128", "1024"}) private int length; @Setup public void setup() { String alphabet = latin ? "abcdefghijklmnopqrstuvwxyz" // English : "????????????????????????????????"; // Russian string = new RandomStringGenerator().randomString(alphabet, length + 2); } } } Which gives (latin) (length) original patched Units insert true 8 24.2 ? 0.1 22.2 ? 0.0 ns/op insert true 64 53.8 ? 0.2 36.1 ? 0.1 ns/op insert true 128 80.9 ? 0.2 44.6 ? 0.0 ns/op insert true 1024 365.4 ? 0.5 109.8 ? 3.9 ns/op insert false 8 33.5 ? 0.5 32.3 ? 0.2 ns/op insert false 64 73.2 ? 0.3 73.2 ? 0.2 ns/op insert false 128 103.9 ? 0.6 103.3 ? 0.1 ns/op insert false 1024 576.5 ? 4.8 569.5 ? 2.0 ns/op Patch is attached. As of tests tier1 and tier2 are ok With best regards, Sergey Tsypanov -------------- next part -------------- A non-text attachment was scrubbed... Name: ASB.patch Type: text/x-diff Size: 3102 bytes Desc: not available URL: From rriggs at openjdk.java.net Fri Sep 25 14:20:13 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 25 Sep 2020 14:20:13 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: <_tvo1hj209XU5Y4JzhXfjSY2wh7-j1cahY7BskdaXNI=.c4acaa07-0a31-4460-b1d3-57a64fed1fdc@github.com> On Tue, 22 Sep 2020 02:45:36 GMT, CoreyAshford wrote: > This patch set encompasses the following commits: > > - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for > the intrinsic. The API is similar to the existing encodeBlock intrinsic. > - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic > implementation > - Adds a Power64LE-specific implementation of the decodeBlock intrinsic. > - Adds a JMH microbenchmark for both Base64 encoding and encoding. > - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding. Changes requested by rriggs (Reviewer). src/java.base/share/classes/java/util/Base64.java line 747: > 745: * Decodes base64 characters, and returns the number of data bytes > 746: * produced by the base64 decode intrinsic. > 747: * "intrinsic" can be omitted. Both the java and the intrinsic produce the same output. src/java.base/share/classes/java/util/Base64.java line 759: > 757: * src, it must process a multiple of four of them, making the > 758: * returned destination length a multiple of three. > 759: * If the dst array is too short does the intrinsic stop short or throw? The java code would throw an ArrayIndexOutOfBoundsException. It should not occur since the java code allocates the proper buffer but... It might be worth mentioning. src/java.base/share/classes/java/util/Base64.java line 820: > 818: dp += dl; > 819: } > 820: if (sp == sl) { I'd rather see (sp >= s1) instead of the equality, its would be consistent with the condition of the while loop. (And is already lines 767-768). test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 260: > 258: } > 259: > 260: private static final byte[] nonBase64 = { Please add a comment describing this test data. (It looks like it could be generated more compactly than an explicit array). Ditto nonBase64URL below. test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 240: > 238: } > 239: > 240: private static byte[] hexStringToByteArray(String s) { A method to convert a Hex String to a byte array already exists in test/lib/jdk/test/lib/Utils.java in toByteArray(s). Add "jdk.test.lib.Utils" to the "@build" line at the top of the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From neliasso at openjdk.java.net Fri Sep 25 15:42:13 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Fri, 25 Sep 2020 15:42:13 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v5] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 15:55:11 GMT, Jatin Bhateja wrote: >> Summary: >> >> 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. >> 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. >> 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop >> copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block >> and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. >> 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user >> sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy >> sizes above 4096 bytes. JMH Results: >> System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz >> Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java >> Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() >> WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8252847 : Modifying file permission to resolve jcheck failure. Looks good to me! ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/61 From plevart at openjdk.java.net Fri Sep 25 15:50:48 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 25 Sep 2020 15:50:48 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> <0H-sMIm0mwGW2f2OxwAwMGBtxDf2BUf7ds3tGEgYXrc=.849aab2b-4cf3-49f7-8e49-ad1df75cb0bb@github.com> Message-ID: On Fri, 25 Sep 2020 02:38:01 GMT, Vicente Romero wrote: >> I have modified the `@since`: 14 -> 16 > > [CSR: Record Classes](https://bugs.openjdk.java.net/browse/JDK-8253605) Hi @vicente-romero-oracle , note that besides tests, there is also a JMH benchmark that measures the performance of records deserialization which forced us to modify the build procedure for all benchmarks to include --enable-preview option in JDK 15 and backports (see https://bugs.openjdk.java.net/browse/JDK-8248135). If you undo this change in JDK 16 then also the problem described in https://bugs.openjdk.java.net/browse/JDK-8250669 and https://bugs.openjdk.java.net/browse/JDK-8248429 will disapear. After that, perhaps undoing the same for JDK 15 and backports together with removing the benchmark is also possible to resolve the issues in older releases as most developement will probably happen in JDK 16 then and so the need for performance testing will mostly be needed in there. We still have to figure out how to enable having benchmarks for preview features as in the future the sure will be a need for that. ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From tonytao0505 at outlook.com Fri Sep 25 10:09:57 2020 From: tonytao0505 at outlook.com (tonytao) Date: Fri, 25 Sep 2020 18:09:57 +0800 Subject: [Lambda]parallel sort stream slow than series sort Message-ID: hi, I wrote a test case to test stream performance,but the parallel sort always slow than the series sort.I test the data size in : 20,000 , 5,000,000, 10,000,000 , 20,000,000 . attatched is the test case source code. jdk version : openjdk version "11.0.8" 2020-07-14 OpenJDK Runtime Environment (build 11.0.8+10-post-Debian-1deb10u1) OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Debian-1deb10u1, mixed mode, sharing) jvm argument: -ea -Xms256m -Xmx8192m macheine: cpu:Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz memory: 16GB Test? result shows as below: 20000: sorted execute time:9ms, resultset rows 20000, 2222222 rows/sec parallel sorted execute time:24ms, resultset rows 20000, 833333 rows/sec 5000000: sorted execute time:245ms, resultset rows 5000000, 20408163 rows/sec parallel sorted execute time:402ms, resultset rows 5000000, 12437810 rows/sec 10000000: sorted execute time:577ms, resultset rows 10000000, 17331022 rows/sec parallel sorted execute time:1230ms, resultset rows 10000000, 8130081 rows/sec 20000000: sorted execute time:1079ms, resultset rows 20000000, 18535681 rows/sec parallel sorted execute time:1790ms, resultset rows 20000000, 11173184 rows/sec this is the test data sample: hdb=> select * from testdata limit 10; ?? id??? |?????????? uptime?????????? | x? | y? | cmt ---------+----------------------------+----+----+---------------------------------- ?1340417 | 2023-02-22 07:30:34.391207 | 33 |? 9 | 4bf16d4c4b638d84b56893de2451c407 ?1340418 | 2023-02-22 07:31:34.391207 | 10 | 91 | c9b78bfbd6b684e62605e96d2d8237a0 ?1340419 | 2023-02-22 07:32:34.391207 | 66 | 24 | 968e5d19ca3a2ddae5d2a366ba06cf16 ?1340420 | 2023-02-22 07:33:34.391207 |? 4 | 42 | bdcf7d764121fc9b0039f80eadea1310 ?1340421 | 2023-02-22 07:34:34.391207 | 27 | 45 | 06520ac5e508f15f09672fa751d5c17a ?1340422 | 2023-02-22 07:35:34.391207 | 36 | 11 | 5bede83b54dfe76f4a249308d8033691 ?1340423 | 2023-02-22 07:36:34.391207 | 41 | 92 | 37f4b34988c0e1387940177a8cc9d83a ?1340424 | 2023-02-22 07:37:34.391207 | 29 | 59 | 416459b54ae00c95e118c93605a40d43 ?1340425 | 2023-02-22 07:38:34.391207 |? 9 | 46 | 46339b8eeae99c7e922003ed87b9d417 ?1340426 | 2023-02-22 07:39:34.391207 | 21 | 29 | 7ede63cdb2a6a86c63534fe5fcfb2f97 (10 rows) It was generated by sql: create table testdata( idint, uptimetimestamp, xint, yint, cmttext ); insert into testdata select id, uptime, round(random()*100), round(random()*100), md5(uptime::text) from ( select generate_series id, current_timestamp + make_interval(mins=> generate_series) uptime from generate_series(1,100000000) ) t; Could you please help me to find the problem? Thanks a lot. From simon at dancingcloudservices.com Fri Sep 25 17:56:35 2020 From: simon at dancingcloudservices.com (Simon Roberts) Date: Fri, 25 Sep 2020 11:56:35 -0600 Subject: [Lambda]parallel sort stream slow than series sort In-Reply-To: References: Message-ID: Tests like this are rarely meaningful. In particular you have a random number generator in there. They are often built on single threaded code protected by mutual exclusion. That of itself prevents the code ever going faster than sequential code, and in fact usually makes it slower due to the additional overhead of inter-thread communication. Further, your example seems to be a test of a database and its driver, and has no obvious relationship to either the Streams API or anything in the core Java libraries. Perhaps I miss something. On Fri, Sep 25, 2020 at 4:09 AM tonytao wrote: > hi, > > I wrote a test case to test stream performance,but the parallel sort > always slow than the series sort.I test the data size in : 20,000 , > 5,000,000, 10,000,000 , 20,000,000 . > > attatched is the test case source code. > > jdk version : > > openjdk version "11.0.8" 2020-07-14 > OpenJDK Runtime Environment (build 11.0.8+10-post-Debian-1deb10u1) > OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Debian-1deb10u1, mixed > mode, sharing) > > jvm argument: > > -ea -Xms256m -Xmx8192m > > macheine: > > cpu:Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz > > memory: 16GB > > Test result shows as below: > > 20000: > > sorted execute time:9ms, resultset rows 20000, 2222222 rows/sec > parallel sorted execute time:24ms, resultset rows 20000, 833333 rows/sec > > 5000000: > > sorted execute time:245ms, resultset rows 5000000, 20408163 rows/sec > parallel sorted execute time:402ms, resultset rows 5000000, 12437810 > rows/sec > > 10000000: > > sorted execute time:577ms, resultset rows 10000000, 17331022 rows/sec > parallel sorted execute time:1230ms, resultset rows 10000000, 8130081 > rows/sec > > 20000000: > > sorted execute time:1079ms, resultset rows 20000000, 18535681 rows/sec > parallel sorted execute time:1790ms, resultset rows 20000000, 11173184 > rows/sec > > > this is the test data sample: > > hdb=> select * from testdata limit 10; > id | uptime | x | y | cmt > > ---------+----------------------------+----+----+---------------------------------- > 1340417 | 2023-02-22 07:30:34.391207 | 33 | 9 | > 4bf16d4c4b638d84b56893de2451c407 > 1340418 | 2023-02-22 07:31:34.391207 | 10 | 91 | > c9b78bfbd6b684e62605e96d2d8237a0 > 1340419 | 2023-02-22 07:32:34.391207 | 66 | 24 | > 968e5d19ca3a2ddae5d2a366ba06cf16 > 1340420 | 2023-02-22 07:33:34.391207 | 4 | 42 | > bdcf7d764121fc9b0039f80eadea1310 > 1340421 | 2023-02-22 07:34:34.391207 | 27 | 45 | > 06520ac5e508f15f09672fa751d5c17a > 1340422 | 2023-02-22 07:35:34.391207 | 36 | 11 | > 5bede83b54dfe76f4a249308d8033691 > 1340423 | 2023-02-22 07:36:34.391207 | 41 | 92 | > 37f4b34988c0e1387940177a8cc9d83a > 1340424 | 2023-02-22 07:37:34.391207 | 29 | 59 | > 416459b54ae00c95e118c93605a40d43 > 1340425 | 2023-02-22 07:38:34.391207 | 9 | 46 | > 46339b8eeae99c7e922003ed87b9d417 > 1340426 | 2023-02-22 07:39:34.391207 | 21 | 29 | > 7ede63cdb2a6a86c63534fe5fcfb2f97 > (10 rows) > > > It was generated by sql: > > create table testdata( > idint, > uptimetimestamp, > xint, > yint, > cmttext > ); > insert into testdata > select > id, > uptime, > round(random()*100), > round(random()*100), > md5(uptime::text) > from ( > select > generate_series id, > current_timestamp + make_interval(mins=> generate_series) > uptime > from generate_series(1,100000000) > ) t; > > > Could you please help me to find the problem? > > Thanks a lot. > > > > -- Simon Roberts (303) 249 3613 From vlv.spb.ru at mail.ru Fri Sep 25 18:25:44 2020 From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=) Date: Fri, 25 Sep 2020 21:25:44 +0300 Subject: =?UTF-8?B?UmU6IFtMYW1iZGFdcGFyYWxsZWwgc29ydCBzdHJlYW0gc2xvdyB0aGFuIHNl?= =?UTF-8?B?cmllcyBzb3J0?= In-Reply-To: References: Message-ID: <1601058344.87876277@f386.i.mail.ru> >? Hi, ? Could you please check with OpenJDK version?14+? Let us?know the results. ? Thank you, Vladimir ? >Date: Fri, 25 Sep 2020 18:09:57 +0800From: tonytao < tonytao0505 at outlook.com > >To: core-libs-dev at openjdk.java.net >Subject: [Lambda]parallel sort stream slow than series sort > >hi, > >I wrote a test case to test stream performance,but the parallel sort >always slow than the series sort.I test the data size in : 20,000 , >5,000,000, 10,000,000 , 20,000,000 . > >attatched is the test case source code. > >jdk version : > >openjdk version "11.0.8" 2020-07-14 >OpenJDK Runtime Environment (build 11.0.8+10-post-Debian-1deb10u1) >OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Debian-1deb10u1, mixed >mode, sharing) > >jvm argument: > >-ea -Xms256m -Xmx8192m > >macheine: > >cpu:Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz > >memory: 16GB > >Test? result shows as below: > >20000: > >sorted execute time:9ms, resultset rows 20000, 2222222 rows/sec >parallel sorted execute time:24ms, resultset rows 20000, 833333 rows/sec > >5000000: > >sorted execute time:245ms, resultset rows 5000000, 20408163 rows/sec >parallel sorted execute time:402ms, resultset rows 5000000, 12437810 >rows/sec > >10000000: > >sorted execute time:577ms, resultset rows 10000000, 17331022 rows/sec >parallel sorted execute time:1230ms, resultset rows 10000000, 8130081 >rows/sec > >20000000: > >sorted execute time:1079ms, resultset rows 20000000, 18535681 rows/sec >parallel sorted execute time:1790ms, resultset rows 20000000, 11173184 >rows/sec > > >this is the test data sample: > >hdb=> select * from testdata limit 10; >??? id??? |?????????? uptime?????????? | x? | y? | cmt >---------+----------------------------+----+----+---------------------------------- >??1340417 | 2023-02-22 07:30:34.391207 | 33 |? 9 | >4bf16d4c4b638d84b56893de2451c407 >??1340418 | 2023-02-22 07:31:34.391207 | 10 | 91 | >c9b78bfbd6b684e62605e96d2d8237a0 >??1340419 | 2023-02-22 07:32:34.391207 | 66 | 24 | >968e5d19ca3a2ddae5d2a366ba06cf16 >??1340420 | 2023-02-22 07:33:34.391207 |? 4 | 42 | >bdcf7d764121fc9b0039f80eadea1310 >??1340421 | 2023-02-22 07:34:34.391207 | 27 | 45 | >06520ac5e508f15f09672fa751d5c17a >??1340422 | 2023-02-22 07:35:34.391207 | 36 | 11 | >5bede83b54dfe76f4a249308d8033691 >??1340423 | 2023-02-22 07:36:34.391207 | 41 | 92 | >37f4b34988c0e1387940177a8cc9d83a >??1340424 | 2023-02-22 07:37:34.391207 | 29 | 59 | >416459b54ae00c95e118c93605a40d43 >??1340425 | 2023-02-22 07:38:34.391207 |? 9 | 46 | >46339b8eeae99c7e922003ed87b9d417 >??1340426 | 2023-02-22 07:39:34.391207 | 21 | 29 | >7ede63cdb2a6a86c63534fe5fcfb2f97 >(10 rows) > > >It was generated by sql: > >create table testdata( >?????idint, >?????uptimetimestamp, >?????xint, >?????yint, >?????cmttext >); >insert into testdata >?????select >?????????id, >?????????uptime, >?????????round(random()*100), >?????????round(random()*100), >?????????md5(uptime::text) >?????from ( >?????????select >?????????????generate_series id, >?????????????current_timestamp + make_interval(mins=> generate_series) uptime >?????????from generate_series(1,100000000) >?????????) t; > >Could you please help me to find the problem? > >Thanks a lot. From ccheung at openjdk.java.net Fri Sep 25 19:06:12 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 25 Sep 2020 19:06:12 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive Message-ID: Following up on archiving lambda proxy classes in dynamic CDS archive ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of lambda proxy classes in static CDS archive. When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will be of the following format: `@lambda-proxy: ` e.g. `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> IsCDSDumpingEnabled) is involved in the core-libs code.) Testing: tiers 1,2,3,4. Performance results (javac on HelloWorld on linux-x64): Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- ============================================================ 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- instr delta = -161497801 -7.2542% time delta = -24.722 ms -6.5951% ------------- Commit messages: - fix extraneous whitespace - 8247666 (initial commit) Changes: https://git.openjdk.java.net/jdk/pull/364/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247666 Stats: 1682 lines in 30 files changed: 1613 ins; 12 del; 57 mod Patch: https://git.openjdk.java.net/jdk/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364 PR: https://git.openjdk.java.net/jdk/pull/364 From herrick at openjdk.java.net Fri Sep 25 20:18:39 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 25 Sep 2020 20:18:39 GMT Subject: RFR: 8231591: [TESTBUG] Create additional two phase jpackage tests [v4] In-Reply-To: References: Message-ID: <_ONXBe5TFxw4pgAi2_Sbwfc8tRHSqSqyCIR79aDicYk=.05012f62-819e-4d9e-9602-f9fd5a685515@github.com> On Fri, 25 Sep 2020 01:08:52 GMT, Alexander Matveev wrote: >> https://bugs.openjdk.java.net/browse/JDK-8231591 >> >> - Added MultiLauncherTwoPhaseTest which uses predefine app image with multiple launcher and tests to make sure installer >> will create shortcuts for all launchers. >> - Fixed Linux DesktopIntegration to create shortcuts for additional launcher if we using pre-define app image. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8231591: [TESTBUG] Create additional two phase jpackage tests (revision 3) Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/263 From herrick at openjdk.java.net Fri Sep 25 20:25:56 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 25 Sep 2020 20:25:56 GMT Subject: Integrated: 8253149: Building an installer from invalid app image fails on =?UTF-8?B?V2luZG934oCm?= In-Reply-To: References: Message-ID: On Sun, 20 Sep 2020 21:23:17 GMT, Andy Herrick wrote: > 8253149: Building an installer from invalid app image fails on Windows and Linux > When jpackage builds a package from an app-image that was not generated by jpackage, the tool should give user a > warning message, and then complete the package anyway. This pull request has now been integrated. Changeset: b159e4ed Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/b159e4ed Stats: 70 lines in 11 files changed: 62 ins; 0 del; 8 mod 8253149: Building an installer from invalid app image fails on Window? Reviewed-by: asemenyuk, almatvee, kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/271 From herrick at openjdk.java.net Fri Sep 25 21:05:23 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 25 Sep 2020 21:05:23 GMT Subject: RFR: 8253426: jpackage is unable to generate working EXE for add-launcher =?UTF-8?B?4oCm?= [v3] In-Reply-To: References: Message-ID: > 8253426: jpackage is unable to generate working EXE for add-launcher configurations. > secondary launchers ignored module, main-jar, and main-class in launcher properties file because the LAUNCHER_DATA > param was not removed from the set of params for each new add-module. testcase added in AddLauncherTest,java Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: 8253426: jpackage is unable to generate working EXE for add-launcher configurations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/347/files - new: https://git.openjdk.java.net/jdk/pull/347/files/01e12871..0a46c58b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=347&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=347&range=01-02 Stats: 14 lines in 1 file changed: 2 ins; 4 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/347.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/347/head:pull/347 PR: https://git.openjdk.java.net/jdk/pull/347 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 kvn at openjdk.java.net Fri Sep 25 21:08:50 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 25 Sep 2020 21:08:50 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v5] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 05:17:38 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 7971: >> >>> 7969: BasicType type, int offset, bool use64byteVector) { >>> 7970: assert(MaxVectorSize >= 32, "vector length < 32"); >>> 7971: use64byteVector |= MaxVectorSize > 32 && AVX3Threshold == 0; >> >> When do you expect AVX3Threshold to be 0? > > As of now when user explicitly pass -XX:AVX3Threshold=0 , default value of AVX3Threshold is 4096. I don't like that you put special meaning on AVX3Threshold=0 and then have to add additional checks for it in places where you check its power of 2. And you don't check such setting in new tests. Actually checking for 0 and power of 2 should be done by flag's constraint. See CodeEntryAlignmentConstraintFunc as example. There is also this strange relation with MaxVectorSize. Also we should consider power level switch for 64 bytes AVX3 vectors. Does it make sense to use it if array length is small (< 4096 default)? ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From kvn at openjdk.java.net Fri Sep 25 21:08:49 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 25 Sep 2020 21:08:49 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v5] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 15:55:11 GMT, Jatin Bhateja wrote: >> Summary: >> >> 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. >> 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. >> 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop >> copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block >> and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. >> 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user >> sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy >> sizes above 4096 bytes. JMH Results: >> System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz >> Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java >> Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() >> WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8252847 : Modifying file permission to resolve jcheck failure. The main concern which is not clear in these changes is ZMM usage which will lower frequency and case performance regression for small arrays. That is why AVX3Threshold is set to 4096 bytes by default. Allowing and checking for 0 AVX3Threshold value contradicts that. Would be nice to have clear comment/explanation about that. I also propose to use Flag constraint() functionality for checking AVX3Threshold value instead of runtime checks everywhere. Separate RFE, please. src/hotspot/cpu/x86/assembler_x86.cpp line 2593: > 2591: > 2592: void Assembler::evmovdqu(XMMRegister dst, KRegister mask, Address src, int vector_len, int type) { > 2593: assert(VM_Version::supports_avx512vlbw(), ""); I suggest to add assert to these 2 new instruction to check 'type' value to make sure only expected types are passed. src/hotspot/cpu/x86/assembler_x86.cpp line 2596: > 2594: InstructionMark im(this); > 2595: bool wide = type == T_SHORT || type == T_LONG || type == T_CHAR; > 2596: bool bwinstr = type == T_BYTE || type == T_SHORT || type == T_CHAR; 'bwinstr' is used only once. You may as well directly set 'prefix' here. (Same in second instruction). src/hotspot/cpu/x86/assembler_x86.cpp line 2595: > 2593: assert(VM_Version::supports_avx512vlbw(), ""); > 2594: InstructionMark im(this); > 2595: bool wide = type == T_SHORT || type == T_LONG || type == T_CHAR; It looks strange but it is correct (I looked on existing evmovdqu* instructions). May be reorder - T_LONG last. Do you consider replacing existing evmovdqu* instructions with these two? src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 1264: > 1262: } > 1263: > 1264: #ifndef PRODUCT macroAssembler_x86.hpp become big. May be we should start thing about splitting arraycopy stubs into separate file. src/hotspot/cpu/x86/stubRoutines_x86.hpp line 36: > 34: enum platform_dependent_constants { > 35: code_size1 = 20000 LP64_ONLY(+10000), // simply increase if too small (assembler will crash if too small) > 36: code_size2 = 35300 LP64_ONLY(+21400) // simply increase if too small (assembler will crash if too small) This is big increase in size! src/hotspot/cpu/x86/vm_version_x86.cpp line 1167: > 1165: > 1166: if (!FLAG_IS_DEFAULT(AVX3Threshold)) { > 1167: if (AVX3Threshold != 0 && !is_power_of_2(AVX3Threshold)) { Consider flag's constraint() instead of runtime these checks. Separate RFE, please. src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ArrayCompareToOp.java line 87: > 85: super(TYPE); > 86: > 87: assert useAVX3Threshold == 0 || CodeUtil.isPowerOf2(useAVX3Threshold) : "AVX3Threshold must be power of 2"; You would need to upstream Graal changes. test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyConjoint.java line 33: > 31: * > 32: * @run main/othervm/timeout=600 -XX:-TieredCompilation -Xbatch -XX:+IgnoreUnrecognizedVMOptions > 33: * -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:ArrayCopyPartialInlineSize=0 -XX:MaxVectorSize=32 -XX:+UnlockDiagnosticVMOptions ArrayCopyPartialInlineSize flag is not defiled in these changes. It seems they need to be included in 8252848 changes. ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/61 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 herrick at openjdk.java.net Fri Sep 25 21:28:48 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 25 Sep 2020 21:28:48 GMT Subject: RFR: 8253426: jpackage is unable to generate working EXE for add-launcher =?UTF-8?B?4oCm?= [v3] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 21:43:52 GMT, Alexey Semenyuk wrote: >> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: >> >> 8253426: jpackage is unable to generate working EXE for add-launcher configurations > > test/jdk/tools/jpackage/share/AddLauncherTest.java line 218: > >> 216: >> 217: TKit.trace("moduleValue: " + moduleValue + " mainClass: " + mainClass >> 218: + " classpath: " + classpath); > > `classpath` variable is `null` at this point. What is the point to log its value? The whole log statement is excessive > because `classpath` variable is `null` and value of `moduleValue` variable is logged implicitly in TKit.assertEquals() > call. ok - implemented as you suggested ------------- PR: https://git.openjdk.java.net/jdk/pull/347 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 mark.reinhold at oracle.com Fri Sep 25 22:17:58 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 25 Sep 2020 15:17:58 -0700 (PDT) Subject: New candidate JEP: 392: Packaging Tool Message-ID: <20200925221758.6A1F33C324E@eggemoggin.niobe.net> https://openjdk.java.net/jeps/392 - Mark From almatvee at openjdk.java.net Fri Sep 25 23:04:50 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 25 Sep 2020 23:04:50 GMT Subject: Integrated: 8231591: [TESTBUG] Create additional two phase jpackage tests In-Reply-To: References: Message-ID: On Sat, 19 Sep 2020 02:42:27 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8231591 > > - Added MultiLauncherTwoPhaseTest which uses predefine app image with multiple launcher and tests to make sure installer > will create shortcuts for all launchers. > - Fixed Linux DesktopIntegration to create shortcuts for additional launcher if we using pre-define app image. This pull request has now been integrated. Changeset: 5a57945f Author: Alexander Matveev URL: https://git.openjdk.java.net/jdk/commit/5a57945f Stats: 147 lines in 5 files changed: 134 ins; 0 del; 13 mod 8231591: [TESTBUG] Create additional two phase jpackage tests Reviewed-by: asemenyuk, herrick ------------- PR: https://git.openjdk.java.net/jdk/pull/263 From almatvee at openjdk.java.net Fri Sep 25 23:35:08 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 25 Sep 2020 23:35:08 GMT Subject: RFR: 8253426: jpackage is unable to generate working EXE for add-launcher =?UTF-8?B?4oCm?= [v3] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 21:05:23 GMT, Andy Herrick wrote: >> 8253426: jpackage is unable to generate working EXE for add-launcher configurations. >> secondary launchers ignored module, main-jar, and main-class in launcher properties file because the LAUNCHER_DATA >> param was not removed from the set of params for each new add-module. testcase added in AddLauncherTest,java > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > 8253426: jpackage is unable to generate working EXE for add-launcher configurations Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/347 From igraves at openjdk.java.net Sat Sep 26 07:04:22 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Sat, 26 Sep 2020 07:04:22 GMT Subject: Integrated: 8252730: jlink does not create reproducible builds on different servers In-Reply-To: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> References: <0I_OxbaIFEL-CCgf9rgwKWLbb_78taGaIIZa8wh2vKw=.4b7a6a4d-9beb-438e-b5e7-59aabe9ce888@github.com> Message-ID: On Mon, 14 Sep 2020 20:35:24 GMT, Ian Graves wrote: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by jlink. This pull request has now been integrated. Changeset: 79904c1f Author: Ian Graves Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/79904c1f Stats: 123 lines in 3 files changed: 115 ins; 1 del; 7 mod 8252730: jlink does not create reproducible builds on different servers Reviewed-by: mchung, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/156 From mik3hall at gmail.com Sat Sep 26 11:57:06 2020 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 26 Sep 2020 06:57:06 -0500 Subject: jpackage OS X codesign IOException Message-ID: java.io.IOException: Command [codesign, -s, Developer ID Application: XXXXX (XXXXX), -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage16414030388823297270/images/image-18070612222985031173/HalfPipe.app] exited with 1 code XXXXX values changed by me From ecki at zusammenkunft.net Sat Sep 26 12:09:08 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 26 Sep 2020 12:09:08 +0000 Subject: jpackage OS X codesign IOException In-Reply-To: References: Message-ID: Looks like the codesign command is not in your PATH Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Michael Hall Gesendet: Saturday, September 26, 2020 1:57:06 PM An: core-libs-dev at openjdk.java.net Betreff: jpackage OS X codesign IOException java.io.IOException: Command [codesign, -s, Developer ID Application: XXXXX (XXXXX), -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage16414030388823297270/images/image-18070612222985031173/HalfPipe.app] exited with 1 code XXXXX values changed by me From mik3hall at gmail.com Sat Sep 26 12:13:51 2020 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 26 Sep 2020 07:13:51 -0500 Subject: jpackage OS X codesign IOException In-Reply-To: References: Message-ID: <56E143CE-5D54-467A-A7FC-AD5BB2FEEFB2@gmail.com> > On Sep 26, 2020, at 7:09 AM, Bernd Eckenfels wrote: > > Looks like the codesign command is not in your PATH > which codesign /usr/bin/codesign From mik3hall at gmail.com Sat Sep 26 12:16:21 2020 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 26 Sep 2020 07:16:21 -0500 Subject: jpackage OS X codesign IOException In-Reply-To: <56E143CE-5D54-467A-A7FC-AD5BB2FEEFB2@gmail.com> References: <56E143CE-5D54-467A-A7FC-AD5BB2FEEFB2@gmail.com> Message-ID: > On Sep 26, 2020, at 7:13 AM, Michael Hall wrote: > > > >> On Sep 26, 2020, at 7:09 AM, Bernd Eckenfels wrote: >> >> Looks like the codesign command is not in your PATH >> > > which codesign > /usr/bin/codesign > PATH= ? /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin ... From mdoerr at openjdk.java.net Sat Sep 26 15:36:28 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Sat, 26 Sep 2020 15:36:28 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 02:45:36 GMT, CoreyAshford wrote: > This patch set encompasses the following commits: > > - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for > the intrinsic. The API is similar to the existing encodeBlock intrinsic. > - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic > implementation > - Adds a Power64LE-specific implementation of the decodeBlock intrinsic. > - Adds a JMH microbenchmark for both Base64 encoding and encoding. > - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding. AOT support needs an update: # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316 # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557) V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603) V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840) V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55) V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159) V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133) V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766) V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037) Can be reproduced by running JTREG tests: compiler/aot/calls/fromAot ------------- Changes requested by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/293 From mik3hall at gmail.com Sat Sep 26 22:37:40 2020 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 26 Sep 2020 17:37:40 -0500 Subject: jpackage OS X codesign IOException In-Reply-To: References: Message-ID: <115D02D0-C38A-4AEE-ACBC-0A783CE93CDD@gmail.com> > On Sep 26, 2020, at 6:57 AM, Michael Hall wrote: > > java.io.IOException: Command [codesign, -s, Developer ID Application: XXXXX (XXXXX), -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage16414030388823297270/images/image-18070612222985031173/HalfPipe.app] exited with 1 code > > XXXXX values changed by me With ?verbose Running [codesign, -s, Developer ID Application: Michael Hall (XXXXXXX), -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app] /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app: is already signed java.io.IOException: Command [codesign, -s, Developer ID Application: Michael Hall (XXXXXXXX), -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app] exited with 1 code at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:73) at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:179) at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:150) at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacAppImageBuilder.signAppBundle(MacAppImageBuilder.java:895) ? jdk.incubator.jpackage.internal.PackagerException: java.io.IOException: Command [codesign, -s, Developer ID Application: Michael Hall (XXXXXXX), -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app] exited with 1 code ? Caused by: java.io.IOException: Command [codesign, -s, Developer ID Application: Michael Hall (XXXXXXX), -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app] exited with 1 code ? Skipping part of stack trace. Changing the id assigned me to XXXXXX again. Leaving my name, not exactly top secret I guess. I was wondering if there was a problem with the embedded blank in the name but that doesn?t seem to go with? /HalfPipe.app: is already signed Many individual files appear to be successfully signed prior to that. There is this, suggesting maybe some runtime signing has already been done? Running [codesign, -f, -s, Developer ID Application: Michael Hall (XXXXXXX), --prefix, us.hall.hp.common., -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app/Contents/runtime] /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app/Contents/runtime: replacing existing signature /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app/Contents/runtime: signed bundle with Mach-O thin (x86_64) [com.oracle.java.us.hall.HalfPipe] Running [codesign, -s, Developer ID Application: Michael Hall (XXXXXXX), --prefix, us.hall.hp.common., -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app/Contents/runtime/Contents/_CodeSignature/CodeResources] /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app/Contents/runtime/Contents/_CodeSignature/CodeResources: signed generic [us.hall.hp.common.CodeResources] From vsharma at openjdk.java.net Sun Sep 27 12:46:21 2020 From: vsharma at openjdk.java.net (Vipin Sharma) Date: Sun, 27 Sep 2020 12:46:21 GMT Subject: RFR: 8252537: Updated @exception with @throws [v4] In-Reply-To: References: Message-ID: <1uaoGmT1-Bw11W4ki15HeUk6PPmAPnHC4kK5nOu4K2o=.5838a706-9f19-4f00-a481-0430c7dc50b4@github.com> > Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. > > Open Subtasks part of this fix are: > 1. JDK-8252537 > 2. JDK-8252539 > 3. JDK-8252540 > 4. JDK-8252541 > > Previous conversation on this: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision: Replaced ... with {@code ...} for modified statement in java.sql ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/95/files - new: https://git.openjdk.java.net/jdk/pull/95/files/37b69369..b9ed6571 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=95&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=95&range=02-03 Stats: 432 lines in 7 files changed: 0 ins; 0 del; 432 mod Patch: https://git.openjdk.java.net/jdk/pull/95.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/95/head:pull/95 PR: https://git.openjdk.java.net/jdk/pull/95 From plevart at openjdk.java.net Sun Sep 27 17:12:00 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Sun, 27 Sep 2020 17:12:00 GMT Subject: RFR: 8159746: (proxy) Support for default methods In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 22:38:04 GMT, Mandy Chung wrote: > This proposes a new static `Proxy::invokeDefaultMethod` method to invoke > the given default method on the given proxy instance. > > The implementation looks up a method handle for `invokespecial` instruction > as if called from with the proxy class as the caller, equivalent to calling > `X.super::m` where `X` is a proxy interface of the proxy class and > `X.super::m` will resolve to the specified default method. > > The implementation will call a private static `proxyClassLookup(Lookup caller)` > method of the proxy class to obtain its private Lookup. This private method > in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class > with full privilege access to use, or else `IllegalAccessException` will be > thrown. > > This patch also proposes to define a proxy class in an unnamed module to > a dynamic module to strengthen encapsulation such that they are only > unconditionally exported from a named module but not open for deep reflective > access. This only applies to the case if all the proxy interfaces are public > and in a package that is exported or open. > > One dynamic module is created for each class loader that defines proxies. > The change changes the dynamic module to contain another package (same > name as the module) that is unconditionally exported and is opened to > `java.base` only. > > There is no change to the package and module of the proxy class for > the following cases: > > - if at least one proxy interface is non-public, then the proxy class is defined > in the package and module of the non-public interfaces > - if at least one proxy is in a package that is non-exported and non-open, > if all proxy interfaces are public, then the proxy class is defined in > a non-exported, non-open package of a dynamic module. > > The spec change is that a proxy class used to be defined in an unnamed > module, i.e. in a exported and open package, is defined in an unconditionally > exported but non-open package. Programs that assume it to be open unconditionally > will be affected and cannot do deep reflection on such proxy classes. > > Peter Levart contributed an initial prototype [1] (thanks Peter). I think > the exceptions could be simplified as more checking should be done prior to > the invocation of the method handle like checking the types of the arguments > with the method type. This approach avoids defining a public API > `protected Proxy::$$proxyClassLookup$$` method. Instead it defines a > private static method that is restricted for Proxy class to use (by > taking a caller parameter to ensure it's a private lookup on Proxy class). > > javadoc/specdiff: > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/ > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/ > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html Hi Mandy, In general this looks good but one thing. The Proxy::invokeDefaultMethod does a lot of checks (creating derived method handles just to check parameters etc.) for every invocation and that means performance is not great. I created a benchmark to see how it compares with bytecode equivalent of invoking super default method: https://gist.github.com/plevart/eee13c50a91bdb61a79cf18a57a0af13 ... The results are not great: Benchmark Mode Cnt Score Error Units ProxyBench.implClass avgt 5 3.709 ? 0.026 ns/op ProxyBench.implProxy avgt 5 926.215 ? 11.835 ns/op ...so I thought why not re-doing that part differently - do as many checks as possible just once and delegate checking of passed-in arguments to method handle chain itself instead of doing that in code with reflection. My attempt is expressed in the following commit on top of your PR: https://github.com/plevart/jdk/commit/9b13be1064ec92ce8a25bda7e75f906e2e0b2978 (I couldn't create a PR against your forked jdk repo - I don't know why but Github doesn't list your fork in the popup to choose from, so I'm just pointing to commit in my fork). With this patch on top, the benchmark results are much better: Benchmark Mode Cnt Score Error Units ProxyBench.implClass avgt 5 3.777 ? 0.005 ns/op ProxyBench.implProxy avgt 5 27.579 ? 0.250 ns/op This patch also changes a little the specification of thrown exception types. Since this is a new method, we could follow what method handles do. The choice among IllegalArgumentException, NullPointerException and ClassCastException seems pretty logical to me that way. In case you don't agree, there is a possibility to do it differently for the price of more complicated method handle chain but not necessarily slower performance. So what do you think? Regards, Peter ------------- PR: https://git.openjdk.java.net/jdk/pull/313 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 lancea at openjdk.java.net Mon Sep 28 10:56:37 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 28 Sep 2020 10:56:37 GMT Subject: RFR: 8252537: Updated @exception with @throws [v4] In-Reply-To: <1uaoGmT1-Bw11W4ki15HeUk6PPmAPnHC4kK5nOu4K2o=.5838a706-9f19-4f00-a481-0430c7dc50b4@github.com> References: <1uaoGmT1-Bw11W4ki15HeUk6PPmAPnHC4kK5nOu4K2o=.5838a706-9f19-4f00-a481-0430c7dc50b4@github.com> Message-ID: On Sun, 27 Sep 2020 12:46:21 GMT, Vipin Sharma wrote: >> Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. >> >> Open Subtasks part of this fix are: >> 1. JDK-8252537 >> 2. JDK-8252539 >> 3. JDK-8252540 >> 4. JDK-8252541 >> >> Previous conversation on this: >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html > > Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision: > > Replaced ... with {@code ...} for modified statement in java.sql The changes look good. Thank you for addressing this. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/95 From jbhateja at openjdk.java.net Mon Sep 28 12:21:01 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 28 Sep 2020 12:21:01 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v6] In-Reply-To: References: Message-ID: > Summary: > > 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. > 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. > 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop > copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block > and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. > 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user > sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy > sizes above 4096 bytes. JMH Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() > WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8252847 : Review comments resolution ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/61/files - new: https://git.openjdk.java.net/jdk/pull/61/files/78c4fe73..2a606276 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=04-05 Stats: 493 lines in 9 files changed: 264 ins; 200 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk/pull/61 From kizune at openjdk.java.net Mon Sep 28 12:53:30 2020 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 28 Sep 2020 12:53:30 GMT Subject: RFR: 8253426: jpackage is unable to generate working EXE for add-launcher =?UTF-8?B?4oCm?= [v3] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 21:05:23 GMT, Andy Herrick wrote: >> 8253426: jpackage is unable to generate working EXE for add-launcher configurations. >> secondary launchers ignored module, main-jar, and main-class in launcher properties file because the LAUNCHER_DATA >> param was not removed from the set of params for each new add-module. testcase added in AddLauncherTest,java > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > 8253426: jpackage is unable to generate working EXE for add-launcher configurations Looks fine. ------------- Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/347 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 rriggs at openjdk.java.net Mon Sep 28 13:17:09 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 28 Sep 2020 13:17:09 GMT Subject: RFR: 8252537: Updated @exception with @throws [v4] In-Reply-To: <1uaoGmT1-Bw11W4ki15HeUk6PPmAPnHC4kK5nOu4K2o=.5838a706-9f19-4f00-a481-0430c7dc50b4@github.com> References: <1uaoGmT1-Bw11W4ki15HeUk6PPmAPnHC4kK5nOu4K2o=.5838a706-9f19-4f00-a481-0430c7dc50b4@github.com> Message-ID: On Sun, 27 Sep 2020 12:46:21 GMT, Vipin Sharma wrote: >> Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. >> >> Open Subtasks part of this fix are: >> 1. JDK-8252537 >> 2. JDK-8252539 >> 3. JDK-8252540 >> 4. JDK-8252541 >> >> Previous conversation on this: >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html > > Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision: > > Replaced ... with {@code ...} for modified statement in java.sql Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/95 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 alanb at openjdk.java.net Mon Sep 28 13:50:30 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 28 Sep 2020 13:50:30 GMT Subject: RFR: 8159746: (proxy) Support for default methods In-Reply-To: References: Message-ID: <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com> On Sun, 27 Sep 2020 17:09:03 GMT, Peter Levart wrote: >> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke >> the given default method on the given proxy instance. >> >> The implementation looks up a method handle for `invokespecial` instruction >> as if called from with the proxy class as the caller, equivalent to calling >> `X.super::m` where `X` is a proxy interface of the proxy class and >> `X.super::m` will resolve to the specified default method. >> >> The implementation will call a private static `proxyClassLookup(Lookup caller)` >> method of the proxy class to obtain its private Lookup. This private method >> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class >> with full privilege access to use, or else `IllegalAccessException` will be >> thrown. >> >> This patch also proposes to define a proxy class in an unnamed module to >> a dynamic module to strengthen encapsulation such that they are only >> unconditionally exported from a named module but not open for deep reflective >> access. This only applies to the case if all the proxy interfaces are public >> and in a package that is exported or open. >> >> One dynamic module is created for each class loader that defines proxies. >> The change changes the dynamic module to contain another package (same >> name as the module) that is unconditionally exported and is opened to >> `java.base` only. >> >> There is no change to the package and module of the proxy class for >> the following cases: >> >> - if at least one proxy interface is non-public, then the proxy class is defined >> in the package and module of the non-public interfaces >> - if at least one proxy is in a package that is non-exported and non-open, >> if all proxy interfaces are public, then the proxy class is defined in >> a non-exported, non-open package of a dynamic module. >> >> The spec change is that a proxy class used to be defined in an unnamed >> module, i.e. in a exported and open package, is defined in an unconditionally >> exported but non-open package. Programs that assume it to be open unconditionally >> will be affected and cannot do deep reflection on such proxy classes. >> >> Peter Levart contributed an initial prototype [1] (thanks Peter). I think >> the exceptions could be simplified as more checking should be done prior to >> the invocation of the method handle like checking the types of the arguments >> with the method type. This approach avoids defining a public API >> `protected Proxy::$$proxyClassLookup$$` method. Instead it defines a >> private static method that is restricted for Proxy class to use (by >> taking a caller parameter to ensure it's a private lookup on Proxy class). >> >> javadoc/specdiff: >> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/ >> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/ >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html > > Hi Mandy, > In general this looks good but one thing. The Proxy::invokeDefaultMethod does a lot of checks (creating derived method > handles just to check parameters etc.) for every invocation and that means performance is not great. I created a > benchmark to see how it compares with bytecode equivalent of invoking super default method: > https://gist.github.com/plevart/eee13c50a91bdb61a79cf18a57a0af13 ... The results are not great: Benchmark > Mode Cnt Score Error Units ProxyBench.implClass avgt 5 3.709 ? 0.026 ns/op ProxyBench.implProxy > avgt 5 926.215 ? 11.835 ns/op ...so I thought why not re-doing that part differently - do as many checks as > possible just once and delegate checking of passed-in arguments to method handle chain itself instead of doing that in > code with reflection. My attempt is expressed in the following commit on top of your PR: > https://github.com/plevart/jdk/commit/9b13be1064ec92ce8a25bda7e75f906e2e0b2978 (I couldn't create a PR against your > forked jdk repo - I don't know why but Github doesn't list your fork in the popup to choose from, so I'm just pointing > to commit in my fork). With this patch on top, the benchmark results are much better: Benchmark Mode Cnt > Score Error Units ProxyBench.implClass avgt 5 3.777 ? 0.005 ns/op ProxyBench.implProxy avgt 5 27.579 ? > 0.250 ns/op This patch also changes a little the specification of thrown exception types. Since this is a new method, > we could follow what method handles do. The choice among IllegalArgumentException, NullPointerException and > ClassCastException seems pretty logical to me that way. In case you don't agree, there is a possibility to do it > differently for the price of more complicated method handle chain but not necessarily slower performance. So what do > you think? Regards, Peter This is java.lang.reflect so throwing CCE for the mismatching parameter case would make it consistent with Method.invoke and maybe other methods. So the performance work is great and maybe see how far it can be brought by means of other MH combinators. ------------- PR: https://git.openjdk.java.net/jdk/pull/313 From igraves at openjdk.java.net Mon Sep 28 13:51:22 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 28 Sep 2020 13:51:22 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy [v4] In-Reply-To: References: Message-ID: <-iGo68IDs_rgSQoGXOLqyp8y6Tqk_9wKFSW_mUYcEwc=.1021fcd2-ec50-4163-b6b5-4f569916dc4b@github.com> > These changes update the jlink plugin command line documentation to tidy them up into a more canonical form. > > The output generated by jlink from this change appears as follows: > >> build/macosx-x64/images/jdk/bin/jlink --list-plugins > > List of available plugins: > --strip-debug Strip debug information from the output image > --strip-java-debug-attributes > Strip Java debug attributes from classes in the output image > --exclude-resources > Specify resources to exclude. > e.g.: **.jcov,glob:**/META-INF/** > --exclude-files > Specify files to exclude. > e.g.: **.java,glob:/java.base/lib/client/** > --exclude-jmod-section > Specify a JMOD section to exclude. > Where is "man" or "headers". > --dedup-legal-notices [error-if-not-same-content] > De-duplicate all legal notices. > If error-if-not-same-content is specified then > it will be an error if two files of the same > filename are different. > --system-modules retainModuleTarget > Fast loading of module descriptors (always enabled) > --strip-native-commands Exclude native commands (such as java/java.exe) from the image > --order-resources > Order resources. > e.g.: **/module-info.class, at classlist,/java.base/java/lang/** > --compress <0|1|2>[:filter=] > Compress all resources in the output image. > Level 0: No compression > Level 1: Constant string sharing > Level 2: ZIP. > An optional filter can be > specified to list the pattern of files to be included. > --vm > Select the HotSpot VM in the output image. Default is all > --include-locales [,]* > BCP 47 language tags separated by a comma, allowing > locale matching defined in RFC 4647. e.g.: en,ja,*-IN > --generate-jli-classes @filename > Specify a file listing the java.lang.invoke classes > to pre-generate. By default, this plugin may use a > builtin list of classes to pre-generate. If this plugin > runs on a different runtime version than the image being > created then code generation will be disabled by > default to guarantee correctness > add ignore-version=true to override this. > --release-info |add:=:=:...|del: > option is to load release properties from the supplied file. > add: is to add properties to the release file. > Any number of = pairs can be passed. > del: is to delete the list of keys in release file. > --add-options Prepend the specified string, which may > include whitespace, before any other options when > invoking the virtual machine in the resulting image. > --vendor-bug-url > Override the vendor bug URL baked into the build. > The value of the system property > "java.vendor.url.bug" will be . > --vendor-vm-bug-url > Override the vendor VM bug URL baked into the build. > The URL displayed in VM error logs will be . > --vendor-version > Override the vendor version string baked into the build, > if any. The value of the system property > "java.vendor.version" will be . > > For options requiring a , the value will be a comma separated > list of elements each using one the following forms: > > glob: > regex: > @ where filename is the name of a file containing patterns to be > used, one pattern per line Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Consolidating to AbstractPlugin ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/305/files - new: https://git.openjdk.java.net/jdk/pull/305/files/4deaa4bf..bd274acf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=305&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=305&range=02-03 Stats: 368 lines in 28 files changed: 109 ins; 171 del; 88 mod Patch: https://git.openjdk.java.net/jdk/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/305/head:pull/305 PR: https://git.openjdk.java.net/jdk/pull/305 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 simon at dancingcloudservices.com Mon Sep 28 14:46:11 2020 From: simon at dancingcloudservices.com (Simon Roberts) Date: Mon, 28 Sep 2020 08:46:11 -0600 Subject: [Lambda]parallel sort stream slow than series sort In-Reply-To: References: Message-ID: Hi Tony, At this point, I would venture 1) This is still the wrong forum. I would think that stackoverflow is a far more appropriate place for discussions about how to use an api. This one, as best I understand it, is about *developing* those libraries. 2) Concurrency inevitably *increases* the total amount of CPU labor required to perform a given piece of work. There's management and coordination required to do this. If the amount of work done in the "job" is small enough, you can find that the overhead swamps the work, and things go badly. 3) Observation 2 is compounded by the fact that there's also *communication* that has to happen between threads. Streams do a good job of minimizing this, but the workload must be sharded across the parallel threads, and then brought back together again. In some situations, this can create so much serialization that the whole thing slows down. A really vicious form of this can arise when performing vast amounts of memory allocation in multiple threads; a TLAB that runs out of capacity has to get more memory from main heap, and that's (inevitably I think) a critical section. 4) This is a "micro-benchmark", and they're essentially never meaningful in Java. At the very least, if you were to observe the JIT compilations (use -XX:+PrintCompilation) you're almost certain to see that it's still optimizing the code by the time the sub-second exercise is over. There are many routes to more valid benchmarks, starting with simply ensuring the process runs for "long enough" to amortize those costs. 5) If you want to see this thing shine, create a Stream that calculates points on a Mandelbrot set, then parallelize that. You'll see that there's nothing wrong with the implementation. Other than that, I really think you should ask this in stackoverflow, not here. On Sun, Sep 27, 2020 at 2:24 AM tonytao wrote: > Hi Roberts, > > Thank for your warmly help. > I debugged into stream parallel it seems parallel stream use a > ArrayListSpliterator split list into pieces in jdk11 and 14,not a mutual > exclusion.Test arrays was retrieved from postgresql,but all data was ready > before running test .I rewriteed the data-generate code in java. > > hi Vladimir, > > I tested in jdk14: > openjdk version "14.0.2" 2020-07-14 > OpenJDK Runtime Environment (build 14.0.2+12-46) > OpenJDK 64-Bit Server VM (build 14.0.2+12-46, mixed mode, sharing) > > parallel sort still slower than series sort. > > sorted execute time:274ms, resultset rows 5000000, 18248175 rows/sec > parallel sorted execute time:627ms, resultset rows 5000000, 7974481 > rows/sec > > hi Roberts & Peter, > > Here is the test code: > > int rowCount = 5000000;LocalDateTime d = LocalDateTime.now();List data = new ArrayList<>();List data2 = new ArrayList<>();long startTime = System.currentTimeMillis();for (int i = 0; i < rowCount; i++) { > Object[] row = new Object[3]; > row[0] = i; > d = d.plusMinutes(1); > row[1] = java.sql.Date.valueOf(d.toLocalDate()); > row[2] = DigestUtils.md5Hex(row[1].toString()); > data.add(row); > data2.add(row);}long endTime = System.currentTimeMillis();System.out.println("read data execute time:" + (endTime - startTime) + "ms, resultset rows " + rowCount + ", " > + rowCount * 1000 / (endTime - startTime) + " rows/sec"); > for (int i = 0; i < 1; i++) { > for (Object x : data.get(i)) { > System.out.println("data type: " + x.getClass() + ", value: " + x); > }} > Comparator comparator = new Comparator() { > @Override > public int compare(Object[] o1, Object[] o2) { > int res = 0; > for (int i = 0; i < o1.length; i++) { > res = ((Comparable) o1[i]).compareTo(o2[i]); > if (res != 0) { > break; > } > } > return res; > }}; > List list;List l = Collections.unmodifiableList(data); > > > startTime = System.currentTimeMillis(); > list = data.stream().sorted(comparator).collect(Collectors.toList()); > endTime = System.currentTimeMillis();System.out.println("sorted execute time:" + (endTime - startTime) + "ms, resultset rows " + list.size() + ", " > + (long) list.size() * 1000 / (endTime - startTime) + " rows/sec"); > > startTime = System.currentTimeMillis(); > list = data2.stream().parallel().sorted(comparator).collect(Collectors.toList()); > endTime = System.currentTimeMillis();System.out.println("parallel sorted execute time:" + (endTime - startTime) + "ms, resultset rows " + list.size() > + ", " + (long) list.size() * 1000 / (endTime - startTime) + " rows/sec"); > > > You could run it in you ide,it depened on: > > org.apache.commons > commons-lang3 > 3.11 > > > > Thanks again! > > Tao Jin. > > > On 9/26/20 1:56 AM, Simon Roberts wrote: > > Tests like this are rarely meaningful. In particular you have a random > number generator in there. They are often built on single threaded code > protected by mutual exclusion. That of itself prevents the code ever going > faster than sequential code, and in fact usually makes it slower due to the > additional overhead of inter-thread communication. > > Further, your example seems to be a test of a database and its driver, and > has no obvious relationship to either the Streams API or anything in the > core Java libraries. Perhaps I miss something. > > > On Fri, Sep 25, 2020 at 4:09 AM tonytao wrote: > >> hi, >> >> I wrote a test case to test stream performance,but the parallel sort >> always slow than the series sort.I test the data size in : 20,000 , >> 5,000,000, 10,000,000 , 20,000,000 . >> >> attatched is the test case source code. >> >> jdk version : >> >> openjdk version "11.0.8" 2020-07-14 >> OpenJDK Runtime Environment (build 11.0.8+10-post-Debian-1deb10u1) >> OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Debian-1deb10u1, mixed >> mode, sharing) >> >> jvm argument: >> >> -ea -Xms256m -Xmx8192m >> >> macheine: >> >> cpu:Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz >> >> memory: 16GB >> >> Test result shows as below: >> >> 20000: >> >> sorted execute time:9ms, resultset rows 20000, 2222222 rows/sec >> parallel sorted execute time:24ms, resultset rows 20000, 833333 rows/sec >> >> 5000000: >> >> sorted execute time:245ms, resultset rows 5000000, 20408163 rows/sec >> parallel sorted execute time:402ms, resultset rows 5000000, 12437810 >> rows/sec >> >> 10000000: >> >> sorted execute time:577ms, resultset rows 10000000, 17331022 rows/sec >> parallel sorted execute time:1230ms, resultset rows 10000000, 8130081 >> rows/sec >> >> 20000000: >> >> sorted execute time:1079ms, resultset rows 20000000, 18535681 rows/sec >> parallel sorted execute time:1790ms, resultset rows 20000000, 11173184 >> rows/sec >> >> >> this is the test data sample: >> >> hdb=> select * from testdata limit 10; >> id | uptime | x | y | cmt >> >> ---------+----------------------------+----+----+---------------------------------- >> 1340417 | 2023-02-22 07:30:34.391207 | 33 | 9 | >> 4bf16d4c4b638d84b56893de2451c407 >> 1340418 | 2023-02-22 07:31:34.391207 | 10 | 91 | >> c9b78bfbd6b684e62605e96d2d8237a0 >> 1340419 | 2023-02-22 07:32:34.391207 | 66 | 24 | >> 968e5d19ca3a2ddae5d2a366ba06cf16 >> 1340420 | 2023-02-22 07:33:34.391207 | 4 | 42 | >> bdcf7d764121fc9b0039f80eadea1310 >> 1340421 | 2023-02-22 07:34:34.391207 | 27 | 45 | >> 06520ac5e508f15f09672fa751d5c17a >> 1340422 | 2023-02-22 07:35:34.391207 | 36 | 11 | >> 5bede83b54dfe76f4a249308d8033691 >> 1340423 | 2023-02-22 07:36:34.391207 | 41 | 92 | >> 37f4b34988c0e1387940177a8cc9d83a >> 1340424 | 2023-02-22 07:37:34.391207 | 29 | 59 | >> 416459b54ae00c95e118c93605a40d43 >> 1340425 | 2023-02-22 07:38:34.391207 | 9 | 46 | >> 46339b8eeae99c7e922003ed87b9d417 >> 1340426 | 2023-02-22 07:39:34.391207 | 21 | 29 | >> 7ede63cdb2a6a86c63534fe5fcfb2f97 >> (10 rows) >> >> >> It was generated by sql: >> >> create table testdata( >> idint, >> uptimetimestamp, >> xint, >> yint, >> cmttext >> ); >> insert into testdata >> select >> id, >> uptime, >> round(random()*100), >> round(random()*100), >> md5(uptime::text) >> from ( >> select >> generate_series id, >> current_timestamp + make_interval(mins=> >> generate_series) uptime >> from generate_series(1,100000000) >> ) t; >> >> >> Could you please help me to find the problem? >> >> Thanks a lot. >> >> >> >> > > -- > Simon Roberts > (303) 249 3613 > > > -- Simon Roberts (303) 249 3613 From eric.c.liu at arm.com Mon Sep 28 15:13:58 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Mon, 28 Sep 2020 15:13:58 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com>, Message-ID: Hi, Thanks for looking at this. For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' to replace 'strncpy'. Thanks, Eric From Roger.Riggs at oracle.com Mon Sep 28 15:32:37 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 28 Sep 2020 11:32:37 -0400 Subject: 8251989: Unified Hex formatting and parsing utility In-Reply-To: <465e58eb-a18e-5aa9-42ad-be5f41c67c8f@oracle.com> References: <1BAC4282-314D-4009-B2F7-28B6FDACBA28@oracle.com> <465e58eb-a18e-5aa9-42ad-be5f41c67c8f@oracle.com> Message-ID: After some reflection on the comments, suggestions, and other advice offered the Hex format API has undergone a significant rewrite. The improvements include: ?- Merged format and parse classes into a single class HexFormat that holds parameters and has methods for all conversions ?- Simplified static factories and added builder methods to create HexFormat copies with modified parameters. ?- Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex ?- Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... ?- Prefix and suffixes now apply to each formatted value, not the string as a whole ?- Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams ?? like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) The HexFormat javadoc is at: http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html Thanks to all that commented and made suggestions on core-libs-dev and privately. Please review and comment.? When the API has settled, I'll turn it into a PR and CSR. Thanks, Roger From sgehwolf at openjdk.java.net Mon Sep 28 16:09:52 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 28 Sep 2020 16:09:52 GMT Subject: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high Message-ID: Tests using `--memory-reservation` started to fail with newer `crun` cgroups v2-capable runtime. It turns out it was incorrectly setting `memory.high` in an early version and got fixed to set `memory.low` now instead. This change accounts for that. ------------- Commit messages: - 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high Changes: https://git.openjdk.java.net/jdk/pull/381/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=381&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253714 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/381.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/381/head:pull/381 PR: https://git.openjdk.java.net/jdk/pull/381 From sgehwolf at openjdk.java.net Mon Sep 28 16:09:52 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 28 Sep 2020 16:09:52 GMT Subject: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 15:59:35 GMT, Severin Gehwolf wrote: > Tests using `--memory-reservation` started to fail with newer `crun` cgroups v2-capable runtime. It turns out it was > incorrectly setting `memory.high` in an early version and got fixed to set `memory.low` now instead. This change > accounts for that. @bobvandette Could you please take a look? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/381 From sgehwolf at openjdk.java.net Mon Sep 28 16:09:52 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 28 Sep 2020 16:09:52 GMT Subject: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:00:57 GMT, Severin Gehwolf wrote: >> Tests using `--memory-reservation` started to fail with newer `crun` cgroups v2-capable runtime. It turns out it was >> incorrectly setting `memory.high` in an early version and got fixed to set `memory.low` now instead. This change >> accounts for that. > > @bobvandette Could you please take a look? Thanks! Note that due to JDK-8253727 not all tests are passing with newer crun runtime (0.8 was last working for me). ------------- PR: https://git.openjdk.java.net/jdk/pull/381 From dfuchs at openjdk.java.net Mon Sep 28 16:21:08 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 28 Sep 2020 16:21:08 GMT Subject: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:05:48 GMT, Daniel D. Daugherty wrote: > 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on linux-aarch64 Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/382 From dcubed at openjdk.java.net Mon Sep 28 16:21:07 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 28 Sep 2020 16:21:07 GMT Subject: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 Message-ID: 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on linux-aarch64 ------------- Commit messages: - Merge branch 'master' into JDK-8253667 - Also ProblemList tools/jlink/JLinkReproducible3Test.java due to 8253688. - 8253667: ProblemList tools/jlink/JLinkReproducibleTest.java on linux-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/382/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=382&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253667 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/382.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/382/head:pull/382 PR: https://git.openjdk.java.net/jdk/pull/382 From iignatyev at openjdk.java.net Mon Sep 28 16:21:08 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 28 Sep 2020 16:21:08 GMT Subject: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:05:48 GMT, Daniel D. Daugherty wrote: > 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on linux-aarch64 Marked as reviewed by iignatyev (Reviewer). test/jdk/ProblemList.txt line 859: > 857: tools/jlink/JLinkReproducibleTest.java 8217166 windows-all > 858: tools/jlink/plugins/CompressorPluginTest.java 8247407 generic-all > 859: tools/jlink/JLinkReproducibleTest.java 8217166 linux-aarch64 wouldn't it be better to "join" JLinkReproducibleTest entries? ```suggestion tools/jlink/JLinkReproducibleTest.java 8217166 windows-all,linux-aarch64 tools/jlink/plugins/CompressorPluginTest.java 8247407 generic-all ------------- PR: https://git.openjdk.java.net/jdk/pull/382 From dcubed at openjdk.java.net Mon Sep 28 16:21:09 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 28 Sep 2020 16:21:09 GMT Subject: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:05:48 GMT, Daniel D. Daugherty wrote: > 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on linux-aarch64 @AlanBateman - not sure if 'core-libs' was the right label to add so I figured I would ping you directly for a review. ------------- PR: https://git.openjdk.java.net/jdk/pull/382 From dcubed at openjdk.java.net Mon Sep 28 16:27:10 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 28 Sep 2020 16:27:10 GMT Subject: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 In-Reply-To: <-gAU0LOjZ46cZQiWUIM4mvrUDKdliwR6iK2cK1zRW6I=.0884b1ea-4d58-497c-93e7-40e64c780adc@github.com> References: <-gAU0LOjZ46cZQiWUIM4mvrUDKdliwR6iK2cK1zRW6I=.0884b1ea-4d58-497c-93e7-40e64c780adc@github.com> Message-ID: <7nF31lfzjQ8TEtH4jPzKCxXYtYPhk-Kl0j4amivaJIo=.8c611556-9958-4145-870a-d24d9b470d47@github.com> On Mon, 28 Sep 2020 16:22:17 GMT, Igor Ignatyev wrote: >> test/jdk/ProblemList.txt line 859: >> >>> 857: tools/jlink/JLinkReproducibleTest.java 8217166 windows-all >>> 858: tools/jlink/plugins/CompressorPluginTest.java 8247407 generic-all >>> 859: tools/jlink/JLinkReproducibleTest.java 8217166 linux-aarch64 >> >> wouldn't it be better to "join" JLinkReproducibleTest entries? >> ```suggestion >> tools/jlink/JLinkReproducibleTest.java 8217166 windows-all,linux-aarch64 >> tools/jlink/plugins/CompressorPluginTest.java 8247407 generic-all > > actually, you have to join them, as only jtreg honors only the last entry for a test -- > [CODETOOLS-7902481](https://bugs.openjdk.java.net/browse/CODETOOLS-7902481) Yes, I should use the existing entry. I didn't think to check for that. ------------- PR: https://git.openjdk.java.net/jdk/pull/382 From iignatyev at openjdk.java.net Mon Sep 28 16:27:10 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 28 Sep 2020 16:27:10 GMT Subject: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 In-Reply-To: References: Message-ID: <-gAU0LOjZ46cZQiWUIM4mvrUDKdliwR6iK2cK1zRW6I=.0884b1ea-4d58-497c-93e7-40e64c780adc@github.com> On Mon, 28 Sep 2020 16:16:52 GMT, Igor Ignatyev wrote: >> 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on linux-aarch64 > > test/jdk/ProblemList.txt line 859: > >> 857: tools/jlink/JLinkReproducibleTest.java 8217166 windows-all >> 858: tools/jlink/plugins/CompressorPluginTest.java 8247407 generic-all >> 859: tools/jlink/JLinkReproducibleTest.java 8217166 linux-aarch64 > > wouldn't it be better to "join" JLinkReproducibleTest entries? > ```suggestion > tools/jlink/JLinkReproducibleTest.java 8217166 windows-all,linux-aarch64 > tools/jlink/plugins/CompressorPluginTest.java 8247407 generic-all actually, you have to join them, as only jtreg honors only the last entry for a test -- [CODETOOLS-7902481](https://bugs.openjdk.java.net/browse/CODETOOLS-7902481) ------------- PR: https://git.openjdk.java.net/jdk/pull/382 From plevart at openjdk.java.net Mon Sep 28 16:29:25 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 28 Sep 2020 16:29:25 GMT Subject: RFR: 8159746: (proxy) Support for default methods In-Reply-To: <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com> References: <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com> Message-ID: On Mon, 28 Sep 2020 13:47:04 GMT, Alan Bateman wrote: >> Hi Mandy, >> In general this looks good but one thing. The Proxy::invokeDefaultMethod does a lot of checks (creating derived method >> handles just to check parameters etc.) for every invocation and that means performance is not great. I created a >> benchmark to see how it compares with bytecode equivalent of invoking super default method: >> https://gist.github.com/plevart/eee13c50a91bdb61a79cf18a57a0af13 ... The results are not great: Benchmark >> Mode Cnt Score Error Units ProxyBench.implClass avgt 5 3.709 ? 0.026 ns/op ProxyBench.implProxy >> avgt 5 926.215 ? 11.835 ns/op ...so I thought why not re-doing that part differently - do as many checks as >> possible just once and delegate checking of passed-in arguments to method handle chain itself instead of doing that in >> code with reflection. My attempt is expressed in the following commit on top of your PR: >> https://github.com/plevart/jdk/commit/9b13be1064ec92ce8a25bda7e75f906e2e0b2978 (I couldn't create a PR against your >> forked jdk repo - I don't know why but Github doesn't list your fork in the popup to choose from, so I'm just pointing >> to commit in my fork). With this patch on top, the benchmark results are much better: Benchmark Mode Cnt >> Score Error Units ProxyBench.implClass avgt 5 3.777 ? 0.005 ns/op ProxyBench.implProxy avgt 5 27.579 ? >> 0.250 ns/op This patch also changes a little the specification of thrown exception types. Since this is a new method, >> we could follow what method handles do. The choice among IllegalArgumentException, NullPointerException and >> ClassCastException seems pretty logical to me that way. In case you don't agree, there is a possibility to do it >> differently for the price of more complicated method handle chain but not necessarily slower performance. So what do >> you think? Regards, Peter > > This is java.lang.reflect so throwing CCE for the mismatching parameter case would make it consistent with > Method.invoke and maybe other methods. So the performance work is great and maybe see how far it can be brought by > means of other MH combinators. @AlanBateman you meant to say throwing CCE for mismatching parameter case would make it **inconsistent** with Method.invoke, right? That's easy to change. We just catch CCE (and NPE?) and re-throw them wrapped in IAE. We don't need to do that via MH combinators. Just directly in code. Performance will remain the same. ------------- PR: https://git.openjdk.java.net/jdk/pull/313 From minqi at openjdk.java.net Mon Sep 28 16:32:52 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 28 Sep 2020 16:32:52 GMT Subject: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:17:21 GMT, Igor Ignatyev wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Update existing entry for tools/jlink/JLinkReproducibleTest.java instead of creating a new one. > > Marked as reviewed by iignatyev (Reviewer). Should we put this for all platforms? ------------- PR: https://git.openjdk.java.net/jdk/pull/382 From dcubed at openjdk.java.net Mon Sep 28 16:32:52 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 28 Sep 2020 16:32:52 GMT Subject: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2] In-Reply-To: References: Message-ID: > 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on linux-aarch64 Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Update existing entry for tools/jlink/JLinkReproducibleTest.java instead of creating a new one. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/382/files - new: https://git.openjdk.java.net/jdk/pull/382/files/38997e41..1574c820 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=382&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=382&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/382.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/382/head:pull/382 PR: https://git.openjdk.java.net/jdk/pull/382 From dcubed at openjdk.java.net Mon Sep 28 16:32:52 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 28 Sep 2020 16:32:52 GMT Subject: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:28:48 GMT, Yumin Qi wrote: >> Marked as reviewed by iignatyev (Reviewer). > > Should we put this for all platforms? Nope. We're currently seeing these failures on linux-aarch64 so that's what started this ProblemListing adventure... ------------- PR: https://git.openjdk.java.net/jdk/pull/382 From iignatyev at openjdk.java.net Mon Sep 28 16:36:33 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 28 Sep 2020 16:36:33 GMT Subject: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:32:52 GMT, Daniel D. Daugherty wrote: >> 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on linux-aarch64 > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Update existing entry for tools/jlink/JLinkReproducibleTest.java instead of creating a new one. Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/382 From dcubed at openjdk.java.net Mon Sep 28 16:36:33 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 28 Sep 2020 16:36:33 GMT Subject: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:16:08 GMT, Daniel Fuchs wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Update existing entry for tools/jlink/JLinkReproducibleTest.java instead of creating a new one. > > Marked as reviewed by dfuchs (Reviewer). @dfuch and @iignatev - please re-review when you the chance... Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/382 From dcubed at openjdk.java.net Mon Sep 28 16:44:11 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 28 Sep 2020 16:44:11 GMT Subject: Integrated: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:05:48 GMT, Daniel D. Daugherty wrote: > 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on linux-aarch64 This pull request has now been integrated. Changeset: 821bd08c Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/821bd08c Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on linux-aarch64 Reviewed-by: dfuchs, iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/382 From github.com+51754783+CoreyAshford at openjdk.java.net Mon Sep 28 16:46:14 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Mon, 28 Sep 2020 16:46:14 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: <_tvo1hj209XU5Y4JzhXfjSY2wh7-j1cahY7BskdaXNI=.c4acaa07-0a31-4460-b1d3-57a64fed1fdc@github.com> References: <_tvo1hj209XU5Y4JzhXfjSY2wh7-j1cahY7BskdaXNI=.c4acaa07-0a31-4460-b1d3-57a64fed1fdc@github.com> Message-ID: On Fri, 25 Sep 2020 13:45:15 GMT, Roger Riggs wrote: >> This patch set encompasses the following commits: >> >> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for >> the intrinsic. The API is similar to the existing encodeBlock intrinsic. >> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic >> implementation >> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic. >> - Adds a JMH microbenchmark for both Base64 encoding and encoding. >> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding. > > src/java.base/share/classes/java/util/Base64.java line 747: > >> 745: * Decodes base64 characters, and returns the number of data bytes >> 746: * produced by the base64 decode intrinsic. >> 747: * > > "intrinsic" can be omitted. Both the java and the intrinsic produce the same output. Good point. Will fix. > src/java.base/share/classes/java/util/Base64.java line 759: > >> 757: * src, it must process a multiple of four of them, making the >> 758: * returned destination length a multiple of three. >> 759: * > > If the dst array is too short does the intrinsic stop short or throw? > The java code would throw an ArrayIndexOutOfBoundsException. > It should not occur since the java code allocates the proper buffer but... > It might be worth mentioning. The intrinsic doesn't have enough information to know how long the dst buffer is. It only knows the starting address and the offset from that starting address; it has to trust the caller. encodeBlock() has the same limitation. I will add a comment to that effect. > src/java.base/share/classes/java/util/Base64.java line 820: > >> 818: dp += dl; >> 819: } >> 820: if (sp == sl) { > > I'd rather see (sp >= s1) instead of the equality, its would be consistent with the condition of the while loop. > (And is already lines 767-768). Agreed. Will change that comparison. > test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 260: > >> 258: } >> 259: >> 260: private static final byte[] nonBase64 = { > > Please add a comment describing this test data. > (It looks like it could be generated more compactly than an explicit array). > Ditto nonBase64URL below. Will do. > test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 240: > >> 238: } >> 239: >> 240: private static byte[] hexStringToByteArray(String s) { > > A method to convert a Hex String to a byte array already exists in test/lib/jdk/test/lib/Utils.java in toByteArray(s). > Add "jdk.test.lib.Utils" to the "@build" line at the top of the test. Cool! Thanks. I was unaware of that function. Will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From github.com+51754783+CoreyAshford at openjdk.java.net Mon Sep 28 16:46:12 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Mon, 28 Sep 2020 16:46:12 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: On Sat, 26 Sep 2020 15:33:29 GMT, Martin Doerr wrote: > AOT support needs an update: > # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316 > # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock > > V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557) > V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603) > V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840) > V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55) > V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159) > V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133) > V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766) > V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037) > > Can be reproduced by running JTREG tests: > compiler/aot/calls/fromAot Thanks for catching that! Will fix on next round. ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From mchung at openjdk.java.net Mon Sep 28 16:59:46 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 28 Sep 2020 16:59:46 GMT Subject: RFR: 8159746: (proxy) Support for default methods In-Reply-To: References: <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com> Message-ID: <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com> On Mon, 28 Sep 2020 16:26:17 GMT, Peter Levart wrote: > @AlanBateman you meant to say throwing CCE for mismatching parameter case would make it **inconsistent** with > Method.invoke, right? That's easy to change. We just catch CCE (and NPE?) and re-throw them wrapped in IAE. We don't > need to do that via MH combinators. Just directly in code. Performance will remain the same. Right, `Method::invoke` throws IAE (not CCE). ------------- PR: https://git.openjdk.java.net/jdk/pull/313 From github.com+51754783+CoreyAshford at openjdk.java.net Mon Sep 28 17:20:45 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Mon, 28 Sep 2020 17:20:45 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: <8n1icvS8ly4JNxXsEJe6qT67B53OwHtMFZrc0XrhWzk=.4271b6c1-cf7e-43f9-af86-392f352a2e8c@github.com> On Mon, 28 Sep 2020 16:35:59 GMT, CoreyAshford wrote: >> AOT support needs an update: >> # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316 >> # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock >> >> V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557) >> V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603) >> V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840) >> V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55) >> V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159) >> V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133) >> V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766) >> V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037) >> >> Can be reproduced by running JTREG tests: >> compiler/aot/calls/fromAot > >> AOT support needs an update: >> # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316 >> # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock >> >> V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557) >> V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603) >> V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840) >> V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55) >> V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159) >> V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133) >> V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766) >> V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037) >> >> Can be reproduced by running JTREG tests: >> compiler/aot/calls/fromAot > > Thanks for catching that! Will fix on next round. Martin Doerr wrote: ... > I can see you're using clrldi to clear the upper bits of the parameters. But seems like it clears one bit too few. You're right. I misread the instruction as clear from bit 0 to bit N, but it's actually create a mask with bits N to 63 with one's, zeroes elsewhere, then AND it with the src register. Will fix. > You can also use cmpwi for the boolean one. Ah, good! Thanks. Will change. > > I wonder about the loop unrolling. It doesn't look beneficial because the loop body is large. > Did you measure performance gain by this unrolling? > I think for agressive tuning we'd have to apply techniques like modulo scheduling, but that's much more work. > So please only use unrolling as far as a benefit is measurable. I did test on a prototype written in C using vector intrinsics, and 8 was the sweet spot, however the structure of that code was a bit different and I should have verified that the same amount of loop unrolling makes sense for the Java intrinsic. I will perform those experiments. > > But you may want to align the loop start to help instruction fetch. Interesting. I did add an align, but in my patch clean up I must have lost it again somehow. I will add it back again. Sorry for that mistake. > We'll test it, but we don't have Power 10. You guys need to cover that. I did test on Power10, but I wasn't able to do performance testing because I ran on an instruction-level simulator. Real hardware will be available in the coming months. Thanks for your careful look at the code, and the regression testing you've done. ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From sgehwolf at openjdk.java.net Mon Sep 28 17:28:40 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 28 Sep 2020 17:28:40 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly Message-ID: Account for interface files for swap and memory being reported independently. The cgroup v1-like value is now reported by adding the memory.max value to the memory.swap.max value. Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15 ------------- Commit messages: - 8253727: [cgroups v2] Memory and swap limits reported incorrectly Changes: https://git.openjdk.java.net/jdk/pull/384/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=384&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253727 Stats: 33 lines in 3 files changed: 30 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/384/head:pull/384 PR: https://git.openjdk.java.net/jdk/pull/384 From sgehwolf at openjdk.java.net Mon Sep 28 17:34:54 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 28 Sep 2020 17:34:54 GMT Subject: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:06:22 GMT, Severin Gehwolf wrote: > Note that due to JDK-8253727 not all tests are passing with newer crun runtime (0.8 was last working for me). All cgroups v2 container tests pass with #384 and this one on `crun 0.15`. ------------- PR: https://git.openjdk.java.net/jdk/pull/381 From sgehwolf at openjdk.java.net Mon Sep 28 17:34:54 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 28 Sep 2020 17:34:54 GMT Subject: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high [v2] In-Reply-To: References: Message-ID: > Tests using `--memory-reservation` started to fail with newer `crun` cgroups v2-capable runtime. It turns out it was > incorrectly setting `memory.high` in an early version and got fixed to set `memory.low` now instead. This change > accounts for that. Severin Gehwolf 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: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/381/files - new: https://git.openjdk.java.net/jdk/pull/381/files/c3337bc6..25d131d8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=381&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=381&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/381.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/381/head:pull/381 PR: https://git.openjdk.java.net/jdk/pull/381 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 bobv at openjdk.java.net Mon Sep 28 17:44:36 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Mon, 28 Sep 2020 17:44:36 GMT Subject: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 17:34:54 GMT, Severin Gehwolf wrote: >> Tests using `--memory-reservation` started to fail with newer `crun` cgroups v2-capable runtime. It turns out it was >> incorrectly setting `memory.high` in an early version and got fixed to set `memory.low` now instead. This change >> accounts for that. > > Severin Gehwolf 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 bobv (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/381 From bobv at openjdk.java.net Mon Sep 28 17:44:36 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Mon, 28 Sep 2020 17:44:36 GMT Subject: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:00:57 GMT, Severin Gehwolf wrote: > @bobvandette Could you please take a look? Thanks! I just verified that using --memory-reservation using my crun version 0.11.42 does result in memory.low being set to the reservation value. ------------- PR: https://git.openjdk.java.net/jdk/pull/381 From brian.goetz at oracle.com Mon Sep 28 17:48:22 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 28 Sep 2020 13:48:22 -0400 Subject: 8251989: Unified Hex formatting and parsing utility In-Reply-To: References: <1BAC4282-314D-4009-B2F7-28B6FDACBA28@oracle.com> <465e58eb-a18e-5aa9-42ad-be5f41c67c8f@oracle.com> Message-ID: <2d6a44f3-a307-beba-deb7-48b26f7e1afa@oracle.com> Minor nit: ??? Appendable foo(Appendable bar) should be ??? A foo(A bar) That way, if you say ??? hex.formatHex(aStringBuilder, bytes) ?????? .foo() where foo() is a method on StringBuilder but not on Appendable, it will still work as expected. On 9/28/2020 11:32 AM, Roger Riggs wrote: > After some reflection on the comments, suggestions, and other advice > offered > the Hex format API has undergone a significant rewrite. > > The improvements include: > > ?- Merged format and parse classes into a single class HexFormat that > holds parameters and has methods for all conversions > ?- Simplified static factories and added builder methods to create > HexFormat copies with modified parameters. > ?- Consistent naming of methods for conversion of byte arrays to > formatted strings and back: formatHex and parseHex > ?- Consistent naming of methods for conversion of primitive types: > toHexDigits... and fromHexDigits... > ?- Prefix and suffixes now apply to each formatted value, not the > string as a whole > ?- Using java.util.Appendable as a target for buffered conversions so > output to Writers and PrintStreams > ?? like System.out are supported in addition to StringBuilder. > (IOExceptions are converted to unchecked exceptions) > > The HexFormat javadoc is at: > http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html > > > Thanks to all that commented and made suggestions on core-libs-dev and > privately. > > Please review and comment.? When the API has settled, I'll turn it > into a PR and CSR. > > Thanks, Roger > > > > > From alexander.matveev at oracle.com Mon Sep 28 18:02:21 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Mon, 28 Sep 2020 11:02:21 -0700 Subject: jpackage OS X codesign IOException In-Reply-To: <115D02D0-C38A-4AEE-ACBC-0A783CE93CDD@gmail.com> References: <115D02D0-C38A-4AEE-ACBC-0A783CE93CDD@gmail.com> Message-ID: <6931306c-934c-6be7-c167-7b53da004b7e@oracle.com> Hi Michael, jpackage should able to handle cases when runtime already signed. Can you provide example of command line you using for jpackage? Do you have anything else already signed (except runtime) in HalfPipe.app bundle? Thanks, Alexander On 9/26/20 3:37 PM, Michael Hall wrote: > >> On Sep 26, 2020, at 6:57 AM, Michael Hall wrote: >> >> java.io.IOException: Command [codesign, -s, Developer ID Application: XXXXX (XXXXX), -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage16414030388823297270/images/image-18070612222985031173/HalfPipe.app] exited with 1 code >> >> XXXXX values changed by me > With ?verbose > > Running [codesign, -s, Developer ID Application: Michael Hall (XXXXXXX), -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app] > /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app: is already signed > java.io.IOException: Command [codesign, -s, Developer ID Application: Michael Hall (XXXXXXXX), -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app] exited with 1 code > at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:73) > at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:179) > at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:150) > at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacAppImageBuilder.signAppBundle(MacAppImageBuilder.java:895) > ? > > jdk.incubator.jpackage.internal.PackagerException: java.io.IOException: Command [codesign, -s, Developer ID Application: Michael Hall (XXXXXXX), -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app] exited with 1 code > ? > > Caused by: java.io.IOException: Command [codesign, -s, Developer ID Application: Michael Hall (XXXXXXX), -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app] exited with 1 code > ? > > Skipping part of stack trace. Changing the id assigned me to XXXXXX again. Leaving my name, not exactly top secret I guess. I was wondering if there was a problem with the embedded blank in the name but that doesn?t seem to go with? > /HalfPipe.app: is already signed > > Many individual files appear to be successfully signed prior to that. > There is this, suggesting maybe some runtime signing has already been done? > > Running [codesign, -f, -s, Developer ID Application: Michael Hall (XXXXXXX), --prefix, us.hall.hp.common., -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app/Contents/runtime] > /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app/Contents/runtime: replacing existing signature > /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app/Contents/runtime: signed bundle with Mach-O thin (x86_64) [com.oracle.java.us.hall.HalfPipe] > Running [codesign, -s, Developer ID Application: Michael Hall (XXXXXXX), --prefix, us.hall.hp.common., -vvvv, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app/Contents/runtime/Contents/_CodeSignature/CodeResources] > /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/jdk.incubator.jpackage2558190777911372665/images/image-9969942555585608642/HalfPipe.app/Contents/runtime/Contents/_CodeSignature/CodeResources: signed generic [us.hall.hp.common.CodeResources] > > > > > From Alan.Bateman at oracle.com Mon Sep 28 18:36:46 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Sep 2020 19:36:46 +0100 Subject: 8251989: Unified Hex formatting and parsing utility In-Reply-To: <2d6a44f3-a307-beba-deb7-48b26f7e1afa@oracle.com> References: <1BAC4282-314D-4009-B2F7-28B6FDACBA28@oracle.com> <465e58eb-a18e-5aa9-42ad-be5f41c67c8f@oracle.com> <2d6a44f3-a307-beba-deb7-48b26f7e1afa@oracle.com> Message-ID: On 28/09/2020 18:48, Brian Goetz wrote: > Minor nit: > > ??? Appendable foo(Appendable bar) > > should be > > ??? A foo(A bar) > > That way, if you say > > ??? hex.formatHex(aStringBuilder, bytes) > ?????? .foo() > > where foo() is a method on StringBuilder but not on Appendable, it > will still work as expected. One other thing is the static method to create a HexFormat with a delimiter. Is it of(String) or ofDelimiter(String)? The class description says "of(delimiter)" and the examples use that form. The list of uses says its "ofDelimiter". -Alan 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 igraves at openjdk.java.net Mon Sep 28 19:18:27 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 28 Sep 2020 19:18:27 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy [v5] In-Reply-To: References: Message-ID: > These changes update the jlink plugin command line documentation to tidy them up into a more canonical form. > > The output generated by jlink from this change appears as follows: > >> build/macosx-x64/images/jdk/bin/jlink --list-plugins > > List of available plugins: > --add-options Prepend the specified string, which may > include whitespace, before any other options when > invoking the virtual machine in the resulting image. > --compress <0|1|2>[:filter=] > Compress all resources in the output image. > Level 0: No compression > Level 1: Constant string sharing > Level 2: ZIP. > An optional filter can be > specified to list the pattern of > files to be included. > --dedup-legal-notices [error-if-not-same-content] > De-duplicate all legal notices. > If error-if-not-same-content is specified then > it will be an error if two files of the same > filename are different. > --exclude-files > Specify files to exclude. > e.g.: **.java,glob:/java.base/lib/client/** > --exclude-jmod-section > Specify a JMOD section to exclude. > Where is "man" or "headers". > --exclude-resources > Specify resources to exclude. > e.g.: **.jcov,glob:**/META-INF/** > --generate-jli-classes @filename > Specify a file listing the java.lang.invoke > classes to pre-generate. By default, this plugin > may use a builtin list of classes to pre-generate. > If this plugin runs on a different runtime version > than the image being created then code generation > will be disabled by default to guarantee > correctness add ignore-version=true > to override this. > --include-locales [,]* > BCP 47 language tags separated by a comma, > allowing > locale matching defined in RFC 4647. > e.g.: en,ja,*-IN > --order-resources > Order resources. > e.g.: **/module-info.class, at classlist, > > --release-info |add:=:=:...|del: > option is to load release properties from > the supplied file. > add: is to add properties to the release file. > Any number of = pairs can be passed. > del: is to delete the list of keys in release file. > --strip-debug Strip debug information from the output image > --strip-java-debug-attributes > Strip Java debug attributes from > classes in the output image > --strip-native-commands Exclude native commands (such as java/java.exe) > from the image. > --system-modules retainModuleTarget > Fast loading of module descriptors (always enabled) > --vendor-bug-url > Override the vendor bug URL baked into the build. > The value of the system property > "java.vendor.url.bug" will be . > --vendor-version > Override the vendor version string baked into the > build,if any. The value of the system property > "java.vendor.version" will be . > --vendor-vm-bug-url > Override the vendor VM bug URL baked > into the build. The URL displayed in VM error > logs will be . > --vm > Select the HotSpot VM in the output image. > Default is all > > For options requiring a , the value will be a comma separated > list of elements each using one the following forms: > > glob: > regex: > @ where filename is the name of a file containing patterns to be > used, one pattern per line Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Additional usage narrowing ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/305/files - new: https://git.openjdk.java.net/jdk/pull/305/files/bd274acf..fe79b361 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=305&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=305&range=03-04 Stats: 27 lines in 1 file changed: 9 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/305/head:pull/305 PR: https://git.openjdk.java.net/jdk/pull/305 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 iignatyev at openjdk.java.net Mon Sep 28 19:53:14 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 28 Sep 2020 19:53:14 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures In-Reply-To: <8n8KvhWjyaRXASTq32-P5KXojlOFB2-JIvPTu88oJRg=.b32b5bd1-5ddc-43a6-bcf0-18b1bc24de26@github.com> References: <8n8KvhWjyaRXASTq32-P5KXojlOFB2-JIvPTu88oJRg=.b32b5bd1-5ddc-43a6-bcf0-18b1bc24de26@github.com> Message-ID: <4IaWMleIYgfWTF-WSCnPHVkUDs8EOInmn8zQlMdOkDM=.0f227f79-7419-4b29-a70a-778e11726968@github.com> On Thu, 10 Sep 2020 12:29:05 GMT, Evgeny Nikitin wrote: > Responding to the comments from pre-Skara thread: > > > test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java: > > I'd prefer invokeAndCompareArrays and invokeAndCheck to be as close as possible: have both of them to accept either > > boolean or Object as 2nd arg; print/throw the same error message > > the invokeAndCheck is very generic, it can be called with different objects and expect any kind of result, not only > boolean. Therefore its output format radically differs from what an array-comparator should show. I am not sure I understand what you mean... 1. granted you can't change `invokeAndCheck`'s 2nd argument to bool as there are other values being passed, but you can change `invokeAndCompareArrays` to accept an `Object` and compare expected and actual values by `Object::equals`. 2. even if you can't change output of these two methods to be the same (which I so far failed to see why), you still can change `invokeAndCheck`'s `message` var to include actual and expected values in the same way as `invokeAndCompareArrays` does. > > maybe I'm missing smth, but I don't understand why ArrayCodec supports only char and byte arrays; and hence I don't > > understand why you need ArrayCodec::of methods, as you can simply do new > > ArrayCoded(Arrays.stream(a).collect(Collectors.toList()) where a is an array of any type > > for Object arrays, one can use that. > for integer primitives one needs Arrays.stream(a).boxed.collect(Collectors.toList()), please note 'boxed' - it is > required and not generic. for bytes or chars, there is none (no overload methos in the Arrays.stream(a)); > To sum up, I can't see how with the given type system and utilities set I can make in a better, less wordy way. I've > added int and long overloads, support for String and Object arrays to make it more complete. you don't need `ArrayCodec::of(Object array)` anymore, do you? > > it seems that ArrayCodec should be an inner static class of ArrayDiff > > I would argue that - I find it useful for printing arrays (and this usage has been utilised in the > TestStringIntrinsics.java). In addition, I dont' like the practice of making such huge classes an inner classes as this > reduces readability and modularity. oki. > Other issues have been fixed. I added support for int, long, Object and String arrays. ------------- PR: https://git.openjdk.java.net/jdk/pull/112 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 iignatyev at openjdk.java.net Mon Sep 28 20:03:18 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 28 Sep 2020 20:03:18 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 12:20:05 GMT, Evgeny Nikitin wrote: > pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html) > > Error reporting was improved by writing a C-style escaped string representations for the variables passed to the > methods being tested. For array comparisons, a dedicated diff-formatter was implemented. > Sample output for comparing byte arrays (with artificial failure): > ----------System.err:(21/1553)---------- > Result: (false) of 'arrayEqualsB' is not equal to expected (true) > Arrays differ starting from [index: 7]: > ... 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... > ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... > ^^^^ > java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not > equal to expected (true) > at > compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273) > at ... stack trace continues - E.N. > Sample output for comparing char arrays: > ----------System.err:(21/1579)*---------- > Result: (false) of 'arrayEqualsC' is not equal to expected (true) > Arrays differ starting from [index: 7]: > ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ... > ... \\u0005, \\u0006, }, \\u0008, \\u0009, \\n, ... > ^^^^^^^ > java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not > equal to expected (true) > at > compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280) > at > ... and so on - E.N. > > testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx. Changes requested by iignatyev (Reviewer). test/lib-test/jdk/test/lib/format/ArrayDiffTest.java line 106: > 104: "[122]%n" + > 105: "[ 7, 8, 9, 10, 125, 12, 13]%n" + > 106: " ^^^"); as far as I remember, the commonly used practice is to align all these lines. (there are other places w/ the same "problem") test/lib/jdk/test/lib/format/ArrayCodec.java line 260: > 258: if (delta > 0) { > 259: element = Format.paddingForWidth(delta) + element; > 260: } wrong indent test/lib/jdk/test/lib/format/Format.java line 109: > 107: */ > 108: public static String paddingForWidth(int width) { > 109: return new String(" ").repeat(width); why not just? Suggestion: return " ".repeat(width); test/lib/jdk/test/lib/format/ArrayDiff.java line 83: > 81: public static class Defaults { > 82: final static int WIDTH = 80; > 83: final static int CONTEXT_BEFORE = 2; either these constants should be `public`, or `Defaults` class should be `package-private`, otherwise, you get a public class w/ no public fields. ------------- PR: https://git.openjdk.java.net/jdk/pull/112 From mcimadamore at openjdk.java.net Mon Sep 28 20:21:38 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 28 Sep 2020 20:21:38 GMT Subject: RFR: 8253590: java/foreign tests are still failing on x86_32 after foreign-memaccess integration Message-ID: This patch addresses a problem in a couple of tests for the foreign memory access API; we have two methods in the API, namely `MemorySegment::asByteBuffer` and `MemorySegment::toByteArray` which should throw an exception if invoked on a segment whose size is bigger than Integer.MAX_VALUE. The problem is that on 32-bits platform is not really possible to allocate a segment bigger than that; for that reason, at some point during 14 we "fixed" this by tweaking the test to allocate so much memory that the allocation itself would fail. When we integrated the latest API changes, this dubious fix was reverted, and now the tests have started misbehaving again. A much better solution is not to rely on allocation; the two tests should just create a synthetic segment using `MemorySegment::ofNativeRestricted`; this way we can test that the API throws when it should, w/o being impacted by what Unsafe does, or does not support on 32-bits platforms. ------------- Commit messages: - Improve robustness of memory access tests by not relying on platform allocation size limits Changes: https://git.openjdk.java.net/jdk/pull/386/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=386&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253590 Stats: 8 lines in 2 files changed: 2 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/386.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/386/head:pull/386 PR: https://git.openjdk.java.net/jdk/pull/386 From mcimadamore at openjdk.java.net Mon Sep 28 21:04:42 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 28 Sep 2020 21:04:42 GMT Subject: RFR: 8253590: java/foreign tests are still failing on x86_32 after foreign-memaccess integration [v2] In-Reply-To: References: Message-ID: > This patch addresses a problem in a couple of tests for the foreign memory access API; we have two methods in the API, > namely `MemorySegment::asByteBuffer` and `MemorySegment::toByteArray` which should throw an exception if invoked on a > segment whose size is bigger than Integer.MAX_VALUE. The problem is that on 32-bits platform is not really possible to > allocate a segment bigger than that; for that reason, at some point during 14 we "fixed" this by tweaking the test to > allocate so much memory that the allocation itself would fail. When we integrated the latest API changes, this dubious > fix was reverted, and now the tests have started misbehaving again. A much better solution is not to rely on > allocation; the two tests should just create a synthetic segment using `MemorySegment::ofNativeRestricted`; this way we > can test that the API throws when it should, w/o being impacted by what Unsafe does, or does not support on 32-bits > platforms. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Remove redundant expected exceptions from array test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/386/files - new: https://git.openjdk.java.net/jdk/pull/386/files/24985028..085d0401 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=386&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=386&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/386.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/386/head:pull/386 PR: https://git.openjdk.java.net/jdk/pull/386 From mchung at openjdk.java.net Mon Sep 28 23:08:04 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 28 Sep 2020 23:08:04 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy [v5] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 19:18:27 GMT, Ian Graves wrote: >> These changes update the jlink plugin command line documentation to tidy them up into a more canonical form. >> >> The output generated by jlink from this change appears as follows: >> >>> build/macosx-x64/images/jdk/bin/jlink --list-plugins >> >> List of available plugins: >> --add-options Prepend the specified string, which may >> include whitespace, before any other options when >> invoking the virtual machine in the resulting image. >> --compress <0|1|2>[:filter=] >> Compress all resources in the output image. >> Level 0: No compression >> Level 1: Constant string sharing >> Level 2: ZIP. >> An optional filter can be >> specified to list the pattern of >> files to be included. >> --dedup-legal-notices [error-if-not-same-content] >> De-duplicate all legal notices. >> If error-if-not-same-content is specified then >> it will be an error if two files of the same >> filename are different. >> --exclude-files >> Specify files to exclude. >> e.g.: **.java,glob:/java.base/lib/client/** >> --exclude-jmod-section >> Specify a JMOD section to exclude. >> Where is "man" or "headers". >> --exclude-resources >> Specify resources to exclude. >> e.g.: **.jcov,glob:**/META-INF/** >> --generate-jli-classes @filename >> Specify a file listing the java.lang.invoke >> classes to pre-generate. By default, this plugin >> may use a builtin list of classes to pre-generate. >> If this plugin runs on a different runtime version >> than the image being created then code generation >> will be disabled by default to guarantee >> correctness add ignore-version=true >> to override this. >> --include-locales [,]* >> BCP 47 language tags separated by a comma, >> allowing >> locale matching defined in RFC 4647. >> e.g.: en,ja,*-IN >> --order-resources >> Order resources. >> e.g.: **/module-info.class, at classlist, >> >> --release-info |add:=:=:...|del: >> option is to load release properties from >> the supplied file. >> add: is to add properties to the release file. >> Any number of = pairs can be passed. >> del: is to delete the list of keys in release file. >> --strip-debug Strip debug information from the output image >> --strip-java-debug-attributes >> Strip Java debug attributes from >> classes in the output image >> --strip-native-commands Exclude native commands (such as java/java.exe) >> from the image. >> --system-modules retainModuleTarget >> Fast loading of module descriptors (always enabled) >> --vendor-bug-url >> Override the vendor bug URL baked into the build. >> The value of the system property >> "java.vendor.url.bug" will be . >> --vendor-version >> Override the vendor version string baked into the >> build,if any. The value of the system property >> "java.vendor.version" will be . >> --vendor-vm-bug-url >> Override the vendor VM bug URL baked >> into the build. The URL displayed in VM error >> logs will be . >> --vm >> Select the HotSpot VM in the output image. >> Default is all >> >> For options requiring a , the value will be a comma separated >> list of elements each using one the following forms: >> >> glob: >> regex: >> @ where filename is the name of a file containing patterns to be >> used, one pattern per line > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Additional usage narrowing Looks good to me. It may be useful to have a regression test to verify the plugin order of the output if possible. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/305 From psandoz at openjdk.java.net Tue Sep 29 00:12:04 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 29 Sep 2020 00:12:04 GMT Subject: RFR: 8253590: java/foreign tests are still failing on x86_32 after foreign-memaccess integration [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 21:04:42 GMT, Maurizio Cimadamore wrote: >> This patch addresses a problem in a couple of tests for the foreign memory access API; we have two methods in the API, >> namely `MemorySegment::asByteBuffer` and `MemorySegment::toByteArray` which should throw an exception if invoked on a >> segment whose size is bigger than Integer.MAX_VALUE. The problem is that on 32-bits platform is not really possible to >> allocate a segment bigger than that; for that reason, at some point during 14 we "fixed" this by tweaking the test to >> allocate so much memory that the allocation itself would fail. When we integrated the latest API changes, this dubious >> fix was reverted, and now the tests have started misbehaving again. A much better solution is not to rely on >> allocation; the two tests should just create a synthetic segment using `MemorySegment::ofNativeRestricted`; this way we >> can test that the API throws when it should, w/o being impacted by what Unsafe does, or does not support on 32-bits >> platforms. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant expected exceptions from array test Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/386 From github.com+51754783+CoreyAshford at openjdk.java.net Tue Sep 29 00:53:59 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Tue, 29 Sep 2020 00:53:59 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:35:59 GMT, CoreyAshford wrote: > Can be reproduced by running JTREG tests: > compiler/aot/calls/fromAot I have tried reproducing this, but haven't yet succeeded. Here's how I'm running it from the jdk/test directory: `jtreg -jdk: ./hotspot/jtreg/compiler/aot/calls/fromAot` The response is this: Test results: no tests selected Report written to /home/cjashfor/git-trees/jdk/test/JTreport/html/report.html Results written to /home/cjashfor/git-trees/jdk/test/JTwork The report's Results sections shows "Total 0" Any ideas? I'm new to running JTReg tests, so don't assume I know anything :) ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From iignatyev at openjdk.java.net Tue Sep 29 01:27:43 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 29 Sep 2020 01:27:43 GMT Subject: RFR: 8253750: use build-stable default seed for Utils.RANDOM_GENERATOR Message-ID: Hi all, could you please review the patch which updates `jdk.test.lib.Utils` to use md5 hash-sum of `java.vm.version` property as default seed for `Utils.RANDOM_GENERATOR`? from JBS: > using the same seed for all runs of a build will make it possible (easier) to compare results from different test runs > (e.g. on different platforms, w/ different flags) and consequently will make test results analysis easier. the patch also updates `RandomGeneratorTest` test, so it expects now that the same values are generated if no seed is provided. testing: ? tier1 ------------- Commit messages: - 8253750: use build-stable default seed for Utils.RANDOM_GENERATOR Changes: https://git.openjdk.java.net/jdk/pull/391/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=391&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253750 Stats: 34 lines in 2 files changed: 26 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/391.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/391/head:pull/391 PR: https://git.openjdk.java.net/jdk/pull/391 From cstein at openjdk.java.net Tue Sep 29 05:45:10 2020 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 29 Sep 2020 05:45:10 GMT Subject: RFR: 8253761: Fix URI syntax of jar --describe-module Message-ID: This commit replaces `"/!"` with `"!/"` in order to generate valid URIs when printing a module description of a modular JAR file. A valid URI is described here: [1] https://bugs.openjdk.java.net/browse/JDK-8253761 [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/net/JarURLConnection.html ------------- Commit messages: - 8253761: Fix URI syntax of jar --describe-module Changes: https://git.openjdk.java.net/jdk/pull/393/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=393&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253761 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/393.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/393/head:pull/393 PR: https://git.openjdk.java.net/jdk/pull/393 From jbhateja at openjdk.java.net Tue Sep 29 06:05:53 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 29 Sep 2020 06:05:53 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v5] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 20:52:28 GMT, Vladimir Kozlov wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8252847 : Modifying file permission to resolve jcheck failure. > > test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyConjoint.java line 33: > >> 31: * >> 32: * @run main/othervm/timeout=600 -XX:-TieredCompilation -Xbatch -XX:+IgnoreUnrecognizedVMOptions >> 33: * -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:ArrayCopyPartialInlineSize=0 -XX:MaxVectorSize=32 -XX:+UnlockDiagnosticVMOptions > > ArrayCopyPartialInlineSize flag is not defiled in these changes. > It seems they need to be included in 8252848 changes. Hi @vnkozlov, I have updated the pull request to cover your comments. Kindly review. New RFE JDK-8253721 has been created for AVX3Threshold flag related changes (PR-394). ------------- PR: https://git.openjdk.java.net/jdk/pull/61 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 michaelm at openjdk.java.net Tue Sep 29 07:13:17 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 29 Sep 2020 07:13:17 GMT Subject: RFR: 8245194: Unix domain socket channel implementation In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 14:41:32 GMT, Michael McMahon wrote: >> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more >> iterations before integrating. >> On 06/09/2020 19:47, Alan Bateman wrote: >>> On 26/08/2020 15:24, Michael McMahon wrote: >>>> >>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >>>> think of that. >>>> >>>> There is a fair bit of other refactoring and simplification done also. Next version is at: >>>> >>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >>>> >>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the >>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved >>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a >>> number points that require clarification to fully understand how this will work with relative, directly relative and >>> drive relative paths. >>> >> >> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That >> would leave WindowsPath unchanged. >>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >>> to get the file path in bytes. >>> >> >> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to >> be useful by other components. >>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its >>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main >>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing). >> >> Okay, that does simplify it a bit. >> >> Thanks, >> Michael. >> >>> -Alan. >>> >>> >>> >>> >>> >>> > >> _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on >> [nio-dev](mailto:nio-dev at openjdk.java.net):_ >> On 07/09/2020 13:14, Michael McMahon wrote: >> >> > > In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >> > > method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >> > > to get the file path in bytes. >> > >> > >> > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to >> > be useful by other components. >> >> The file system provider shouldn't know anything about Unix domain >> sockets so I prefer not to have "UnixDomain" in the name of this method. >> I also would prefer if null is an exception so that it is consistent >> with the other methods. >> > > I'm not sure what to call the method then. It returns a UTF-8 string > converted to bytes on Windows and the output of getByteArrayForSysCalls on Unix. > It could be called getByteArrayUTF8 on Windows, but that would not > be right on Unix. > > Since sockets are file system entities, why not have socket in the method name? > > What about getByteArrayForSocket() ? > >> I think it would be useful to also summarize how the bind/connect works >> on Windows. For example, suppose the working directory is 240 characters >> and the UnixDomainSocketAddress is to a simple relative path of 20 >> characters. If I understand correctly, the proposal will encode the >> simple relative path (not the resolved absolute path) to bytes using >> UTF-8 so it will probably be 20+ bytes in this case. > > Right > >> This hould be okay >> but inconsistent with the rest of? file system implementation which will >> use the long form. Also if the name is long then it won't use the long >> path prefix (\?) but instead rely on failure because the resulting >> sequence of bytes when encoded is > 100, is that correct? >> > > Yes, that is how it is working currently. We check the length in native code > just before calling bind(). Whether the long path prefix is present or not > won't matter because the path will not be used once it is longer than ~100 bytes. > > Michael. >> -Alan. Hi Alan, Thanks for the comments. Assume all are accepted, except as queried below > _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on > [nio-dev](mailto:nio-dev at openjdk.java.net):_ > On 24/09/2020 13:17, Michael McMahon wrote: > I've pulled the latest commits from jdk/pull/55 and have another set of > comments. > > src/java.base/share/classes/sun/nio/ch/InetSocketChannelImpl.java > src/java.base/share/classes/sun/nio/ch/InetServerSocketChannelImpl.java > - class level comment is out dated after the split so should be updated > to make it clear that it for Inet implementations. > - the comment "End of field protected by stateLock" has been copied down > from ServerSocketChannelImpl.java and is confusing here so I think > should be removed. > - The existing convention is to declare the final fields at the top so > best to keep consistent after the split. > > src/java.base/share/classes/sun/net/ext/ExtendedSocketOptions.java > - the change to isStreamOption would be cleaned if the "SO_FLOW_SLA" > case is removed (I think it was missed by JDK-8244582). > > src/java.base/share/classes/sun/net/util/SocketExceptions.java > - it's a bit inconsistent for of(IOException, SocketAddress) to handle > InetSocketAddress types itself, it would be cleaner to handle both > address types or use two helper methods. > - Is the null check in ofUnixDomain left over from a previous iteration? > > src/java.base/share/classes/sun/nio/ch/SelectorProviderImpl.java > - it would be help to split the really long lines to keep it consistent > with the existing code > > src/java.base/share/classes/sun/nio/fs/AbstractFileSystemProvider.java > - it might be cleaner to rename the method to getSunPathForSocketFile. > It doesn't access the file so would be better not to throw IOException. > - for the description it might be clearer to say that it "Returns a path > name as bytes for ..." > > src/java.base/share/native/libnet/net_util.h > - are you sure that struct sockaddr_un is defined on all platforms, > including slightly older VC++ releases. struct sockaddr_un is declared in on Windows and on Unix. So, it is included via net_util_md.h I suspect the definition is only in fairly recent SDKs on Windows, and I'm not sure what I can do about that. If is present it will have the definition. If it's not present, then there will be a compile error, but I don't know how to tell if it is present.. > - the lines are a bit long here, inconsistent with the existing code. > > src/java.base/unix/classes/sun/nio/ch/UnixDomainHelper.java > - I think this should be removed and the method included in > UnixDomainSockets > - The hardcoding of /tmp and /var/tmp needs to be dropped too. We also > need to find a name name for jdk.nio.channels.tmpdir as this is specific > to Unix domain sockets. The problem here is that the Java impl of UnixDomainHelper is platform specific, but UnixDomainSockets is shared, but with platform specific native methods. If I make UnixDomainSockets.java platform specific then there will be a lot of duplication of code. Maybe we could pick a better name than UnixDomainHelper? As regards hard-coding of /tmp and /var/tmp, I think we need to be very careful to ensure that the directory name used to hold these automatically bound sockets is as short as possible. ${java.io.tmpdir} is sometimes long enough on our test systems to push the names over the ~100 byte limit. I don't see a good alternative to using /tmp or /var/tmp on Unix On Windows %TEMP% seems to be always defined and seems to always refer to a directory with a short name. What about "jdk.nio.unixdomain.tmpdir" for the property name? > - you can avoid the ugly cast by creating a PrivilegedAction and then > return doPrivileged(pa). > > src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java > - if you rename the parameter to obj and use UnixPath file = > UnixPath.toUnixPath(obj) then it will be consistent with the existing > code. It will also ensure that ProviderMismatchException is thrown. > > src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java > - this can use WindowsPath file = WindowsPath.toWindowsPathobj) > > src/java.base/windows/classes/sun/nio/ch/PipeImpl.java > src/java.base/windows/classes/sun/nio/ch/SinkChannelImpl.java > - I think the change to SinkChannelImpl.java should be dropped. Instead, > move the setting TCP_NODELAY to the PipeImpl constructor and it should > be a lot cleaner. It also means the "buffered" field is not needed. > - if you rename tryUnixDomain noUnixDomainSockets you avoid the > volatile-write at initialization time > - createListener would be a clean if the flag is checked before the > try/catch. > > src/java.base/windows/native/libnet/net_util_md.h > - what is the include of afunix.h needed, left over? > Explained above is Windows only. > src/java.base/windows/native/libnio/ch/Net.c > - are these changed needed? I would only checked localInetAddress and > remoteInetAddress to be called on file descriptor to inet sockets. > I had changed this file, but reverted all changes in the last version. I don't know why the webrev is still seeing changes. After this round, hopefully they will be gone. > src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java > src/jdk.net/macosx/classes/jdk/net/MacOSXSocketOptions.java > - IOUtil.makePipe return a long that encodes the two file descriptors > and may be simpler to avoid populating the int[] in JNI code. > > test/jdk/com/sun/nio/sctp/SctpServerChannel/NonBlockingAccept.java > - did you mean to change this test? > > test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/ConnectionPoolTest.java > - is this needed? > > I'm still working through new Unix* code and the tests so more comments > soon. > > -Alan Thanks for the review. I'm making the changes as described, except where noted above for further discussion. This should appear as a new webrev revision today. Michael ------------- PR: https://git.openjdk.java.net/jdk/pull/52 From plevart at openjdk.java.net Tue Sep 29 07:48:13 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 29 Sep 2020 07:48:13 GMT Subject: RFR: 8159746: (proxy) Support for default methods In-Reply-To: <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com> References: <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com> <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com> Message-ID: On Mon, 28 Sep 2020 16:57:16 GMT, Mandy Chung wrote: >> @AlanBateman you meant to say throwing CCE for mismatching parameter case would make it **inconsistent** with >> Method.invoke, right? That's easy to change. We just catch CCE (and NPE?) and re-throw them wrapped in IAE. We don't >> need to do that via MH combinators. Just directly in code. Performance will remain the same. > >> @AlanBateman you meant to say throwing CCE for mismatching parameter case would make it **inconsistent** with >> Method.invoke, right? That's easy to change. We just catch CCE (and NPE?) and re-throw them wrapped in IAE. We don't >> need to do that via MH combinators. Just directly in code. Performance will remain the same. > > Right, `Method::invoke` throws IAE (not CCE). So here's a patch on top of my last patch that reverts the exception behaviour back to be consistent with Method::invoke https://github.com/mlchung/jdk/pull/1 ------------- PR: https://git.openjdk.java.net/jdk/pull/313 From mdoerr at openjdk.java.net Tue Sep 29 08:59:45 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 29 Sep 2020 08:59:45 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 00:51:37 GMT, CoreyAshford wrote: >>> AOT support needs an update: >>> # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316 >>> # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock >>> >>> V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557) >>> V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603) >>> V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840) >>> V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55) >>> V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159) >>> V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133) >>> V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766) >>> V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037) >>> >>> Can be reproduced by running JTREG tests: >>> compiler/aot/calls/fromAot >> >> Thanks for catching that! Will fix on next round. > >> Can be reproduced by running JTREG tests: >> compiler/aot/calls/fromAot > > I have tried reproducing this, but haven't yet succeeded. Here's how I'm running it from the jdk/test directory: > > `jtreg -jdk: ./hotspot/jtreg/compiler/aot/calls/fromAot` > > The response is this: > > Test results: no tests selected > Report written to /home/cjashfor/git-trees/jdk/test/JTreport/html/report.html > Results written to /home/cjashfor/git-trees/jdk/test/JTwork > The report's Results sections shows "Total 0" > > Any ideas? I'm new to running JTReg tests, so don't assume I know anything :) Did you try on x86? AOT is not supported on PPC64. ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From michaelm at openjdk.java.net Tue Sep 29 09:00:02 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 29 Sep 2020 09:00:02 GMT Subject: RFR: 8245194: Unix domain socket channel implementation [v8] In-Reply-To: References: Message-ID: > Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >>> think of that. >>> >>> There is a fair bit of other refactoring and simplification done also. Next version is at: >>> >>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >>> >> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the >> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved >> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a >> number points that require clarification to fully understand how this will work with relative, directly relative and >> drive relative paths. >> > > Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That > would leave WindowsPath unchanged. >> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >> to get the file path in bytes. >> > > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to > be useful by other components. >> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its >> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main >> issue is that class is that it means we end up with two classes with static factory methods doing the same thing). > > Okay, that does simplify it a bit. > > Thanks, > Michael. > >> -Alan. >> >> >> >> >> >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: unixdomainchannels: Update after Alan's review of Sept 29 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/52/files - new: https://git.openjdk.java.net/jdk/pull/52/files/a08186d7..c669e2d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=06-07 Stats: 201 lines in 21 files changed: 60 ins; 61 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk/pull/52 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 michaelm at openjdk.java.net Tue Sep 29 09:24:38 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 29 Sep 2020 09:24:38 GMT Subject: RFR: 8245194: Unix domain socket channel implementation [v9] In-Reply-To: References: Message-ID: > Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >>> think of that. >>> >>> There is a fair bit of other refactoring and simplification done also. Next version is at: >>> >>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >>> >> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the >> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved >> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a >> number points that require clarification to fully understand how this will work with relative, directly relative and >> drive relative paths. >> > > Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That > would leave WindowsPath unchanged. >> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >> to get the file path in bytes. >> > > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to > be useful by other components. >> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its >> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main >> issue is that class is that it means we end up with two classes with static factory methods doing the same thing). > > Okay, that does simplify it a bit. > > Thanks, > Michael. > >> -Alan. >> >> >> >> >> >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: unixdomainchannels: typo in WindowsFileSystemProvider.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/52/files - new: https://git.openjdk.java.net/jdk/pull/52/files/c669e2d9..4dc90c78 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk/pull/52 From aph at openjdk.java.net Tue Sep 29 09:24:46 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 29 Sep 2020 09:24:46 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 06:03:57 GMT, Ard Biesheuvel wrote: >> @ardbiesheuvel : Ard, could you please ack this patch? Thanks. > > Acked-by: Ard Biesheuvel > If this feature is not auto-enabled when the SHA3 hardware feature is there, we will have one failure for the following > test: test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java > 15 #-----testresult----- > 16 > description=file:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java > 17 elapsed=31546 0:00:31.546 18 end=Mon Sep 21 10:27:58 CST 2020 > 19 environment=regtest > 20 execStatus=Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Option 'UseSHA3Intrinsics' is > expected to have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default > Any suggestions for this? I don't understand your question. There should be two acceptable results, either "Pass" or "Not supported". What else is possible? ------------- PR: https://git.openjdk.java.net/jdk/pull/207 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 mcimadamore at openjdk.java.net Tue Sep 29 09:43:00 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 29 Sep 2020 09:43:00 GMT Subject: Integrated: 8253590: java/foreign tests are still failing on x86_32 after foreign-memaccess integration In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 20:14:28 GMT, Maurizio Cimadamore wrote: > This patch addresses a problem in a couple of tests for the foreign memory access API; we have two methods in the API, > namely `MemorySegment::asByteBuffer` and `MemorySegment::toByteArray` which should throw an exception if invoked on a > segment whose size is bigger than Integer.MAX_VALUE. The problem is that on 32-bits platform is not really possible to > allocate a segment bigger than that; for that reason, at some point during 14 we "fixed" this by tweaking the test to > allocate so much memory that the allocation itself would fail. When we integrated the latest API changes, this dubious > fix was reverted, and now the tests have started misbehaving again. A much better solution is not to rely on > allocation; the two tests should just create a synthetic segment using `MemorySegment::ofNativeRestricted`; this way we > can test that the API throws when it should, w/o being impacted by what Unsafe does, or does not support on 32-bits > platforms. This pull request has now been integrated. Changeset: ebf443a1 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/ebf443a1 Stats: 10 lines in 2 files changed: 2 ins; 2 del; 6 mod 8253590: java/foreign tests are still failing on x86_32 after foreign-memaccess integration Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/386 From alanb at openjdk.java.net Tue Sep 29 10:01:06 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 29 Sep 2020 10:01:06 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy [v5] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 19:18:27 GMT, Ian Graves wrote: >> These changes update the jlink plugin command line documentation to tidy them up into a more canonical form. >> >> The output generated by jlink from this change appears as follows: >> >>> build/macosx-x64/images/jdk/bin/jlink --list-plugins >> >> List of available plugins: >> --add-options Prepend the specified string, which may >> include whitespace, before any other options when >> invoking the virtual machine in the resulting image. >> --compress <0|1|2>[:filter=] >> Compress all resources in the output image. >> Level 0: No compression >> Level 1: Constant string sharing >> Level 2: ZIP. >> An optional filter can be >> specified to list the pattern of >> files to be included. >> --dedup-legal-notices [error-if-not-same-content] >> De-duplicate all legal notices. >> If error-if-not-same-content is specified then >> it will be an error if two files of the same >> filename are different. >> --exclude-files >> Specify files to exclude. >> e.g.: **.java,glob:/java.base/lib/client/** >> --exclude-jmod-section >> Specify a JMOD section to exclude. >> Where is "man" or "headers". >> --exclude-resources >> Specify resources to exclude. >> e.g.: **.jcov,glob:**/META-INF/** >> --generate-jli-classes @filename >> Specify a file listing the java.lang.invoke >> classes to pre-generate. By default, this plugin >> may use a builtin list of classes to pre-generate. >> If this plugin runs on a different runtime version >> than the image being created then code generation >> will be disabled by default to guarantee >> correctness add ignore-version=true >> to override this. >> --include-locales [,]* >> BCP 47 language tags separated by a comma, >> allowing >> locale matching defined in RFC 4647. >> e.g.: en,ja,*-IN >> --order-resources >> Order resources. >> e.g.: **/module-info.class, at classlist, >> >> --release-info |add:=:=:...|del: >> option is to load release properties from >> the supplied file. >> add: is to add properties to the release file. >> Any number of = pairs can be passed. >> del: is to delete the list of keys in release file. >> --strip-debug Strip debug information from the output image >> --strip-java-debug-attributes >> Strip Java debug attributes from >> classes in the output image >> --strip-native-commands Exclude native commands (such as java/java.exe) >> from the image. >> --system-modules retainModuleTarget >> Fast loading of module descriptors (always enabled) >> --vendor-bug-url >> Override the vendor bug URL baked into the build. >> The value of the system property >> "java.vendor.url.bug" will be . >> --vendor-version >> Override the vendor version string baked into the >> build,if any. The value of the system property >> "java.vendor.version" will be . >> --vendor-vm-bug-url >> Override the vendor VM bug URL baked >> into the build. The URL displayed in VM error >> logs will be . >> --vm >> Select the HotSpot VM in the output image. >> Default is all >> >> For options requiring a , the value will be a comma separated >> list of elements each using one the following forms: >> >> glob: >> regex: >> @ where filename is the name of a file containing patterns to be >> used, one pattern per line > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Additional usage narrowing Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/305 From alanb at openjdk.java.net Tue Sep 29 10:01:06 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 29 Sep 2020 10:01:06 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy [v5] In-Reply-To: References: Message-ID: <0vV08rFxQMEKZVdl2DA9N4foJ4pvBSbV_zfkrH6u5Ng=.5efeaf08-cb41-47cc-ad8e-57cc95ac5f6d@github.com> On Mon, 28 Sep 2020 23:05:37 GMT, Mandy Chung wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Additional usage narrowing > > Looks good to me. It may be useful to have a regression test to verify the plugin order of the output if possible. The new AbstractPlugin and each of the implementations extending it look good. The new usages messages look good too. A few minor formatting nits in a few places but otherwise I think good to go. ------------- PR: https://git.openjdk.java.net/jdk/pull/305 From kim.barrett at oracle.com Tue Sep 29 10:51:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 06:51:15 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> Message-ID: > On Sep 28, 2020, at 11:13 AM, Eric Liu wrote: > > Hi, > > Thanks for looking at this. > > For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). > I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' > to replace 'strncpy'. > > > Thanks, > Eric I don't think using memory functions in place of string functions for string manipulation is really an improvement. I did a bit of experimenting. With gcc10.2, and using the --enable-asan configure option, we get a -Wstringop-truncation warning in CompilerCounters::set_current_method, even after careful adjustment of the code to use the documented idiom for avoiding that warning. I initially wondered whether this might be only in fastdebug builds, where we also define _FORTIFY_SOURCE=2. The asan faq https://github.com/google/sanitizers/wiki/AddressSanitizer#faq says asan doesn't work well with _FORTIFY_SOURCE. But the same warning occurs in a release build, where we aren't defining _FORTIFY_SOURCE. At this point all I can conclude is that --enable-asan (i.e. -fsanitize=address) is simply incompatible with -Wstringop-truncation, at least through gcc10. That seems like a bug that someone should report. (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) We don't normally build with -fsanitize=address; that's something that someone might want to turn on sometimes for testing or debugging, but I don't think we're planning to have it always on, even in debug builds. Since it seems to be incompatible with various other options that we *do* normally use, I think the way to allow --enable-asan to be (possibly) usable is in the build system at configure time. That is, the --enable-asan configure option should, in addition to adding -fsanitize=address, also (1) disable -Wstringop-truncation and (2) disable the defining of _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes involves conditionalizing their addition/removal using ${ASAN_ENABLED}. Scattering pragmas for disabling -Wstringop-truncation doesn't cut it. 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 sgehwolf at openjdk.java.net Tue Sep 29 11:16:56 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 29 Sep 2020 11:16:56 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v2] In-Reply-To: References: Message-ID: > Account for interface files for swap and memory being reported independently. > The cgroup v1-like value is now reported by adding the memory.max value to > the memory.swap.max value. > > Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15 Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Account for unlimited values in the test for memory.swap.max/memory.max ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/384/files - new: https://git.openjdk.java.net/jdk/pull/384/files/7dd62cfd..37a5979b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=384&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=384&range=00-01 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/384/head:pull/384 PR: https://git.openjdk.java.net/jdk/pull/384 From kim.barrett at oracle.com Tue Sep 29 11:17:50 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 07:17:50 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> Message-ID: <2E08727F-E790-4B7F-82EC-FAE9031C7E16@oracle.com> > On Sep 29, 2020, at 6:51 AM, Kim Barrett wrote: > >> On Sep 28, 2020, at 11:13 AM, Eric Liu wrote: >> >> Hi, >> >> Thanks for looking at this. >> >> For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). >> I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' >> to replace 'strncpy'. >> >> >> Thanks, >> Eric > > [?] > At this point all I can conclude is that --enable-asan (i.e. > -fsanitize=address) is simply incompatible with -Wstringop-truncation, at > least through gcc10. That seems like a bug that someone should report. > (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) > > [?] > > Since it seems to be incompatible with various other options that we *do* > normally use, I think the way to allow --enable-asan to be (possibly) usable > is in the build system at configure time. That is, the --enable-asan > configure option should, in addition to adding -fsanitize=address, also (1) > disable -Wstringop-truncation and (2) disable the defining of > _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes > involves conditionalizing their addition/removal using ${ASAN_ENABLED}. > > Scattering pragmas for disabling -Wstringop-truncation doesn't cut it. Another option might be to solve https://bugs.openjdk.java.net/browse/JDK-8232187 From sgehwolf at openjdk.java.net Tue Sep 29 11:19:45 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 29 Sep 2020 11:19:45 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly In-Reply-To: References: Message-ID: <5BbK1XDcEv4UExbyrtrAXbmMna6iLJ9K2vt_u_UP1R0=.60ad58fb-5ecf-47bd-a9e5-6222e237561b@github.com> On Mon, 28 Sep 2020 17:22:21 GMT, Severin Gehwolf wrote: > Account for interface files for swap and memory being reported independently. > The cgroup v1-like value is now reported by adding the memory.max value to > the memory.swap.max value. > > Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15 @bobvandette Could you please look at this as well? It would be much appreciated. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From jpai at openjdk.java.net Tue Sep 29 11:39:20 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 29 Sep 2020 11:39:20 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException [v2] In-Reply-To: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: > Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? > > As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds > the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This > is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is > larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the > `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent > this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the > necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which > reproduces the issue and verifies the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Address the review comments and introduce an array size check in JarFile.getBytes() method itself ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/323/files - new: https://git.openjdk.java.net/jdk/pull/323/files/76dcea76..279c7c83 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=323&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=323&range=00-01 Stats: 17 lines in 1 file changed: 10 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/323.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/323/head:pull/323 PR: https://git.openjdk.java.net/jdk/pull/323 From jpai at openjdk.java.net Tue Sep 29 11:47:58 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 29 Sep 2020 11:47:58 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException [v2] In-Reply-To: References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: <30rEkG2yhP3TeNWwtOgtebkVP9FhGLnhe5XCxLyfN5Y=.167dab69-401e-42b9-bf8d-094657df5bfb@github.com> On Thu, 24 Sep 2020 16:36:28 GMT, Brent Christian wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Address the review comments and introduce an array size check in JarFile.getBytes() method itself > > src/java.base/share/classes/java/util/jar/JarFile.java line 791: > >> 789: private byte[] getBytes(ZipEntry ze) throws IOException { >> 790: try (InputStream is = super.getInputStream(ze)) { >> 791: int len = (int)ze.getSize(); > > I think the main issue is the casting of the 'long' value from ZipEntry.getSize() into an 'int'. I think checking if > the size is > the maximum array size and throwing an OOME here might be a sufficient fix on its own. Hello Brent, Thank you for the review and sorry about the delayed response - I was involved in a few other things so couldn't get to this sooner. I have taken your input and updated this patch to address this part. Specifically, I have introduced a new `MAX_BUFFER_SIZE` within the `JarFile`. This `MAX_BUFFER_SIZE` is an actual copy of the field (and value) of `java.io.InputStream#MAX_BUFFER_SIZE`. I have done a minor change to the javadoc of this field as compared to what is in the javadoc of its `InputStream` counterpart. I did this so that the OOM exception message being thrown matches the comment in this javadoc (the `InputStream` has a mismatch in its javadoc and the actual message that gets thrown). Additionally, in this patch, the `if (len != -1 ...)` has been changed to `if (len >= 0 ...)` to prevent the code from entering this block when `Zip64` format is involved where (from what I can gather) an uncompressed entry size value can have 2^64 (unsigned) bytes. ------------- PR: https://git.openjdk.java.net/jdk/pull/323 From michaelm at openjdk.java.net Tue Sep 29 12:21:04 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 29 Sep 2020 12:21:04 GMT Subject: RFR: 8245194: Unix domain socket channel implementation [v10] In-Reply-To: References: Message-ID: > Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >>> think of that. >>> >>> There is a fair bit of other refactoring and simplification done also. Next version is at: >>> >>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >>> >> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the >> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved >> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a >> number points that require clarification to fully understand how this will work with relative, directly relative and >> drive relative paths. >> > > Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That > would leave WindowsPath unchanged. >> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >> to get the file path in bytes. >> > > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to > be useful by other components. >> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its >> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main >> issue is that class is that it means we end up with two classes with static factory methods doing the same thing). > > Okay, that does simplify it a bit. > > Thanks, > Michael. > >> -Alan. >> >> >> >> >> >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: unixdomainchannels: change to Net.c was missed after all ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/52/files - new: https://git.openjdk.java.net/jdk/pull/52/files/4dc90c78..3fe6baa4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=08-09 Stats: 12 lines in 1 file changed: 0 ins; 10 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk/pull/52 From jaroslav.tulach at oracle.com Tue Sep 29 12:31:38 2020 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Tue, 29 Sep 2020 14:31:38 +0200 Subject: Adding default methods in a 100% binary compatible way Message-ID: <2701352.NgBsaNRSFp@logwork> Hi. I took a part in a tweetting about incompatibilities related to `CharSequence.isEmpty()` over the weekend and Claes Redestad suggested I share a summary of my findings at this mailing list. I asked a simple question: Is it possible to add a default method in a 100% binary compatible way? The following post provides the answer: http://wiki.apidesign.org/wiki/BinaryCompatibleDefaultMethods I am sure almost everyone on this mailing list is aware of the individual observations made in my post. They are colloquially known. However it is not common to see them combined together as far as I can say. When I composed them, I got relatively surprising answer: Yes, adding default methods to interfaces in a 100% binary compatible way is possible at the end! Best regards. Jaroslav Tulach NetBeans Founder and initial architect Author of Practical API Design book OracleLabs From rrich at openjdk.java.net Tue Sep 29 13:56:47 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 29 Sep 2020 13:56:47 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v4] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request incrementally with five additional commits since the last revision: - EATests.java: bugfix to prevent ObjectCollectedException - Better encapsulation of JvmtiDeferredUpdates. Moved jvmtiDeferredLocalVariableSet to jvmtiDeferredUpdates.hpp - EscapeBarrier: moved method comments. - Shuffled parameters of EscapeBarrier constructors to better match each other - Moved class EscapeBarrier and class JvmtiDeferredUpdates into dedicated files. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/119/files - new: https://git.openjdk.java.net/jdk/pull/119/files/5bf631ba..c33cc4e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=02-03 Stats: 1385 lines in 18 files changed: 777 ins; 586 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Tue Sep 29 13:59:51 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 29 Sep 2020 13:59:51 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 12:28:13 GMT, Richard Reingruber wrote: >> The minor updates in response to my comments are fine. >> >> The more major updates ... I can't really comment on. > >> >> >> The minor updates in response to my comments are fine. >> >> The more major updates ... I can't really comment on. > > Thanks for looking at the changes and for giving feedback. Hi Serguei, thanks for providing feedback! I've pushed the changes based on it now but I have not yet merged master again. This needs a little work... Please find my replies to your comments below. Thanks, Richard. > Could you consider to place the classes EscapeBarrier and JvmtiDeferredUpdates > into theyr own .hpp/.cpp files? The class JvmtiDeferredUpdates would be better > to put into the folder 'prims' then. Done. In addition I moved preexisting class jvmtiDeferredLocalVariableSet and class jvmtiDeferredLocalVariable from runtime/vframe_hp.hpp to prims/jvmtiDeferredUpdates.hpp. Please let me know if not ok. > src/hotspot/share/opto/macro.cpp: > > ``` > @@ -1091,11 +1091,11 @@ > bool PhaseMacroExpand::eliminate_allocate_node(AllocateNode *alloc) { > // Don't do scalar replacement if the frame can be popped by JVMTI: > // if reallocation fails during deoptimization we'll pop all > // interpreter frames for this compiled frame and that won't play > // nice with JVMTI popframe. > - if (!EliminateAllocations || JvmtiExport::can_pop_frame() || !alloc->_is_non_escaping) { > + if (!EliminateAllocations || !alloc->_is_non_escaping) { > return false; > } > ``` > > I wonder if the comment is still correct after you removed the check for JvmtiExport::can_pop_frame(). Good catch. I fixed it previously with https://github.com/openjdk/jdk/pull/119/commits/18dd54b4e6f17ca723e4ae1a1e8dc57e81878dd3 > src/hotspot/share/runtime/deoptimization.hpp: > > ``` > + EscapeBarrier(JavaThread* calling_thread, JavaThread* deoptee_thread, bool barrier_active) > + : _calling_thread(calling_thread), _deoptee_thread(deoptee_thread), > + _barrier_active(barrier_active && (JVMCI_ONLY(UseJVMCICompiler) NOT_JVMCI(false) > + COMPILER2_PRESENT(|| DoEscapeAnalysis))) > . . . . . . . . . > + > + // Revert ea based optimizations for all java threads > + EscapeBarrier(JavaThread* calling_thread, bool barrier_active) > + : _calling_thread(calling_thread), _deoptee_thread(NULL), > ``` > > Nit: would better to make the parameter deoptee_thread to be the 3rd to better mach the seconf constructor. I have shuffled the parameters and moved barrier_active at first position. Would that be ok? > > ``` > + bool all_threads() const { return _deoptee_thread == NULL; } // Should revert optimizations for all > threads. + bool self_deopt() const { return _calling_thread == _deoptee_thread; } // Current thread deoptimizes > its own objects. + bool barrier_active() const { return _barrier_active; } // Inactive barriers are > created if no local objects can escape. ``` > > I'd suggest to put comments in a line before function definitions as it is done for other declarations/definitions. Done. // Note that there are quite a few locations with the comment on the same line ;) > src/hotspot/share/runtime/deoptimization.cpp: > > ``` > @@ -349,12 +408,12 @@ > > // Now that the vframeArray has been created if we have any deferred local writes > // added by jvmti then we can free up that structure as the data is now in the > // vframeArray > > - if (thread->deferred_locals() != NULL) { > - GrowableArray* list = thread->deferred_locals(); > + if (JvmtiDeferredUpdates::deferred_locals(thread) != NULL) { > + GrowableArray* list = JvmtiDeferredUpdates::deferred_locals(thread); > int i = 0; > do { > // Because of inlining we could have multiple vframes for a single frame > // and several of the vframes could have deferred writes. Find them all. > if (list->at(i)->id() == array->original().id()) { > > @@ -365,13 +424,14 @@ > } else { > i++; > } > } while ( i < list->length() ); > if (list->length() == 0) { > - thread->set_deferred_locals(NULL); > - // free the list and elements back to C heap. > - delete list; > + JvmtiDeferredUpdates* updates = thread->deferred_updates(); > + thread->set_deferred_updates(NULL); > + // free deferred updates. > + delete updates; > } > ``` > > It is not clear why the 'list' is not deleted anymore. If it is intentional then could you, please, add a comment with > an explanation? 'list' is now embedded in JvmtiDeferredUpdates. It es deleted as part of the JvmtiDeferredUpdates instance when there are no more deferred updates. class JvmtiDeferredUpdates : public CHeapObj { [...] // Deferred updates of locals, expressions, and monitors GrowableArray _deferred_locals_updates; [...] }; I introduced JvmtiDeferredUpdates because this patch introduces a new type of deferred update: _relock_count_after_wait. I tried to improve the encapsulation of class JvmtiDeferredUpdates and simplified the location you are referring to. So when is memory for deferred updates freed? (A) Deferred local variable updates are deleted when the compiled target frame is replaced with corresponding interpreter frames. See JvmtiDeferredUpdates::delete_updates_for_frame(). (B) A thread's JvmtiDeferredUpdates instance is deleted if all updates where delivered. All updates where delivered when JvmtiDeferredUpdates::count() returns 0. This is checked whenever updates are delivered. See call sites in JvmtiDeferredUpdates::delete_updates_for_frame() and JvmtiDeferredUpdates::get_and_reset_relock_count_after_wait(). (C) Besides (B) a thread's JvmtiDeferredUpdates instance is also deleted when the thread is destroyed. All not yet delivered updates are deleted then too. See JavaThread::~JavaThread() and JvmtiDeferredUpdates::~JvmtiDeferredUpdates(). > If you are okay to separate the EscapeBarrier class into its own hpp/cpp files > then the class EscapeBarrierSuspendHandshake is better to be colocated with > it. Done. > The below functions EscapeBarrier::sync_and_suspend_one() and do_thread() make a call to the set_obj_deopt_flag() which > seems to be a duplication. At least, it is not clear why this duplication exist and so, needs to be explained in a > comment. ``` > +void EscapeBarrier::sync_and_suspend_one() { > + assert(_calling_thread != NULL, "calling thread must not be NULL"); > + assert(_deoptee_thread != NULL, "deoptee thread must not be NULL"); > + assert(barrier_active(), "should not call"); > + > + // Sync with other threads that might be doing deoptimizations > + { > + // Need to switch to _thread_blocked for the wait() call > + ThreadBlockInVM tbivm(_calling_thread); > + MonitorLocker ml(_calling_thread, EscapeBarrier_lock, Mutex::_no_safepoint_check_flag); > + while (_self_deoptimization_in_progress || _deoptee_thread->is_obj_deopt_suspend()) { > + ml.wait(); > + } > + > + if (self_deopt()) { > + _self_deoptimization_in_progress = true; > + return; > + } > + > + // set suspend flag for target thread > + _deoptee_thread->set_obj_deopt_flag(); > + } > + > + // suspend target thread > + EscapeBarrierSuspendHandshake sh(NULL, "EscapeBarrierSuspendOne"); > + Handshake::execute_direct(&sh, _deoptee_thread); > + assert(!_deoptee_thread->has_last_Java_frame() || _deoptee_thread->frame_anchor()->walkable(), > + "stack should be walkable now"); > +} > . . . . . > +class EscapeBarrierSuspendHandshake : public HandshakeClosure { > + JavaThread* _excluded_thread; > + public: > + EscapeBarrierSuspendHandshake(JavaThread* excluded_thread, const char* name) : > + HandshakeClosure(name), > + _excluded_thread(excluded_thread) {} > + void do_thread(Thread* th) { > + if (th->is_Java_thread() && !th->is_hidden_from_external_view() && (th != _excluded_thread)) { > + th->set_obj_deopt_flag(); > + } > + } > +}; > ``` I previously removed the set_obj_deopt_flag() call from EscapeBarrierSuspendHandshake::do_thread() in [1]. For synchronization it is better to set_obj_deopt_flag() before the handshake (see comment in EscapeBarrier::sync_and_suspend_all()). [1] https://github.com/openjdk/jdk/pull/119/commits/18dd54b4e6f17ca723e4ae1a1e8dc57e81878dd3 > /src/hotspot/share/prims/jvmtiImpl.cpp: > > ``` > 421 // Constructor for non-object getter > 422 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type) > 423 : _thread(thread) > 424 , _calling_thread(NULL) > 425 , _depth(depth) > 426 , _index(index) > 427 , _type(type) > 428 , _jvf(NULL) > 429 , _set(false) > 430 , _eb(NULL, NULL, type == T_OBJECT) > 431 , _result(JVMTI_ERROR_NONE) > 432 { > 433 } > 434 > 435 // Constructor for object or non-object setter > 436 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type, jvalue value) > 437 : _thread(thread) > 438 , _calling_thread(NULL) > 439 , _depth(depth) > 440 , _index(index) > 441 , _type(type) > 442 , _value(value) > 443 , _jvf(NULL) > 444 , _set(true) > 445 , _eb(JavaThread::current(), thread, type == T_OBJECT) > 446 , _result(JVMTI_ERROR_NONE) > 447 { > 448 } > 449 > 450 // Constructor for object getter > 451 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, JavaThread* calling_thread, jint depth, int index) > 452 : _thread(thread) > 453 , _calling_thread(calling_thread) > 454 , _depth(depth) > 455 , _index(index) > 456 , _type(T_OBJECT) > 457 , _jvf(NULL) > 458 , _set(false) > 459 , _eb(calling_thread, thread, true) > 460 , _result(JVMTI_ERROR_NONE) > 461 { > 462 } > ``` > > I think, false has to be passed to the constructors of non-object getters instead of expression: > "type == T_OBJECT". > The type can not be T_OBJECT for non-object getters. I used to do that. Then I changed it because the c++ compiler can fold the comparison to "false" and if somebody changes the non-object getter to get objects too then it would still be correct. Let me know if you still think it is better to pass false. Maybe add an assertion type == T_OBJECT then? > Q: Is an EscapeBarrier useful if false is passed as the barrier_active parameter? The EscapeBarrier is not needed then. In the case of the non-object getter above I'd hope that most of the constructor/desctructor of EscapeBarrier is eliminated by the c++ compiler then. Besides the changes you suggested I have made a bugfix in test/jdk/com/sun/jdi/EATests.java to prevent ObjectCollectedException. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From jlahoda at openjdk.java.net Tue Sep 29 14:07:57 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 29 Sep 2020 14:07:57 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v6] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Fri, 25 Sep 2020 00:41:47 GMT, Vicente Romero wrote: >> Co-authored-by: Vicente Romero >> Co-authored-by: Harold Seigel >> Co-authored-by: Jonathan Gibbons >> Co-authored-by: Brian Goetz >> Co-authored-by: Maurizio Cimadamore >> Co-authored-by: Joe Darcy >> Co-authored-by: Chris Hegarty >> Co-authored-by: Jan Lahoda > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > adding missing changes to some tests Marked as reviewed by jlahoda (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From jlahoda at openjdk.java.net Tue Sep 29 14:07:57 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 29 Sep 2020 14:07:57 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> <0H-sMIm0mwGW2f2OxwAwMGBtxDf2BUf7ds3tGEgYXrc=.849aab2b-4cf3-49f7-8e49-ad1df75cb0bb@github.com> Message-ID: On Fri, 25 Sep 2020 15:47:30 GMT, Peter Levart wrote: >> [CSR: Record Classes](https://bugs.openjdk.java.net/browse/JDK-8253605) > > Hi @vicente-romero-oracle , note that besides tests, there is also a JMH benchmark that measures the performance of > records deserialization (org.openjdk.bench.java.io.RecordDeserialization) which forced us to modify the build procedure > for all benchmarks to include --enable-preview option in JDK 15 and backports (see > https://bugs.openjdk.java.net/browse/JDK-8248135). If you undo this change in JDK 16 then also the problem described in > https://bugs.openjdk.java.net/browse/JDK-8250669 and https://bugs.openjdk.java.net/browse/JDK-8248429 will disapear. > After that, perhaps undoing the same for JDK 15 and backports together with removing the benchmark is also possible to > resolve the issues in older releases as most developement will probably happen in JDK 16 then and so the need for > performance testing will mostly be needed in there. We still have to figure out how to enable having benchmarks for > preview features as in the future there most probably will be a need for that. Langtools code looks good to me. We probably can also remove the RECORDS entry from PreviewFeature.Feature. ------------- PR: https://git.openjdk.java.net/jdk/pull/290 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 adinn at openjdk.java.net Tue Sep 29 14:13:12 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 29 Sep 2020 14:13:12 GMT Subject: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high [v2] In-Reply-To: References: Message-ID: <6J36GkHW2lcFezGcVVgLwHJJeOveUsoJdPgqExAFw40=.94a29ae2-bad5-4b8c-9e6e-67af2e60eb66@github.com> On Mon, 28 Sep 2020 17:34:54 GMT, Severin Gehwolf wrote: >> Tests using `--memory-reservation` started to fail with newer `crun` cgroups v2-capable runtime. It turns out it was >> incorrectly setting `memory.high` in an early version and got fixed to set `memory.low` now instead. This change >> accounts for that. > > Severin Gehwolf 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. Looks fine to me, especially if Bob says it's ok. ------------- Marked as reviewed by adinn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/381 From rriggs at openjdk.java.net Tue Sep 29 14:23:29 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Sep 2020 14:23:29 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 14:04:19 GMT, Weijun Wang wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Small cleanups to javadoc and code > > Just some comments based on the output example. Are there any other comments or suggestions? ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From weijun at openjdk.java.net Tue Sep 29 14:29:59 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 29 Sep 2020 14:29:59 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:20:50 GMT, Roger Riggs wrote: >> Just some comments based on the output example. > > Are there any other comments or suggestions? Can you post an example output of that cert? What about indefinite length? (Ex: 0x24, (byte) 0x80, 4, 2, 'a', 'b', 4, 2, 'c', 'd', 0, 0) ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From sgehwolf at openjdk.java.net Tue Sep 29 14:42:15 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 29 Sep 2020 14:42:15 GMT Subject: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high [v2] In-Reply-To: <6J36GkHW2lcFezGcVVgLwHJJeOveUsoJdPgqExAFw40=.94a29ae2-bad5-4b8c-9e6e-67af2e60eb66@github.com> References: <6J36GkHW2lcFezGcVVgLwHJJeOveUsoJdPgqExAFw40=.94a29ae2-bad5-4b8c-9e6e-67af2e60eb66@github.com> Message-ID: <_VuSfXAc97_Xbyi1cJw8NC4HHniysvJfMog8M4LSOgU=.5fd671a4-4e0b-4bb1-9c4f-a4672479c388@github.com> On Tue, 29 Sep 2020 14:10:42 GMT, Andrew Dinn wrote: > Looks fine to me, especially if Bob says it's ok. Thanks for the review, Andrew! ------------- PR: https://git.openjdk.java.net/jdk/pull/381 From bobv at openjdk.java.net Tue Sep 29 14:43:58 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Tue, 29 Sep 2020 14:43:58 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 11:16:56 GMT, Severin Gehwolf wrote: >> Account for interface files for swap and memory being reported independently. >> The cgroup v1-like value is now reported by adding the memory.max value to >> the memory.swap.max value. >> >> Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15 > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Account for unlimited values in the test for memory.swap.max/memory.max > @bobvandette Could you please look at this as well? It would be much appreciated. Thanks! I made some comments before this most recent change. Did you see them? src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 168: > 166: char* mem_swp_limit_str = mem_swp_limit_val(); > 167: jlong swap_limit = limit_from_str(mem_swp_limit_str); > 168: if (swap_limit >= 0) { In the recent fix for JDK-8250984, we added support for systems that don't have swap accounting enabled. CgroupV2 currently has a bug where you can't even set memory limits in this config but assuming they will fix that, we might want to add that support for v2 now. If the memory.swap.max file is not avail, then we return whatever memory limit is. src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 170: > 168: if (swap_limit >= 0) { > 169: jlong memory_limit = read_memory_limit_in_bytes(); > 170: if (memory_limit == -1) { Shouldn't this be an assert. If swap limit is set, you need a memory limit set. src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java line 297: > 295: return swapLimit; > 296: } > 297: Do you have the same issue with getMemoryAndSwapUsage "memory.swap.current", where you have a to add memory usage + swap usage? I did a quick test and found that the memory.swap.current file does not appear to include memory usage. I set a memory and swap limit and memory.current was 3M but memory.swap.current was 0. If you apply the JDK-8250984 fix for v2, getMemoryAndSwapUsage will have to be fixed as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From sgehwolf at openjdk.java.net Tue Sep 29 14:50:40 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 29 Sep 2020 14:50:40 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:41:08 GMT, Bob Vandette wrote: > > @bobvandette Could you please look at this as well? It would be much appreciated. Thanks! > > I made some comments before this most recent change. Did you see them? @bobvandette No, unfortunately not. There should be a mailing list reply on the lists if there was anything public, but I don't see any here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069262.html Not sure what went wrong :-( ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From rriggs at openjdk.java.net Tue Sep 29 14:52:07 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Sep 2020 14:52:07 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:27:29 GMT, Weijun Wang wrote: >> Are there any other comments or suggestions? > > Can you post an example output of that cert? What about indefinite length? (Ex: 0x24, (byte) 0x80, 4, 2, 'a', 'b', 4, > 2, 'c', 'd', 0, 0) For your example the output is: 0000: 24 80 ; UNIVERSAL CONSTRUCTED OCTET STRING [INDEFINITE] 0002: 04 02 61 62 ; OCTET STRING [2] 'ab' 0006: 04 02 63 64 ; OCTET STRING [2] 'cd' 000a: 00 00 ; END-OF-CONTENT ``` It seems to have lost an indent, I'll take a look at that. ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From bobv at openjdk.java.net Tue Sep 29 14:53:43 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Tue, 29 Sep 2020 14:53:43 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:47:50 GMT, Severin Gehwolf wrote: > > > @bobvandette Could you please look at this as well? It would be much appreciated. Thanks! > > > > > > I made some comments before this most recent change. Did you see them? > > @bobvandette No, unfortunately not. There should be a mailing list reply on the lists if there was anything public, but > I don't see any here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069262.html > > Not sure what went wrong :-( I responded directly in the github page under "Files Changed" and annotated the source changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From sgehwolf at openjdk.java.net Tue Sep 29 15:07:32 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 29 Sep 2020 15:07:32 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 18:01:28 GMT, Bob Vandette wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Account for unlimited values in the test for memory.swap.max/memory.max > > src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 168: > >> 166: char* mem_swp_limit_str = mem_swp_limit_val(); >> 167: jlong swap_limit = limit_from_str(mem_swp_limit_str); >> 168: if (swap_limit >= 0) { > > In the recent fix for JDK-8250984, we added support for systems that don't have swap accounting enabled. CgroupV2 > currently has a bug where you can't even set memory limits in this config but assuming they will fix that, we might > want to add that support for v2 now. If the memory.swap.max file is not avail, then we return whatever memory limit is. Hmm, I'd prefer if we kept those two changes separate. This makes it easier to backport and makes intent more obvious. FWIW, I'd like to bring this to 15u. I've filed https://bugs.openjdk.java.net/browse/JDK-8253797 to track this. > src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 170: > >> 168: if (swap_limit >= 0) { >> 169: jlong memory_limit = read_memory_limit_in_bytes(); >> 170: if (memory_limit == -1) { > > Shouldn't this be an assert. If swap limit is set, you need a memory limit set. OK, fine with me. I'll fix it. > Do you have the same issue with getMemoryAndSwapUsage "memory.swap.current", where you have a to add memory usage + > swap usage? That's a good point. I'll fix that as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From sgehwolf at openjdk.java.net Tue Sep 29 15:07:31 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 29 Sep 2020 15:07:31 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:51:25 GMT, Bob Vandette wrote: > > > > @bobvandette Could you please look at this as well? It would be much appreciated. Thanks! > > > > > > > > > I made some comments before this most recent change. Did you see them? > > > > > > @bobvandette No, unfortunately not. There should be a mailing list reply on the lists if there was anything public, but > > I don't see any here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069262.html > > Not sure what went wrong :-( > > I responded directly in the github page under "Files Changed" and annotated the source changes. I see. If you did it as part of a "Review" and didn't finish the review, then it would only be visible to yourself (as a draft). "Add a single comment" option (or whatever it's called) shows up right away, AFAIK. ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From sgehwolf at openjdk.java.net Tue Sep 29 15:14:24 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 29 Sep 2020 15:14:24 GMT Subject: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high [v2] In-Reply-To: <_VuSfXAc97_Xbyi1cJw8NC4HHniysvJfMog8M4LSOgU=.5fd671a4-4e0b-4bb1-9c4f-a4672479c388@github.com> References: <6J36GkHW2lcFezGcVVgLwHJJeOveUsoJdPgqExAFw40=.94a29ae2-bad5-4b8c-9e6e-67af2e60eb66@github.com> <_VuSfXAc97_Xbyi1cJw8NC4HHniysvJfMog8M4LSOgU=.5fd671a4-4e0b-4bb1-9c4f-a4672479c388@github.com> Message-ID: On Tue, 29 Sep 2020 14:39:50 GMT, Severin Gehwolf wrote: >> Looks fine to me, especially if Bob says it's ok. > >> Looks fine to me, especially if Bob says it's ok. > > Thanks for the review, Andrew! The early implementation of cgroups v2 support was done with crun 0.8 and it contained a bug which set memory.high over memory.low when --memory-reservation was being used as a CLI option. This bug has been fixed in later crun versions, starting with crun 0.11. Use memory.low in OpenJDK as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/381 From bobv at openjdk.java.net Tue Sep 29 15:15:53 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Tue, 29 Sep 2020 15:15:53 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 15:00:43 GMT, Severin Gehwolf wrote: >> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 168: >> >>> 166: char* mem_swp_limit_str = mem_swp_limit_val(); >>> 167: jlong swap_limit = limit_from_str(mem_swp_limit_str); >>> 168: if (swap_limit >= 0) { >> >> In the recent fix for JDK-8250984, we added support for systems that don't have swap accounting enabled. CgroupV2 >> currently has a bug where you can't even set memory limits in this config but assuming they will fix that, we might >> want to add that support for v2 now. If the memory.swap.max file is not avail, then we return whatever memory limit is. > > Hmm, I'd prefer if we kept those two changes separate. This makes it easier to backport and makes intent more obvious. > FWIW, I'd like to bring this to 15u. I've filed https://bugs.openjdk.java.net/browse/JDK-8253797 to track this. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From sgehwolf at openjdk.java.net Tue Sep 29 15:18:58 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 29 Sep 2020 15:18:58 GMT Subject: Integrated: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 15:59:35 GMT, Severin Gehwolf wrote: > Tests using `--memory-reservation` started to fail with newer `crun` cgroups v2-capable runtime. It turns out it was > incorrectly setting `memory.high` in an early version and got fixed to set `memory.low` now instead. This change > accounts for that. This pull request has now been integrated. Changeset: ff6843ca Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/ff6843ca Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high The early implementation of cgroups v2 support was done with crun 0.8 and it contained a bug which set memory.high over memory.low when --memory-reservation was being used as a CLI option. This bug has been fixed in later crun versions, starting with crun 0.11. Use memory.low in OpenJDK as well. Reviewed-by: bobv, adinn ------------- PR: https://git.openjdk.java.net/jdk/pull/381 From jnimeh at openjdk.java.net Tue Sep 29 15:22:50 2020 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Tue, 29 Sep 2020 15:22:50 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:49:49 GMT, Roger Riggs wrote: >> Can you post an example output of that cert? What about indefinite length? (Ex: 0x24, (byte) 0x80, 4, 2, 'a', 'b', 4, >> 2, 'c', 'd', 0, 0) > > For your example the output is: > 0000: 24 80 ; UNIVERSAL CONSTRUCTED OCTET STRING [INDEFINITE] > 0002: 04 02 61 62 ; OCTET STRING [2] 'ab' > 0006: 04 02 63 64 ; OCTET STRING [2] 'cd' > 000a: 00 00 ; END-OF-CONTENT ``` > > It seems to have lost an indent, I'll take a look at that. Also in that last example, it seems to suggest that the second octet string is nested within the first one since it sits at a second indent layer. They are both primitives completely covered by their two byte values so shouldn't they sit at the same indentation level? Or is the indentation not there to suggest nested substructures and is more for separation between elements? Or is this what you mean by "lost an indent"? Also, should the end of content be at the same indentation level as the initial indefinite length encoding? ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From herrick at openjdk.java.net Tue Sep 29 15:57:01 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 29 Sep 2020 15:57:01 GMT Subject: RFR: 8253747: tools/jpackage/share/AppImagePackageTest.java fails with InstalledPackageSize: 0 Message-ID: 8253747: tools/jpackage/share/AppImagePackageTest.java fails with InstalledPackageSize: 0 Updated Debian code in test to get package size in BK, allowing for non-zero size less than 1KB ------------- Commit messages: - JDK-8253747: tools/jpackage/share/AppImagePackageTest.java fails with InstalledPackageSize: 0 - JDK-8253747: tools/jpackage/AppImagePackageTest.java fails Changes: https://git.openjdk.java.net/jdk/pull/404/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=404&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253747 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/404.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/404/head:pull/404 PR: https://git.openjdk.java.net/jdk/pull/404 From github.com+51754783+CoreyAshford at openjdk.java.net Tue Sep 29 16:42:03 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Tue, 29 Sep 2020 16:42:03 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com> On Tue, 29 Sep 2020 08:41:37 GMT, Martin Doerr wrote: > Did you try on x86? AOT is not supported on PPC64. I didn't. No wonder. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From vromero at openjdk.java.net Tue Sep 29 16:49:36 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 16:49:36 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v7] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > Co-authored-by: Vicente Romero > Co-authored-by: Harold Seigel > Co-authored-by: Jonathan Gibbons > Co-authored-by: Brian Goetz > Co-authored-by: Maurizio Cimadamore > Co-authored-by: Joe Darcy > Co-authored-by: Chris Hegarty > Co-authored-by: Jan Lahoda Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge branch 'JDK-8246774' of https://github.com/vicente-romero-oracle/jdk into JDK-8246774 - adding missing changes to some tests - Merge branch 'master' into JDK-8246774 - modifiying @since from 14 to 16 - Merge pull request #1 from ChrisHegarty/record-serial-tests Remove preview args from JDK tests - Remove preview args from ObjectMethodsTest - Remove preview args from record serialization tests - removing the javax.lang.model related code to be moved to a separate bug - 8246774: Record Classes (final) implementation Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Jonathan Gibbons Co-authored-by: Brian Goetz Co-authored-by: Maurizio Cimadamore Co-authored-by: Joe Darcy Co-authored-by: Chris Hegarty Co-authored-by: Jan Lahoda - adding missing changes to some tests - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d5be8294...482fedec ------------- Changes: https://git.openjdk.java.net/jdk/pull/290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=06 Stats: 535 lines in 109 files changed: 32 ins; 278 del; 225 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Tue Sep 29 17:10:34 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 17:10:34 GMT Subject: RFR: 8253455: Record Classes (final) javax.lang.model changes [v2] In-Reply-To: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> Message-ID: > Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort > to make records a final feature of the Java Language. The rest of the code has been published in > [PR#290](https://github.com/openjdk/jdk/pull/290) Thanks, > Vicente Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - adding reminder to remove RECORDS from PreviewFeature - Merge branch 'JDK-8253455' of https://github.com/vicente-romero-oracle/jdk into JDK-8253455 - 8253455: Record Classes (final) javax.lang.model changes Co-authored-by: Vicente Romero Co-authored-by: Joe Darcy - 8253455: Record Classes (final) javax.lang.model changes Co-authored-by: Vicente Romero Co-authored-by: Joe Darcy ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/291/files - new: https://git.openjdk.java.net/jdk/pull/291/files/4814f9e9..9b24af7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=00-01 Stats: 34575 lines in 777 files changed: 7972 ins; 24236 del; 2367 mod Patch: https://git.openjdk.java.net/jdk/pull/291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/291/head:pull/291 PR: https://git.openjdk.java.net/jdk/pull/291 From mchung at openjdk.java.net Tue Sep 29 17:25:05 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 29 Sep 2020 17:25:05 GMT Subject: RFR: 8159746: (proxy) Support for default methods In-Reply-To: References: <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com> <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com> Message-ID: On Tue, 29 Sep 2020 07:45:40 GMT, Peter Levart wrote: >>> @AlanBateman you meant to say throwing CCE for mismatching parameter case would make it **inconsistent** with >>> Method.invoke, right? That's easy to change. We just catch CCE (and NPE?) and re-throw them wrapped in IAE. We don't >>> need to do that via MH combinators. Just directly in code. Performance will remain the same. >> >> Right, `Method::invoke` throws IAE (not CCE). > > So here's a patch on top of my last patch that reverts the exception behaviour back to be consistent with Method::invoke > https://github.com/mlchung/jdk/pull/1 > So here's a patch on top of my last patch that reverts the exception behaviour back to be consistent with Method::invoke > [mlchung#1](https://github.com/mlchung/jdk/pull/1) Thanks Peter. Looks good in general with a couple of comments. You can push to my local branch once you make any change per the feedback. ------------- PR: https://git.openjdk.java.net/jdk/pull/313 From rriggs at openjdk.java.net Tue Sep 29 17:52:11 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Sep 2020 17:52:11 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v5] In-Reply-To: References: Message-ID: <3Kr8YyqwdaS2mhqkGNNEdNV5a0TXdDvDmtHrhIJ-0nc=.a4346874-bfe3-450e-94c3-1f61f82f6369@github.com> > # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1 formatter reads a stream and produces annotated output of the > tags, values, and structures. > When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized > with the hex formatted output. > > Small changes to HexPrinter are included to improve the output readability. > > > Example decoding of a .pem certificate: > SEQUENCE [910] > SEQUENCE [630] > CONTEXT cons 0 [3] > BYTE 2, > BYTE 3, > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > SEQUENCE [76] > SET [11] > SEQUENCE [9] > OBJECT ID [3] 2.5.4.6 (CountryName) > 'IN' > ... > SET [16] > SEQUENCE [14] > OBJECT ID [3] 2.5.4.3 (CommonName) > Client1 > SEQUENCE [30] > UTCTIME [13] '150526221718Z' > UTCTIME [13] '250523221718Z' > ... > SEQUENCE [290] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > NULL > BIT STRING [271] > CONTEXT cons 3 [123] > SEQUENCE [121] > SEQUENCE [9] > OBJECT ID [3] 2.5.29.19 (BasicConstraints) > OCTET STRING [2] > SEQUENCE [44] > OBJECT ID [9] 2.16.840.1.113730.1.13 > OCTET STRING [31] '..OpenSSL Generated Certificate' > SEQUENCE [29] > OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > OCTET STRING [22] > SEQUENCE [31] > OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > OCTET STRING [24] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > BIT STRING [257] > When used with the HexPrinter test utility, the formatting of the > hexadecimal values is selected with the parameters to HexPrinter. > > 0000: 30 82 03 8e ; SEQUENCE [910] > 0004: 30 82 02 76 ; SEQUENCE [630] > 0008: a0 03 ; CONTEXT cons 0 [3] > 000a: 02 01 02 ; BYTE 2, > 000d: 02 01 03 ; BYTE 3, > 0010: 30 0d ; SEQUENCE [13] > 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 001d: 05 00 ; NULL > 001f: 30 ; SEQUENCE [76] > 0020: 4c ; > 0021: 31 0b ; SET [11] > 0023: 30 09 ; SEQUENCE [9] > 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) > 002a: 13 02 49 4e ; 'IN' > > ... ... > > 005b: 31 10 ; SET [16] > 005d: 30 0e ; SEQUENCE [14] > 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) > 0060: 03 55 04 03 ; > 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 > 006d: 30 1e ; SEQUENCE [30] > 006f: 17 ; UTCTIME [13] '150526221718Z' > 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; > 007e: 17 0d ; UTCTIME [13] '250523221718Z' > 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; > > ... ... > > 00db: 30 82 01 22 ; SEQUENCE [290] > 00df: 30 ; SEQUENCE [13] > 00e0: 0d ; > 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > 00ec: 05 00 ; NULL > 00ee: 03 82 ; BIT STRING [271] > 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; > > ... > > 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; > 0200: 01 ; > 0201: a3 7b ; CONTEXT cons 3 [123] > 0203: 30 79 ; SEQUENCE [121] > 0205: 30 09 ; SEQUENCE [9] > 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) > 020c: 04 02 30 00 ; OCTET STRING [2] > 0210: 30 2c ; SEQUENCE [44] > 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 > 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated > Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; > 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; > 023e: 30 1d ; SEQUENCE [29] > 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] > 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; > 025d: 30 1f ; SEQUENCE [31] > 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > 0260: 03 55 1d 23 ; > 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] > 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ; NULL > 028d: 03 82 01 ; BIT STRING [257] > 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; > > ... > > 0390: 6d 94 ; Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Corrected reading of extended length bytes, depth of indefinite length tag-values, added test for indefinite length ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/268/files - new: https://git.openjdk.java.net/jdk/pull/268/files/25115595..91741d4a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=03-04 Stats: 21 lines in 2 files changed: 18 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/268/head:pull/268 PR: https://git.openjdk.java.net/jdk/pull/268 From sgehwolf at openjdk.java.net Tue Sep 29 18:22:40 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 29 Sep 2020 18:22:40 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v3] In-Reply-To: References: Message-ID: > Account for interface files for swap and memory being reported independently. > The cgroup v1-like value is now reported by adding the memory.max value to > the memory.swap.max value. > > Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15 Severin Gehwolf 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 one additional commit since the last revision: 8253727: [cgroups v2] Memory and swap limits reported incorrectly ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/384/files - new: https://git.openjdk.java.net/jdk/pull/384/files/37a5979b..380cd49e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=384&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=384&range=01-02 Stats: 2342 lines in 104 files changed: 1251 ins; 577 del; 514 mod Patch: https://git.openjdk.java.net/jdk/pull/384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/384/head:pull/384 PR: https://git.openjdk.java.net/jdk/pull/384 From sgehwolf at openjdk.java.net Tue Sep 29 18:22:40 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 29 Sep 2020 18:22:40 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v3] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:51:25 GMT, Bob Vandette wrote: >>> > @bobvandette Could you please look at this as well? It would be much appreciated. Thanks! >>> >>> I made some comments before this most recent change. Did you see them? >> >> @bobvandette No, unfortunately not. There should be a mailing list reply on the lists if there was anything public, but >> I don't see any here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069262.html >> >> Not sure what went wrong :-( > >> > > @bobvandette Could you please look at this as well? It would be much appreciated. Thanks! >> > >> > >> > I made some comments before this most recent change. Did you see them? >> >> @bobvandette No, unfortunately not. There should be a mailing list reply on the lists if there was anything public, but >> I don't see any here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069262.html >> >> Not sure what went wrong :-( > > I responded directly in the github page under "Files Changed" and annotated the source changes. @bobvandette How does the updated patch look to you? ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From vromero at openjdk.java.net Tue Sep 29 18:27:50 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 18:27:50 GMT Subject: RFR: 8253455: Record Classes (final) javax.lang.model changes [v3] In-Reply-To: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> Message-ID: <-AXqi1M883qgcJBJWxgsnsJwUYNWyVEI9h80oGdy1wA=.67c5c8f8-d8ba-4aab-9e70-5dbdeb578efb@github.com> > Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort > to make records a final feature of the Java Language. The rest of the code has been published in > [PR#290](https://github.com/openjdk/jdk/pull/290) Thanks, > Vicente Vicente Romero 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: adding reminder to remove RECORDS from PreviewFeature ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/291/files - new: https://git.openjdk.java.net/jdk/pull/291/files/9b24af7d..f0845f6f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/291/head:pull/291 PR: https://git.openjdk.java.net/jdk/pull/291 From sgehwolf at openjdk.java.net Tue Sep 29 18:29:47 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 29 Sep 2020 18:29:47 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v4] In-Reply-To: References: Message-ID: > Account for interface files for swap and memory being reported independently. > The cgroup v1-like value is now reported by adding the memory.max value to > the memory.swap.max value. > > Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15 Severin Gehwolf 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: 8253727: [cgroups v2] Memory and swap limits reported incorrectly ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/384/files - new: https://git.openjdk.java.net/jdk/pull/384/files/380cd49e..cc9b1087 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=384&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=384&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/384/head:pull/384 PR: https://git.openjdk.java.net/jdk/pull/384 From vromero at openjdk.java.net Tue Sep 29 18:34:07 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 18:34:07 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v8] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > Co-authored-by: Vicente Romero > Co-authored-by: Harold Seigel > Co-authored-by: Jonathan Gibbons > Co-authored-by: Brian Goetz > Co-authored-by: Maurizio Cimadamore > Co-authored-by: Joe Darcy > Co-authored-by: Chris Hegarty > Co-authored-by: Jan Lahoda Vicente Romero 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. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/482fedec..76e3d278 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=06-07 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From sverre.moe at gmail.com Tue Sep 29 18:41:30 2020 From: sverre.moe at gmail.com (Sverre Moe) Date: Tue, 29 Sep 2020 20:41:30 +0200 Subject: jpackage rpm bug Message-ID: I think I found a bug in jpackage. When using a resource directory with a desktop-file and a spec-file. The resulting RPM file will contain the desktop file, but its filename is wrong. It is adding the application name twice. Instead of "test-application.desktop" the RPM contains "test-application-test-application.desktop". I created a test application project on GitHub to demonstrate this problem. https://github.com/DJViking/test-application Running the gradle task createPackage will create an RPM with the desktop file. ~> export JAVA_HOME=/usr/java/jdk-14 ~> ./gradlew createPackage /Sverre From bobv at openjdk.java.net Tue Sep 29 19:03:11 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Tue, 29 Sep 2020 19:03:11 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v4] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 18:29:47 GMT, Severin Gehwolf wrote: >> Account for interface files for swap and memory being reported independently. >> The cgroup v1-like value is now reported by adding the memory.max value to >> the memory.swap.max value. >> >> Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15 > > Severin Gehwolf 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: > 8253727: [cgroups v2] Memory and swap limits reported incorrectly Marked as reviewed by bobv (Committer). test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java line 248: > 246: newVal = valSwap; > 247: } else { > 248: // ignore error values for valMemory, since the container runtime Add an assert?? ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From bobv at openjdk.java.net Tue Sep 29 19:03:12 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Tue, 29 Sep 2020 19:03:12 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v4] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:00:15 GMT, Bob Vandette wrote: >> Severin Gehwolf 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: >> 8253727: [cgroups v2] Memory and swap limits reported incorrectly > > test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java line 248: > >> 246: newVal = valSwap; >> 247: } else { >> 248: // ignore error values for valMemory, since the container runtime > > Add an assert?? Other than that nit, it looks fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From rriggs at openjdk.java.net Tue Sep 29 19:23:17 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Sep 2020 19:23:17 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: <6CuxYxb4ZJwX_sW3lyJ8dTFWvn8Aydb6JRCOh9KLGWU=.a06d3e9b-e5e2-4def-ab0a-22695681ce71@github.com> On Tue, 29 Sep 2020 15:20:13 GMT, Jamil Nimeh wrote: > Also in that last example, it seems to suggest that the second octet string is nested within the first one since it > sits at a second indent layer. They are both primitives completely covered by their two byte values so shouldn't they > sit at the same indentation level? Or is the indentation not there to suggest nested substructures and is more for > separation between elements? Or is this what you mean by "lost an indent"? Also, should the end of content be at the > same indentation level as the initial indefinite length encoding? Yes, all of the enclosed items should be at the same indent level. (A bug as it turns out). I chose to indent the END-OF-CONTENT line at the same level to terminate the list of tag-values at that level All of the items enclosed are at the same level. The updated output is: 0000: 24 80 ; UNIVERSAL CONSTRUCTED OCTET STRING [INDEFINITE] 0002: 04 02 61 62 ; OCTET STRING [2] 'ab' 0006: 04 02 63 64 ; OCTET STRING [2] 'cd' 000a: 00 00 ; END-OF-CONTENT ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From jnimeh at openjdk.java.net Tue Sep 29 19:38:21 2020 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Tue, 29 Sep 2020 19:38:21 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: <6CuxYxb4ZJwX_sW3lyJ8dTFWvn8Aydb6JRCOh9KLGWU=.a06d3e9b-e5e2-4def-ab0a-22695681ce71@github.com> References: <6CuxYxb4ZJwX_sW3lyJ8dTFWvn8Aydb6JRCOh9KLGWU=.a06d3e9b-e5e2-4def-ab0a-22695681ce71@github.com> Message-ID: On Tue, 29 Sep 2020 19:20:42 GMT, Roger Riggs wrote: >> Also in that last example, it seems to suggest that the second octet string is nested within the first one since it >> sits at a second indent layer. They are both primitives completely covered by their two byte values so shouldn't they >> sit at the same indentation level? Or is the indentation not there to suggest nested substructures and is more for >> separation between elements? Or is this what you mean by "lost an indent"? Also, should the end of content be at the >> same indentation level as the initial indefinite length encoding? > >> Also in that last example, it seems to suggest that the second octet string is nested within the first one since it >> sits at a second indent layer. They are both primitives completely covered by their two byte values so shouldn't they >> sit at the same indentation level? Or is the indentation not there to suggest nested substructures and is more for >> separation between elements? Or is this what you mean by "lost an indent"? Also, should the end of content be at the >> same indentation level as the initial indefinite length encoding? > > Yes, all of the enclosed items should be at the same indent level. (A bug as it turns out). > I chose to indent the END-OF-CONTENT line at the same level to terminate the list of tag-values at that level > All of the items enclosed are at the same level. > > The updated output is: > 0000: 24 80 ; UNIVERSAL CONSTRUCTED OCTET STRING [INDEFINITE] > 0002: 04 02 61 62 ; OCTET STRING [2] 'ab' > 0006: 04 02 63 64 ; OCTET STRING [2] 'cd' > 000a: 00 00 ; END-OF-CONTENT Regarding the end-of-content identifier, that looks good. Thanks for fixing the indentation for the right-side ASN.1 interpretation of the bytes. My only remaining question is whether the corresponding hex dumps on the left should match the indentation levels as well. I don't have a strong opinion either way on that one but if you're indenting for each element at the same nest level it seems like that could potentially chew up a lot of horizontal space. Was the extra indentation for the second octet string done for readability? ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From igraves at openjdk.java.net Tue Sep 29 19:40:56 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 29 Sep 2020 19:40:56 GMT Subject: RFR: 8204256: improve jlink error message to report unsupported class file format Message-ID: This pull request contains a change to facilitate better error messages in jlink for when jlink creates an image from jmod files that are unsupported by the runtime by being _too new_. The existing behavior supports modules that are too old via an error about a mismatched version. The solution to this problem is constrained by jlink's use of some specified behavior by java.lang.module.ModuleFinder. The solution in this PR is to subclass some existing exceptions internally as to signal to jlink more specific error conditions when attempting to find and open modules. ------------- Commit messages: - Handling error messages for unsupported module descriptor versions Changes: https://git.openjdk.java.net/jdk/pull/409/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=409&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8204256 Stats: 141 lines in 6 files changed: 120 ins; 1 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/409.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/409/head:pull/409 PR: https://git.openjdk.java.net/jdk/pull/409 From rriggs at openjdk.java.net Tue Sep 29 19:43:17 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Sep 2020 19:43:17 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: <6CuxYxb4ZJwX_sW3lyJ8dTFWvn8Aydb6JRCOh9KLGWU=.a06d3e9b-e5e2-4def-ab0a-22695681ce71@github.com> Message-ID: <4FF9K0RIVTb_RZYn3dOuuGchJeKY0Pgez8ZcILkc_YY=.0837a70f-0fa4-4a83-a755-517e7579757f@github.com> On Tue, 29 Sep 2020 19:35:42 GMT, Jamil Nimeh wrote: > Regarding the end-of-content identifier, that looks good. Thanks for fixing the indentation for the right-side ASN.1 > interpretation of the bytes. My only remaining question is whether the corresponding hex dumps on the left should match > the indentation levels as well. I don't have a strong opinion either way on that one but if you're indenting for each > element at the same nest level it seems like that could potentially chew up a lot of horizontal space. Was the extra > indentation for the second octet string done for readability? Max had requested the current offset of the byte values, so it was easy to see where each new value started and to keep the offsets on a modulo boundary. The formatter on the right is largely decoupled from the hex value tabular form on the left while keeping the correspondence between the formatted items and the bytes. ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From jnimeh at openjdk.java.net Tue Sep 29 19:47:00 2020 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Tue, 29 Sep 2020 19:47:00 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: <4FF9K0RIVTb_RZYn3dOuuGchJeKY0Pgez8ZcILkc_YY=.0837a70f-0fa4-4a83-a755-517e7579757f@github.com> References: <6CuxYxb4ZJwX_sW3lyJ8dTFWvn8Aydb6JRCOh9KLGWU=.a06d3e9b-e5e2-4def-ab0a-22695681ce71@github.com> <4FF9K0RIVTb_RZYn3dOuuGchJeKY0Pgez8ZcILkc_YY=.0837a70f-0fa4-4a83-a755-517e7579757f@github.com> Message-ID: <03h_NA3QgxQ5sUC6MuB5NBe6QLG7hWRtW1sR7U5Bib8=.9bb280e8-997f-4899-a14d-bd60ea3ce8e8@github.com> On Tue, 29 Sep 2020 19:40:46 GMT, Roger Riggs wrote: > > > > Regarding the end-of-content identifier, that looks good. Thanks for fixing the indentation for the right-side ASN.1 > > interpretation of the bytes. My only remaining question is whether the corresponding hex dumps on the left should match > > the indentation levels as well. I don't have a strong opinion either way on that one but if you're indenting for each > > element at the same nest level it seems like that could potentially chew up a lot of horizontal space. Was the extra > > indentation for the second octet string done for readability? > > Max had requested the current offset of the byte values, so it was easy to see where each new value started and to keep > the offsets on a modulo boundary. The formatter on the right is largely decoupled from the hex value tabular form on > the left while keeping the correspondence between the formatted items and the bytes. If you and Max find that better from a visual perspective then that works for me. Thanks for clarifying that. ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From bobv at openjdk.java.net Tue Sep 29 19:50:58 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Tue, 29 Sep 2020 19:50:58 GMT Subject: RFR: 8253476: TestUseContainerSupport.java fails on some Linux kernels =?UTF-8?B?dy9v4oCm?= In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 15:52:43 GMT, Harold Seigel wrote: > Please review this small change to remove "--memory 200m" option from TestUseContainerSupport.java. This can cause > test failures on systems where swap accounting is disabled. Marked as reviewed by bobv (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/303 From weijun at openjdk.java.net Tue Sep 29 19:53:54 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 29 Sep 2020 19:53:54 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v5] In-Reply-To: <3Kr8YyqwdaS2mhqkGNNEdNV5a0TXdDvDmtHrhIJ-0nc=.a4346874-bfe3-450e-94c3-1f61f82f6369@github.com> References: <3Kr8YyqwdaS2mhqkGNNEdNV5a0TXdDvDmtHrhIJ-0nc=.a4346874-bfe3-450e-94c3-1f61f82f6369@github.com> Message-ID: On Tue, 29 Sep 2020 17:52:11 GMT, Roger Riggs wrote: >> # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter >> >> Debugging functions that utilize ASN.1, DER, and BER encoded streams is >> difficult without test utilities to show the contents. >> The ASN.1 formatter reads a stream and produces annotated output of the >> tags, values, and structures. >> When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized >> with the hex formatted output. >> >> Small changes to HexPrinter are included to improve the output readability. >> >> >> Example decoding of a .pem certificate: >> SEQUENCE [910] >> SEQUENCE [630] >> CONTEXT cons 0 [3] >> BYTE 2, >> BYTE 3, >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> NULL >> SEQUENCE [76] >> SET [11] >> SEQUENCE [9] >> OBJECT ID [3] 2.5.4.6 (CountryName) >> 'IN' >> ... >> SET [16] >> SEQUENCE [14] >> OBJECT ID [3] 2.5.4.3 (CommonName) >> Client1 >> SEQUENCE [30] >> UTCTIME [13] '150526221718Z' >> UTCTIME [13] '250523221718Z' >> ... >> SEQUENCE [290] >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) >> NULL >> BIT STRING [271] >> CONTEXT cons 3 [123] >> SEQUENCE [121] >> SEQUENCE [9] >> OBJECT ID [3] 2.5.29.19 (BasicConstraints) >> OCTET STRING [2] >> SEQUENCE [44] >> OBJECT ID [9] 2.16.840.1.113730.1.13 >> OCTET STRING [31] '..OpenSSL Generated Certificate' >> SEQUENCE [29] >> OBJECT ID [3] 2.5.29.14 (SubjectKeyID) >> OCTET STRING [22] >> SEQUENCE [31] >> OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) >> OCTET STRING [24] >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> NULL >> BIT STRING [257] >> When used with the HexPrinter test utility, the formatting of the >> hexadecimal values is selected with the parameters to HexPrinter. >> >> 0000: 30 82 03 8e ; SEQUENCE [910] >> 0004: 30 82 02 76 ; SEQUENCE [630] >> 0008: a0 03 ; CONTEXT cons 0 [3] >> 000a: 02 01 02 ; BYTE 2, >> 000d: 02 01 03 ; BYTE 3, >> 0010: 30 0d ; SEQUENCE [13] >> 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> 001d: 05 00 ; NULL >> 001f: 30 ; SEQUENCE [76] >> 0020: 4c ; >> 0021: 31 0b ; SET [11] >> 0023: 30 09 ; SEQUENCE [9] >> 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) >> 002a: 13 02 49 4e ; 'IN' >> >> ... ... >> >> 005b: 31 10 ; SET [16] >> 005d: 30 0e ; SEQUENCE [14] >> 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) >> 0060: 03 55 04 03 ; >> 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 >> 006d: 30 1e ; SEQUENCE [30] >> 006f: 17 ; UTCTIME [13] '150526221718Z' >> 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; >> 007e: 17 0d ; UTCTIME [13] '250523221718Z' >> 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; >> >> ... ... >> >> 00db: 30 82 01 22 ; SEQUENCE [290] >> 00df: 30 ; SEQUENCE [13] >> 00e0: 0d ; >> 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) >> 00ec: 05 00 ; NULL >> 00ee: 03 82 ; BIT STRING [271] >> 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; >> >> ... >> >> 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; >> 0200: 01 ; >> 0201: a3 7b ; CONTEXT cons 3 [123] >> 0203: 30 79 ; SEQUENCE [121] >> 0205: 30 09 ; SEQUENCE [9] >> 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) >> 020c: 04 02 30 00 ; OCTET STRING [2] >> 0210: 30 2c ; SEQUENCE [44] >> 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 >> 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated >> Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; >> 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; >> 023e: 30 1d ; SEQUENCE [29] >> 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) >> 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] >> 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; >> 025d: 30 1f ; SEQUENCE [31] >> 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) >> 0260: 03 55 1d 23 ; >> 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] >> 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; >> 027e: 30 0d ; SEQUENCE [13] >> 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> 028b: 05 00 ; NULL >> 028d: 03 82 01 ; BIT STRING [257] >> 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; >> >> ... >> >> 0390: 6d 94 ; > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Corrected reading of extended length bytes, depth of indefinite length tag-values, added test for indefinite length LGTM. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/268 From bobv at openjdk.java.net Tue Sep 29 20:02:13 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Tue, 29 Sep 2020 20:02:13 GMT Subject: RFR: 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 15:52:43 GMT, Harold Seigel wrote: > Please review this small change to remove "--memory 200m" option from TestUseContainerSupport.java. This can cause > test failures on systems where swap accounting is disabled. Marked as reviewed by bobv (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/303 From coleenp at openjdk.java.net Tue Sep 29 20:02:13 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 29 Sep 2020 20:02:13 GMT Subject: RFR: 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 15:52:43 GMT, Harold Seigel wrote: > Please review this small change to remove "--memory 200m" option from TestUseContainerSupport.java. This can cause > test failures on systems where swap accounting is disabled. Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/303 From hseigel at openjdk.java.net Tue Sep 29 20:02:13 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 29 Sep 2020 20:02:13 GMT Subject: Integrated: 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities In-Reply-To: References: Message-ID: <98-B5_UGIrZgMaHOXvhStdjWYvkg4o-3TmUuDkMabns=.7f1a6ceb-7c2a-4d84-8c1c-f84a5692f59f@github.com> On Tue, 22 Sep 2020 15:52:43 GMT, Harold Seigel wrote: > Please review this small change to remove "--memory 200m" option from TestUseContainerSupport.java. This can cause > test failures on systems where swap accounting is disabled. This pull request has now been integrated. Changeset: 2fe0a5d7 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/2fe0a5d7 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities Reviewed-by: bobv, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/303 From bobv at openjdk.java.net Tue Sep 29 20:02:13 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Tue, 29 Sep 2020 20:02:13 GMT Subject: RFR: 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:57:14 GMT, Coleen Phillimore wrote: >> Please review this small change to remove "--memory 200m" option from TestUseContainerSupport.java. This can cause >> test failures on systems where swap accounting is disabled. > > Marked as reviewed by coleenp (Reviewer). Setting a 200MB container Limit when swap accounting is not enabled in the Kernel will cause a SEGV depending on how much RAM is available in the host. When we test with UseContainerSupport disabled and a container limit imposed by docker, the VM assumes it has all host memory available to it. The VM ergonomics will then assume it has a lot of memory and will potentially select a very large heap. When the heap is initialized, it will exceed the containers limit causing the SEGV. ------------- PR: https://git.openjdk.java.net/jdk/pull/303 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 igraves at openjdk.java.net Tue Sep 29 20:51:05 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 29 Sep 2020 20:51:05 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy [v6] In-Reply-To: References: Message-ID: > These changes update the jlink plugin command line documentation to tidy them up into a more canonical form. > > The output generated by jlink from this change appears as follows: > >> build/macosx-x64/images/jdk/bin/jlink --list-plugins > > List of available plugins: > --add-options Prepend the specified string, which may > include whitespace, before any other options when > invoking the virtual machine in the resulting image. > --compress <0|1|2>[:filter=] > Compress all resources in the output image. > Level 0: No compression > Level 1: Constant string sharing > Level 2: ZIP. > An optional filter can be > specified to list the pattern of > files to be included. > --dedup-legal-notices [error-if-not-same-content] > De-duplicate all legal notices. > If error-if-not-same-content is specified then > it will be an error if two files of the same > filename are different. > --exclude-files > Specify files to exclude. > e.g.: **.java,glob:/java.base/lib/client/** > --exclude-jmod-section > Specify a JMOD section to exclude. > Where is "man" or "headers". > --exclude-resources > Specify resources to exclude. > e.g.: **.jcov,glob:**/META-INF/** > --generate-jli-classes @filename > Specify a file listing the java.lang.invoke > classes to pre-generate. By default, this plugin > may use a builtin list of classes to pre-generate. > If this plugin runs on a different runtime version > than the image being created then code generation > will be disabled by default to guarantee > correctness add ignore-version=true > to override this. > --include-locales [,]* > BCP 47 language tags separated by a comma, > allowing > locale matching defined in RFC 4647. > e.g.: en,ja,*-IN > --order-resources > Order resources. > e.g.: **/module-info.class, at classlist, > > --release-info |add:=:=:...|del: > option is to load release properties from > the supplied file. > add: is to add properties to the release file. > Any number of = pairs can be passed. > del: is to delete the list of keys in release file. > --strip-debug Strip debug information from the output image > --strip-java-debug-attributes > Strip Java debug attributes from > classes in the output image > --strip-native-commands Exclude native commands (such as java/java.exe) > from the image. > --system-modules retainModuleTarget > Fast loading of module descriptors (always enabled) > --vendor-bug-url > Override the vendor bug URL baked into the build. > The value of the system property > "java.vendor.url.bug" will be . > --vendor-version > Override the vendor version string baked into the > build,if any. The value of the system property > "java.vendor.version" will be . > --vendor-vm-bug-url > Override the vendor VM bug URL baked > into the build. The URL displayed in VM error > logs will be . > --vm > Select the HotSpot VM in the output image. > Default is all > > For options requiring a , the value will be a comma separated > list of elements each using one the following forms: > > glob: > regex: > @ where filename is the name of a file containing patterns to be > used, one pattern per line Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Updating JLinkTest to assert alphabetical order on --list-plugins ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/305/files - new: https://git.openjdk.java.net/jdk/pull/305/files/fe79b361..5372b15c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=305&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=305&range=04-05 Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/305/head:pull/305 PR: https://git.openjdk.java.net/jdk/pull/305 From igraves at openjdk.java.net Tue Sep 29 20:51:06 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 29 Sep 2020 20:51:06 GMT Subject: RFR: 8218685: jlink --list-plugins needs to be readable and tidy [v5] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 09:58:41 GMT, Alan Bateman wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Additional usage narrowing > > Marked as reviewed by alanb (Reviewer). Updated JLinkTest to assert alphabetical order. With that I will /integrate . ------------- PR: https://git.openjdk.java.net/jdk/pull/305 From vromero at openjdk.java.net Tue Sep 29 21:18:33 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 21:18:33 GMT Subject: RFR: 8253455: Record Classes javax.lang.model changes [v4] In-Reply-To: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> Message-ID: > Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort > to make records a final feature of the Java Language. The rest of the code has been published in > [PR#290](https://github.com/openjdk/jdk/pull/290) Thanks, > Vicente Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: this test will be fixed in the patch for JDK-8246774 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/291/files - new: https://git.openjdk.java.net/jdk/pull/291/files/f0845f6f..aeb799ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=02-03 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/291/head:pull/291 PR: https://git.openjdk.java.net/jdk/pull/291 From igraves at openjdk.java.net Tue Sep 29 21:19:32 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 29 Sep 2020 21:19:32 GMT Subject: Integrated: 8218685: jlink --list-plugins needs to be readable and tidy In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 17:52:00 GMT, Ian Graves wrote: > These changes update the jlink plugin command line documentation to tidy them up into a more canonical form. > > The output generated by jlink from this change appears as follows: > >> build/macosx-x64/images/jdk/bin/jlink --list-plugins > > List of available plugins: > --add-options Prepend the specified string, which may > include whitespace, before any other options when > invoking the virtual machine in the resulting image. > --compress <0|1|2>[:filter=] > Compress all resources in the output image. > Level 0: No compression > Level 1: Constant string sharing > Level 2: ZIP. > An optional filter can be > specified to list the pattern of > files to be included. > --dedup-legal-notices [error-if-not-same-content] > De-duplicate all legal notices. > If error-if-not-same-content is specified then > it will be an error if two files of the same > filename are different. > --exclude-files > Specify files to exclude. > e.g.: **.java,glob:/java.base/lib/client/** > --exclude-jmod-section > Specify a JMOD section to exclude. > Where is "man" or "headers". > --exclude-resources > Specify resources to exclude. > e.g.: **.jcov,glob:**/META-INF/** > --generate-jli-classes @filename > Specify a file listing the java.lang.invoke > classes to pre-generate. By default, this plugin > may use a builtin list of classes to pre-generate. > If this plugin runs on a different runtime version > than the image being created then code generation > will be disabled by default to guarantee > correctness add ignore-version=true > to override this. > --include-locales [,]* > BCP 47 language tags separated by a comma, > allowing > locale matching defined in RFC 4647. > e.g.: en,ja,*-IN > --order-resources > Order resources. > e.g.: **/module-info.class, at classlist, > > --release-info |add:=:=:...|del: > option is to load release properties from > the supplied file. > add: is to add properties to the release file. > Any number of = pairs can be passed. > del: is to delete the list of keys in release file. > --strip-debug Strip debug information from the output image > --strip-java-debug-attributes > Strip Java debug attributes from > classes in the output image > --strip-native-commands Exclude native commands (such as java/java.exe) > from the image. > --system-modules retainModuleTarget > Fast loading of module descriptors (always enabled) > --vendor-bug-url > Override the vendor bug URL baked into the build. > The value of the system property > "java.vendor.url.bug" will be . > --vendor-version > Override the vendor version string baked into the > build,if any. The value of the system property > "java.vendor.version" will be . > --vendor-vm-bug-url > Override the vendor VM bug URL baked > into the build. The URL displayed in VM error > logs will be . > --vm > Select the HotSpot VM in the output image. > Default is all > > For options requiring a , the value will be a comma separated > list of elements each using one the following forms: > > glob: > regex: > @ where filename is the name of a file containing patterns to be > used, one pattern per line This pull request has now been integrated. Changeset: 8df3e72c Author: Ian Graves Committer: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/8df3e72c Stats: 711 lines in 32 files changed: 291 ins; 299 del; 121 mod 8218685: jlink --list-plugins needs to be readable and tidy Reviewed-by: mchung, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/305 From vromero at openjdk.java.net Tue Sep 29 21:37:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 21:37:58 GMT Subject: RFR: 8253455: Record Classes javax.lang.model changes [v5] In-Reply-To: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> Message-ID: > Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort > to make records a final feature of the Java Language. The rest of the code has been published in > [PR#290](https://github.com/openjdk/jdk/pull/290) Thanks, > Vicente Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: adding a comment to PreviewFeature.Feature ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/291/files - new: https://git.openjdk.java.net/jdk/pull/291/files/aeb799ff..f5682fc2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=03-04 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/291/head:pull/291 PR: https://git.openjdk.java.net/jdk/pull/291 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 valeriep at openjdk.java.net Tue Sep 29 22:25:24 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 22:25:24 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 09:22:25 GMT, Andrew Haley wrote: >> Acked-by: Ard Biesheuvel > >> If this feature is not auto-enabled when the SHA3 hardware feature is there, we will have one failure for the following >> test: test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java >> 15 #-----testresult----- >> 16 >> description=file:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java >> 17 elapsed=31546 0:00:31.546 18 end=Mon Sep 21 10:27:58 CST 2020 >> 19 environment=regtest >> 20 execStatus=Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Option 'UseSHA3Intrinsics' is >> expected to have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default >> Any suggestions for this? > > I don't understand your question. There should be two acceptable results, either "Pass" or "Not supported". What else > is possible? I have looked at the java security changes, i.e. src/java.base/share/classes/sun/security/provider/SHA3.java. It looks fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/207 From bpb at openjdk.java.net Tue Sep 29 22:26:23 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 29 Sep 2020 22:26:23 GMT Subject: RFR: JDK-8252937: Correct "no comment" warnings from javadoc in java.math =?UTF-8?B?4oCm?= Message-ID: Please review this simple change to clean up some warnings encountered when javadoc is run. ------------- Commit messages: - JDK-8252937: Correct "no comment" warnings from javadoc in java.math package Changes: https://git.openjdk.java.net/jdk/pull/415/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=415&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252937 Stats: 16 lines in 3 files changed: 12 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/415.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/415/head:pull/415 PR: https://git.openjdk.java.net/jdk/pull/415 From darcy at openjdk.java.net Tue Sep 29 22:31:10 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 29 Sep 2020 22:31:10 GMT Subject: RFR: JDK-8252937: Correct "no comment" warnings from javadoc in java.math =?UTF-8?B?4oCm?= In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 22:20:03 GMT, Brian Burkhalter wrote: > Please review this simple change to clean up some warnings encountered when javadoc is run. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/415 From almatvee at openjdk.java.net Tue Sep 29 22:39:15 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 29 Sep 2020 22:39:15 GMT Subject: RFR: 8253747: tools/jpackage/share/AppImagePackageTest.java fails with InstalledPackageSize: 0 In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 15:50:36 GMT, Andy Herrick wrote: > 8253747: tools/jpackage/share/AppImagePackageTest.java fails with InstalledPackageSize: 0 > Updated Debian code in test to get package size in BK, allowing for non-zero size less than 1KB Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/404 From andy.herrick at oracle.com Tue Sep 29 22:43:10 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 29 Sep 2020 18:43:10 -0400 Subject: jpackage rpm bug In-Reply-To: References: Message-ID: <0cc3e524-6d73-ce29-bcb5-8ddb2cd72d4c@oracle.com> I filed issue for this: https://bugs.openjdk.java.net/browse/JDK-8253826 and will look in it in the morning. /Andy On 9/29/2020 2:41 PM, Sverre Moe wrote: > When using a resource directory with a desktop-file and a spec-file. > The resulting RPM file will contain the desktop file, but its filename is > wrong. It is adding the application name twice. > > Instead of "test-application.desktop" the RPM contains > "test-application-test-application.desktop". > > I created a test application project on GitHub to demonstrate this problem. > https://github.com/DJViking/test-application > > Running the gradle task createPackage will create an RPM with the desktop > file. > ~> export JAVA_HOME=/usr/java/jdk-14 > ~> ./gradlew createPackage From rriggs at openjdk.java.net Tue Sep 29 22:49:24 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Sep 2020 22:49:24 GMT Subject: RFR: 8252937: Correct "no comment" warnings from javadoc in java.math package In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 22:20:03 GMT, Brian Burkhalter wrote: > Please review this simple change to clean up some warnings encountered when javadoc is run. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/415 From bpb at openjdk.java.net Tue Sep 29 22:49:24 2020 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 29 Sep 2020 22:49:24 GMT Subject: Integrated: 8252937: Correct "no comment" warnings from javadoc in java.math package In-Reply-To: References: Message-ID: <8MLhdmFeF3WUOzgpGqPgyF94e0zS_DFxS966CkQVOQQ=.f4c12835-a149-4581-9ec6-16e9c5a318bb@github.com> On Tue, 29 Sep 2020 22:20:03 GMT, Brian Burkhalter wrote: > Please review this simple change to clean up some warnings encountered when javadoc is run. This pull request has now been integrated. Changeset: 5310d858 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/5310d858 Stats: 16 lines in 3 files changed: 12 ins; 0 del; 4 mod 8252937: Correct "no comment" warnings from javadoc in java.math package Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/415 From sspitsyn at openjdk.java.net Wed Sep 30 00:08:44 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 30 Sep 2020 00:08:44 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v6] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Tue, 29 Sep 2020 14:05:27 GMT, Jan Lahoda wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> adding missing changes to some tests > > Marked as reviewed by jlahoda (Reviewer). The instrument tests update looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Wed Sep 30 00:21:20 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 30 Sep 2020 00:21:20 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v6] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Wed, 30 Sep 2020 00:06:19 GMT, Serguei Spitsyn wrote: >> Marked as reviewed by jlahoda (Reviewer). > > The instrument tests update looks good to me. @sspitsyn thanks for the review. Please add yourself as a reviewer ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Wed Sep 30 00:24:29 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 30 Sep 2020 00:24:29 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v6] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <9lpq7-8Hjtvui3jtyOxfKKRCGa1yObk5po4zn92Waog=.93761bb3-a0cc-4cd6-95a5-28d95c11012d@github.com> On Wed, 30 Sep 2020 00:18:17 GMT, Vicente Romero wrote: >> The instrument tests update looks good to me. > > @sspitsyn thanks for the review. Please add yourself as a reviewer @plevart interesting, but I think that I prefer to update those benchmarks in a follow-up patch in order to keep this patch as simple as possible. I will file a follow-up issue in JIRA and link it to JDK-8246774 ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From sspitsyn at openjdk.java.net Wed Sep 30 00:30:49 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 30 Sep 2020 00:30:49 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v8] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Tue, 29 Sep 2020 18:34:07 GMT, Vicente Romero wrote: >> Co-authored-by: Vicente Romero >> Co-authored-by: Harold Seigel >> Co-authored-by: Jonathan Gibbons >> Co-authored-by: Brian Goetz >> Co-authored-by: Maurizio Cimadamore >> Co-authored-by: Joe Darcy >> Co-authored-by: Chris Hegarty >> Co-authored-by: Jan Lahoda > > Vicente Romero 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 sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/290 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 weijun at openjdk.java.net Wed Sep 30 03:06:56 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 30 Sep 2020 03:06:56 GMT Subject: RFR: 8253829: Wrong length compared in SSPI bridge Message-ID: For two principals to be the same, they are either all "user at R", or one is "user" and the other is "user at R". The check here wants to fail early if the length are different. "l" is the whole length and "r" is the length of the name (without realm). The comparison should be reflective but there is a typo. For example, for "user at R" and "user", l1 = 6, l2 = 4, r1 = 4, r2 = 4, the check will succeed and the names are treated as different. This is not the expected behavior. No regression test because we don't support SSPI testing in the OpenJDK repo now. ------------- Commit messages: - 8253829: Wrong length compared in SSPI bridge Changes: https://git.openjdk.java.net/jdk/pull/419/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=419&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253829 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/419/head:pull/419 PR: https://git.openjdk.java.net/jdk/pull/419 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 iklam at openjdk.java.net Wed Sep 30 04:09:10 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 30 Sep 2020 04:09:10 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 17:52:24 GMT, Calvin Cheung wrote: > Following up on archiving lambda proxy classes in dynamic CDS archive > ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of > lambda proxy classes in static CDS archive. > When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved > during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will > be of the following format: > `@lambda-proxy: ` > > e.g. > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` > > When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above > `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool > indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool > entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index > and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. > During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not > found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> > IsCDSDumpingEnabled) is involved in the core-libs code.) > Testing: tiers 1,2,3,4. > > Performance results (javac on HelloWorld on linux-x64): > Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " > 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- > 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- > 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- > 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- > 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- > 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- > 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- > 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- > 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- > 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- > ============================================================ > 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- > instr delta = -161497801 -7.2542% > time delta = -24.722 ms -6.5951% I have reviewed a small part of the changes. Here are my initial comments src/hotspot/share/classfile/systemDictionaryShared.cpp line 336: > 334: > 335: static unsigned int dumptime_hash(Symbol* sym) { > 336: if (sym == NULL) { How about adding a comment "_invoked_name may be NULL"? src/hotspot/share/classfile/systemDictionaryShared.cpp line 2300: > 2298: > 2299: class ArchivedLambdaMirrorPatcher { > 2300: static void update(Klass* k) { I think ArchivedLambdaMirrorPatcher can be subclass of ArchivedMirrorPatcher. That way you can share the same code for ArchivedMirrorPatcher::update (you can make this a protected method). src/hotspot/share/classfile/systemDictionaryShared.cpp line 2242: > 2240: st->print_cr("Dynamic Shared Lambda Dictionary"); > 2241: SharedLambdaDictionaryPrinter ldp(st); > 2242: _dynamic_lambda_proxy_class_dictionary.iterate(&ldp); I think this function can be refactored, something like: SystemDictionaryShared::print_on(outputStream* st) { if (UseSharedSpaces) { print_on("", &_builtin_dictionary, &_unregistered_dictionary, &_lambda_proxy_class_dictionary); if (DynamicArchive::is_mapped()) { print_on("Dynamic ", &dynamic__builtin_dictionary, &_dynamic_unregistered_dictionary, &_dynamic_lambda_proxy_class_dictionary); } } } src/hotspot/share/classfile/systemDictionaryShared.cpp line 1984: > 1982: int compare_runtime_lambda_proxy_class_info(const RunTimeLambdaProxyClassNode& r1, > 1983: const RunTimeLambdaProxyClassNode& r2) { > 1984: ResourceMark rm; Is this function being used? ------------- PR: https://git.openjdk.java.net/jdk/pull/364 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 eric.c.liu at arm.com Wed Sep 30 07:30:49 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Wed, 30 Sep 2020 07:30:49 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> , Message-ID: Hi Kim, Thanks for your review. I tried to solve the problem with your suggestion, and have just one question. > On 29 September 2020 18:51 PM, Kim Barrett wrote: > I don't think using memory functions in place of string functions for string > manipulation is really an improvement. Yes, the original code has no problem basically but as you said asan seems incompatible with -Wstringop-truncation. Using 'memcpy' just a workaround. > I did a bit of experimenting. > > With gcc10.2, and using the --enable-asan configure option, we get a > -Wstringop-truncation warning in CompilerCounters::set_current_method, even > after careful adjustment of the code to use the documented idiom for > avoiding that warning. > > I initially wondered whether this might be only in fastdebug builds, where > we also define _FORTIFY_SOURCE=2.? The asan faq > https://github.com/google/sanitizers/wiki/AddressSanitizer#faq > says asan doesn't work well with _FORTIFY_SOURCE. > > But the same warning occurs in a release build, where we aren't defining > _FORTIFY_SOURCE. > At this point all I can conclude is that --enable-asan (i.e. > -fsanitize=address) is simply incompatible with -Wstringop-truncation, at > least through gcc10.? That seems like a bug that someone should report. > (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) > > We don't normally build with -fsanitize=address; that's something that > someone might want to turn on sometimes for testing or debugging, but I > don't think we're planning to have it always on, even in debug builds. > Since it seems to be incompatible with various other options that we *do* > normally use, I think the way to allow --enable-asan to be (possibly) usable > is in the build system at configure time. That is, the --enable-asan > configure option should, in addition to adding -fsanitize=address, also (1) > disable -Wstringop-truncation and (2) disable the defining of > _FORTIFY_SOURCE in fastdebug builds.? It looks like making those changes > involves conditionalizing their addition/removal using ${ASAN_ENABLED}. Disable -Wstringop-truncation seems more reasonable. Is that necessary to disable _FORTIFY_SOURCE in fastdebug? With gcc10.1, disable -Wstringop-truncation seems enough. I didn't test with fastdebug mode before, and now it has been tested in our internal both with release and fastdebug mode. Thanks, Eric From felix.yang at huawei.com Wed Sep 30 08:25:54 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 30 Sep 2020 08:25:54 +0000 Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: Hi, > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > retn at openjdk.java.net] On Behalf Of Andrew Haley > Sent: Tuesday, September 29, 2020 5:25 PM > To: core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; > hotspot-compiler-dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic > > On Thu, 17 Sep 2020 06:03:57 GMT, Ard Biesheuvel > wrote: > > >> @ardbiesheuvel : Ard, could you please ack this patch? Thanks. > > > > Acked-by: Ard Biesheuvel > > > If this feature is not auto-enabled when the SHA3 hardware feature is > > there, we will have one failure for the following > > test: > > test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOp > > tionOnSupportedCPU.java > > 15 #-----testresult----- > > 16 > > description=file:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler/ > > intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java > > 17 elapsed=31546 0:00:31.546 18 end=Mon Sep 21 10:27:58 CST 2020 > > 19 environment=regtest > > 20 execStatus=Failed. Execution failed: `main' threw exception: > > java.lang.AssertionError: Option 'UseSHA3Intrinsics' is expected to > > have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default > Any suggestions for this? > > I don't understand your question. There should be two acceptable results, > either "Pass" or "Not supported". What else is possible? This new test is similar to existing test cases in the same directory like: TestUseSHA256IntrinsicsOptionOnSupportedCPU.java Currently, we ran this new test using QEMU which supports the aarch64 SHA3 feature. This new test is expecting option 'UseSHA3Intrinsics' to be auto-enabled by the JVM when it detects the availability of SHA3 feature. But that was not satisfied since we explicitly disable this option even when SHA3 feature is available. + if (UseSHA && (_features & CPU_SHA3)) { + // Do not auto-enable UseSHA3Intrinsics until it has been fully tested on hardware + // if (FLAG_IS_DEFAULT(UseSHA3Intrinsics)) { + // FLAG_SET_DEFAULT(UseSHA3Intrinsics, true); + // } So I could thought of several choices: 1. Do not add this new test for now; 2. Keep this new test and add on extra requirement for it: @requires os.arch!="aarch64"; (We could remove this when UseSHA3Intrinsics has been fully tested on real hardware and thus could be auto-enabled.) 3. Auto-enable UseSHA3Intrinsics when SHA3 feature is available for now; Is there a better way? Thanks, Felix From felix.yang at huawei.com Wed Sep 30 08:28:13 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 30 Sep 2020 08:28:13 +0000 Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: Hi, > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-retn at openjdk.java.net] On Behalf > Of Valerie Peng > Sent: Wednesday, September 30, 2020 6:25 AM > To: core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; > hotspot-compiler-dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic > > On Tue, 29 Sep 2020 09:22:25 GMT, Andrew Haley > wrote: > > >> Acked-by: Ard Biesheuvel > > > >> If this feature is not auto-enabled when the SHA3 hardware feature is > >> there, we will have one failure for the following > >> test: > >> test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsO > >> ptionOnSupportedCPU.java > >> 15 #-----testresult----- > >> 16 > >> description=file:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler > >> /intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java > >> 17 elapsed=31546 0:00:31.546 18 end=Mon Sep 21 10:27:58 CST 2020 > >> 19 environment=regtest > >> 20 execStatus=Failed. Execution failed: `main' threw exception: > >> java.lang.AssertionError: Option 'UseSHA3Intrinsics' is expected to > >> have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default > Any suggestions for this? > > > > I don't understand your question. There should be two acceptable > > results, either "Pass" or "Not supported". What else is possible? > > I have looked at the java security changes, i.e. > src/java.base/share/classes/sun/security/provider/SHA3.java. It looks fine. Thanks for reviewing this part. Best Regards, Felix From chegar at openjdk.java.net Wed Sep 30 08:56:38 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 30 Sep 2020 08:56:38 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Wed, 23 Sep 2020 08:54:57 GMT, Chris Hegarty wrote: >> Vicente Romero has updated the pull request incrementally with three additional commits since the last revision: >> >> - Merge pull request #1 from ChrisHegarty/record-serial-tests >> >> Remove preview args from JDK tests >> - Remove preview args from ObjectMethodsTest >> - Remove preview args from record serialization tests > > test/langtools/tools/javac/records/LocalStaticDeclarations.java line 33: > >> 31: * jdk.compiler/com.sun.tools.javac.util >> 32: * @build combo.ComboTestHelper >> 33: * @compile LocalStaticDeclarations.java > > This, and other, explicit at compile tags could be elided, no? The test source file will be implicitly compiled by the > at run tag. I believe that the explicit at compile tag was added original so that the enable preview and source version > options could be passed to javac - neither of which are needed any more. Does this test need an @run tag rather than an @compile tag ? ( the @run with implicitly compile the source file, before running it ) ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From chegar at openjdk.java.net Wed Sep 30 08:56:37 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 30 Sep 2020 08:56:37 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Wed, 23 Sep 2020 03:34:29 GMT, Vicente Romero wrote: >> Co-authored-by: Vicente Romero >> Co-authored-by: Harold Seigel >> Co-authored-by: Jonathan Gibbons >> Co-authored-by: Brian Goetz >> Co-authored-by: Maurizio Cimadamore >> Co-authored-by: Joe Darcy >> Co-authored-by: Chris Hegarty >> Co-authored-by: Jan Lahoda > > Vicente Romero has updated the pull request incrementally with three additional commits since the last revision: > > - Merge pull request #1 from ChrisHegarty/record-serial-tests > > Remove preview args from JDK tests > - Remove preview args from ObjectMethodsTest > - Remove preview args from record serialization tests Marked as reviewed by chegar (Reviewer). test/langtools/tools/javac/records/LocalStaticDeclarations.java line 33: > 31: * jdk.compiler/com.sun.tools.javac.util > 32: * @build combo.ComboTestHelper > 33: * @compile LocalStaticDeclarations.java This, and other, explicit at compile tags could be elided, no? The test source file will be implicitly compiled by the at run tag. I believe that the explicit at compile tag was added original so that the enable preview and source version options could be passed to javac - neither of which are needed any more. ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From chegar at openjdk.java.net Wed Sep 30 09:00:06 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 30 Sep 2020 09:00:06 GMT Subject: RFR: 8253455: Record Classes javax.lang.model changes [v5] In-Reply-To: References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> Message-ID: On Tue, 29 Sep 2020 21:37:58 GMT, Vicente Romero wrote: >> Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort >> to make records a final feature of the Java Language. The rest of the code has been published in >> [PR#290](https://github.com/openjdk/jdk/pull/290) Thanks, >> Vicente > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > adding a comment to PreviewFeature.Feature src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 114: > 112: /** > 113: * A record type. > 114: * @since 14 The `@since` tags will all need to be updated to `16`, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/291 From sgehwolf at openjdk.java.net Wed Sep 30 09:37:41 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 30 Sep 2020 09:37:41 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v5] In-Reply-To: References: Message-ID: > Account for interface files for swap and memory being reported independently. > The cgroup v1-like value is now reported by adding the memory.max value to > the memory.swap.max value. > > Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15 Severin Gehwolf 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: 8253727: [cgroups v2] Memory and swap limits reported incorrectly ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/384/files - new: https://git.openjdk.java.net/jdk/pull/384/files/cc9b1087..f4c8678f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=384&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=384&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/384/head:pull/384 PR: https://git.openjdk.java.net/jdk/pull/384 From sgehwolf at openjdk.java.net Wed Sep 30 09:37:42 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 30 Sep 2020 09:37:42 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v4] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:00:43 GMT, Bob Vandette wrote: >> test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java line 248: >> >>> 246: newVal = valSwap; >>> 247: } else { >>> 248: // ignore error values for valMemory, since the container runtime >> >> Add an assert?? > > Other than that nit, it looks fine. It's now an assert. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From michaelm at openjdk.java.net Wed Sep 30 09:40:14 2020 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 30 Sep 2020 09:40:14 GMT Subject: RFR: 8245194: Unix domain socket channel implementation [v11] In-Reply-To: References: Message-ID: > Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, >>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you >>> think of that. >>> >>> There is a fair bit of other refactoring and simplification done also. Next version is at: >>> >>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/ >>> >> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the >> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved >> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a >> number points that require clarification to fully understand how this will work with relative, directly relative and >> drive relative paths. >> > > Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That > would leave WindowsPath unchanged. >> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a >> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place >> to get the file path in bytes. >> > > Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to > be useful by other components. >> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its >> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main >> issue is that class is that it means we end up with two classes with static factory methods doing the same thing). > > Okay, that does simplify it a bit. > > Thanks, > Michael. > >> -Alan. >> >> >> >> >> >> Michael McMahon 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 13 additional commits since the last revision: - Merge branch 'master' into unixdomainchannels - unixdomainchannels: remove more cruft from Windows Net.c - unixdomainchannels: change to Net.c was missed after all - unixdomainchannels: typo in WindowsFileSystemProvider.java - unixdomainchannels: Update after Alan's review of Sept 29 - Merge branch 'master' into unixdomainchannels - unixdomainchannels: some tests were failing on Windows version prior to 10/2019 - unixdomainchannels: updates after comments sent by Alan 14 Sept - unixdomainchannels: updates from review of Sept 11 2020 - Merge branch 'master' into unixdomainchannels - ... and 3 more: https://git.openjdk.java.net/jdk/compare/39516fa7...c40d2059 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/52/files - new: https://git.openjdk.java.net/jdk/pull/52/files/3fe6baa4..c40d2059 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=09-10 Stats: 30349 lines in 734 files changed: 5895 ins; 22231 del; 2223 mod Patch: https://git.openjdk.java.net/jdk/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk/pull/52 From sgehwolf at openjdk.java.net Wed Sep 30 10:10:38 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 30 Sep 2020 10:10:38 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v4] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:00:57 GMT, Bob Vandette wrote: >> Severin Gehwolf 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 bobv (Committer). Account for interface files for swap and memory being reported independently. The cgroup v1-like value is now reported by adding the memory.max value to the memory.swap.max value, and memory.current and memory.swap.current respectively. ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From sgehwolf at openjdk.java.net Wed Sep 30 10:14:15 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 30 Sep 2020 10:14:15 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v4] In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 10:07:40 GMT, Severin Gehwolf wrote: >> Marked as reviewed by bobv (Committer). > > Account for interface files for swap and memory being reported independently. > The cgroup v1-like value is now reported by adding the memory.max value to > the memory.swap.max value, and memory.current and memory.swap.current > respectively. @adinn Could I ask you to review this one as well, please? Thanks very much! ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From kim.barrett at oracle.com Wed Sep 30 10:23:50 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 30 Sep 2020 06:23:50 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> Message-ID: > On Sep 30, 2020, at 3:30 AM, Eric Liu wrote: > > Hi Kim, > > Thanks for your review. > I tried to solve the problem with your suggestion, and have just one question. > >> On 29 September 2020 18:51 PM, Kim Barrett wrote: >> With gcc10.2, and using the --enable-asan configure option, we get a >> -Wstringop-truncation warning in CompilerCounters::set_current_method, even >> after careful adjustment of the code to use the documented idiom for >> avoiding that warning. >> >> I initially wondered whether this might be only in fastdebug builds, where >> we also define _FORTIFY_SOURCE=2. The asan faq >> https://urldefense.com/v3/__https://github.com/google/sanitizers/wiki/AddressSanitizer*faq__;Iw!!GqivPVa7Brio!IFzpRJ6UwKlp2que6K1FLh9xe_Oe3s-shyGmlz3pzFTlEyZwdqk7yjfH_uovCn8U$ >> says asan doesn't work well with _FORTIFY_SOURCE. >> >> But the same warning occurs in a release build, where we aren't defining >> _FORTIFY_SOURCE. > >> At this point all I can conclude is that --enable-asan (i.e. >> -fsanitize=address) is simply incompatible with -Wstringop-truncation, at >> least through gcc10. That seems like a bug that someone should report. >> (Might be same as or related to https://urldefense.com/v3/__https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650__;!!GqivPVa7Brio!IFzpRJ6UwKlp2que6K1FLh9xe_Oe3s-shyGmlz3pzFTlEyZwdqk7yjfH_sMh77QA$ ) >> >> We don't normally build with -fsanitize=address; that's something that >> someone might want to turn on sometimes for testing or debugging, but I >> don't think we're planning to have it always on, even in debug builds. > >> Since it seems to be incompatible with various other options that we *do* >> normally use, I think the way to allow --enable-asan to be (possibly) usable >> is in the build system at configure time. That is, the --enable-asan >> configure option should, in addition to adding -fsanitize=address, also (1) >> disable -Wstringop-truncation and (2) disable the defining of >> _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes >> involves conditionalizing their addition/removal using ${ASAN_ENABLED}. > > Disable -Wstringop-truncation seems more reasonable. > Is that necessary to disable _FORTIFY_SOURCE in fastdebug? With gcc10.1, > disable -Wstringop-truncation seems enough. > > I didn't test with fastdebug mode before, and now it has been tested in our internal > both with release and fastdebug mode. My suggestiion that _FORTIFY_SOURCE should be disabled too is based on what the ASan FAQ and various bug reports and related threads say, which seems to be that combining ASan and _FORTIFY_SOURCE can cause problems to be missed and can lead to very strange fortify warnings. I found a couple of threads from a few years ago suggesting that maybe ASan should have interceptors for the fortify functions, but didn?t find any indication that?s actually happened. If it has, then the combination is presumably no longer problematic. From alanb at openjdk.java.net Wed Sep 30 10:59:05 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 30 Sep 2020 10:59:05 GMT Subject: RFR: 8204256: improve jlink error message to report unsupported class file format In-Reply-To: References: Message-ID: <4G3_8Xep8bMY6mC17exBywM_HTJNLQI_JJkURTzg8QU=.6b26d80c-3e4d-46a5-abfe-1ff58af8b51f@github.com> On Tue, 29 Sep 2020 19:33:35 GMT, Ian Graves wrote: > This pull request contains a change to facilitate better error messages in jlink for when jlink creates an image from > jmod files that are unsupported by the runtime by being _too new_. The existing behavior supports modules that are too > old via an error about a mismatched version. The solution to this problem is constrained by jlink's use of some > specified behavior by java.lang.module.ModuleFinder. The solution in this PR is to subclass some existing exceptions > internally as to signal to jlink more specific error conditions when attempting to find and open modules. Bug here: > https://bugs.openjdk.java.net/browse/JDK-8204256 > New Error message example: > > `Error: jlink encountered a java.base jmod with unsupported module descriptor version 60.0` This impacts the java.lang.module API. I think I'd prefer to drop all changes to jdk.internal.module from this patch and instead focus on a jlink specific change. ------------- Changes requested by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/409 From magnus.ihse.bursie at oracle.com Wed Sep 30 11:09:20 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Sep 2020 13:09:20 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <2E08727F-E790-4B7F-82EC-FAE9031C7E16@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> <2E08727F-E790-4B7F-82EC-FAE9031C7E16@oracle.com> Message-ID: <0ffa79c3-bff2-cd65-0f00-df16e573cb45@oracle.com> On 2020-09-29 13:17, Kim Barrett wrote: >> On Sep 29, 2020, at 6:51 AM, Kim Barrett wrote: >> >>> On Sep 28, 2020, at 11:13 AM, Eric Liu wrote: >>> >>> Hi, >>> >>> Thanks for looking at this. >>> >>> For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). >>> I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' >>> to replace 'strncpy'. >>> >>> >>> Thanks, >>> Eric >> [?] >> At this point all I can conclude is that --enable-asan (i.e. >> -fsanitize=address) is simply incompatible with -Wstringop-truncation, at >> least through gcc10. That seems like a bug that someone should report. >> (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) >> >> [?] >> >> Since it seems to be incompatible with various other options that we *do* >> normally use, I think the way to allow --enable-asan to be (possibly) usable >> is in the build system at configure time. That is, the --enable-asan >> configure option should, in addition to adding -fsanitize=address, also (1) >> disable -Wstringop-truncation and (2) disable the defining of >> _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes >> involves conditionalizing their addition/removal using ${ASAN_ENABLED}. >> >> Scattering pragmas for disabling -Wstringop-truncation doesn't cut it. > Another option might be to solve https://bugs.openjdk.java.net/browse/JDK-8232187 > Will that really help? If a os::strncpy_s method is added to hotspot, how should NetworkInterface.c in libnet be able to use it? /Magnus From fguallini at openjdk.java.net Wed Sep 30 11:13:12 2020 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 30 Sep 2020 11:13:12 GMT Subject: RFR: 8232840: [TESTBUG] java/math/BigInteger/largeMemory/SymmetricRangeTests.java fails due to "OutOfMemoryError: Requested array size exceeds VM limit" Message-ID: SymmetricRangeTests.java was added to ProblemList as it was throwing OOM time ago. Now, tests have been executed multiple times again with a combination of VM options with 100% pass rate, the issue could not be reproduced anymore, it seems quite stable to be removed from the ProblemList at this time. Required os.maxMemory has been increased as a preventive measure to run the tests only in an system where memory available is enough to give the JVM some elbow room ------------- Commit messages: - remove SymmetricRangeTests from problemlist Changes: https://git.openjdk.java.net/jdk/pull/432/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=432&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232840 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/432.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/432/head:pull/432 PR: https://git.openjdk.java.net/jdk/pull/432 From plevart at openjdk.java.net Wed Sep 30 11:22:02 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 30 Sep 2020 11:22:02 GMT Subject: RFR: 8159746: (proxy) Support for default methods In-Reply-To: References: <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com> <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com> Message-ID: On Tue, 29 Sep 2020 17:22:26 GMT, Mandy Chung wrote: >> So here's a patch on top of my last patch that reverts the exception behaviour back to be consistent with Method::invoke >> https://github.com/mlchung/jdk/pull/1 > >> So here's a patch on top of my last patch that reverts the exception behaviour back to be consistent with Method::invoke >> [mlchung#1](https://github.com/mlchung/jdk/pull/1) > > Thanks Peter. Looks good in general with a couple of comments. You can push to my local branch once you make any > change per the feedback. The https://github.com/mlchung/jdk/pull/1 has been updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/313 From enikitin at openjdk.java.net Wed Sep 30 11:51:58 2020 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Wed, 30 Sep 2020 11:51:58 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v2] In-Reply-To: References: Message-ID: > pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html) > > Error reporting was improved by writing a C-style escaped string representations for the variables passed to the > methods being tested. For array comparisons, a dedicated diff-formatter was implemented. > Sample output for comparing byte arrays (with artificial failure): > ----------System.err:(21/1553)---------- > Result: (false) of 'arrayEqualsB' is not equal to expected (true) > Arrays differ starting from [index: 7]: > ... 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... > ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... > ^^^^ > java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not > equal to expected (true) > at > compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273) > at ... stack trace continues - E.N. > Sample output for comparing char arrays: > ----------System.err:(21/1579)*---------- > Result: (false) of 'arrayEqualsC' is not equal to expected (true) > Arrays differ starting from [index: 7]: > ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ... > ... \\u0005, \\u0006, }, \\u0008, \\u0009, \\n, ... > ^^^^^^^ > java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not > equal to expected (true) > at > compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280) > at > ... and so on - E.N. > > testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx. Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision: Fix indent in ArrayCodec ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/112/files - new: https://git.openjdk.java.net/jdk/pull/112/files/ed213112..7e6c0a69 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/112/head:pull/112 PR: https://git.openjdk.java.net/jdk/pull/112 From enikitin at openjdk.java.net Wed Sep 30 11:52:02 2020 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Wed, 30 Sep 2020 11:52:02 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 19:55:44 GMT, Igor Ignatyev wrote: >> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indent in ArrayCodec > > test/lib/jdk/test/lib/format/ArrayCodec.java line 260: > >> 258: if (delta > 0) { >> 259: element = Format.paddingForWidth(delta) + element; >> 260: } > > wrong indent Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/112 From enikitin at openjdk.java.net Wed Sep 30 11:57:17 2020 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Wed, 30 Sep 2020 11:57:17 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v3] In-Reply-To: References: Message-ID: > pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html) > > Error reporting was improved by writing a C-style escaped string representations for the variables passed to the > methods being tested. For array comparisons, a dedicated diff-formatter was implemented. > Sample output for comparing byte arrays (with artificial failure): > ----------System.err:(21/1553)---------- > Result: (false) of 'arrayEqualsB' is not equal to expected (true) > Arrays differ starting from [index: 7]: > ... 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... > ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... > ^^^^ > java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not > equal to expected (true) > at > compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273) > at ... stack trace continues - E.N. > Sample output for comparing char arrays: > ----------System.err:(21/1579)*---------- > Result: (false) of 'arrayEqualsC' is not equal to expected (true) > Arrays differ starting from [index: 7]: > ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ... > ... \\u0005, \\u0006, }, \\u0008, \\u0009, \\n, ... > ^^^^^^^ > java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not > equal to expected (true) > at > compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280) > at > ... and so on - E.N. > > testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx. Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision: Replace new space string with constant ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/112/files - new: https://git.openjdk.java.net/jdk/pull/112/files/7e6c0a69..402fb529 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/112/head:pull/112 PR: https://git.openjdk.java.net/jdk/pull/112 From enikitin at openjdk.java.net Wed Sep 30 11:57:18 2020 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Wed, 30 Sep 2020 11:57:18 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v3] In-Reply-To: References: Message-ID: <1jTQLX0cQ3wAa3TkVMb7RwpNAt-jeQ7ZTGvwRQyw-LU=.078e33e2-d72f-47e4-ab10-9283c3155bac@github.com> On Mon, 28 Sep 2020 20:00:12 GMT, Igor Ignatyev wrote: >> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace new space string with constant > > test/lib/jdk/test/lib/format/ArrayDiff.java line 83: > >> 81: public static class Defaults { >> 82: final static int WIDTH = 80; >> 83: final static int CONTEXT_BEFORE = 2; > > either these constants should be `public`, or `Defaults` class should be `package-private`, otherwise, you get a public > class w/ no public fields. Old cpp sins... fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/112 From kim.barrett at oracle.com Wed Sep 30 12:19:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 30 Sep 2020 08:19:15 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <0ffa79c3-bff2-cd65-0f00-df16e573cb45@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> <2E08727F-E790-4B7F-82EC-FAE9031C7E16@oracle.com> <0ffa79c3-bff2-cd65-0f00-df16e573cb45@oracle.com> Message-ID: <4FD74735-D627-4587-8CC0-CFF21F4FF71C@oracle.com> > On Sep 30, 2020, at 7:09 AM, Magnus Ihse Bursie wrote: > > > > On 2020-09-29 13:17, Kim Barrett wrote: >> Another option might be to solve https://bugs.openjdk.java.net/browse/JDK-8232187 >> > Will that really help? If a os::strncpy_s method is added to hotspot, how should NetworkInterface.c in libnet be able to use it? > > /Magnus That?s already mentioned in the comments for that bug. A real solution needs to figure out a solution to that part too. So not an easy solve. Also as mentioned in the comments, strncpy_s might not be the right API to provide. strscpy might be better. It might be that bug report should be retitled and the description rewritten. From enikitin at openjdk.java.net Wed Sep 30 13:33:26 2020 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Wed, 30 Sep 2020 13:33:26 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v3] In-Reply-To: References: Message-ID: <6uP_GLWutOyBqeow_RfFYi_hoZfvyVCM44KiCUi0YUA=.15bc3210-1c1d-4de4-be79-84c3d13e1b68@github.com> On Mon, 28 Sep 2020 19:51:50 GMT, Igor Ignatyev wrote: >> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace new space string with constant > > test/lib-test/jdk/test/lib/format/ArrayDiffTest.java line 106: > >> 104: "[122]%n" + >> 105: "[ 7, 8, 9, 10, 125, 12, 13]%n" + >> 106: " ^^^"); > > as far as I remember, the commonly used practice is to align all these lines. > > (there are other places w/ the same "problem") ... in almost every test :). Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/112 From rrich at openjdk.java.net Wed Sep 30 14:25:20 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 30 Sep 2020 14:25:20 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v5] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'master' into JDK-8227745 - Make parameter current_thread of JvmtiEnvBase::check_top_frame() a JavaThread* again. With Asynchronous handshakes the type was changed from JavaThread* to Thread* but this is not necessary as check_top_frame() is not executed during a handshake / safepoint (robehn confirmed). - Merge branch 'master' into JDK-8227745 - EATests.java: bugfix to prevent ObjectCollectedException - Better encapsulation of JvmtiDeferredUpdates. Moved jvmtiDeferredLocalVariableSet to jvmtiDeferredUpdates.hpp - EscapeBarrier: moved method comments. - Shuffled parameters of EscapeBarrier constructors to better match each other - Moved class EscapeBarrier and class JvmtiDeferredUpdates into dedicated files. - Merge branch 'master' into JDK-8227745 - Changes based on dholmes' feedback. EscapeBarrier::sync_and_suspend_all(): - Set suspend flags before handshake because then the setting will be visible after leaving the _thread_blocked state in JavaThread::wait_for_object_deoptimization() JavaThread::wait_for_object_deoptimization() - Reuse SpinYield instead of new custom spinning code. - Do safepoint check after the loop. This is possible because the set_obj_deopt_flag is done before the handshake. - Don't set_suspend_equivalent() anymore for more simplicity. It's just an optimization (that won't pay off here). Added/updated source code comments. Additional smaller enhancements. - ... and 1 more: https://git.openjdk.java.net/jdk/compare/04775f11...af39d5b2 ------------- Changes: https://git.openjdk.java.net/jdk/pull/119/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=04 Stats: 5788 lines in 52 files changed: 5568 ins; 116 del; 104 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From enikitin at openjdk.java.net Wed Sep 30 14:30:29 2020 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Wed, 30 Sep 2020 14:30:29 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v3] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 20:00:35 GMT, Igor Ignatyev wrote: >> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace new space string with constant > > Changes requested by iignatyev (Reviewer). > 1. granted you can't change `invokeAndCheck`'s 2nd argument to bool as there are other values being passed, but you can > change `invokeAndCompareArrays` to accept an `Object` and compare expected and actual values by `Object::equals`. Well, I think that would make `invokeAndCompareArrays` look less specific and confuse a reader by creating a false impression that it could be called with an Object as an expected result. In reality, the method is only called with 'equals' of different signatures, and 'equals' does always return boolean. It could've been named 'invokeEqualsOnArraysAndCompareThem` :) The other method, `invokeAndCheck` is different. It can call, for example, `String.concat("abc", "def")` and expect the String "abcdef" as result. It does really need to be generic. > 2. even if you can't change output of these two methods to be the same (which I so far failed to see why), you still > can change `invokeAndCheck`'s `message` var to include actual and expected values in the same way as > `invokeAndCompareArrays` does. `invokeAndCompareArrays` / `ArrayDiff` compares two huge arrays and present a nice short *slice* in the difference area. The short slice is possible because we do a limited task - compare arrays. `invokeAndCheck` , on the other hand, can have as parameters the `utf16`, a string of 10K symbols. Do we really need a 10K string as output in our log? > you don't need `ArrayCodec::of(Object array)` anymore, do you? Unfortunately, it is used in the ArrayCodec.format (which is used in TestStringIntrinsics.java) - to make it possible to call it with everything and not swamp the code with overloads. ------------- PR: https://git.openjdk.java.net/jdk/pull/112 From vromero at openjdk.java.net Wed Sep 30 14:50:40 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 30 Sep 2020 14:50:40 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <3HQG1K8tFl8GYpUnm_gbEH8MqTKMQ17fONGeb0m1RnE=.c74d767c-e371-471a-b963-944460e468f7@github.com> On Wed, 30 Sep 2020 08:54:14 GMT, Chris Hegarty wrote: >> test/langtools/tools/javac/records/LocalStaticDeclarations.java line 33: >> >>> 31: * jdk.compiler/com.sun.tools.javac.util >>> 32: * @build combo.ComboTestHelper >>> 33: * @compile LocalStaticDeclarations.java >> >> This, and other, explicit at compile tags could be elided, no? The test source file will be implicitly compiled by the >> at run tag. I believe that the explicit at compile tag was added original so that the enable preview and source version >> options could be passed to javac - neither of which are needed any more. > > Does this test need an @run tag rather than an @compile tag ? ( the @run with implicitly compile the source file, > before running it ) yep u are right it could be removed, I will check all the instances of this, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From alanb at openjdk.java.net Wed Sep 30 15:53:23 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 30 Sep 2020 15:53:23 GMT Subject: RFR: 8232840: java/math/BigInteger/largeMemory/SymmetricRangeTests.java fails due to "OutOfMemoryError: Requested array size exceeds VM limit" In-Reply-To: References: Message-ID: <8D3dojgKjS9pCYNigBqHBEAWmFISR_TbPbf1uTEQceU=.2016436f-67bb-4bfc-af68-d0972a53ab9f@github.com> On Wed, 30 Sep 2020 11:06:16 GMT, Fernando Guallini wrote: > SymmetricRangeTests.java was added to ProblemList as it was throwing OOM time ago. Now, tests have been executed > multiple times again with a combination of VM options with 100% pass rate, the issue could not be reproduced anymore, > it seems quite stable to be removed from the ProblemList at this time. Required os.maxMemory has been increased as a > preventive measure to run the tests only in an system where memory available is enough to give the JVM some elbow room Looks good and I assume you've run it many times to be sure that 10GB is sufficient. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/432 From iignatyev at openjdk.java.net Wed Sep 30 16:37:28 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 30 Sep 2020 16:37:28 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v3] In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 11:57:17 GMT, Evgeny Nikitin wrote: >> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html) >> >> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the >> methods being tested. For array comparisons, a dedicated diff-formatter was implemented. >> Sample output for comparing byte arrays (with artificial failure): >> ----------System.err:(21/1553)---------- >> Result: (false) of 'arrayEqualsB' is not equal to expected (true) >> Arrays differ starting from [index: 7]: >> ... 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... >> ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... >> ^^^^ >> java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not >> equal to expected (true) >> at >> compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273) >> at ... stack trace continues - E.N. >> Sample output for comparing char arrays: >> ----------System.err:(21/1579)*---------- >> Result: (false) of 'arrayEqualsC' is not equal to expected (true) >> Arrays differ starting from [index: 7]: >> ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ... >> ... \\u0005, \\u0006, }, \\u0008, \\u0009, \\n, ... >> ^^^^^^^ >> java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not >> equal to expected (true) >> at >> compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280) >> at >> ... and so on - E.N. >> >> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx. > > Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision: > > Replace new space string with constant test/lib/jdk/test/lib/format/ArrayCodec.java line 157: > 155: return ArrayCodec.of((String[])array); > 156: } else if (!type.isPrimitive() && !type.isArray()) { > 157: return ArrayCodec.of((String[])array); Suggestion: return ArrayCodec.of((Object[])array); copy-paste typo? ------------- PR: https://git.openjdk.java.net/jdk/pull/112 From iignatyev at openjdk.java.net Wed Sep 30 16:37:28 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 30 Sep 2020 16:37:28 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v3] In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 14:27:52 GMT, Evgeny Nikitin wrote: > The other method, `invokeAndCheck` is different. It can call, for example, `String.concat("abc", "def")` and expect the > String "abcdef" as result. It does really need to be generic. although I still don't see them as really being that much different, I'm fine w/ keeping them as-is. > `invokeAndCompareArrays` / `ArrayDiff` compares two huge arrays and present a nice short _slice_ in the difference > area. The short slice is possible because we do a limited task - compare arrays. `invokeAndCheck` , on the other hand, > can have as parameters the `utf16`, a string of 10K symbols. Do we really need a 10K string as output in our log? I think we do, as people tend to first look at exception's messages and only then look thru other logs, so having relative information in the exception is always a good thing. should 10K symbols become a problem (this though would also mean that you can't print the compared values w/ `Format.asLiteral`), we can revisit this. > > > you don't need `ArrayCodec::of(Object array)` anymore, do you? > > Unfortunately, it is used in the ArrayCodec.format (which is used in TestStringIntrinsics.java) - to make it possible > to call it with everything and not swamp the code with overloads. hm, I somehow missed that usage, but you don't need to repeat to the same switch over a component type in `ArrayDiff::of`, do you? ------------- PR: https://git.openjdk.java.net/jdk/pull/112 From valeriep at openjdk.java.net Wed Sep 30 17:11:54 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 30 Sep 2020 17:11:54 GMT Subject: RFR: 8253829: Wrong length compared in SSPI bridge In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 02:59:40 GMT, Weijun Wang wrote: > For two principals to be the same, they are either all "user at R", or one is "user" and the other is "user at R". The check > here wants to fail early if the length are different. "l" is the whole length and "r" is the length of the name > (without realm). The comparison should be reflective but there is a typo. For example, for "user at R" and "user", l1 = > 6, l2 = 4, r1 = 4, r2 = 4, the check will succeed and the names are treated as different. This is not the expected > behavior. No regression test because we don't support SSPI testing in the OpenJDK repo now. Looks fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/419 From valeriep at openjdk.java.net Wed Sep 30 17:16:28 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 30 Sep 2020 17:16:28 GMT Subject: RFR: 8253829: Wrong length compared in SSPI bridge In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 02:59:40 GMT, Weijun Wang wrote: > For two principals to be the same, they are either all "user at R", or one is "user" and the other is "user at R". The check > here wants to fail early if the length are different. "l" is the whole length and "r" is the length of the name > (without realm). The comparison should be reflective but there is a typo. For example, for "user at R" and "user", l1 = > 6, l2 = 4, r1 = 4, r2 = 4, the check will succeed and the names are treated as different. This is not the expected > behavior. No regression test because we don't support SSPI testing in the OpenJDK repo now. Marked as reviewed by valeriep (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/419 From weijun at openjdk.java.net Wed Sep 30 17:16:28 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 30 Sep 2020 17:16:28 GMT Subject: Integrated: 8253829: Wrong length compared in SSPI bridge In-Reply-To: References: Message-ID: <_hXrpFCaBKbVc1qGMB22JBG30gq128hvlOFVH8F8JV4=.e3c50b09-54d4-45a8-a28e-796085410529@github.com> On Wed, 30 Sep 2020 02:59:40 GMT, Weijun Wang wrote: > For two principals to be the same, they are either all "user at R", or one is "user" and the other is "user at R". The check > here wants to fail early if the length are different. "l" is the whole length and "r" is the length of the name > (without realm). The comparison should be reflective but there is a typo. For example, for "user at R" and "user", l1 = > 6, l2 = 4, r1 = 4, r2 = 4, the check will succeed and the names are treated as different. This is not the expected > behavior. No regression test because we don't support SSPI testing in the OpenJDK repo now. This pull request has now been integrated. Changeset: e5ba020e Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/e5ba020e Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8253829: Wrong length compared in SSPI bridge Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/419 From mchung at openjdk.java.net Wed Sep 30 17:25:52 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 30 Sep 2020 17:25:52 GMT Subject: RFR: 8159746: (proxy) Support for default methods [v2] In-Reply-To: References: Message-ID: <3oUplIHCIAhwptQ2DxmV6k4y55eQRF_Pj30EfP1j8oU=.428d41c0-5f57-4459-bd55-da8a0a269c1d@github.com> > This proposes a new static `Proxy::invokeDefaultMethod` method to invoke > the given default method on the given proxy instance. > > The implementation looks up a method handle for `invokespecial` instruction > as if called from with the proxy class as the caller, equivalent to calling > `X.super::m` where `X` is a proxy interface of the proxy class and > `X.super::m` will resolve to the specified default method. > > The implementation will call a private static `proxyClassLookup(Lookup caller)` > method of the proxy class to obtain its private Lookup. This private method > in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class > with full privilege access to use, or else `IllegalAccessException` will be > thrown. > > This patch also proposes to define a proxy class in an unnamed module to > a dynamic module to strengthen encapsulation such that they are only > unconditionally exported from a named module but not open for deep reflective > access. This only applies to the case if all the proxy interfaces are public > and in a package that is exported or open. > > One dynamic module is created for each class loader that defines proxies. > The change changes the dynamic module to contain another package (same > name as the module) that is unconditionally exported and is opened to > `java.base` only. > > There is no change to the package and module of the proxy class for > the following cases: > > - if at least one proxy interface is non-public, then the proxy class is defined > in the package and module of the non-public interfaces > - if at least one proxy is in a package that is non-exported and non-open, > if all proxy interfaces are public, then the proxy class is defined in > a non-exported, non-open package of a dynamic module. > > The spec change is that a proxy class used to be defined in an unnamed > module, i.e. in a exported and open package, is defined in an unconditionally > exported but non-open package. Programs that assume it to be open unconditionally > will be affected and cannot do deep reflection on such proxy classes. > > Peter Levart contributed an initial prototype [1] (thanks Peter). I think > the exceptions could be simplified as more checking should be done prior to > the invocation of the method handle like checking the types of the arguments > with the method type. This approach avoids defining a public API > `protected Proxy::$$proxyClassLookup$$` method. Instead it defines a > private static method that is restricted for Proxy class to use (by > taking a caller parameter to ensure it's a private lookup on Proxy class). > > javadoc/specdiff: > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/ > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/ > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html Mandy Chung has updated the pull request incrementally with four additional commits since the last revision: - Merge pull request #1 from plevart/proxy-default-method-performance Performance improvements for Proxy::invokeDefaultMethod - Add test case for InvocationTargetException - Revert the thrown exceptions spec to be consistent with Method::invoke - Speed up Proxy.invokeDefaultMethod while also changing its spec regarding exception types thrown ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/313/files - new: https://git.openjdk.java.net/jdk/pull/313/files/c311a744..e6283580 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=00-01 Stats: 197 lines in 2 files changed: 97 ins; 24 del; 76 mod Patch: https://git.openjdk.java.net/jdk/pull/313.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/313/head:pull/313 PR: https://git.openjdk.java.net/jdk/pull/313 From bchristi at openjdk.java.net Wed Sep 30 17:36:10 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 30 Sep 2020 17:36:10 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException [v2] In-Reply-To: References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: On Tue, 29 Sep 2020 11:39:20 GMT, Jaikiran Pai wrote: >> Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? >> >> As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds >> the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This >> is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is >> larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the >> `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent >> this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the >> necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which >> reproduces the issue and verifies the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Address the review comments and introduce an array size check in JarFile.getBytes() method itself If there is only modest improvement in test duration, we may want to add a jtreg timeout tag. Also, given the long duration but relative low priority of testing this, it perhaps should be moved out of Tier 1. I will look into those things after your next update. src/java.base/share/classes/java/util/jar/JarFile.java line 161: > 159: * OutOfMemoryError: Required array size too large > 160: */ > 161: private static final int MAX_BUFFER_SIZE = Integer.MAX_VALUE - 8; "/**" comments are generally only used for public documentation. For use here, probably a single line // comment would be sufficient to explain what this value is. This constant is also named, "MAX_ARRAY_SIZE" in various places, which seems more applicable to this case. src/java.base/share/classes/java/util/jar/JarFile.java line 801: > 799: if (len > MAX_BUFFER_SIZE) { > 800: throw new OutOfMemoryError("Required array size too large"); > 801: } I would just add a new `long zeSize` to read and check `ze.getSize()`, and then (int) cast it into `len`, as before. Then I think no changes would be needed past L802, `int bytesRead;` test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 45: > 43: public class LargeManifestOOMTest { > 44: > 45: Unneeded blank lines test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 83: > 81: } > 82: } > 83: Extra line test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 78: > 76: bw.write("OOM-Test: "); > 77: for (long i = 0; i < 2147483648L; i++) { > 78: bw.write("a"); As you probably noticed, this test takes a little while to run. One way to speed it up a little would be to write more characters at a time. While we're at it, we may as well make the Manifest well-formed by breaking it into 72-byte lines. See "Line length" under: https://docs.oracle.com/en/java/javase/15/docs/specs/jar/jar.html#notes-on-manifest-and-signature-files Just write enough lines to exceed Integer.MAX_VALUE bytes. ------------- Changes requested by bchristi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/323 From bchristi at openjdk.java.net Wed Sep 30 17:36:10 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 30 Sep 2020 17:36:10 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException [v2] In-Reply-To: References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: On Wed, 23 Sep 2020 15:09:44 GMT, Jaikiran Pai wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Address the review comments and introduce an array size check in JarFile.getBytes() method itself > > test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 60: > >> 58: final OutOfMemoryError oome = Assert.expectThrows(OutOfMemoryError.class, () -> jar.getManifest()); >> 59: // additionally verify that the OOM was for the right/expected reason >> 60: if (!"Required array size too large".equals(oome.getMessage())) { > > I wasn't too sure if I should add this additional check on the message of the `OutOfMemoryError`, but decided to do it > anyway, given that from what I remember there were some discussions in the `core-libs-dev` list a while back on the > exact messages that such OOMs should throw. So I guessed that it might be OK to rely on those messages in the tests > within this project. However, I am open to removing specific check if it's considered unnecessary. I think it's fine either way. ------------- PR: https://git.openjdk.java.net/jdk/pull/323 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 lancea at openjdk.java.net Wed Sep 30 18:41:17 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 30 Sep 2020 18:41:17 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException [v2] In-Reply-To: References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: On Wed, 30 Sep 2020 17:26:18 GMT, Brent Christian wrote: >> test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 60: >> >>> 58: final OutOfMemoryError oome = Assert.expectThrows(OutOfMemoryError.class, () -> jar.getManifest()); >>> 59: // additionally verify that the OOM was for the right/expected reason >>> 60: if (!"Required array size too large".equals(oome.getMessage())) { >> >> I wasn't too sure if I should add this additional check on the message of the `OutOfMemoryError`, but decided to do it >> anyway, given that from what I remember there were some discussions in the `core-libs-dev` list a while back on the >> exact messages that such OOMs should throw. So I guessed that it might be OK to rely on those messages in the tests >> within this project. However, I am open to removing specific check if it's considered unnecessary. > > I think it's fine either way. If you are going to validate the message, which I probably would not, it would be important to make sure it document if the message is changed in JarFile::getBytes, that the test needs updated. Otherwise it will be easy to miss. ------------- PR: https://git.openjdk.java.net/jdk/pull/323 From mchung at openjdk.java.net Wed Sep 30 19:14:28 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 30 Sep 2020 19:14:28 GMT Subject: RFR: 8159746: (proxy) Support for default methods [v3] In-Reply-To: References: Message-ID: <8zAT7wr3UEpc3_urKByQrMHiJJqkrZ_ORhpQ_f8yciY=.d4fabdef-49b0-4979-a1bd-ef0fd5dfb097@github.com> > This proposes a new static `Proxy::invokeDefaultMethod` method to invoke > the given default method on the given proxy instance. > > The implementation looks up a method handle for `invokespecial` instruction > as if called from with the proxy class as the caller, equivalent to calling > `X.super::m` where `X` is a proxy interface of the proxy class and > `X.super::m` will resolve to the specified default method. > > The implementation will call a private static `proxyClassLookup(Lookup caller)` > method of the proxy class to obtain its private Lookup. This private method > in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class > with full privilege access to use, or else `IllegalAccessException` will be > thrown. > > This patch also proposes to define a proxy class in an unnamed module to > a dynamic module to strengthen encapsulation such that they are only > unconditionally exported from a named module but not open for deep reflective > access. This only applies to the case if all the proxy interfaces are public > and in a package that is exported or open. > > One dynamic module is created for each class loader that defines proxies. > The change changes the dynamic module to contain another package (same > name as the module) that is unconditionally exported and is opened to > `java.base` only. > > There is no change to the package and module of the proxy class for > the following cases: > > - if at least one proxy interface is non-public, then the proxy class is defined > in the package and module of the non-public interfaces > - if at least one proxy is in a package that is non-exported and non-open, > if all proxy interfaces are public, then the proxy class is defined in > a non-exported, non-open package of a dynamic module. > > The spec change is that a proxy class used to be defined in an unnamed > module, i.e. in a exported and open package, is defined in an unconditionally > exported but non-open package. Programs that assume it to be open unconditionally > will be affected and cannot do deep reflection on such proxy classes. > > Peter Levart contributed an initial prototype [1] (thanks Peter). I think > the exceptions could be simplified as more checking should be done prior to > the invocation of the method handle like checking the types of the arguments > with the method type. This approach avoids defining a public API > `protected Proxy::$$proxyClassLookup$$` method. Instead it defines a > private static method that is restricted for Proxy class to use (by > taking a caller parameter to ensure it's a private lookup on Proxy class). > > javadoc/specdiff: > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/ > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/ > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html Mandy Chung 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: - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method - minor tweak to the spec wording and impl - Merge pull request #1 from plevart/proxy-default-method-performance Performance improvements for Proxy::invokeDefaultMethod - Add test case for InvocationTargetException - Revert the thrown exceptions spec to be consistent with Method::invoke - Speed up Proxy.invokeDefaultMethod while also changing its spec regarding exception types thrown - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method - fix regression tests due to proxy name change - minor bug fix - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method - ... and 7 more: https://git.openjdk.java.net/jdk/compare/48d0df07...db6cfc13 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/313/files - new: https://git.openjdk.java.net/jdk/pull/313/files/e6283580..db6cfc13 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=01-02 Stats: 34661 lines in 1936 files changed: 6781 ins; 22873 del; 5007 mod Patch: https://git.openjdk.java.net/jdk/pull/313.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/313/head:pull/313 PR: https://git.openjdk.java.net/jdk/pull/313 From mchung at openjdk.java.net Wed Sep 30 19:14:32 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 30 Sep 2020 19:14:32 GMT Subject: RFR: 8159746: (proxy) Support for default methods In-Reply-To: References: <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com> <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com> Message-ID: On Wed, 30 Sep 2020 11:19:40 GMT, Peter Levart wrote: >>> So here's a patch on top of my last patch that reverts the exception behaviour back to be consistent with Method::invoke >>> [mlchung#1](https://github.com/mlchung/jdk/pull/1) >> >> Thanks Peter. Looks good in general with a couple of comments. You can push to my local branch once you make any >> change per the feedback. > > The https://github.com/mlchung/jdk/pull/1 has been updated. @plevart I have merged your PR and made minor tweak. Please review CSR: https://bugs.openjdk.java.net/browse/JDK-8253870 ------------- PR: https://git.openjdk.java.net/jdk/pull/313 From github.com+51754783+CoreyAshford at openjdk.java.net Wed Sep 30 19:19:24 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Wed, 30 Sep 2020 19:19:24 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com> References: <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com> Message-ID: On Tue, 29 Sep 2020 16:39:25 GMT, CoreyAshford wrote: > Did you try on x86? AOT is not supported on PPC64. After looking at this a bit, I find that there seems to be an assumption in the code that if there is an intrinsic symbol defined in aotCodeHeap.cpp using the SET_AOT_GLOBAL_SYMBOL_VALUE macro, it is required that the intrinsic is implemented for every arch that implements AOT. In this case, there isn't an implementation for x86_64 (yet), so that's why the failure is occurring. I was tempted to put in an arch-specific #if for ppc arch only, but I don't see any arch-specific code in this area, and it doesn't make sense either because AOT isn't supported on ppc at all. Another alternative is to remove the SET_AOT_GLOBAL_SYMBOL_VALUE for decodeBlock, since the implementation is not defined (yet) for any arch which supports AOT. A third alternative would be to leave the macro call in, but comment it out, saying to uncomment it when it's supported on all AOT-capable arches. Any thoughts? ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From enikitin at openjdk.java.net Wed Sep 30 19:49:18 2020 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Wed, 30 Sep 2020 19:49:18 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v4] In-Reply-To: References: Message-ID: > pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html) > > Error reporting was improved by writing a C-style escaped string representations for the variables passed to the > methods being tested. For array comparisons, a dedicated diff-formatter was implemented. > Sample output for comparing byte arrays (with artificial failure): > ----------System.err:(21/1553)---------- > Result: (false) of 'arrayEqualsB' is not equal to expected (true) > Arrays differ starting from [index: 7]: > ... 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... > ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... > ^^^^ > java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not > equal to expected (true) > at > compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273) > at ... stack trace continues - E.N. > Sample output for comparing char arrays: > ----------System.err:(21/1579)*---------- > Result: (false) of 'arrayEqualsC' is not equal to expected (true) > Arrays differ starting from [index: 7]: > ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ... > ... \\u0005, \\u0006, }, \\u0008, \\u0009, \\n, ... > ^^^^^^^ > java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not > equal to expected (true) > at > compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280) > at > ... and so on - E.N. > > testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx. Evgeny Nikitin has updated the pull request incrementally with three additional commits since the last revision: - Fix Object component type for ArrayCodec.of - Align strings in ArrayDiffTest - Make ArrayDif defaults really public ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/112/files - new: https://git.openjdk.java.net/jdk/pull/112/files/402fb529..803cd355 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=02-03 Stats: 45 lines in 3 files changed: 0 ins; 0 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/112/head:pull/112 PR: https://git.openjdk.java.net/jdk/pull/112 From enikitin at openjdk.java.net Wed Sep 30 19:49:19 2020 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Wed, 30 Sep 2020 19:49:19 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v3] In-Reply-To: References: Message-ID: <5_ehofREVqI1X6QzRkAZT1OoUEe9gd7g3EpS2tBhgJg=.d56ba641-667c-4ffa-a68c-55f9b6374b9b@github.com> On Wed, 30 Sep 2020 16:35:02 GMT, Igor Ignatyev wrote: >> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace new space string with constant > > test/lib/jdk/test/lib/format/ArrayCodec.java line 157: > >> 155: return ArrayCodec.of((String[])array); >> 156: } else if (!type.isPrimitive() && !type.isArray()) { >> 157: return ArrayCodec.of((String[])array); > > Suggestion: > > return ArrayCodec.of((Object[])array); > > copy-paste typo? A good one, thanks. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/112 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 enikitin at openjdk.java.net Wed Sep 30 20:23:01 2020 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Wed, 30 Sep 2020 20:23:01 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v5] In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 16:34:10 GMT, Igor Ignatyev wrote: > I think we do, as people tend to first look at exception's messages and only then look thru other logs, so having > relative information in the exception is always a good thing. should 10K symbols become a problem (this though would > also mean that you can't print the compared values w/ `Format.asLiteral`), we can revisit this. Ok, I got it. I was blind and stupid, sorry. Fixed, please check the e6fb6d04cad > hm, I somehow missed that usage, but you don't need to repeat to the same switch over a component type in > `ArrayDiff::of`, do you? <sigh>... I can see no better solution here. The `ArrayDiff::of` checks that both component types are the same in addition, but I probably could have avoided duplicating the switch (we can ignore double guessing the type). The issue is that in ArrayDiff is forwarded to first and second, I would need to declare them as generic (ArrayCodec). The type system seem to not allow me to fix that nicely. ------------- PR: https://git.openjdk.java.net/jdk/pull/112 From enikitin at openjdk.java.net Wed Sep 30 20:23:01 2020 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Wed, 30 Sep 2020 20:23:01 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v5] In-Reply-To: References: Message-ID: <-tlozxBhWYLfWzNnau-oENPWtFOywM8uZiDUmeVFCuc=.ce97c644-b5f8-4a62-b140-48e8d3aed0ac@github.com> > pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html) > > Error reporting was improved by writing a C-style escaped string representations for the variables passed to the > methods being tested. For array comparisons, a dedicated diff-formatter was implemented. > Sample output for comparing byte arrays (with artificial failure): > ----------System.err:(21/1553)---------- > Result: (false) of 'arrayEqualsB' is not equal to expected (true) > Arrays differ starting from [index: 7]: > ... 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... > ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ... > ^^^^ > java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not > equal to expected (true) > at > compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273) > at ... stack trace continues - E.N. > Sample output for comparing char arrays: > ----------System.err:(21/1579)*---------- > Result: (false) of 'arrayEqualsC' is not equal to expected (true) > Arrays differ starting from [index: 7]: > ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ... > ... \\u0005, \\u0006, }, \\u0008, \\u0009, \\n, ... > ^^^^^^^ > java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not > equal to expected (true) > at > compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280) > at > ... and so on - E.N. > > testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx. Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision: Print all arguments in the invokeAndCheck's exception ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/112/files - new: https://git.openjdk.java.net/jdk/pull/112/files/803cd355..e6fb6d04 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=03-04 Stats: 11 lines in 1 file changed: 4 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/112/head:pull/112 PR: https://git.openjdk.java.net/jdk/pull/112 From sergei.tsypanov at yandex.ru Wed Sep 30 20:30:20 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Wed, 30 Sep 2020 22:30:20 +0200 Subject: [PATCH] Drop explicit zeroing at instantiation of Atomic* objects Message-ID: <7569121601497210@mail.yandex.ru> Hello, often objects of atomic types e.g. AtomicInteger are explicitly zeroed at initialization, which is redundant and slower than relying on default values (zeros): @State(Scope.Thread) @OutputTimeUnit(TimeUnit.NANOSECONDS) @BenchmarkMode(value = Mode.AverageTime) public class AtomicBenchmark { @Benchmark public Object defaultValue() { return new AtomicInteger(); } @Benchmark public Object explicitValue() { return new AtomicInteger(0); } } Semantically both new AtomicInteger() and new AtomicInteger(0) are the same, but explicitValue() is much slower: Benchmark Mode Cnt Score Error Units AtomicBenchmark.defaultValue avgt 30 4.778 ? 0.403 ns/op AtomicBenchmark.explicitValue avgt 30 11.846 ? 0.273 ns/op The reason is assignment to volatile fields which is not necessary [1]. Previously there were similar clean-up issues, e.g. [2], which in its nutshell is about the same. If this change is relevant then I'd like someone to file an issue to let me create a proper PR for it. Patch is attached. Regards, Sergey Tsypanov 1. http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html 2. https://bugs.openjdk.java.net/browse/JDK-8035284 -------------- next part -------------- A non-text attachment was scrubbed... Name: Drop_explicit_zeroing.patch Type: text/x-diff Size: 9750 bytes Desc: not available URL: From rriggs at openjdk.java.net Wed Sep 30 20:45:39 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 30 Sep 2020 20:45:39 GMT Subject: Integrated: 8252523: Add ASN.1 Formatter to work with test utility HexPrinter In-Reply-To: References: Message-ID: On Sun, 20 Sep 2020 13:54:02 GMT, Roger Riggs wrote: > # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1 formatter reads a stream and produces annotated output of the > tags, values, and structures. > When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized > with the hex formatted output. > > Small changes to HexPrinter are included to improve the output readability. > > > Example decoding of a .pem certificate: > SEQUENCE [910] > SEQUENCE [630] > CONTEXT cons 0 [3] > BYTE 2, > BYTE 3, > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > SEQUENCE [76] > SET [11] > SEQUENCE [9] > OBJECT ID [3] 2.5.4.6 (CountryName) > 'IN' > ... > SET [16] > SEQUENCE [14] > OBJECT ID [3] 2.5.4.3 (CommonName) > Client1 > SEQUENCE [30] > UTCTIME [13] '150526221718Z' > UTCTIME [13] '250523221718Z' > ... > SEQUENCE [290] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > NULL > BIT STRING [271] > CONTEXT cons 3 [123] > SEQUENCE [121] > SEQUENCE [9] > OBJECT ID [3] 2.5.29.19 (BasicConstraints) > OCTET STRING [2] > SEQUENCE [44] > OBJECT ID [9] 2.16.840.1.113730.1.13 > OCTET STRING [31] '..OpenSSL Generated Certificate' > SEQUENCE [29] > OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > OCTET STRING [22] > SEQUENCE [31] > OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > OCTET STRING [24] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > BIT STRING [257] > When used with the HexPrinter test utility, the formatting of the > hexadecimal values is selected with the parameters to HexPrinter. > > 0000: 30 82 03 8e ; SEQUENCE [910] > 0004: 30 82 02 76 ; SEQUENCE [630] > 0008: a0 03 ; CONTEXT cons 0 [3] > 000a: 02 01 02 ; BYTE 2, > 000d: 02 01 03 ; BYTE 3, > 0010: 30 0d ; SEQUENCE [13] > 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 001d: 05 00 ; NULL > 001f: 30 ; SEQUENCE [76] > 0020: 4c ; > 0021: 31 0b ; SET [11] > 0023: 30 09 ; SEQUENCE [9] > 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) > 002a: 13 02 49 4e ; 'IN' > > ... ... > > 005b: 31 10 ; SET [16] > 005d: 30 0e ; SEQUENCE [14] > 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) > 0060: 03 55 04 03 ; > 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 > 006d: 30 1e ; SEQUENCE [30] > 006f: 17 ; UTCTIME [13] '150526221718Z' > 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; > 007e: 17 0d ; UTCTIME [13] '250523221718Z' > 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; > > ... ... > > 00db: 30 82 01 22 ; SEQUENCE [290] > 00df: 30 ; SEQUENCE [13] > 00e0: 0d ; > 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > 00ec: 05 00 ; NULL > 00ee: 03 82 ; BIT STRING [271] > 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; > > ... > > 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; > 0200: 01 ; > 0201: a3 7b ; CONTEXT cons 3 [123] > 0203: 30 79 ; SEQUENCE [121] > 0205: 30 09 ; SEQUENCE [9] > 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) > 020c: 04 02 30 00 ; OCTET STRING [2] > 0210: 30 2c ; SEQUENCE [44] > 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 > 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated > Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; > 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; > 023e: 30 1d ; SEQUENCE [29] > 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] > 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; > 025d: 30 1f ; SEQUENCE [31] > 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > 0260: 03 55 1d 23 ; > 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] > 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ; NULL > 028d: 03 82 01 ; BIT STRING [257] > 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; > > ... > > 0390: 6d 94 ; This pull request has now been integrated. Changeset: 092c2277 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/092c2277 Stats: 776 lines in 5 files changed: 766 ins; 1 del; 9 mod 8252523: Add ASN.1 Formatter to work with test utility HexPrinter Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From iignatyev at openjdk.java.net Wed Sep 30 21:21:26 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 30 Sep 2020 21:21:26 GMT Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics failures [v5] In-Reply-To: References: Message-ID: <6vRhHgd3e0gnEqpA5d_R7PMM_QK2OQicLzjRM5tQ69k=.c7d9e131-533f-4418-a101-1890ecc9c4c9@github.com> On Wed, 30 Sep 2020 20:20:08 GMT, Evgeny Nikitin wrote: >>> The other method, `invokeAndCheck` is different. It can call, for example, `String.concat("abc", "def")` and expect the >>> String "abcdef" as result. It does really need to be generic. >> although I still don't see them as really being that much different, I'm fine w/ keeping them as-is. >> >> >>> `invokeAndCompareArrays` / `ArrayDiff` compares two huge arrays and present a nice short _slice_ in the difference >>> area. The short slice is possible because we do a limited task - compare arrays. `invokeAndCheck` , on the other hand, >>> can have as parameters the `utf16`, a string of 10K symbols. Do we really need a 10K string as output in our log? >> >> I think we do, as people tend to first look at exception's messages and only then look thru other logs, so having >> relative information in the exception is always a good thing. should 10K symbols become a problem (this though would >> also mean that you can't print the compared values w/ `Format.asLiteral`), we can revisit this. >>> >>> > you don't need `ArrayCodec::of(Object array)` anymore, do you? >>> >>> Unfortunately, it is used in the ArrayCodec.format (which is used in TestStringIntrinsics.java) - to make it possible >>> to call it with everything and not swamp the code with overloads. >> >> hm, I somehow missed that usage, but you don't need to repeat to the same switch over a component type in >> `ArrayDiff::of`, do you? > >> I think we do, as people tend to first look at exception's messages and only then look thru other logs, so having >> relative information in the exception is always a good thing. should 10K symbols become a problem (this though would >> also mean that you can't print the compared values w/ `Format.asLiteral`), we can revisit this. > > Ok, I got it. I was blind and stupid, sorry. Fixed, please check the e6fb6d04cad > >> hm, I somehow missed that usage, but you don't need to repeat to the same switch over a component type in >> `ArrayDiff::of`, do you? > > <sigh>... I can see no better solution here. The `ArrayDiff::of` checks that both component types are the same in > addition, but I probably could have avoided duplicating the switch (we can ignore double guessing the type). The issue > is that in ArrayDiff is forwarded to first and second, I would need to declare them as generic > (ArrayCodec). The type system seem to not allow me to fix that nicely. > > I think we do, as people tend to first look at exception's messages and only then look thru other logs, so having > > relative information in the exception is always a good thing. should 10K symbols become a problem (this though would > > also mean that you can't print the compared values w/ `Format.asLiteral`), we can revisit this. > > Ok, I got it. I was blind and stupid, sorry. Fixed, please check the > [e6fb6d0](https://github.com/openjdk/jdk/commit/e6fb6d04caddc4b410a594574f570cfcb9445e4a) I'd use `StringBuilder` to construct the message. > > hm, I somehow missed that usage, but you don't need to repeat to the same switch over a component type in > > `ArrayDiff::of`, do you? > > ... I can see no better solution here. The `ArrayDiff::of` checks that both component types are the same in > addition, but I probably could have avoided duplicating the switch (we can ignore double guessing the type). The issue > is that in ArrayDiff is forwarded to first and second, I would need to declare them as generic (ArrayCodec). The type > system seem to not allow me to fix that nicely. wouldn't the following patch do? --git a/test/lib/jdk/test/lib/format/ArrayDiff.java b/test/lib/jdk/test/lib/format/ArrayDiff.java --- a/test/lib/jdk/test/lib/format/ArrayDiff.java +++ b/test/lib/jdk/test/lib/format/ArrayDiff.java @@ -123,41 +123,10 @@ public class ArrayDiff implements Diff { if (!bothAreArrays || !componentTypesAreSame) { throw new IllegalArgumentException("Both arguments should be arrays of the same type"); } - - var type = first.getClass().getComponentType(); - if (type == byte.class) { - return new ArrayDiff<>( - ArrayCodec.of((byte[])first), - ArrayCodec.of((byte[])second), - width, contextBefore); - } else if (type == int.class) { - return new ArrayDiff<>( - ArrayCodec.of((int[])first), - ArrayCodec.of((int[])second), - width, contextBefore); - } else if (type == long.class) { - return new ArrayDiff<>( - ArrayCodec.of((long[])first), - ArrayCodec.of((long[])second), - width, contextBefore); - } else if (type == char.class) { - return new ArrayDiff<>( - ArrayCodec.of((char[])first), - ArrayCodec.of((char[])second), - width, contextBefore); - } else if (type == String.class) { - return new ArrayDiff<>( - ArrayCodec.of((String[])first), - ArrayCodec.of((String[])second), - width, contextBefore); - } else if (!type.isPrimitive() && !type.isArray()) { - return new ArrayDiff<>( - ArrayCodec.of((Object[])first), - ArrayCodec.of((Object[])second), - width, contextBefore); - } - - throw new IllegalArgumentException("Unsupported array component type: " + type); + return new ArrayDiff( + ArrayCodec.of(first), + ArrayCodec.of(second), + width, contextBefore); } /** ------------- PR: https://git.openjdk.java.net/jdk/pull/112 From joe.darcy at oracle.com Wed Sep 30 21:29:49 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Sep 2020 14:29:49 -0700 Subject: RFR: 8253455: Record Classes javax.lang.model changes [v5] In-Reply-To: References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> Message-ID: <74fa9c6a-2345-6364-ac74-96ce508d3fae@oracle.com> On 9/30/2020 2:00 AM, Chris Hegarty wrote: > On Tue, 29 Sep 2020 21:37:58 GMT, Vicente Romero wrote: > >>> Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort >>> to make records a final feature of the Java Language. The rest of the code has been published in >>> [PR#290](https://github.com/openjdk/jdk/pull/290) Thanks, >>> Vicente >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> adding a comment to PreviewFeature.Feature > src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 114: > >> 112: /** >> 113: * A record type. >> 114: * @since 14 > The `@since` tags will all need to be updated to `16`, right? While I acknowledge that is what the current version of the JEP directs to happen in this situation, the API elements in question really are present in 14 and 15 so I don't think saying they are "since 16" is necessarily clearer. -Joe From plevart at openjdk.java.net Wed Sep 30 21:30:26 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 30 Sep 2020 21:30:26 GMT Subject: RFR: 8159746: (proxy) Support for default methods [v3] In-Reply-To: <8zAT7wr3UEpc3_urKByQrMHiJJqkrZ_ORhpQ_f8yciY=.d4fabdef-49b0-4979-a1bd-ef0fd5dfb097@github.com> References: <8zAT7wr3UEpc3_urKByQrMHiJJqkrZ_ORhpQ_f8yciY=.d4fabdef-49b0-4979-a1bd-ef0fd5dfb097@github.com> Message-ID: On Wed, 30 Sep 2020 19:14:28 GMT, Mandy Chung wrote: >> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke >> the given default method on the given proxy instance. >> >> The implementation looks up a method handle for `invokespecial` instruction >> as if called from with the proxy class as the caller, equivalent to calling >> `X.super::m` where `X` is a proxy interface of the proxy class and >> `X.super::m` will resolve to the specified default method. >> >> The implementation will call a private static `proxyClassLookup(Lookup caller)` >> method of the proxy class to obtain its private Lookup. This private method >> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class >> with full privilege access to use, or else `IllegalAccessException` will be >> thrown. >> >> This patch also proposes to define a proxy class in an unnamed module to >> a dynamic module to strengthen encapsulation such that they are only >> unconditionally exported from a named module but not open for deep reflective >> access. This only applies to the case if all the proxy interfaces are public >> and in a package that is exported or open. >> >> One dynamic module is created for each class loader that defines proxies. >> The change changes the dynamic module to contain another package (same >> name as the module) that is unconditionally exported and is opened to >> `java.base` only. >> >> There is no change to the package and module of the proxy class for >> the following cases: >> >> - if at least one proxy interface is non-public, then the proxy class is defined >> in the package and module of the non-public interfaces >> - if at least one proxy is in a package that is non-exported and non-open, >> if all proxy interfaces are public, then the proxy class is defined in >> a non-exported, non-open package of a dynamic module. >> >> The spec change is that a proxy class used to be defined in an unnamed >> module, i.e. in a exported and open package, is defined in an unconditionally >> exported but non-open package. Programs that assume it to be open unconditionally >> will be affected and cannot do deep reflection on such proxy classes. >> >> Peter Levart contributed an initial prototype [1] (thanks Peter). I think >> the exceptions could be simplified as more checking should be done prior to >> the invocation of the method handle like checking the types of the arguments >> with the method type. This approach avoids defining a public API >> `protected Proxy::$$proxyClassLookup$$` method. Instead it defines a >> private static method that is restricted for Proxy class to use (by >> taking a caller parameter to ensure it's a private lookup on Proxy class). >> >> javadoc/specdiff: >> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/ >> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/ >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html > > Mandy Chung 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: > - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method > - minor tweak to the spec wording and impl > - Merge pull request #1 from plevart/proxy-default-method-performance > > Performance improvements for Proxy::invokeDefaultMethod > - Add test case for InvocationTargetException > - Revert the thrown exceptions spec to be consistent with Method::invoke > - Speed up Proxy.invokeDefaultMethod while also changing its spec regarding exception types thrown > - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method > - fix regression tests due to proxy name change > - minor bug fix > - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/5b4fb338...db6cfc13 src/java.base/share/classes/java/lang/reflect/Proxy.java line 1256: > 1254: * {@code args} elements cannot be assigned to the corresponding > 1255: * method parameter type. > 1256: * Hm, well, on a second thought, the following: "...or if, after possible unboxing, any of the args elements cannot be assigned to the corresponding method parameter type" is not quite what happens. For example, if the method parameter type is primitive long and an Integer object is passed to the invokeDefaultMethod at its place, then according to above wording "after unboxing" we get an int value. Can int value be assigned to long parameter? What happens is that Integer object 1st tries to be cast to Long and only then unboxing happens. Such is the order of spreadArguments MH operator. ------------- PR: https://git.openjdk.java.net/jdk/pull/313 From plevart at openjdk.java.net Wed Sep 30 21:34:33 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 30 Sep 2020 21:34:33 GMT Subject: RFR: 8159746: (proxy) Support for default methods [v3] In-Reply-To: <8zAT7wr3UEpc3_urKByQrMHiJJqkrZ_ORhpQ_f8yciY=.d4fabdef-49b0-4979-a1bd-ef0fd5dfb097@github.com> References: <8zAT7wr3UEpc3_urKByQrMHiJJqkrZ_ORhpQ_f8yciY=.d4fabdef-49b0-4979-a1bd-ef0fd5dfb097@github.com> Message-ID: <0TfPuI3ZHSLDrT5vKnJSQet2Smi2s_xlKMNrJNHPTe4=.7815b857-dd6a-4306-b950-cf95801ce428@github.com> On Wed, 30 Sep 2020 19:14:28 GMT, Mandy Chung wrote: >> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke >> the given default method on the given proxy instance. >> >> The implementation looks up a method handle for `invokespecial` instruction >> as if called from with the proxy class as the caller, equivalent to calling >> `X.super::m` where `X` is a proxy interface of the proxy class and >> `X.super::m` will resolve to the specified default method. >> >> The implementation will call a private static `proxyClassLookup(Lookup caller)` >> method of the proxy class to obtain its private Lookup. This private method >> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class >> with full privilege access to use, or else `IllegalAccessException` will be >> thrown. >> >> This patch also proposes to define a proxy class in an unnamed module to >> a dynamic module to strengthen encapsulation such that they are only >> unconditionally exported from a named module but not open for deep reflective >> access. This only applies to the case if all the proxy interfaces are public >> and in a package that is exported or open. >> >> One dynamic module is created for each class loader that defines proxies. >> The change changes the dynamic module to contain another package (same >> name as the module) that is unconditionally exported and is opened to >> `java.base` only. >> >> There is no change to the package and module of the proxy class for >> the following cases: >> >> - if at least one proxy interface is non-public, then the proxy class is defined >> in the package and module of the non-public interfaces >> - if at least one proxy is in a package that is non-exported and non-open, >> if all proxy interfaces are public, then the proxy class is defined in >> a non-exported, non-open package of a dynamic module. >> >> The spec change is that a proxy class used to be defined in an unnamed >> module, i.e. in a exported and open package, is defined in an unconditionally >> exported but non-open package. Programs that assume it to be open unconditionally >> will be affected and cannot do deep reflection on such proxy classes. >> >> Peter Levart contributed an initial prototype [1] (thanks Peter). I think >> the exceptions could be simplified as more checking should be done prior to >> the invocation of the method handle like checking the types of the arguments >> with the method type. This approach avoids defining a public API >> `protected Proxy::$$proxyClassLookup$$` method. Instead it defines a >> private static method that is restricted for Proxy class to use (by >> taking a caller parameter to ensure it's a private lookup on Proxy class). >> >> javadoc/specdiff: >> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/ >> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/ >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html > > Mandy Chung 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: > - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method > - minor tweak to the spec wording and impl > - Merge pull request #1 from plevart/proxy-default-method-performance > > Performance improvements for Proxy::invokeDefaultMethod > - Add test case for InvocationTargetException > - Revert the thrown exceptions spec to be consistent with Method::invoke > - Speed up Proxy.invokeDefaultMethod while also changing its spec regarding exception types thrown > - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method > - fix regression tests due to proxy name change > - minor bug fix > - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/3112f91d...db6cfc13 src/java.base/share/classes/java/lang/reflect/Proxy.java line 1256: > 1254: * {@code args} elements cannot be assigned to the corresponding > 1255: * method parameter type. > 1256: * After trying it in practice, I see your words are correct. 1st unboxing happens and then assignment. ------------- PR: https://git.openjdk.java.net/jdk/pull/313 From mchung at openjdk.java.net Wed Sep 30 21:50:54 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 30 Sep 2020 21:50:54 GMT Subject: RFR: 8204256: improve jlink error message to report unsupported class file format In-Reply-To: <4G3_8Xep8bMY6mC17exBywM_HTJNLQI_JJkURTzg8QU=.6b26d80c-3e4d-46a5-abfe-1ff58af8b51f@github.com> References: <4G3_8Xep8bMY6mC17exBywM_HTJNLQI_JJkURTzg8QU=.6b26d80c-3e4d-46a5-abfe-1ff58af8b51f@github.com> Message-ID: On Wed, 30 Sep 2020 10:56:46 GMT, Alan Bateman wrote: >> This pull request contains a change to facilitate better error messages in jlink for when jlink creates an image from >> jmod files that are unsupported by the runtime by being _too new_. The existing behavior supports modules that are too >> old via an error about a mismatched version. The solution to this problem is constrained by jlink's use of some >> specified behavior by java.lang.module.ModuleFinder. The solution in this PR is to subclass some existing exceptions >> internally as to signal to jlink more specific error conditions when attempting to find and open modules. Bug here: >> https://bugs.openjdk.java.net/browse/JDK-8204256 >> New Error message example: >> >> `Error: jlink encountered a java.base jmod with unsupported module descriptor version 60.0` > > This impacts the java.lang.module API. I think I'd prefer to drop all changes to jdk.internal.module from this patch > and instead focus on a jlink specific change. Maybe `ModulePath` can provide a method to open an input stream of the `module-info.class` of the named module found on the module path. jlink can then parse the class file to check if the major and minor version is supported class file version. Or a simpler solution is to concatenate the `FindException` message with the exception message of the cause. This will also cover other error cases besides unsupported class file version. ------------- PR: https://git.openjdk.java.net/jdk/pull/409 From igraves at openjdk.java.net Wed Sep 30 22:17:20 2020 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 30 Sep 2020 22:17:20 GMT Subject: RFR: 8204256: improve jlink error message to report unsupported class file format In-Reply-To: References: <4G3_8Xep8bMY6mC17exBywM_HTJNLQI_JJkURTzg8QU=.6b26d80c-3e4d-46a5-abfe-1ff58af8b51f@github.com> Message-ID: On Wed, 30 Sep 2020 21:48:12 GMT, Mandy Chung wrote: >> This impacts the java.lang.module API. I think I'd prefer to drop all changes to jdk.internal.module from this patch >> and instead focus on a jlink specific change. > > Maybe `ModulePath` can provide a method to open an input stream of the `module-info.class` of the named module found on > the module path. jlink can then parse the class file to check if the major and minor version is supported class file > version. Or a simpler solution is to concatenate the `FindException` message with the exception message of the cause. > This will also cover other error cases besides unsupported class file version. @mlchung's second suggestion would be the easiest route to take. I wanted to avoid fishing into exception messages or anything along those lines. The initial work to this fix was to explore how tricky attaining that kind of parity is. Alternatively we could change the existing exception message path and modify it so it's in line with the simpler solution as well? That makes sense to me, anyway. ------------- PR: https://git.openjdk.java.net/jdk/pull/409 From mchung at openjdk.java.net Wed Sep 30 22:24:23 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 30 Sep 2020 22:24:23 GMT Subject: RFR: 8204256: improve jlink error message to report unsupported class file format In-Reply-To: References: <4G3_8Xep8bMY6mC17exBywM_HTJNLQI_JJkURTzg8QU=.6b26d80c-3e4d-46a5-abfe-1ff58af8b51f@github.com> Message-ID: On Wed, 30 Sep 2020 22:14:43 GMT, Ian Graves wrote: > Alternatively we could change the existing exception message path and modify it so it's in line with the simpler > solution as well? That makes sense to me, anyway. Sounds reasonable to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/409 From alex.buckley at oracle.com Wed Sep 30 22:57:35 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 30 Sep 2020 15:57:35 -0700 Subject: RFR: 8253455: Record Classes javax.lang.model changes [v5] In-Reply-To: <74fa9c6a-2345-6364-ac74-96ce508d3fae@oracle.com> References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> <74fa9c6a-2345-6364-ac74-96ce508d3fae@oracle.com> Message-ID: On 9/30/2020 2:29 PM, Joe Darcy wrote: >>> Vicente Romero has updated the pull request incrementally with one >>> additional commit since the last revision: >>> >>> ?? adding a comment to PreviewFeature.Feature >> src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java >> line 114: >> >>> 112:???? /** >>> 113:????? * A record type. >>> 114:????? * @since 14 >> The `@since` tags will all need to be updated to `16`, right? > > While I acknowledge that is what the current version of the JEP directs > to happen in this situation, the API elements in question really are > present in 14 and 15 so I don't think saying they are "since 16" is > necessarily clearer. The reason that JEP 12 says to have @since reflect the final-and-permanent release rather than a preview release is to provide a JEP owner with a simple rule that applies regardless of whether an API element evolves between preview and permanent status. Just because an API element exists in 14 and 15 (as preview) and 16 (as permanent) doesn't mean it has exactly the same semantics in 16 as in 14 or 15 -- previewing is the one avenue by which an element can materially change its behavior between 14 and 15 and 16. Also, where API elements are previewed over time, the choice to have some elements be @since 14 while others are @since 15 or @since 16 would cause confusion in future -- "Are the 14 and 15-era elements associated with records considered to be final, given that records weren't finalized until 16? Might the 14 and 15-era elements be removed one day?" -- so I think it's best to focus @since consistently on the release where a feature becomes final-and-permanent. Alex From ccheung at openjdk.java.net Wed Sep 30 23:17:18 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 30 Sep 2020 23:17:18 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 03:43:51 GMT, Ioi Lam wrote: >> Following up on archiving lambda proxy classes in dynamic CDS archive >> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of >> lambda proxy classes in static CDS archive. >> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved >> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will >> be of the following format: >> `@lambda-proxy: ` >> >> e.g. >> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` >> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` >> >> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above >> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool >> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool >> entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index >> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. >> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not >> found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> >> IsCDSDumpingEnabled) is involved in the core-libs code.) >> Testing: tiers 1,2,3,4. >> >> Performance results (javac on HelloWorld on linux-x64): >> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " >> 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- >> 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- >> 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- >> 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- >> 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- >> 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- >> 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- >> 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- >> 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- >> 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- >> ============================================================ >> 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- >> instr delta = -161497801 -7.2542% >> time delta = -24.722 ms -6.5951% > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 336: > >> 334: >> 335: static unsigned int dumptime_hash(Symbol* sym) { >> 336: if (sym == NULL) { > > How about adding a comment "_invoked_name may be NULL"? Comment added. > src/hotspot/share/classfile/systemDictionaryShared.cpp line 2300: > >> 2298: >> 2299: class ArchivedLambdaMirrorPatcher { >> 2300: static void update(Klass* k) { > > I think ArchivedLambdaMirrorPatcher can be subclass of ArchivedMirrorPatcher. That way you can share the same code for > ArchivedMirrorPatcher::update (you can make this a protected method). I've changed the ArchivedLambdaMirrorPatcher to the following: class ArchivedLambdaMirrorPatcher : public ArchivedMirrorPatcher { public: void do_value(const RunTimeLambdaProxyClassInfo* info) { InstanceKlass* ik = info->proxy_klass_head(); while (ik != NULL) { update(ik); Klass* k = ik->next_link(); ik = (k != NULL) ? InstanceKlass::cast(k) : NULL; } } }; > src/hotspot/share/classfile/systemDictionaryShared.cpp line 2242: > >> 2240: st->print_cr("Dynamic Shared Lambda Dictionary"); >> 2241: SharedLambdaDictionaryPrinter ldp(st); >> 2242: _dynamic_lambda_proxy_class_dictionary.iterate(&ldp); > > I think this function can be refactored, something like: > > SystemDictionaryShared::print_on(outputStream* st) { > if (UseSharedSpaces) { > print_on("", &_builtin_dictionary, &_unregistered_dictionary, &_lambda_proxy_class_dictionary); > if (DynamicArchive::is_mapped()) { > print_on("Dynamic ", &dynamic__builtin_dictionary, &_dynamic_unregistered_dictionary, > &_dynamic_lambda_proxy_class_dictionary); > } > } > } I've added the following print_on function for code refactoring: void SystemDictionaryShared::print_on(const char* prefix, RunTimeSharedDictionary builtin_dictionary, RunTimeSharedDictionary unregistered_dictionary, LambdaProxyClassDictionary lambda_dictionary, outputStream* st) { st->print_cr("%sShared Dictionary", prefix); SharedDictionaryPrinter p(st); builtin_dictionary.iterate(&p); unregistered_dictionary.iterate(&p); if (!lambda_dictionary.empty()) { st->print_cr("%sShared Lambda Dictionary", prefix); SharedLambdaDictionaryPrinter ldp(st); lambda_dictionary.iterate(&ldp); } } > src/hotspot/share/classfile/systemDictionaryShared.cpp line 1984: > >> 1982: int compare_runtime_lambda_proxy_class_info(const RunTimeLambdaProxyClassNode& r1, >> 1983: const RunTimeLambdaProxyClassNode& r2) { >> 1984: ResourceMark rm; > > Is this function being used? No, it is an unused function. I've removed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/364 From almatvee at openjdk.java.net Wed Sep 30 23:18:37 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 30 Sep 2020 23:18:37 GMT Subject: RFR: 8253747: tools/jpackage/share/AppImagePackageTest.java fails with InstalledPackageSize: 0 In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 15:50:36 GMT, Andy Herrick wrote: > 8253747: tools/jpackage/share/AppImagePackageTest.java fails with InstalledPackageSize: 0 > Updated Debian code in test to get package size in BK, allowing for non-zero size less than 1KB Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/404 From ccheung at openjdk.java.net Wed Sep 30 23:25:00 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 30 Sep 2020 23:25:00 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v2] In-Reply-To: References: Message-ID: > Following up on archiving lambda proxy classes in dynamic CDS archive > ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of > lambda proxy classes in static CDS archive. > When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved > during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will > be of the following format: > `@lambda-proxy: ` > > e.g. > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` > > When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above > `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool > indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool > entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index > and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. > During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not > found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> > IsCDSDumpingEnabled) is involved in the core-libs code.) > Testing: tiers 1,2,3,4. > > Performance results (javac on HelloWorld on linux-x64): > Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " > 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- > 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- > 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- > 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- > 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- > 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- > 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- > 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- > 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- > 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- > ============================================================ > 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- > instr delta = -161497801 -7.2542% > time delta = -24.722 ms -6.5951% Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/364/files - new: https://git.openjdk.java.net/jdk/pull/364/files/4a55fddc..d66667d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=00-01 Stats: 68 lines in 2 files changed: 23 ins; 41 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364 PR: https://git.openjdk.java.net/jdk/pull/364 From rriggs at openjdk.java.net Wed Sep 30 23:38:54 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 30 Sep 2020 23:38:54 GMT Subject: RFR: 8253883: Problem list jdk/test/lib/hexdump/ASN1Formatter on Windows Message-ID: The new lib-test/jdk/test/lib/hexdump/ASN1FormatterTest should be put on the problem list until the problem with newline counting on Windows is fixed. ------------- Commit messages: - Put ASN1FormatterTest on the Problem list until it is fixed. Changes: https://git.openjdk.java.net/jdk/pull/448/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=448&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253883 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/448/head:pull/448 PR: https://git.openjdk.java.net/jdk/pull/448 From lancea at openjdk.java.net Wed Sep 30 23:47:52 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 30 Sep 2020 23:47:52 GMT Subject: RFR: 8253883: Problem list jdk/test/lib/hexdump/ASN1Formatter on Windows In-Reply-To: References: Message-ID: <8icQwl7NbMKlJMaHxh6X2Pux4E1--xLjAKaQoy_qpT4=.f2d1bceb-a024-4113-aa07-130c0f38d0d7@github.com> On Wed, 30 Sep 2020 23:31:55 GMT, Roger Riggs wrote: > The new lib-test/jdk/test/lib/hexdump/ASN1FormatterTest should be put on the problem list until the problem with > newline counting on Windows is fixed. looks good ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/448 From rriggs at openjdk.java.net Wed Sep 30 23:47:53 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 30 Sep 2020 23:47:53 GMT Subject: Integrated: 8253883: Problem list jdk/test/lib/hexdump/ASN1Formatter on Windows In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 23:31:55 GMT, Roger Riggs wrote: > The new lib-test/jdk/test/lib/hexdump/ASN1FormatterTest should be put on the problem list until the problem with > newline counting on Windows is fixed. This pull request has now been integrated. Changeset: 05a764f4 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/05a764f4 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8253883: Problem list jdk/test/lib/hexdump/ASN1Formatter on Windows Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/448 From joe.darcy at oracle.com Wed Sep 30 23:48:32 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Sep 2020 16:48:32 -0700 Subject: RFR: 8253455: Record Classes javax.lang.model changes [v5] In-Reply-To: References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> <74fa9c6a-2345-6364-ac74-96ce508d3fae@oracle.com> Message-ID: <2b78ecff-a1a1-d465-1183-2e054bb4ba84@oracle.com> On 9/30/2020 3:57 PM, Alex Buckley wrote: > On 9/30/2020 2:29 PM, Joe Darcy wrote: >>>> Vicente Romero has updated the pull request incrementally with one >>>> additional commit since the last revision: >>>> >>>> ?? adding a comment to PreviewFeature.Feature >>> src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java >>> line 114: >>> >>>> 112:???? /** >>>> 113:????? * A record type. >>>> 114:????? * @since 14 >>> The `@since` tags will all need to be updated to `16`, right? >> >> While I acknowledge that is what the current version of the JEP >> directs to happen in this situation, the API elements in question >> really are present in 14 and 15 so I don't think saying they are >> "since 16" is necessarily clearer. > > The reason that JEP 12 says to have @since reflect the > final-and-permanent release rather than a preview release is to > provide a JEP owner with a simple rule that applies regardless of > whether an API element evolves between preview and permanent status. > Just because an API element exists in 14 and 15 (as preview) and 16 > (as permanent) doesn't mean it has exactly the same semantics in 16 as > in 14 or 15 -- previewing is the one avenue by which an element can > materially change its behavior between 14 and 15 and 16. Conversely, the fact that an API element is preview on one release and non-preview in a subsequent one does not necessarily imply the spec has changed. (Although it might have changed, of course.) Non-preview methods don't necessarily have *exactly* the same semantics between releases either, subject to our general API evolution policies. > Also, where API elements are previewed over time, the choice to have > some elements be @since 14 while others are @since 15 or @since 16 > would cause confusion in future -- "Are the 14 and 15-era elements > associated with records considered to be final, given that records > weren't finalized until 16? Might the 14 and 15-era elements be > removed one day?" -- so I think it's best to focus @since consistently > on the release where a feature becomes final-and-permanent. > Another kind of consistency would be "use the @since tag for the release the API element was first added." For readers, it would be a simple rule that non-preview and not-deprecated-for-removal API elements can be assumed to be present in the next release. -Joe From tonytao0505 at outlook.com Sun Sep 27 08:24:28 2020 From: tonytao0505 at outlook.com (tonytao) Date: Sun, 27 Sep 2020 16:24:28 +0800 Subject: [Lambda]parallel sort stream slow than series sort In-Reply-To: References: Message-ID: Hi Roberts, Thank for your warmly help. I debugged into stream? parallel it seems parallel stream use a ArrayListSpliterator split? list into pieces in jdk11 and 14,not a? mutual exclusion.Test arrays was retrieved? from postgresql,but all data was ready before running test .I rewriteed the data-generate code in java. hi Vladimir, I tested in jdk14: openjdk version "14.0.2" 2020-07-14 OpenJDK Runtime Environment (build 14.0.2+12-46) OpenJDK 64-Bit Server VM (build 14.0.2+12-46, mixed mode, sharing) parallel sort still slower than series sort. sorted execute time:274ms, resultset rows 5000000, 18248175 rows/sec parallel sorted execute time:627ms, resultset rows 5000000, 7974481 rows/sec hi Roberts & Peter, Here is the test code: int rowCount= 5000000; LocalDateTime d= LocalDateTime.now(); List data= new ArrayList<>(); List data2= new ArrayList<>(); long startTime= System.currentTimeMillis(); for (int i= 0; i< rowCount; i++) { Object[] row= new Object[3]; row[0] = i; d= d.plusMinutes(1); row[1] = java.sql.Date.valueOf(d.toLocalDate()); row[2] = DigestUtils.md5Hex(row[1].toString()); data.add(row); data2.add(row); } long endTime= System.currentTimeMillis(); System.out.println("read data execute time:" + (endTime- startTime) + "ms, resultset rows " + rowCount+ ", " + rowCount* 1000 / (endTime- startTime) + " rows/sec"); for (int i= 0; i< 1; i++) { for (Object x: data.get(i)) { System.out.println("data type: " + x.getClass() + ", value: " + x); } } Comparator comparator= new Comparator() { @Override public int compare(Object[] o1, Object[] o2) { int res= 0; for (int i= 0; i< o1.length; i++) { res= ((Comparable) o1[i]).compareTo(o2[i]); if (res!= 0) { break; } } return res; } }; List list; List l= Collections.unmodifiableList(data); startTime= System.currentTimeMillis(); list= data.stream().sorted(comparator).collect(Collectors.toList()); endTime= System.currentTimeMillis(); System.out.println("sorted execute time:" + (endTime- startTime) + "ms, resultset rows " + list.size() + ", " + (long) list.size() * 1000 / (endTime- startTime) + " rows/sec"); startTime= System.currentTimeMillis(); list= data2.stream().parallel().sorted(comparator).collect(Collectors.toList()); endTime= System.currentTimeMillis(); System.out.println("parallel sorted execute time:" + (endTime- startTime) + "ms, resultset rows " + list.size() + ", " + (long) list.size() * 1000 / (endTime- startTime) + " rows/sec"); You could run it in you ide,it depened on: ??? ??? ??? ??? ??? org.apache.commons ??? ??? ??? commons-lang3 ??? ??? ??? 3.11 ??? ??? Thanks again! Tao Jin. On 9/26/20 1:56 AM, Simon Roberts wrote: > Tests like this are rarely meaningful. In particular you have a random > number generator in there. They are often built on single threaded > code protected by mutual exclusion. That of itself prevents the code > ever going faster than sequential code, and in fact usually makes it > slower due to the additional overhead of inter-thread communication. > > Further, your example seems to be a test of a database and its driver, > and has no obvious relationship to either the Streams API or anything > in the core Java libraries. Perhaps I miss something. > > > On Fri, Sep 25, 2020 at 4:09 AM tonytao > wrote: > > hi, > > I wrote a test case to test stream performance,but the parallel sort > always slow than the series sort.I test the data size in : 20,000 , > 5,000,000, 10,000,000 , 20,000,000 . > > attatched is the test case source code. > > jdk version : > > openjdk version "11.0.8" 2020-07-14 > OpenJDK Runtime Environment (build 11.0.8+10-post-Debian-1deb10u1) > OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Debian-1deb10u1, mixed > mode, sharing) > > jvm argument: > > -ea -Xms256m -Xmx8192m > > macheine: > > cpu:Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz > > memory: 16GB > > Test? result shows as below: > > 20000: > > sorted execute time:9ms, resultset rows 20000, 2222222 rows/sec > parallel sorted execute time:24ms, resultset rows 20000, 833333 > rows/sec > > 5000000: > > sorted execute time:245ms, resultset rows 5000000, 20408163 rows/sec > parallel sorted execute time:402ms, resultset rows 5000000, 12437810 > rows/sec > > 10000000: > > sorted execute time:577ms, resultset rows 10000000, 17331022 rows/sec > parallel sorted execute time:1230ms, resultset rows 10000000, 8130081 > rows/sec > > 20000000: > > sorted execute time:1079ms, resultset rows 20000000, 18535681 rows/sec > parallel sorted execute time:1790ms, resultset rows 20000000, > 11173184 > rows/sec > > > this is the test data sample: > > hdb=> select * from testdata limit 10; > ??? id??? |?????????? uptime?????????? | x? | y? | cmt > ---------+----------------------------+----+----+---------------------------------- > ??1340417 | 2023-02-22 07:30:34.391207 | 33 |? 9 | > 4bf16d4c4b638d84b56893de2451c407 > ??1340418 | 2023-02-22 07:31:34.391207 | 10 | 91 | > c9b78bfbd6b684e62605e96d2d8237a0 > ??1340419 | 2023-02-22 07:32:34.391207 | 66 | 24 | > 968e5d19ca3a2ddae5d2a366ba06cf16 > ??1340420 | 2023-02-22 07:33:34.391207 |? 4 | 42 | > bdcf7d764121fc9b0039f80eadea1310 > ??1340421 | 2023-02-22 07:34:34.391207 | 27 | 45 | > 06520ac5e508f15f09672fa751d5c17a > ??1340422 | 2023-02-22 07:35:34.391207 | 36 | 11 | > 5bede83b54dfe76f4a249308d8033691 > ??1340423 | 2023-02-22 07:36:34.391207 | 41 | 92 | > 37f4b34988c0e1387940177a8cc9d83a > ??1340424 | 2023-02-22 07:37:34.391207 | 29 | 59 | > 416459b54ae00c95e118c93605a40d43 > ??1340425 | 2023-02-22 07:38:34.391207 |? 9 | 46 | > 46339b8eeae99c7e922003ed87b9d417 > ??1340426 | 2023-02-22 07:39:34.391207 | 21 | 29 | > 7ede63cdb2a6a86c63534fe5fcfb2f97 > (10 rows) > > > It was generated by sql: > > create? table? testdata( > ? ? ?idint, > ? ? ?uptimetimestamp, > ? ? ?xint, > ? ? ?yint, > ? ? ?cmttext > ); > insert? into? testdata > ? ? ?select > ? ? ? ? ?id, > ? ? ? ? ?uptime, > ? ? ? ? ?round(random()*100), > ? ? ? ? ?round(random()*100), > ? ? ? ? ?md5(uptime::text) > ? ? ?from? ( > ? ? ? ? ?select > ? ? ? ? ? ? ?generate_series id, > ? ? ? ? ? ? ?current_timestamp? +? make_interval(mins=> > generate_series)? uptime > ? ? ? ? ?from? generate_series(1,100000000) > ? ? ? ? ?)? t; > > > Could you please help me to find the problem? > > Thanks a lot. > > > > > > -- > Simon Roberts > (303) 249 3613 >