From goetz.lindenmaier at sap.com Mon Jun 1 07:18:33 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 1 Jun 2020 07:18:33 +0000 Subject: [11u] RFR: 8231586: enlarge encoding space for OopMapValue offsets In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing! Best regards, Goetz -----Original Message----- From: Doerr, Martin Sent: Freitag, 29. Mai 2020 14:52 To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8231586: enlarge encoding space for OopMapValue offsets Hi G?tz, backport looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Donnerstag, 28. Mai 2020 21:28 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8231586: enlarge encoding space for > OopMapValue offsets > > Hi, > > I would like to downport this for parity with 11.0.9-oracle. > > I had to resolve oopMap.cpp:326. > The code indented within the new if (omv.type() == > OopMapValue::derived_oop_value) differs slightly. > > http://cr.openjdk.java.net/~goetz/wr20/8231586-OopMapValues- > jdk11/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8231586 > https://hg.openjdk.java.net/jdk/jdk/rev/f9cc0141574c > > Please review. > > Best regards, > Goetz. From goetz.lindenmaier at sap.com Mon Jun 1 07:18:54 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 1 Jun 2020 07:18:54 +0000 Subject: [11u] RFR: 8232083: Minimal VM is broken after JDK-8231586 In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing! Best regards, Goetz -----Original Message----- From: Doerr, Martin Sent: Freitag, 29. Mai 2020 14:48 To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8232083: Minimal VM is broken after JDK-8231586 Hi G?tz, backport looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Donnerstag, 28. Mai 2020 22:04 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 8232083: Minimal VM is broken after JDK- > 8231586 > > Hi, > > I had to resolve as the code indented after removal of two nested { > differs. Please review. > > http://cr.openjdk.java.net/~goetz/wr20/8232083-Minimal_VM- > after_8321586/01/ > https://bugs.openjdk.java.net/browse/JDK-8232083 > https://hg.openjdk.java.net/jdk/jdk/rev/3df2bf731a87 > > Best regards, > Goetz. From zgu at redhat.com Mon Jun 1 20:21:44 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 1 Jun 2020 16:21:44 -0400 Subject: [14] RFR 8242602: Shenandoah: allow earlier recycle of trashed regions during concurrent root processing Message-ID: <9fd821ae-d724-8a92-5a66-d2f2ca20482c@redhat.com> Hi, I would like to backport this patch to 14u. Early recycling immediate trash regions, provides additional head room for GC to avoid allocation failures, especially, when concurrent class unloading can take quite some time. The original patch does not apply cleanly, but the conflicts are minor, due to line shifts in ShenandoahHeap.cpp. Original Bug: https://bugs.openjdk.java.net/browse/JDK-8242602 Original Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242602/webrev.01/ 14u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242602-14u/webrev.00/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu From rob.mckenna at oracle.com Mon Jun 1 22:21:02 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 1 Jun 2020 23:21:02 +0100 Subject: [14u Communication] 14.0.2 higher bar In-Reply-To: <20200218171508.GB16228@yoga> References: <20200218171508.GB16228@yoga> Message-ID: <20200601222102.GA2075@DESKTOP-JNNKIHU.localdomain> Hi folks, Its getting late in the 14.0.2 cycle so I'm sending a quick message to let you know that from next week we will likely only accept showstoppers or critical regressions for 14.0.2. -Rob From goetz.lindenmaier at sap.com Tue Jun 2 15:59:00 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Jun 2020 15:59:00 +0000 Subject: [11u] RFR: 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR Message-ID: Hi I would like to downport this for parity with 11.0.9-oracle. It applies clean but keytool/Main.java does not compile. It calls fullDisplayAlgName() to print the warning which is not in 11. I included this rather simple function. This results in the same printout as in jdk15 and makes sure later changes (8172404) downport clean. http://cr.openjdk.java.net/~goetz/wr20/8233228-disable_weak_curves-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8233228 https://hg.openjdk.java.net/jdk/jdk14/rev/169e9680821c Best regards, Goetz. From aph at redhat.com Wed Jun 3 08:29:46 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 3 Jun 2020 09:29:46 +0100 Subject: [11u] RFR: 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR In-Reply-To: References: Message-ID: On 02/06/2020 16:59, Lindenmaier, Goetz wrote: > http://cr.openjdk.java.net/~goetz/wr20/8233228-disable_weak_curves-jdk11/01/ > > Please review. Looks good. My God, what a mess elliptic-curve cryptography can be when used in the real world! [1] It makes me yearn for the good old simplicity of RSA, and reminds us all how easy it is to be tempted by the call of "efficient" public-key cryptography. [1] http://safecurves.cr.yp.to/ -- 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 dcherepanov at azul.com Wed Jun 3 10:09:32 2020 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Wed, 3 Jun 2020 13:09:32 +0300 Subject: [13u] RFR 8232357: Compare version info of Santuario to legal notice Message-ID: <16d062c9-9a5b-1668-1f2a-165faf61a26c@azul.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8232357 original patch: https://hg.openjdk.java.net/jdk/jdk/rev/7322c48a84cf webrev for 13u: http://cr.openjdk.java.net/~dcherepanov/openjdk13u/8232357/webrev.v0/ The patch applies cleanly except the comment in XMLDSigRI.java (the comment already present in 13u after update to version 2.1.4). Thanks, Dmitry From dcherepanov at azul.com Wed Jun 3 10:33:16 2020 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Wed, 3 Jun 2020 13:33:16 +0300 Subject: [13u] RFR 8234728: Some security tests should support TLSv1.3 Message-ID: JBS: https://bugs.openjdk.java.net/browse/JDK-8234728 original patch: https://hg.openjdk.java.net/jdk/jdk14/rev/fa82151f29c4 webrev for 13u: http://cr.openjdk.java.net/~dcherepanov/openjdk13u/8234728/webrev.v0/ The change in NullHostnameCheck.java doesn?t apply due to different context (8228967 isn?t in 13u), re-applied manually. Other parts apply cleanly. Thanks, Dmitry From matthias.baesken at sap.com Wed Jun 3 10:43:44 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 3 Jun 2020 10:43:44 +0000 Subject: RFR [jdk11]: 8242141: New System Properties to configure the TLS signature schemes In-Reply-To: References: Message-ID: Hi Goetz, thanks for the review ! >This are really trivial resolves. >The change to SessionTicketExtension can be dropped. That file came with 1. >JDK-8211018 Session Resumption without Server-Side State >which is an enhancement not in 11. So there is no other place for >that code in 11. > >Reviewed. From abrygin at azul.com Wed Jun 3 14:22:27 2020 From: abrygin at azul.com (Andrew Brygin) Date: Wed, 3 Jun 2020 17:22:27 +0300 Subject: [13u] RFR 8234728: Some security tests should support TLSv1.3 In-Reply-To: References: Message-ID: <6327776e-c577-716b-628c-69fff2d1bf65@azul.com> Hello Dmitry, the change looks fine to me. Thanks, Andrew On 03/06/2020 13:33, Dmitry Cherepanov wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8234728 > original patch: https://hg.openjdk.java.net/jdk/jdk14/rev/fa82151f29c4 > webrev for 13u: > http://cr.openjdk.java.net/~dcherepanov/openjdk13u/8234728/webrev.v0/ > > The change in NullHostnameCheck.java doesn?t apply due to different > context (8228967 isn?t in 13u), re-applied manually. > Other parts apply cleanly. > > Thanks, > > Dmitry From goetz.lindenmaier at sap.com Wed Jun 3 14:31:00 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 3 Jun 2020 14:31:00 +0000 Subject: [11u] RFR: 8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?" Message-ID: Hi, I am downporting this for parity with 11.0.9-oracle. I had to resolve the test description. I added the @requires, it is useful in any case. http://cr.openjdk.java.net/~goetz/wr20/8230402-leaking_tasks-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8230402 https://hg.openjdk.java.net/jdk/jdk/rev/2ca886fd1d52 Best regards, Goetz. From yan at azul.com Wed Jun 3 14:50:12 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 3 Jun 2020 17:50:12 +0300 Subject: [13u] RFR 8232357: Compare version info of Santuario to legal notice In-Reply-To: <16d062c9-9a5b-1668-1f2a-165faf61a26c@azul.com> References: <16d062c9-9a5b-1668-1f2a-165faf61a26c@azul.com> Message-ID: Looks good and harmless to me --yan On 03.06.2020 13:09, Dmitry Cherepanov wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8232357 > original patch: https://hg.openjdk.java.net/jdk/jdk/rev/7322c48a84cf > webrev for 13u: http://cr.openjdk.java.net/~dcherepanov/openjdk13u/8232357/webrev.v0/ > > The patch applies cleanly except the comment in XMLDSigRI.java (the comment already present in 13u > after update to version 2.1.4). > > Thanks, > > Dmitry From shade at redhat.com Wed Jun 3 18:28:54 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 3 Jun 2020 20:28:54 +0200 Subject: [14] RFR: 8246100: Shenandoah: walk roots in more efficient order Message-ID: <2da2dd1a-64b4-8ad1-6b1d-43d4e6864d8a@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8246100 https://cr.openjdk.java.net/~shade/8246100/webrev.14u.01/ The context in 14u is a bit different. Re-did the patch, by shuffling the lines in the existing files. 14u webrev: https://cr.openjdk.java.net/~shade/8246100/webrev.14u.01/ Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah enabled -- Thanks, -Aleksey From shade at redhat.com Wed Jun 3 18:30:24 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 3 Jun 2020 20:30:24 +0200 Subject: [14] RFR 8246097: Shenandoah: limit parallelism in CLDG root handling Message-ID: <314697e8-dd39-87ec-60d1-4311ebb04587@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8246097 https://hg.openjdk.java.net/jdk/jdk/rev/c60f06714a9e The context in 14u is a bit different. Trivial application of the rejected hunks by hand. http://cr.openjdk.java.net/~shade/8246097/webrev.14u.01/ Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah enabled -- Thanks, -Aleksey From zgu at redhat.com Wed Jun 3 19:42:34 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 3 Jun 2020 15:42:34 -0400 Subject: [14] RFR: 8246100: Shenandoah: walk roots in more efficient order In-Reply-To: <2da2dd1a-64b4-8ad1-6b1d-43d4e6864d8a@redhat.com> References: <2da2dd1a-64b4-8ad1-6b1d-43d4e6864d8a@redhat.com> Message-ID: Looks good. -Zhengyu On 6/3/20 2:28 PM, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8246100 > https://cr.openjdk.java.net/~shade/8246100/webrev.14u.01/ > > The context in 14u is a bit different. Re-did the patch, by shuffling the lines in the existing > files. 14u webrev: > https://cr.openjdk.java.net/~shade/8246100/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah enabled > From zgu at redhat.com Wed Jun 3 19:43:45 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 3 Jun 2020 15:43:45 -0400 Subject: [14] RFR 8246097: Shenandoah: limit parallelism in CLDG root handling In-Reply-To: <314697e8-dd39-87ec-60d1-4311ebb04587@redhat.com> References: <314697e8-dd39-87ec-60d1-4311ebb04587@redhat.com> Message-ID: <39a1c24f-c721-3aa8-d671-2038975d80cf@redhat.com> Good. -Zhengyu On 6/3/20 2:30 PM, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8246097 > https://hg.openjdk.java.net/jdk/jdk/rev/c60f06714a9e > > The context in 14u is a bit different. Trivial application of the rejected hunks by hand. > http://cr.openjdk.java.net/~shade/8246097/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah enabled > From matthias.baesken at sap.com Thu Jun 4 09:49:13 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 4 Jun 2020 09:49:13 +0000 Subject: [11u] RFR: 8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?" Message-ID: Hi G?tz, I noticed a small diff regarding the timeout (and I find the timeouts in the test in https://hg.openjdk.java.net/jdk/jdk/rev/2ca886fd1d52) when comparing to jdk/jdk , was this intentional ? diff test/hotspot/jtreg/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.java /jdk11u-dev/test/hotspot/jtreg/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.java 29c29 < * @run main/othervm/timeout=300 -XX:-TieredCompilation -XX:CompileThreshold=2 -XX:CICompilerCount=1 --- > * @run main/othervm -XX:-TieredCompilation -XX:CompileThreshold=2 -XX:CICompilerCount=1 31c31 < * @run main/othervm/timeout=300 -XX:TieredCompileTaskTimeout=1000 -XX:CompileThresholdScaling=0.001 -XX:CICompilerCount=2 --- > * @run main/othervm -XX:TieredCompileTaskTimeout=1000 -XX:CompileThresholdScaling=0.001 -XX:CICompilerCount=2 Otherwise looks good. Best regards, Matthias >I am downporting this for parity with 11.0.9-oracle. >I had to resolve the test description. >I added the @requires, it is useful in any case. >http://cr.openjdk.java.net/~goetz/wr20/8230402-leaking_tasks-jdk11/01/ > >Please review. > > https://bugs.openjdk.java.net/browse/JDK-8230402 > https://hg.openjdk.java.net/jdk/jdk/rev/2ca886fd1d52 From goetz.lindenmaier at sap.com Thu Jun 4 10:33:51 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Jun 2020 10:33:51 +0000 Subject: [11u] RFR: 8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?" In-Reply-To: References: Message-ID: Oops, that's just the code I had to resolve. I didn't save the file, it was still open. Thanks for spotting this. New webrev: http://cr.openjdk.java.net/~goetz/wr20/8230402-leaking_tasks-jdk11/02/ Best regards, Goetz. From: Baesken, Matthias Sent: Thursday, June 4, 2020 11:49 AM To: jdk-updates-dev at openjdk.java.net; Lindenmaier, Goetz Subject: Re : [11u] RFR: 8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?" Hi G?tz, I noticed a small diff regarding the timeout (and I find the timeouts in the test in https://hg.openjdk.java.net/jdk/jdk/rev/2ca886fd1d52) when comparing to jdk/jdk , was this intentional ? diff test/hotspot/jtreg/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.java /jdk11u-dev/test/hotspot/jtreg/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.java 29c29 < * @run main/othervm/timeout=300 -XX:-TieredCompilation -XX:CompileThreshold=2 -XX:CICompilerCount=1 --- > * @run main/othervm -XX:-TieredCompilation -XX:CompileThreshold=2 -XX:CICompilerCount=1 31c31 < * @run main/othervm/timeout=300 -XX:TieredCompileTaskTimeout=1000 -XX:CompileThresholdScaling=0.001 -XX:CICompilerCount=2 --- > * @run main/othervm -XX:TieredCompileTaskTimeout=1000 -XX:CompileThresholdScaling=0.001 -XX:CICompilerCount=2 Otherwise looks good. Best regards, Matthias >I am downporting this for parity with 11.0.9-oracle. >I had to resolve the test description. >I added the @requires, it is useful in any case. >http://cr.openjdk.java.net/~goetz/wr20/8230402-leaking_tasks-jdk11/01/ > >Please review. > > https://bugs.openjdk.java.net/browse/JDK-8230402 > https://hg.openjdk.java.net/jdk/jdk/rev/2ca886fd1d52 From matthias.baesken at sap.com Thu Jun 4 10:56:18 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 4 Jun 2020 10:56:18 +0000 Subject: [11u] RFR: 8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?" In-Reply-To: References: Message-ID: Looks good to me . From: Lindenmaier, Goetz Sent: Donnerstag, 4. Juni 2020 12:34 To: Baesken, Matthias ; jdk-updates-dev at openjdk.java.net Subject: RE: Re : [11u] RFR: 8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?" Oops, that's just the code I had to resolve. I didn't save the file, it was still open. Thanks for spotting this. New webrev: http://cr.openjdk.java.net/~goetz/wr20/8230402-leaking_tasks-jdk11/02/ Best regards, Goetz. From: Baesken, Matthias > Sent: Thursday, June 4, 2020 11:49 AM To: jdk-updates-dev at openjdk.java.net; Lindenmaier, Goetz > Subject: Re : [11u] RFR: 8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?" Hi G?tz, I noticed a small diff regarding the timeout (and I find the timeouts in the test in https://hg.openjdk.java.net/jdk/jdk/rev/2ca886fd1d52) when comparing to jdk/jdk , was this intentional ? diff test/hotspot/jtreg/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.java /jdk11u-dev/test/hotspot/jtreg/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.java 29c29 < * @run main/othervm/timeout=300 -XX:-TieredCompilation -XX:CompileThreshold=2 -XX:CICompilerCount=1 --- > * @run main/othervm -XX:-TieredCompilation -XX:CompileThreshold=2 -XX:CICompilerCount=1 31c31 < * @run main/othervm/timeout=300 -XX:TieredCompileTaskTimeout=1000 -XX:CompileThresholdScaling=0.001 -XX:CICompilerCount=2 --- > * @run main/othervm -XX:TieredCompileTaskTimeout=1000 -XX:CompileThresholdScaling=0.001 -XX:CICompilerCount=2 Otherwise looks good. Best regards, Matthias >I am downporting this for parity with 11.0.9-oracle. >I had to resolve the test description. >I added the @requires, it is useful in any case. >http://cr.openjdk.java.net/~goetz/wr20/8230402-leaking_tasks-jdk11/01/ > >Please review. > > https://bugs.openjdk.java.net/browse/JDK-8230402 > https://hg.openjdk.java.net/jdk/jdk/rev/2ca886fd1d52 From suenaga at oss.nttdata.com Thu Jun 4 23:19:55 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 5 Jun 2020 08:19:55 +0900 Subject: [11u] RFA: 8242283: Can't start JVM when java home path includes non-ASCII character In-Reply-To: References: Message-ID: <17c1ac0c-53fd-1411-3124-e5bb645b8d10@oss.nttdata.com> Hi all, I've received email from Naoto (jdk-updates Reviewer), but it wasn't delivered because he hadn't subscribed jdk-update-dev. I share message from him: --- I reviewed the following 11u backport of the fix to 8242283, and it looks good to me. https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-April/003002.html I cannot reply directly on jdk-updates-dev as I am not subscribing to it. Naoto --- Thanks, Yasumasa On 2020/04/14 9:40, Yasumasa Suenaga wrote: > Hi all, > > Please approve this backport: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8242283 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242283/11u/webrev.00/ > ? original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/5f5876adb88c > > JVM fails to start on Windows with non-ASCII characters in the path if current regional format differs from the system locale. > We need to convert char* to wchar_t* to support long path, so I used CP_THREAD_ACP in MultiByteToWideChar(). > But we found CP_ACP works nicely rather than CP_THREAD_ACP. > > Using CP_THREAD_ACP was introduced in JDK-8240197 and JDK-8240725, however only JDK-8240197 has been backported to 11u. > So I want to apply original bug to 11u partially. (it makes the change for HotSpot only) > > > Thanks, > > Yasumasa From abrygin at azul.com Fri Jun 5 10:24:15 2020 From: abrygin at azul.com (Andrew Brygin) Date: Fri, 5 Jun 2020 13:24:15 +0300 Subject: [13u] RFR: 8235243 and 8235325 Message-ID: <44b85c2c-16cc-e905-5e17-8643f1b8bc0c@azul.com> Hello, I would like to backport following changes into 13u: Bug: https://bugs.openjdk.java.net/browse/JDK-8235243 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/775b714a2e49 Webrev: http://cr.openjdk.java.net/~bae/13u/8235243/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8235325 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/cfc005b8a117 Webrev: http://cr.openjdk.java.net/~bae/13u/8235325/webrev.00/ The fix for 8235325 resolves a build failure caused by the fix for 8235243, so it seems to be reasonable to join them into single review request. Both changes are exactly same as for 14, but should be applied to a different file: vm_version.cpp instead of abstract_vm_version.cpp, because fix for 8233787, which introduces the abstract_vm_version.cpp, is not backported to 13u. Thanks, Andrew From yan at azul.com Fri Jun 5 10:35:21 2020 From: yan at azul.com (Yuri Nesterenko) Date: Fri, 5 Jun 2020 13:35:21 +0300 Subject: [13u] RFR: 8235243 and 8235325 In-Reply-To: <44b85c2c-16cc-e905-5e17-8643f1b8bc0c@azul.com> References: <44b85c2c-16cc-e905-5e17-8643f1b8bc0c@azul.com> Message-ID: <9eb79d51-b5c9-e3a4-9d9a-d060d4e08320@azul.com> Fine with me! --yan On 05.06.2020 13:24, Andrew Brygin wrote: > Hello, > > I would like to backport following changes into 13u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235243 > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/775b714a2e49 > Webrev: http://cr.openjdk.java.net/~bae/13u/8235243/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235325 > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/cfc005b8a117 > Webrev: http://cr.openjdk.java.net/~bae/13u/8235325/webrev.00/ > > The fix for 8235325 resolves a build failure caused by the fix for > 8235243, so it seems to be reasonable to join them into single review > request. > > Both changes are exactly same as for 14, but should be applied to a > different file: vm_version.cpp instead of abstract_vm_version.cpp, > because fix for 8233787, which introduces the abstract_vm_version.cpp, > is not backported to 13u. > > Thanks, > Andrew > From goetz.lindenmaier at sap.com Fri Jun 5 11:13:33 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 5 Jun 2020 11:13:33 +0000 Subject: [11u] RFR: 8234149: Several regression tests do not dispose Frame at end Message-ID: Hi, I am downporting this for 11.0.9-oracle parity. I had to resolve a row of files: bug4796987.java: OS check in context different, easy resolve. bug6596966.java: simple resolve. Indented code differs again in os check. bug6470128.java, bug6580930.java, bug6827786.java, bug4202954.java, bug4624207.java all similar indentation issues. bug4962534.java, bug4634626.java: main method being fixed is only in 15 because "8213110: Remove the use of applets in automatic tests" is not in 11. I just copied the whole main method. This way these fixes can not be overseen in case 8213110 is brought to 11 at some point. http://cr.openjdk.java.net/~goetz/wr20/8234149-dispose_frame-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8234149 https://hg.openjdk.java.net/jdk/jdk/rev/7637e77c4c8a Best regards, Goetz. From goetz.lindenmaier at sap.com Fri Jun 5 13:32:51 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 5 Jun 2020 13:32:51 +0000 Subject: [11u] RFR: 8172404: Tools should warn if weak algorithms are used before restricting them Message-ID: Hi I downport this for parity with 11.0.9-oracle. I had to resolve a row of files. Main.java: This does not apply because 15 uses fullDisplayAlgName(). I adapted the code to use this, too. It comes with downport of 8233228 which is in work. Resources.java, TsacertOptionTest.java, Warning.java: Copyright only ConciseJarsigner.java, DefaultOptions.java, NameClash.java and EC.java are shell tests in 11. Moved fixes there. http://cr.openjdk.java.net/~goetz/wr20/8172404-warn_weak_algs-jdk11/01/ (Webrev somehow mentions 8233228, too, but the patch contains only the 8172404 Changes.) Please review. https://bugs.openjdk.java.net/browse/JDK-8172404 https://hg.openjdk.java.net/jdk/jdk/rev/6611a79f2ddf Best regards, Goetz From neugens at redhat.com Fri Jun 5 14:02:30 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 5 Jun 2020 16:02:30 +0200 Subject: CFV: New JDK Updates Committer: Jie Kang Message-ID: Hi all! I hereby nominate Jie Kang (jkang) [0] to JDK Updates Committer. Jie has backported a number of patches to OpenJDK 11u, in particular: JDK-8205516 JDK-8214896 JDK-8214925 JDK-8213448 JDK-8218935 JDK-8225694 JDK-8223697 JDK-8215771 JDK-8233075 JDK-8232806 JDK-8219904 Votes are due by 19h00 UTC on Friday, the 19th of June, 2020. Only current JDK Updates Committers (and above) [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Cheers, Mario [0] https://openjdk.java.net/census#jkang [1] https://openjdk.java.net/census#jdk-updates [2] http://openjdk.java.net/projects/#committer-vote -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From jianglizhou at google.com Fri Jun 5 17:03:08 2020 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 5 Jun 2020 10:03:08 -0700 Subject: RFR:[jdk11]:JDK-8213574: Deadlock in string table expansion when dumping lots of CDS classes In-Reply-To: References: Message-ID: [+christoph.langer at sap.com, +martinrb at google.com] Gentle ping Martin or Christoph, could you please review the backport? Thanks! Jiangli On Mon, May 18, 2020 at 2:31 PM Jiangli Zhou wrote: > > Please review the backport for JDK-8213574 to JDK 11: > > backport webrev: > http://cr.openjdk.java.net/~jiangli/8213574-jdk11-backport/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8213574 > > Original webrev: http://hg.openjdk.java.net/jdk/jdk/rev/d5eebe1e03fe > > CDS dumping may run into a deadlock situation during copying the > interned j.l.String objects in the VM thread, while the service thread > is concurrently expanding the string table. I ran into the deadlock > recently when creating a CDS archive with an input classlist of ~60K > classes on JDK 11. The backport addresses the deadlock issue. > > The diffs in symbolTable.cpp are not included in the backport as they > only apply to ConcurrentHashTable. In JDK 11 the SymbolTable is not > yet a ConcurrentHashTable. All other diffs in the patch applied > cleanly. > > Tested with tier1, jtreg/runtime/SharedArchiveFile > > Best, > Jiangli From martinrb at google.com Fri Jun 5 18:42:43 2020 From: martinrb at google.com (Martin Buchholz) Date: Fri, 5 Jun 2020 11:42:43 -0700 Subject: RFR:[jdk11]:JDK-8213574: Deadlock in string table expansion when dumping lots of CDS classes In-Reply-To: References: Message-ID: Looks good to me! On Fri, Jun 5, 2020 at 10:03 AM Jiangli Zhou wrote: > > [+christoph.langer at sap.com, +martinrb at google.com] > > Gentle ping > > Martin or Christoph, could you please review the backport? > > Thanks! > Jiangli > > > > On Mon, May 18, 2020 at 2:31 PM Jiangli Zhou wrote: > > > > Please review the backport for JDK-8213574 to JDK 11: > > > > backport webrev: > > http://cr.openjdk.java.net/~jiangli/8213574-jdk11-backport/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8213574 > > > > Original webrev: http://hg.openjdk.java.net/jdk/jdk/rev/d5eebe1e03fe > > > > CDS dumping may run into a deadlock situation during copying the > > interned j.l.String objects in the VM thread, while the service thread > > is concurrently expanding the string table. I ran into the deadlock > > recently when creating a CDS archive with an input classlist of ~60K > > classes on JDK 11. The backport addresses the deadlock issue. > > > > The diffs in symbolTable.cpp are not included in the backport as they > > only apply to ConcurrentHashTable. In JDK 11 the SymbolTable is not > > yet a ConcurrentHashTable. All other diffs in the patch applied > > cleanly. > > > > Tested with tier1, jtreg/runtime/SharedArchiveFile > > > > Best, > > Jiangli From jianglizhou at google.com Fri Jun 5 19:06:38 2020 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 5 Jun 2020 12:06:38 -0700 Subject: RFR:[jdk11]:JDK-8213574: Deadlock in string table expansion when dumping lots of CDS classes In-Reply-To: References: Message-ID: Thanks, Martin. Best, Jiangli On Fri, Jun 5, 2020 at 11:42 AM Martin Buchholz wrote: > > Looks good to me! > > On Fri, Jun 5, 2020 at 10:03 AM Jiangli Zhou wrote: > > > > [+christoph.langer at sap.com, +martinrb at google.com] > > > > Gentle ping > > > > Martin or Christoph, could you please review the backport? > > > > Thanks! > > Jiangli > > > > > > > > On Mon, May 18, 2020 at 2:31 PM Jiangli Zhou wrote: > > > > > > Please review the backport for JDK-8213574 to JDK 11: > > > > > > backport webrev: > > > http://cr.openjdk.java.net/~jiangli/8213574-jdk11-backport/webrev.00/ > > > https://bugs.openjdk.java.net/browse/JDK-8213574 > > > > > > Original webrev: http://hg.openjdk.java.net/jdk/jdk/rev/d5eebe1e03fe > > > > > > CDS dumping may run into a deadlock situation during copying the > > > interned j.l.String objects in the VM thread, while the service thread > > > is concurrently expanding the string table. I ran into the deadlock > > > recently when creating a CDS archive with an input classlist of ~60K > > > classes on JDK 11. The backport addresses the deadlock issue. > > > > > > The diffs in symbolTable.cpp are not included in the backport as they > > > only apply to ConcurrentHashTable. In JDK 11 the SymbolTable is not > > > yet a ConcurrentHashTable. All other diffs in the patch applied > > > cleanly. > > > > > > Tested with tier1, jtreg/runtime/SharedArchiveFile > > > > > > Best, > > > Jiangli From dlemmond at amazon.com Fri Jun 5 22:08:48 2020 From: dlemmond at amazon.com (Lemmond, Dan) Date: Fri, 5 Jun 2020 22:08:48 +0000 Subject: [11u] RFR: JDK-8222074: Enhance auto vectorization for x86 Message-ID: Hi, I sent this review out previously but it was moderated. Moderators, feel free to discard the old one. This backport is a prerequisite for backporting JDK-8230591. I plan to backport JDK-8226721 and JDK-8231713 in the coming days before finally backporting JDK-8230591. This review is part of a set and will need to be pushed with the backport for JDK-8224234 which I will be sending out shortly. JBS: https://bugs.openjdk.java.net/browse/JDK-8222074 Webrev: http://cr.openjdk.java.net/~phh/8222074/webrev.11u.00/ Original review thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/033561.html Please review this backport for JDK-8222074 to 11u. The changeset applied cleanly for the most part, only requiring a manual fix for two hunks. The two hunks that needed to be fixed were hunk 3 in assembler_x86.hpp and hunk 3 in x86.ad. The backport compiled without issue and successfully passed the Tier1 Hotspot tests. Please note that the change to CheckGraalIntrinsics.java was omitted from this backport as the check was ?isJDK13OrHigher? which is not relevant for 11u. Thank you, Dan From dlemmond at amazon.com Fri Jun 5 22:09:25 2020 From: dlemmond at amazon.com (Lemmond, Dan) Date: Fri, 5 Jun 2020 22:09:25 +0000 Subject: [11u] RFR: JDK-8224234: compiler/codegen/TestCharVect2.java fails in test_mulc Message-ID: <9EABFF76-EB99-4FE5-B80E-6DC9F2284125@amazon.com> Hi, I sent this request out previously but it was moderated. Moderators, please feel free to discard the old one. Please review this backport for 11u. This is the second review in the set for JDK-8222074 which has previously been sent out for review. Even though it applies cleanly, I am sending it out for review as it will need to be applied alongside the backport for JDK-8222074. JBS: https://bugs.openjdk.java.net/browse/JDK-8224234 Webrev: http://cr.openjdk.java.net/~phh/8224234/webrev.11u.00/ Original review thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-June/034175.html This patch compiled without issue and passed all Tier1 Hotspot tests. Thanks, Dan From neugens.limasoftware at gmail.com Fri Jun 5 23:20:36 2020 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 6 Jun 2020 01:20:36 +0200 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: References: Message-ID: Vote: yes Cheers, Mario On Fri 5. Jun 2020 at 16:03, Mario Torre wrote: > Hi all! > > I hereby nominate Jie Kang (jkang) [0] to JDK Updates Committer. > > Jie has backported a number of patches to OpenJDK 11u, in particular: > > JDK-8205516 > JDK-8214896 > JDK-8214925 > JDK-8213448 > JDK-8218935 > JDK-8225694 > JDK-8223697 > JDK-8215771 > JDK-8233075 > JDK-8232806 > JDK-8219904 > > Votes are due by 19h00 UTC on Friday, the 19th of June, 2020. > > Only current JDK Updates Committers (and above) [1] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Cheers, > Mario > > [0] https://openjdk.java.net/census#jkang > [1] https://openjdk.java.net/census#jdk-updates > [2] http://openjdk.java.net/projects/#committer-vote > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From mbalao at redhat.com Sat Jun 6 02:14:34 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 5 Jun 2020 23:14:34 -0300 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: References: Message-ID: On 6/5/20 11:02 AM, Mario Torre wrote: > I hereby nominate Jie Kang (jkang) [0] to JDK Updates Committer. Vote: yes From david.holmes at oracle.com Sat Jun 6 12:32:52 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 6 Jun 2020 22:32:52 +1000 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: References: Message-ID: <4a1314ea-373c-9e46-e4d4-ffc8f2606fea@oracle.com> Hi Mario, On 6/06/2020 12:02 am, Mario Torre wrote: > Hi all! > > I hereby nominate Jie Kang (jkang) [0] to JDK Updates Committer. > > Jie has backported a number of patches to OpenJDK 11u, in particular: > > JDK-8205516 > JDK-8214896 > JDK-8214925 > JDK-8213448 > JDK-8218935 > JDK-8225694 > JDK-8223697 > JDK-8215771 > JDK-8233075 > JDK-8232806 > JDK-8219904 Please clarify which of these are actual contributions by Jie and which are simply "hg import" of the original changeset. I do not consider a clean import as a contribution. If there is more to this that warrants being considered a contribution then please elaborate. Further there is a hole in our role checking if a non-committer actually pushed backport changesets in the first place! Thanks, David ----- > Votes are due by 19h00 UTC on Friday, the 19th of June, 2020. > > Only current JDK Updates Committers (and above) [1] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Cheers, > Mario > > [0] https://openjdk.java.net/census#jkang > [1] https://openjdk.java.net/census#jdk-updates > [2] http://openjdk.java.net/projects/#committer-vote > From neugens at redhat.com Sat Jun 6 18:28:50 2020 From: neugens at redhat.com (Mario Torre) Date: Sat, 6 Jun 2020 20:28:50 +0200 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: <4a1314ea-373c-9e46-e4d4-ffc8f2606fea@oracle.com> References: <4a1314ea-373c-9e46-e4d4-ffc8f2606fea@oracle.com> Message-ID: On Sat, Jun 6, 2020 at 2:33 PM David Holmes wrote: > > Hi Mario, Hi David, > Please clarify which of these are actual contributions by Jie and which > are simply "hg import" of the original changeset. I do not consider a > clean import as a contribution. If there is more to this that warrants > being considered a contribution then please elaborate. Here's more information about each backport: Those required re-work: https://bugs.openjdk.java.net/browse/JDK-8205516 https://bugs.openjdk.java.net/browse/JDK-8213448 https://bugs.openjdk.java.net/browse/JDK-8232806 Those were "clean" backports (for some definition of clean): https://bugs.openjdk.java.net/browse/JDK-8214896 https://bugs.openjdk.java.net/browse/JDK-8214925 https://bugs.openjdk.java.net/browse/JDK-8218935 https://bugs.openjdk.java.net/browse/JDK-8225694 https://bugs.openjdk.java.net/browse/JDK-8223697 https://bugs.openjdk.java.net/browse/JDK-8215771 https://bugs.openjdk.java.net/browse/JDK-8233075 https://bugs.openjdk.java.net/browse/JDK-8219904 However I have a real problem marking clean backports as a "simple hg import of the original changeset", because it's never the case. Each patch needs to be studied and understood and tested, even when it applied cleanly, so there's real work involved, and you can see this for example in the discussion about JDK-8223697, which despite applying cleanly was actually a result of a few back and forth and required assessment of another patch that didn't apply cleanly. I would be very worried if any developer would apply a patch, see that it's clean and just pushes it. There's maybe an issue in the process where the updates project is also responsible to produce the topmost stable release (i.e. JDK15u) and so the Committer role is akin to that of Committer for the jdk-dev in this case, but for the most part the updates produce maintenance releases of typically older trains, like JDK 11 or 13 (8u is not in this by chance, because back then we had a separate update project for each version). Selecting a Committer for those versions would be very difficult if we only allowed non clean backports as contributions, because the reality is that most of the backports apply cleanly or with trivial modifications, so the rationale behind a Yes vote, in my opinion, should be the quality of the work this developer does (which means also ensuring that a patch that is a clean backport is also contextually accurate and does not have unwanted side effects), the frequency of his contributions and the likelihood that he will continue contributing. Of course, YMMV, and I respect that. > Further there is a hole in our role checking if a non-committer actually > pushed backport changesets in the first place! Jie didn't push those patches, he contributed them and someone (usually Christopher!) pushed them. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From goetz.lindenmaier at sap.com Mon Jun 8 06:26:49 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Jun 2020 06:26:49 +0000 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: References: Message-ID: Vote: yes Best regards, Goetz. -----Original Message----- From: jdk-updates-dev On Behalf Of Mario Torre Sent: Freitag, 5. Juni 2020 16:03 To: jdk-updates-dev Subject: CFV: New JDK Updates Committer: Jie Kang Hi all! I hereby nominate Jie Kang (jkang) [0] to JDK Updates Committer. Jie has backported a number of patches to OpenJDK 11u, in particular: JDK-8205516 JDK-8214896 JDK-8214925 JDK-8213448 JDK-8218935 JDK-8225694 JDK-8223697 JDK-8215771 JDK-8233075 JDK-8232806 JDK-8219904 Votes are due by 19h00 UTC on Friday, the 19th of June, 2020. Only current JDK Updates Committers (and above) [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Cheers, Mario [0] https://openjdk.java.net/census#jkang [1] https://openjdk.java.net/census#jdk-updates [2] http://openjdk.java.net/projects/#committer-vote -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From robbin.ehn at oracle.com Mon Jun 8 08:41:59 2020 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 8 Jun 2020 10:41:59 +0200 Subject: RFR:[jdk11]:JDK-8213574: Deadlock in string table expansion when dumping lots of CDS classes In-Reply-To: References: Message-ID: <53e04dda-255c-6ef3-ec1d-ea5ecea65d90@oracle.com> Looks good, thanks! /Robbin On 2020-06-05 19:03, Jiangli Zhou wrote: > [+christoph.langer at sap.com, +martinrb at google.com] > > Gentle ping > > Martin or Christoph, could you please review the backport? > > Thanks! > Jiangli > > > > On Mon, May 18, 2020 at 2:31 PM Jiangli Zhou wrote: >> >> Please review the backport for JDK-8213574 to JDK 11: >> >> backport webrev: >> http://cr.openjdk.java.net/~jiangli/8213574-jdk11-backport/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8213574 >> >> Original webrev: http://hg.openjdk.java.net/jdk/jdk/rev/d5eebe1e03fe >> >> CDS dumping may run into a deadlock situation during copying the >> interned j.l.String objects in the VM thread, while the service thread >> is concurrently expanding the string table. I ran into the deadlock >> recently when creating a CDS archive with an input classlist of ~60K >> classes on JDK 11. The backport addresses the deadlock issue. >> >> The diffs in symbolTable.cpp are not included in the backport as they >> only apply to ConcurrentHashTable. In JDK 11 the SymbolTable is not >> yet a ConcurrentHashTable. All other diffs in the patch applied >> cleanly. >> >> Tested with tier1, jtreg/runtime/SharedArchiveFile >> >> Best, >> Jiangli From david.holmes at oracle.com Mon Jun 8 09:30:27 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Jun 2020 19:30:27 +1000 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: References: <4a1314ea-373c-9e46-e4d4-ffc8f2606fea@oracle.com> Message-ID: <407c0319-ba19-575d-f19b-1a63a85669d5@oracle.com> Hi Mario, On 7/06/2020 4:28 am, Mario Torre wrote: > On Sat, Jun 6, 2020 at 2:33 PM David Holmes wrote: >> >> Hi Mario, > > Hi David, > >> Please clarify which of these are actual contributions by Jie and which >> are simply "hg import" of the original changeset. I do not consider a >> clean import as a contribution. If there is more to this that warrants >> being considered a contribution then please elaborate. > > Here's more information about each backport: > > Those required re-work: > https://bugs.openjdk.java.net/browse/JDK-8205516 > https://bugs.openjdk.java.net/browse/JDK-8213448 > https://bugs.openjdk.java.net/browse/JDK-8232806 > > Those were "clean" backports (for some definition of clean): > https://bugs.openjdk.java.net/browse/JDK-8214896 > https://bugs.openjdk.java.net/browse/JDK-8214925 > https://bugs.openjdk.java.net/browse/JDK-8218935 > https://bugs.openjdk.java.net/browse/JDK-8225694 > https://bugs.openjdk.java.net/browse/JDK-8223697 > https://bugs.openjdk.java.net/browse/JDK-8215771 > https://bugs.openjdk.java.net/browse/JDK-8233075 > https://bugs.openjdk.java.net/browse/JDK-8219904 > > However I have a real problem marking clean backports as a "simple hg > import of the original changeset", because it's never the case. Each > patch needs to be studied and understood and tested, even when it > applied cleanly, so there's real work involved, and you can see this > for example in the discussion about JDK-8223697, which despite > applying cleanly was actually a result of a few back and forth and > required assessment of another patch that didn't apply cleanly. I > would be very worried if any developer would apply a patch, see that > it's clean and just pushes it. That can certainly be the case, but in other cases e.g. https://bugs.openjdk.java.net/browse/JDK-8233075 https://bugs.openjdk.java.net/browse/JDK-8214896 the change is quite trivial (both the original change and the backport). My point being that the onus is on the person posting the CFV to make sure that the contributions of the nominee can be clearly seen. In the case of jdk-updates and backports it is exceedingly difficult for voters to be able to know whether a backport was trivial or indeed reflects a significant contribution from someone else. As you note the process itself is flawed because the involvement of someone in a backport is not even be visible in the changeset. :( > There's maybe an issue in the process where the updates project is > also responsible to produce the topmost stable release (i.e. JDK15u) > and so the Committer role is akin to that of Committer for the jdk-dev > in this case, but for the most part the updates produce maintenance > releases of typically older trains, like JDK 11 or 13 (8u is not in > this by chance, because back then we had a separate update project for > each version). > > Selecting a Committer for those versions would be very difficult if we > only allowed non clean backports as contributions, because the reality > is that most of the backports apply cleanly or with trivial > modifications, so the rationale behind a Yes vote, in my opinion, > should be the quality of the work this developer does (which means > also ensuring that a patch that is a clean backport is also > contextually accurate and does not have unwanted side effects), the > frequency of his contributions and the likelihood that he will > continue contributing. Of course, YMMV, and I respect that. > >> Further there is a hole in our role checking if a non-committer actually >> pushed backport changesets in the first place! > > Jie didn't push those patches, he contributed them and someone > (usually Christopher!) pushed them. Thanks for clarifying that. Cheers, David ----- > Cheers, > Mario > From zgu at redhat.com Mon Jun 8 12:14:20 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 8 Jun 2020 08:14:20 -0400 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: References: Message-ID: <8cae03d9-a888-eede-ef9d-817bbf903711@redhat.com> Vote: yes. -Zhengyu On 6/5/20 10:02 AM, Mario Torre wrote: > Hi all! > > I hereby nominate Jie Kang (jkang) [0] to JDK Updates Committer. > > Jie has backported a number of patches to OpenJDK 11u, in particular: > > JDK-8205516 > JDK-8214896 > JDK-8214925 > JDK-8213448 > JDK-8218935 > JDK-8225694 > JDK-8223697 > JDK-8215771 > JDK-8233075 > JDK-8232806 > JDK-8219904 > > Votes are due by 19h00 UTC on Friday, the 19th of June, 2020. > > Only current JDK Updates Committers (and above) [1] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Cheers, > Mario > > [0] https://openjdk.java.net/census#jkang > [1] https://openjdk.java.net/census#jdk-updates > [2] http://openjdk.java.net/projects/#committer-vote > From abrygin at azul.com Mon Jun 8 12:55:33 2020 From: abrygin at azul.com (Andrew Brygin) Date: Mon, 8 Jun 2020 15:55:33 +0300 Subject: [13u] RFR: 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit Message-ID: <738c64d0-cdcd-5d99-f084-1aabdf6574a6@azul.com> Hello, I would like to backport a fix for JDK-8233019 to jdk13u: Bug: https://bugs.openjdk.java.net/browse/JDK-8233019 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/9bbe560e8131 Webrebv: http://cr.openjdk.java.net/~bae/13u/8233019/webrev.00/ The original change applies cleanly, except two files where a little context update is required due to absence of the fix for JDK-8230505: src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp: < } else if (is_reference_type(c->type())) { --- > } else if (c->type() == T_OBJECT || c->type() == T_ARRAY) { src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp: < } else if (is_reference_type(c->type())) { --- > } else if (c->type() == T_OBJECT || c->type() == T_ARRAY) { The change tested on linux x86_64 with tier1 and supplied regression test. Thanks, Andrew From thomas.stuefe at gmail.com Mon Jun 8 13:11:06 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 8 Jun 2020 15:11:06 +0200 Subject: [13u] RFR: 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit In-Reply-To: <738c64d0-cdcd-5d99-f084-1aabdf6574a6@azul.com> References: <738c64d0-cdcd-5d99-f084-1aabdf6574a6@azul.com> Message-ID: LGTM Regards, Thomas On Mon, Jun 8, 2020 at 2:56 PM Andrew Brygin wrote: > Hello, > > I would like to backport a fix for JDK-8233019 to jdk13u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233019 > Original change: http://hg.openjdk.java.net/jdk/jdk/rev/9bbe560e8131 > Webrebv: http://cr.openjdk.java.net/~bae/13u/8233019/webrev.00/ > > The original change applies cleanly, except two files where a little > context update is required due to absence of the fix for JDK-8230505: > > src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp: > < } else if (is_reference_type(c->type())) { > --- > > } else if (c->type() == T_OBJECT || c->type() == T_ARRAY) { > > src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp: > < } else if (is_reference_type(c->type())) { > --- > > } else if (c->type() == T_OBJECT || c->type() == T_ARRAY) { > > The change tested on linux x86_64 with tier1 and supplied regression test. > > Thanks, > Andrew > > From goetz.lindenmaier at sap.com Mon Jun 8 14:26:09 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Jun 2020 14:26:09 +0000 Subject: [11u] RFR: 8244225: stringop-overflow warning on strncpy call from compile_the_world_in Message-ID: Hi, I would like to bring this to jdk11u-dev for parity with 11.0.9-oracle. This is a fix that was only implemented for 11, so I can not see the original implementation. It fixes a gcc 8 warning in code that was removed later on. I think we should fix this in open jdk11u too. This way, we can be sure the fix is associated with the same bug. I see the same message as reported in the bug when compiling with gcc 8.2. The cause for the warning is that (len-6) can be bigger than the buffer size. Obviously the compiler inlined string_ends_with() and CSEed the strlen() calls. I implemented it by returning if len-6 is too long. That is the same error handling as when there are too many '.' in the filename. Please review: http://cr.openjdk.java.net/~goetz/wr20/8244225-stringop_gcc8_warning-jdk11/01/index.html https://bugs.openjdk.java.net/browse/JDK-8244225 Best regards, Goetz. From abrygin at azul.com Mon Jun 8 14:56:54 2020 From: abrygin at azul.com (Andrew Brygin) Date: Mon, 8 Jun 2020 17:56:54 +0300 Subject: [13u] RFR: 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing Message-ID: Hello, I would like to backport a fix for 8233197 to jdk13u: Bug: https://bugs.openjdk.java.net/browse/JDK-8233197 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/127ca611f19b Webrev: http://cr.openjdk.java.net/~bae/13u/8233197/webrev.00/ The original change applies cleanly except one chunk in jfrRecorder.cpp, where the condition in is_cds_dump_requested() should use old notation "(DumpSharedSpaces || DynamicDumpSharedSpaces)" instead of "Arguments::is_dumping_archive()", because fix for JDK-8231606 has not been backported into 13u. src/hotspot/share/jfr/recorder/jfrRecorder.cpp: < - if (Arguments::is_dumping_archive() && (JfrOptionSet::startup_recording_options() != NULL)) { < + if (Arguments::is_dumping_archive() && (JfrOptionSet::start_flight_recording_options() != NULL)) { --- > - if ((DumpSharedSpaces || DynamicDumpSharedSpaces) && (JfrOptionSet::startup_recording_options() != NULL)) { > + if ((DumpSharedSpaces || DynamicDumpSharedSpaces) && (JfrOptionSet::start_flight_recording_options() != NULL)) { The fix tested on linux x86_64 with tier1 and jdk/jfr tests. Thanks, Andrew From matthias.baesken at sap.com Mon Jun 8 15:14:21 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 8 Jun 2020 15:14:21 +0000 Subject: RFR [jdk11]: 8223940: Private key not supported by chosen signature algorithm Message-ID: Hello, please review the jdk11 backport of 8223940: Private key not supported by chosen signature algorithm . I had to do a few adjustments to the jdk/jdk change for jdk11 : -The algorithmConstraints - parameter of getSignerOfPreferableAlgorithm Is not present in jdk11 so this is missing from the calls in the jdk11 webrev (see for example src/java.base/share/classes/sun/security/ssl/DHServerKeyExchange.java ). In src/java.base/share/classes/sun/security/ssl/SignatureScheme.java , the SignatureUtil.initVerifyWithParam calls were changed . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8223940 http://cr.openjdk.java.net/~mbaesken/webrevs/8223940_jdk11_0/ Webrev from jdk/jdk : https://hg.openjdk.java.net/jdk/jdk/rev/d6e682e8fcc3 Thanks, Matthias From adinn at redhat.com Mon Jun 8 15:46:27 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 8 Jun 2020 16:46:27 +0100 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: References: Message-ID: <53d22a88-fa85-c253-f321-a6e18ed85a5f@redhat.com> Vote: yes On 05/06/2020 15:02, Mario Torre wrote: > Hi all! > > I hereby nominate Jie Kang (jkang) [0] to JDK Updates Committer. > > Jie has backported a number of patches to OpenJDK 11u, in particular: > > JDK-8205516 > JDK-8214896 > JDK-8214925 > JDK-8213448 > JDK-8218935 > JDK-8225694 > JDK-8223697 > JDK-8215771 > JDK-8233075 > JDK-8232806 > JDK-8219904 > > Votes are due by 19h00 UTC on Friday, the 19th of June, 2020. > > Only current JDK Updates Committers (and above) [1] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Cheers, > Mario > > [0] https://openjdk.java.net/census#jkang > [1] https://openjdk.java.net/census#jdk-updates > [2] http://openjdk.java.net/projects/#committer-vote > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From yan at azul.com Mon Jun 8 15:58:36 2020 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 8 Jun 2020 18:58:36 +0300 Subject: [13u] RFR: 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: <84613cf1-6dd0-58b1-338e-bc3970faebd3@azul.com> OK, looks good to me. And JDK-8231606 is too huge and involving, for this context. --yan On 08.06.2020 17:56, Andrew Brygin wrote: > Hello, > > I would like to backport a fix for 8233197 to jdk13u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233197 > Original change: http://hg.openjdk.java.net/jdk/jdk/rev/127ca611f19b > Webrev: http://cr.openjdk.java.net/~bae/13u/8233197/webrev.00/ > > The original change applies cleanly except one chunk in > jfrRecorder.cpp, where the condition in is_cds_dump_requested() should > use old notation "(DumpSharedSpaces || DynamicDumpSharedSpaces)" instead > of "Arguments::is_dumping_archive()", because fix for JDK-8231606 has > not been backported into 13u. > > src/hotspot/share/jfr/recorder/jfrRecorder.cpp: > > < - if (Arguments::is_dumping_archive() && > (JfrOptionSet::startup_recording_options() != NULL)) { > < + if (Arguments::is_dumping_archive() && > (JfrOptionSet::start_flight_recording_options() != NULL)) { > --- >> - if ((DumpSharedSpaces || DynamicDumpSharedSpaces) && > (JfrOptionSet::startup_recording_options() != NULL)) { >> + if ((DumpSharedSpaces || DynamicDumpSharedSpaces) && > (JfrOptionSet::start_flight_recording_options() != NULL)) { > > The fix tested on linux x86_64 with tier1 and jdk/jfr tests. > > Thanks, > Andrew > From jianglizhou at google.com Mon Jun 8 16:21:38 2020 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 8 Jun 2020 09:21:38 -0700 Subject: RFR:[jdk11]:JDK-8213574: Deadlock in string table expansion when dumping lots of CDS classes In-Reply-To: <53e04dda-255c-6ef3-ec1d-ea5ecea65d90@oracle.com> References: <53e04dda-255c-6ef3-ec1d-ea5ecea65d90@oracle.com> Message-ID: Thank you, Robbin! Best, Jiangli On Mon, Jun 8, 2020 at 1:42 AM Robbin Ehn wrote: > > Looks good, thanks! > > /Robbin > > On 2020-06-05 19:03, Jiangli Zhou wrote: > > [+christoph.langer at sap.com, +martinrb at google.com] > > > > Gentle ping > > > > Martin or Christoph, could you please review the backport? > > > > Thanks! > > Jiangli > > > > > > > > On Mon, May 18, 2020 at 2:31 PM Jiangli Zhou wrote: > >> > >> Please review the backport for JDK-8213574 to JDK 11: > >> > >> backport webrev: > >> http://cr.openjdk.java.net/~jiangli/8213574-jdk11-backport/webrev.00/ > >> https://bugs.openjdk.java.net/browse/JDK-8213574 > >> > >> Original webrev: http://hg.openjdk.java.net/jdk/jdk/rev/d5eebe1e03fe > >> > >> CDS dumping may run into a deadlock situation during copying the > >> interned j.l.String objects in the VM thread, while the service thread > >> is concurrently expanding the string table. I ran into the deadlock > >> recently when creating a CDS archive with an input classlist of ~60K > >> classes on JDK 11. The backport addresses the deadlock issue. > >> > >> The diffs in symbolTable.cpp are not included in the backport as they > >> only apply to ConcurrentHashTable. In JDK 11 the SymbolTable is not > >> yet a ConcurrentHashTable. All other diffs in the patch applied > >> cleanly. > >> > >> Tested with tier1, jtreg/runtime/SharedArchiveFile > >> > >> Best, > >> Jiangli From stooke at redhat.com Mon Jun 8 17:00:15 2020 From: stooke at redhat.com (Simon Tooke) Date: Mon, 8 Jun 2020 13:00:15 -0400 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: References: Message-ID: vote: yes. On 2020-06-05 10:02 a.m., Mario Torre wrote: > Hi all! > > I hereby nominate Jie Kang (jkang) [0] to JDK Updates Committer. > > Jie has backported a number of patches to OpenJDK 11u, in particular: > > JDK-8205516 > JDK-8214896 > JDK-8214925 > JDK-8213448 > JDK-8218935 > JDK-8225694 > JDK-8223697 > JDK-8215771 > JDK-8233075 > JDK-8232806 > JDK-8219904 > > Votes are due by 19h00 UTC on Friday, the 19th of June, 2020. > > Only current JDK Updates Committers (and above) [1] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Cheers, > Mario > > [0] https://openjdk.java.net/census#jkang > [1] https://openjdk.java.net/census#jdk-updates > [2] http://openjdk.java.net/projects/#committer-vote > From aph at redhat.com Mon Jun 8 17:34:39 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 Jun 2020 18:34:39 +0100 Subject: [11u] RFR: 8244225: stringop-overflow warning on strncpy call from compile_the_world_in In-Reply-To: References: Message-ID: <7c94a79c-9b49-62b0-a6fd-1b8c156cd8fb@redhat.com> Hi, On 08/06/2020 15:26, Lindenmaier, Goetz wrote: > http://cr.openjdk.java.net/~goetz/wr20/8244225-stringop_gcc8_warning-jdk11/01/index.html > > https://bugs.openjdk.java.net/browse/JDK-8244225 Looks good. -- 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 sgehwolf at redhat.com Mon Jun 8 18:11:27 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 08 Jun 2020 20:11:27 +0200 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: References: Message-ID: <6b4b7f5cc84e71cbfeaacaba398aabd6e235749d.camel@redhat.com> Vote: yes On Fri, 2020-06-05 at 16:02 +0200, Mario Torre wrote: > Hi all! > > I hereby nominate Jie Kang (jkang) [0] to JDK Updates Committer. > > Jie has backported a number of patches to OpenJDK 11u, in particular: > > JDK-8205516 > JDK-8214896 > JDK-8214925 > JDK-8213448 > JDK-8218935 > JDK-8225694 > JDK-8223697 > JDK-8215771 > JDK-8233075 > JDK-8232806 > JDK-8219904 > > Votes are due by 19h00 UTC on Friday, the 19th of June, 2020. > > Only current JDK Updates Committers (and above) [1] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Cheers, > Mario > > [0] https://openjdk.java.net/census#jkang > [1] https://openjdk.java.net/census#jdk-updates > [2] http://openjdk.java.net/projects/#committer-vote > From neugens.limasoftware at gmail.com Mon Jun 8 18:34:54 2020 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 8 Jun 2020 20:34:54 +0200 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: <407c0319-ba19-575d-f19b-1a63a85669d5@oracle.com> References: <4a1314ea-373c-9e46-e4d4-ffc8f2606fea@oracle.com> <407c0319-ba19-575d-f19b-1a63a85669d5@oracle.com> Message-ID: Il giorno lun 8 giu 2020 alle ore 11:31 David Holmes ha scritto: > My point being that the onus is on the person posting the CFV to make > sure that the contributions of the nominee can be clearly seen. In the > case of jdk-updates and backports it is exceedingly difficult for voters > to be able to know whether a backport was trivial or indeed reflects a > significant contribution from someone else. As you note the process > itself is flawed because the involvement of someone in a backport is not > even be visible in the changeset. :( Sure, I agree making it more transparent is desirable, I'll make sure next time to write a more detailed request. > Thanks for clarifying that. np! Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From goetz.lindenmaier at sap.com Tue Jun 9 05:42:45 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jun 2020 05:42:45 +0000 Subject: [11u] RFR: 8244703: "platform encoding not initialized" exceptions with debugger, JNI Message-ID: Hi, I would like to downport this for parity with 11.0.9-oracle. The change to make/modules/jdk.jdwp.agent/Lib.gmk does not apply. The file does not exist in 11. It was renamed and reworked in 15. The original file is make/lib/Lib-jdk.jdwp.agent.gmk. The coding added with the patch was already there in 11, but removed in the rework, so there is no need to patch Lib-jdk.jdwp.agent.gmk. So this RFR basically asks for agreeing on leaving out the change to the makefile. http://cr.openjdk.java.net/~goetz/wr20/8244703-enc_not_initalized-jdk11/01/ http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/f8dcda193d72/make/lib/Lib-jdk.jdwp.agent.gmk#l52 Please review. https://bugs.openjdk.java.net/browse/JDK-8244703 https://hg.openjdk.java.net/jdk/jdk/rev/8e28aae50680 Best regards, Goetz. From abrygin at azul.com Tue Jun 9 08:14:57 2020 From: abrygin at azul.com (Andrew Brygin) Date: Tue, 9 Jun 2020 11:14:57 +0300 Subject: [13u] RFR: 8234270: [REDO] JDK-8204128 NMT might report incorrect numbers for Compiler area Message-ID: <6ec8c5f1-939e-e828-364e-f1655eda9d29@azul.com> Hello, I would like to backport the fix for 8234270 to 13u: Bug: https://bugs.openjdk.java.net/browse/JDK-8234270 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/ac6f7738a0ee Webrev: http://cr.openjdk.java.net/~bae/13u/8234270/webrev.00/ The original change applies cleanly, except method MemoryCounter::resize(), where the context needs to be updated due to absence of the fix for JDK-8234737 (Harmonize parameter order in Atomic - add) in 13u: src/hotspot/share/services/mallocTracker.hpp: < Atomic::add(&_size, size_t(sz)); --- > Atomic::add(size_t(sz), &_size); Tested with tier1 on linux x86_64. Thanks, Andrew From goetz.lindenmaier at sap.com Tue Jun 9 09:00:54 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jun 2020 09:00:54 +0000 Subject: [CAUTION] RFR [jdk11]: 8223940: Private key not supported by chosen signature algorithm In-Reply-To: References: Message-ID: Hi Matthias, I had a look at your change. You also edited handling of signAlgParameter, (it is signAlgParams in the original change). That looks good. I had to resolve similar code previously. Reviewed. Best regards, Goetz > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Baesken, Matthias > Sent: Monday, June 8, 2020 5:14 PM > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] RFR [jdk11]: 8223940: Private key not supported by > chosen signature algorithm > > Hello, please review the jdk11 backport of 8223940: Private key not > supported by chosen signature algorithm . > > I had to do a few adjustments to the jdk/jdk change for jdk11 : > > -The algorithmConstraints - parameter of getSignerOfPreferableAlgorithm > Is not present in jdk11 so this is missing from the calls in the jdk11 webrev > (see for example > src/java.base/share/classes/sun/security/ssl/DHServerKeyExchange.java ). > > In src/java.base/share/classes/sun/security/ssl/SignatureScheme.java , the > SignatureUtil.initVerifyWithParam calls were changed . > > > > Bug/webrev : > https://bugs.openjdk.java.net/browse/JDK-8223940 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223940_jdk11_0/ > > Webrev from jdk/jdk : > > https://hg.openjdk.java.net/jdk/jdk/rev/d6e682e8fcc3 > > Thanks, Matthias From dcherepanov at azul.com Tue Jun 9 09:32:15 2020 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Tue, 9 Jun 2020 12:32:15 +0300 Subject: [13u] RFR 8223260: NamingManager should cache InitialContextFactory Message-ID: <27e1aab8-354c-e942-6a6d-82263a3eb0ae@azul.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8223260 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/92b01977fde2 Webrev for 13u: http://cr.openjdk.java.net/~dcherepanov/openjdk13u/8223260/webrev.v0/ The patch applies cleanly but build fails due to using java.io.Serial annotation in NamingManager.java (the annotation introduced in 14), removed the use of the annotation. Tested with tier1 and javax/naming tests. Thanks, Dmitry From dcherepanov at azul.com Tue Jun 9 09:35:40 2020 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Tue, 9 Jun 2020 12:35:40 +0300 Subject: [13u] RFR: 8234270: [REDO] JDK-8204128 NMT might report incorrect numbers for Compiler area In-Reply-To: <6ec8c5f1-939e-e828-364e-f1655eda9d29@azul.com> References: <6ec8c5f1-939e-e828-364e-f1655eda9d29@azul.com> Message-ID: <7ff518ae-9468-8150-4ddd-3d228caf5739@azul.com> Looks good to me. Thanks, Dmitry On 09.06.2020 11:14, Andrew Brygin wrote: > Hello, > > I would like to backport the fix for 8234270 to 13u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8234270 > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/ac6f7738a0ee > Webrev: http://cr.openjdk.java.net/~bae/13u/8234270/webrev.00/ > > The original change applies cleanly, except method > MemoryCounter::resize(), where the context needs to be updated due to > absence of the fix for JDK-8234737 (Harmonize parameter order in Atomic > - add) in 13u: > > src/hotspot/share/services/mallocTracker.hpp: > < Atomic::add(&_size, size_t(sz)); > --- >> Atomic::add(size_t(sz), &_size); > Tested with tier1 on linux x86_64. > > Thanks, > Andrew From yan at azul.com Tue Jun 9 09:45:43 2020 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 9 Jun 2020 12:45:43 +0300 Subject: [13u] RFR 8223260: NamingManager should cache InitialContextFactory In-Reply-To: <27e1aab8-354c-e942-6a6d-82263a3eb0ae@azul.com> References: <27e1aab8-354c-e942-6a6d-82263a3eb0ae@azul.com> Message-ID: OK, looks good to me --yan On 09.06.2020 12:32, Dmitry Cherepanov wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8223260 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/92b01977fde2 > Webrev for 13u: http://cr.openjdk.java.net/~dcherepanov/openjdk13u/8223260/webrev.v0/ > > The patch applies cleanly but build fails due to using java.io.Serial annotation in NamingManager.java > (the annotation introduced in 14), removed the use of the annotation. > > Tested with tier1 and javax/naming tests. > > Thanks, > > Dmitry From goetz.lindenmaier at sap.com Tue Jun 9 10:33:31 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jun 2020 10:33:31 +0000 Subject: [11u] RFR: 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR In-Reply-To: References: Message-ID: Hi Andrew, Thanks for the review! > My God, what a mess elliptic-curve cryptography can be ?? ... Keeps up the work for the maintainers :/ Best regards, Goetz. > -----Original Message----- > From: Andrew Haley > Sent: Wednesday, June 3, 2020 10:30 AM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8233228: Disable weak named curves by default in TLS, > CertPath, and Signed JAR > > On 02/06/2020 16:59, Lindenmaier, Goetz wrote: > > http://cr.openjdk.java.net/~goetz/wr20/8233228-disable_weak_curves- > jdk11/01/ > > > > Please review. > > Looks good. > > My God, what a mess elliptic-curve cryptography can be when used in > the real world! [1] It makes me yearn for the good old simplicity of > RSA, and reminds us all how easy it is to be tempted by the call of > "efficient" public-key cryptography. > > [1] http://safecurves.cr.yp.to/ > > -- > 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 goetz.lindenmaier at sap.com Tue Jun 9 10:34:31 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jun 2020 10:34:31 +0000 Subject: [11u] RFR: 8244225: stringop-overflow warning on strncpy call from compile_the_world_in In-Reply-To: <7c94a79c-9b49-62b0-a6fd-1b8c156cd8fb@redhat.com> References: <7c94a79c-9b49-62b0-a6fd-1b8c156cd8fb@redhat.com> Message-ID: Hi Andrew, Thanks for the review! Best regards, Goetz. > -----Original Message----- > From: Andrew Haley > Sent: Monday, June 8, 2020 7:35 PM > To: Lindenmaier, Goetz ; jdk-updates-dev > > Subject: Re: [11u] RFR: 8244225: stringop-overflow warning on strncpy call > from compile_the_world_in > > Hi, > > On 08/06/2020 15:26, Lindenmaier, Goetz wrote: > > > http://cr.openjdk.java.net/~goetz/wr20/8244225-stringop_gcc8_warning- > jdk11/01/index.html > > > > https://bugs.openjdk.java.net/browse/JDK-8244225 > > Looks good. > > -- > 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 matthias.baesken at sap.com Tue Jun 9 11:08:58 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Jun 2020 11:08:58 +0000 Subject: [11u] RFR: 8244703: "platform encoding not initialized" exceptions with debugger, JNI In-Reply-To: References: Message-ID: Hello Goetz, looks good to me ! Best regards, Matthias -----Original Message----- From: Lindenmaier, Goetz Sent: Dienstag, 9. Juni 2020 07:43 To: 'jdk-updates-dev' Subject: [11u] RFR: 8244703: "platform encoding not initialized" exceptions with debugger, JNI Hi, I would like to downport this for parity with 11.0.9-oracle. The change to make/modules/jdk.jdwp.agent/Lib.gmk does not apply. The file does not exist in 11. It was renamed and reworked in 15. The original file is make/lib/Lib-jdk.jdwp.agent.gmk. The coding added with the patch was already there in 11, but removed in the rework, so there is no need to patch Lib-jdk.jdwp.agent.gmk. So this RFR basically asks for agreeing on leaving out the change to the makefile. http://cr.openjdk.java.net/~goetz/wr20/8244703-enc_not_initalized-jdk11/01/ http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/f8dcda193d72/make/lib/Lib-jdk.jdwp.agent.gmk#l52 Please review. https://bugs.openjdk.java.net/browse/JDK-8244703 https://hg.openjdk.java.net/jdk/jdk/rev/8e28aae50680 Best regards, Goetz. From matthias.baesken at sap.com Tue Jun 9 11:55:49 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Jun 2020 11:55:49 +0000 Subject: [11u] RFR: 8234149: Several regression tests do not dispose Frame at end In-Reply-To: References: Message-ID: Hello Goetz , looks good to me . While looking at all those files , I noticed that http://cr.openjdk.java.net/~goetz/wr20/8234149-dispose_frame-jdk11/01/test/jdk/javax/swing/JFrame/4962534/bug4962534.java.frames.html has no @key headful (btw same for test/jdk/javax/swing/JFrame/8037575/bug8037575.java ) Looks like test/jdk/javax/swing/JFrame/8037575/bug8037575.java still has no key headful in jdk/jdk while bug4962534.java got it ... Should I open a bug for test/jdk/javax/swing/JFrame/8037575/bug8037575.java ? Best regards, Matthias From: Lindenmaier, Goetz Sent: Freitag, 5. Juni 2020 13:14 To: 'jdk-updates-dev at openjdk.java.net' Subject: [11u] RFR: 8234149: Several regression tests do not dispose Frame at end Hi, I am downporting this for 11.0.9-oracle parity. I had to resolve a row of files: bug4796987.java: OS check in context different, easy resolve. bug6596966.java: simple resolve. Indented code differs again in os check. bug6470128.java, bug6580930.java, bug6827786.java, bug4202954.java, bug4624207.java all similar indentation issues. bug4962534.java, bug4634626.java: main method being fixed is only in 15 because "8213110: Remove the use of applets in automatic tests" is not in 11. I just copied the whole main method. This way these fixes can not be overseen in case 8213110 is brought to 11 at some point. http://cr.openjdk.java.net/~goetz/wr20/8234149-dispose_frame-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8234149 https://hg.openjdk.java.net/jdk/jdk/rev/7637e77c4c8a Best regards, Goetz. From goetz.lindenmaier at sap.com Tue Jun 9 16:46:17 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jun 2020 16:46:17 +0000 Subject: [11u] RFR: 8228967: Trust/Key store and SSL context utilities for tests Message-ID: Hi, I would like to bring this test-only change to 11.0.9. This applies clean except for two trivial resolves: Previously, when downporting "8234728: Some security tests should support TLSv1.3", I had to resolve NullHostnameCheck.java because this change was missing. Now, bringing this to 11u, I had to resolve the same location again now, obviously. Further, I had to resolve the copyright in PacketLossRetransmission.java. http://cr.openjdk.java.net/~goetz/wr20/8228967-ssl_test_utilities-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8228967 https://hg.openjdk.java.net/jdk/jdk/rev/d80e4bce4588 Best regards, Goetz. From goetz.lindenmaier at sap.com Tue Jun 9 17:10:23 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jun 2020 17:10:23 +0000 Subject: [11u] RFR: 8234149: Several regression tests do not dispose Frame at end In-Reply-To: References: Message-ID: Hi Matthias, Thanks for reviewing my change. * @key headful As far as I know many tests in jdk/jdk lack the headful tag. In 11u there are even more, because changes introducing the tag in head are not all downported. When I added these tags to many tests, I tried to find all that cause problems if they are run in a headless environment. While I think fixing any test wrt. to the tag is useful, I'm not sure it's worth the effort to do it for a single test. Best regards, Goetz. From: Baesken, Matthias Sent: Tuesday, June 9, 2020 1:56 PM To: Lindenmaier, Goetz ; 'jdk-updates-dev at openjdk.java.net' Subject: RE: [11u] RFR: 8234149: Several regression tests do not dispose Frame at end Hello Goetz , looks good to me . While looking at all those files , I noticed that http://cr.openjdk.java.net/~goetz/wr20/8234149-dispose_frame-jdk11/01/test/jdk/javax/swing/JFrame/4962534/bug4962534.java.frames.html has no @key headful (btw same for test/jdk/javax/swing/JFrame/8037575/bug8037575.java ) Looks like test/jdk/javax/swing/JFrame/8037575/bug8037575.java still has no key headful in jdk/jdk while bug4962534.java got it ... Should I open a bug for test/jdk/javax/swing/JFrame/8037575/bug8037575.java ? Best regards, Matthias From: Lindenmaier, Goetz > Sent: Freitag, 5. Juni 2020 13:14 To: 'jdk-updates-dev at openjdk.java.net' > Subject: [11u] RFR: 8234149: Several regression tests do not dispose Frame at end Hi, I am downporting this for 11.0.9-oracle parity. I had to resolve a row of files: bug4796987.java: OS check in context different, easy resolve. bug6596966.java: simple resolve. Indented code differs again in os check. bug6470128.java, bug6580930.java, bug6827786.java, bug4202954.java, bug4624207.java all similar indentation issues. bug4962534.java, bug4634626.java: main method being fixed is only in 15 because "8213110: Remove the use of applets in automatic tests" is not in 11. I just copied the whole main method. This way these fixes can not be overseen in case 8213110 is brought to 11 at some point. http://cr.openjdk.java.net/~goetz/wr20/8234149-dispose_frame-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8234149 https://hg.openjdk.java.net/jdk/jdk/rev/7637e77c4c8a Best regards, Goetz. From christoph.langer at sap.com Wed Jun 10 08:34:24 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 10 Jun 2020 08:34:24 +0000 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: References: Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Mario Torre > Sent: Freitag, 5. Juni 2020 16:03 > To: jdk-updates-dev > Subject: CFV: New JDK Updates Committer: Jie Kang > > Hi all! > > I hereby nominate Jie Kang (jkang) [0] to JDK Updates Committer. > > Jie has backported a number of patches to OpenJDK 11u, in particular: > > JDK-8205516 > JDK-8214896 > JDK-8214925 > JDK-8213448 > JDK-8218935 > JDK-8225694 > JDK-8223697 > JDK-8215771 > JDK-8233075 > JDK-8232806 > JDK-8219904 > > Votes are due by 19h00 UTC on Friday, the 19th of June, 2020. > > Only current JDK Updates Committers (and above) [1] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Cheers, > Mario > > [0] https://openjdk.java.net/census#jkang > [1] https://openjdk.java.net/census#jdk-updates > [2] http://openjdk.java.net/projects/#committer-vote > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From snazarkin at azul.com Wed Jun 10 09:35:22 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Wed, 10 Jun 2020 09:35:22 +0000 Subject: [13u] RFR: 8226721 : Missing intrinsics for Math.ceil, floor, rint Message-ID: <3FA83800-47D9-41E0-ACF1-B637ABDF54EA@azul.com> Hi! Please review a set of backports to bring math intrinsic to jdk13. The train consists of initial commit (8226721) and build fix for x86 (8231713) Original records https://bugs.openjdk.java.net/browse/JDK-8226721 (initial) https://bugs.openjdk.java.net/browse/JDK-8231713 (x86 build fix) The patch from 8226721 applies mostly cleanly except one small part at x86.ad due to context shift by missed 8224974. The second part (8231713) applies cleanly. Webrev http://cr.openjdk.java.net/~snazarki/webrev/8226721/ From yan at azul.com Wed Jun 10 14:48:10 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 10 Jun 2020 17:48:10 +0300 Subject: [13u] RFR: 8226721 : Missing intrinsics for Math.ceil, floor, rint In-Reply-To: <3FA83800-47D9-41E0-ACF1-B637ABDF54EA@azul.com> References: <3FA83800-47D9-41E0-ACF1-B637ABDF54EA@azul.com> Message-ID: <902890ca-367e-b107-8b05-74801762dddf@azul.com> Hi Sergey, how did you test that? Thank you for the backport! --yan On 10.06.2020 12:35, Sergey Nazarkin wrote: > Hi! > > Please review a set of backports to bring math intrinsic to jdk13. The train consists of initial commit (8226721) and build fix for x86 (8231713) > > Original records > https://bugs.openjdk.java.net/browse/JDK-8226721 (initial) > https://bugs.openjdk.java.net/browse/JDK-8231713 (x86 build fix) > > The patch from 8226721 applies mostly cleanly except one small part at x86.ad due to context shift by missed 8224974. The second part (8231713) applies cleanly. > > Webrev > http://cr.openjdk.java.net/~snazarki/webrev/8226721/ > > > From abrygin at azul.com Wed Jun 10 15:11:49 2020 From: abrygin at azul.com (Andrew Brygin) Date: Wed, 10 Jun 2020 18:11:49 +0300 Subject: [13u] RFR: 8240972: macOS codesign fail on macOS 10.13.5 or older Message-ID: <6f6dbbbf-785b-b224-1e85-40ae4418edca@azul.com> Hello, I would like to backport the fix for JDK-8240972 to 13u: Bug: https://bugs.openjdk.java.net/browse/JDK-8240972 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/4253bf176649 Webrev: http://cr.openjdk.java.net/~bae/13u/8240972/webrev.00 The original change modifies file make/autoconf/basic_tools.m4 which does not exist in jdk13u due to absence of the fix for JDK-8239708. However, the same change applies cleanly to make/autoconf/basics.m4. Thanks, Andrew From abrygin at azul.com Wed Jun 10 15:53:47 2020 From: abrygin at azul.com (Andrew Brygin) Date: Wed, 10 Jun 2020 18:53:47 +0300 Subject: [13u] RFR: 8244951: Missing entitlements for hardened runtime Message-ID: <8d79857d-30b1-eb1d-8a5f-f89e6364399f@azul.com> Hello, I would like to backport the fix for JDK-8244951 to 13u: Bug: https://bugs.openjdk.java.net/browse/JDK-8244951 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/c86677114b24 Webrev: http://cr.openjdk.java.net/~bae/13u/8244951/webrev.00/ The original change does not apply cleanly, because 13u does not have jpackage code, so the related part of the change is removed. The rest of the fix is applied without changes. Thanks, Andrew From yan at azul.com Wed Jun 10 16:01:38 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 10 Jun 2020 19:01:38 +0300 Subject: [13u] RFR: 8244951: Missing entitlements for hardened runtime In-Reply-To: <8d79857d-30b1-eb1d-8a5f-f89e6364399f@azul.com> References: <8d79857d-30b1-eb1d-8a5f-f89e6364399f@azul.com> Message-ID: OK, fine with me. Even if it requires a follow-up, it will be easier to apply it to the similar with other releases codebase. --yan On 10.06.2020 18:53, Andrew Brygin wrote: > Hello, > > I would like to backport the fix for JDK-8244951 to 13u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244951 > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/c86677114b24 > Webrev: http://cr.openjdk.java.net/~bae/13u/8244951/webrev.00/ > > The original change does not apply cleanly, because 13u does not have > jpackage code, so the related part of the change is removed. The rest of > the fix is applied without changes. > > Thanks, > Andrew > From yan at azul.com Wed Jun 10 16:02:15 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 10 Jun 2020 19:02:15 +0300 Subject: [13u] RFR: 8240972: macOS codesign fail on macOS 10.13.5 or older In-Reply-To: <6f6dbbbf-785b-b224-1e85-40ae4418edca@azul.com> References: <6f6dbbbf-785b-b224-1e85-40ae4418edca@azul.com> Message-ID: <246fe4ab-cceb-699a-e4da-50ad751a172e@azul.com> Looks good to me. Thanks, --yan On 10.06.2020 18:11, Andrew Brygin wrote: > Hello, > > I would like to backport the fix for JDK-8240972 to 13u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8240972 > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/4253bf176649 > Webrev: http://cr.openjdk.java.net/~bae/13u/8240972/webrev.00 > > The original change modifies file make/autoconf/basic_tools.m4 which > does not exist in jdk13u due to absence of the fix for JDK-8239708. > However, the same change applies cleanly to make/autoconf/basics.m4. > > > Thanks, > Andrew > From snazarkin at azul.com Wed Jun 10 16:05:34 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Wed, 10 Jun 2020 16:05:34 +0000 Subject: [13u] RFR: 8226721 : Missing intrinsics for Math.ceil, floor, rint In-Reply-To: <902890ca-367e-b107-8b05-74801762dddf@azul.com> References: <3FA83800-47D9-41E0-ACF1-B637ABDF54EA@azul.com> <902890ca-367e-b107-8b05-74801762dddf@azul.com> Message-ID: <599E2DD3-9A17-46A5-8215-E018A2DD1D26@azul.com> x86/x64 build, regular tier1/tier2 tests (x64 only), + jmh Sergey Nazarkin > On Jun 10, 2020, at 17:48, Yuri Nesterenko wrote: > > Hi Sergey, > > how did you test that? > > Thank you for the backport! > > --yan > > On 10.06.2020 12:35, Sergey Nazarkin wrote: >> Hi! >> >> Please review a set of backports to bring math intrinsic to jdk13. The train consists of initial commit (8226721) and build fix for x86 (8231713) >> >> Original records >> https://bugs.openjdk.java.net/browse/JDK-8226721 (initial) >> https://bugs.openjdk.java.net/browse/JDK-8231713 (x86 build fix) >> >> The patch from 8226721 applies mostly cleanly except one small part at x86.ad due to context shift by missed 8224974. The second part (8231713) applies cleanly. >> >> Webrev >> http://cr.openjdk.java.net/~snazarki/webrev/8226721/ >> >> >> From yan at azul.com Wed Jun 10 16:06:48 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 10 Jun 2020 19:06:48 +0300 Subject: [13u] RFR: 8226721 : Missing intrinsics for Math.ceil, floor, rint In-Reply-To: <599E2DD3-9A17-46A5-8215-E018A2DD1D26@azul.com> References: <3FA83800-47D9-41E0-ACF1-B637ABDF54EA@azul.com> <902890ca-367e-b107-8b05-74801762dddf@azul.com> <599E2DD3-9A17-46A5-8215-E018A2DD1D26@azul.com> Message-ID: OK, fine with me, then! --yan On 10.06.2020 19:05, Sergey Nazarkin wrote: > x86/x64 build, regular tier1/tier2 tests (x64 only), + jmh > > > Sergey Nazarkin > > > > >> On Jun 10, 2020, at 17:48, Yuri Nesterenko wrote: >> >> Hi Sergey, >> >> how did you test that? >> >> Thank you for the backport! >> >> --yan >> >> On 10.06.2020 12:35, Sergey Nazarkin wrote: >>> Hi! >>> >>> Please review a set of backports to bring math intrinsic to jdk13. The train consists of initial commit (8226721) and build fix for x86 (8231713) >>> >>> Original records >>> https://bugs.openjdk.java.net/browse/JDK-8226721 (initial) >>> https://bugs.openjdk.java.net/browse/JDK-8231713 (x86 build fix) >>> >>> The patch from 8226721 applies mostly cleanly except one small part at x86.ad due to context shift by missed 8224974. The second part (8231713) applies cleanly. >>> >>> Webrev >>> http://cr.openjdk.java.net/~snazarki/webrev/8226721/ >>> >>> >>> > From dcherepanov at azul.com Thu Jun 11 08:56:44 2020 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Thu, 11 Jun 2020 11:56:44 +0300 Subject: [13u] RFR 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Message-ID: <89cd6812-7e6f-14fa-01eb-6b44ed4d3391@azul.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8241638 original patch: https://hg.openjdk.java.net/jdk/jdk/rev/3f8d03880bf5 webrev for 13u: http://cr.openjdk.java.net/~dcherepanov/openjdk13u/8241638/webrev.v0/ The patch applies cleanly except the change in LauncherCommon.gmk due to different context (context changed after 8233410), re-applied this part manually. Thanks, Dmitry From katya at azul.com Thu Jun 11 14:47:18 2020 From: katya at azul.com (Ekaterina Vergizova) Date: Thu, 11 Jun 2020 14:47:18 +0000 Subject: [13u] RFR: 8235563: [TESTBUG] appcds/CommandLineFlagComboNegative.java does not handle archive mapping failure Message-ID: Hello, I would like to backport the fix for 8235563 to 13u. It's a test only change, and already included into 11u. JBS: https://bugs.openjdk.java.net/browse/JDK-8235563 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/6b8a675f35e1 Webrev for 13u: http://cr.openjdk.java.net/~yan/8235563/webrev.00/ The changes are the same as for 15, but should be applied to test/hotspot/jtreg/runtime/appcds/CommandLineFlagComboNegative.java instead of test/hotspot/jtreg/runtime/cds/appcds/CommandLineFlagComboNegative.java, because 8202339 that modifies the test location is not backported to 13u. The affected test passes. Thanks, Ekaterina From katya at azul.com Thu Jun 11 15:20:54 2020 From: katya at azul.com (Ekaterina Vergizova) Date: Thu, 11 Jun 2020 15:20:54 +0000 Subject: [13u] RFR: 8238676: jni crashes on accessing it from process exit hook Message-ID: <248585a42b5e49f5a24c4e4a7261a7c2@azul.com> Hello, I would like to backport the fix for 8238676 and its regression fix 8240603 to 13u. They are already included into 11u. JBS: https://bugs.openjdk.java.net/browse/JDK-8238676 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/80e4a066342d Webrev for 13u: http://cr.openjdk.java.net/~yan/8238676/webrev.00/ The patch for 8238676 applies almost cleanly except for: - changes for make/test/JtregNativeHotspot.gmk apply manually due to different context (8179317 is not in 13u) - the second hunk of src/hotspot/share/prims/jni.cpp applies manually due to different context (8234739 is not in 13u) The patch for 8240603 applies cleanly. Tested with tier1 on Windows, the test added in 8238676 failed before the fixes and passes after. Thanks, Ekaterina From dlemmond at amazon.com Thu Jun 11 16:53:36 2020 From: dlemmond at amazon.com (Lemmond, Dan) Date: Thu, 11 Jun 2020 16:53:36 +0000 Subject: [11u] RFR: JDK-8206895: aarch64: rework error-prone cmp instuction Message-ID: Hello, Please review this backport request for JDK-8206895: aarch64: rework error-prone cmp instruction. JBS: https://bugs.openjdk.java.net/browse/JDK-8206895 Webrev: http://cr.openjdk.java.net/~phh/8206895/webrev.11u.00/ Original review thread: https://mail.openjdk.java.net/pipermail/hotspot-dev/2018-July/033461.html This backport required fixes to three hunks and the omission of one hunk entirely. macroAssembler_aarch64.cpp required hunk 19 to be manually applied, and stubGenerator_aarch64.cpp required hunk 7 and 13 to be manually applied. I have omitted hunk 15 from the backport as JDK-8218966 was backported previously, which overwrites that section with a bug fix. The backport compiles without issue and passes all Tier1 Hotspot tests. Thanks, Dan From aph at redhat.com Thu Jun 11 17:24:12 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Jun 2020 18:24:12 +0100 Subject: [11u] RFR: JDK-8206895: aarch64: rework error-prone cmp instuction In-Reply-To: References: Message-ID: <16032b64-828a-cef4-afa7-667a2e2656ce@redhat.com> On 11/06/2020 17:53, Lemmond, Dan wrote: > The backport compiles without issue and passes all Tier1 Hotspot tests. Please explain why this should be back-ported. BTW, we already discussed backporting it to 11 here and it was rejected as too risky: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-July/033437.html Unless this actually fixes a bug, it looks dubious as a backport. -- 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 hohensee at amazon.com Thu Jun 11 17:34:53 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Jun 2020 17:34:53 +0000 Subject: [11u] RFR: JDK-8206895: aarch64: rework error-prone cmp instuction In-Reply-To: References: Message-ID: <4594D50C-B96D-4989-BCDF-5C74F8CABA45@amazon.com> Lgtm. I'll take the issue and add a Fix Request (11u) comment for you. Thanks, Paul ?On 6/11/20, 9:55 AM, "jdk-updates-dev on behalf of Lemmond, Dan" wrote: Hello, Please review this backport request for JDK-8206895: aarch64: rework error-prone cmp instruction. JBS: https://bugs.openjdk.java.net/browse/JDK-8206895 Webrev: http://cr.openjdk.java.net/~phh/8206895/webrev.11u.00/ Original review thread: https://mail.openjdk.java.net/pipermail/hotspot-dev/2018-July/033461.html This backport required fixes to three hunks and the omission of one hunk entirely. macroAssembler_aarch64.cpp required hunk 19 to be manually applied, and stubGenerator_aarch64.cpp required hunk 7 and 13 to be manually applied. I have omitted hunk 15 from the backport as JDK-8218966 was backported previously, which overwrites that section with a bug fix. The backport compiles without issue and passes all Tier1 Hotspot tests. Thanks, Dan From dlemmond at amazon.com Thu Jun 11 19:15:10 2020 From: dlemmond at amazon.com (Lemmond, Dan) Date: Thu, 11 Jun 2020 19:15:10 +0000 Subject: [11u] RFR: JDK-8206895: aarch64: rework error-prone cmp instuction Message-ID: <95370983-0D5B-49BC-81EA-F939C33A9839@amazon.com> > BTW, we already discussed backporting it to 11 here and it was rejected > as too risky: I haven?t been able to find any information about the risk associated with 8206895 (this patch), but the 8206265 thread you refer to reads to me that a smaller, easily reviewable fix was approved for 11.0.1 due to stability concerns right after GA, while a somewhat riskier but better fix went into 12. If there were/are other reasons, I'd appreciate any insight you can provide. > Please explain why this should be back-ported. It looks like a nice stability and readability improvement to me. Given that it's been baking since 12, I see the backport risk as minor. Thanks, Dan ?On 6/11/20, 10:25 AM, "Andrew Haley" wrote: On 11/06/2020 17:53, Lemmond, Dan wrote: > The backport compiles without issue and passes all Tier1 Hotspot tests. Please explain why this should be back-ported. BTW, we already discussed backporting it to 11 here and it was rejected as too risky: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-July/033437.html Unless this actually fixes a bug, it looks dubious as a backport. -- 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 Fri Jun 12 11:13:11 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Jun 2020 12:13:11 +0100 Subject: [11u] RFR: JDK-8206895: aarch64: rework error-prone cmp instuction In-Reply-To: <95370983-0D5B-49BC-81EA-F939C33A9839@amazon.com> References: <95370983-0D5B-49BC-81EA-F939C33A9839@amazon.com> Message-ID: On 11/06/2020 20:15, Lemmond, Dan wrote: >> BTW, we already discussed backporting it to 11 here and it was rejected >> as too risky: > > I haven?t been able to find any information about the risk > associated with 8206895 (this patch), but the 8206265 thread you > refer to reads to me that a smaller, easily reviewable fix was > approved for 11.0.1 due to stability concerns right after GA, while > a somewhat riskier but better fix went into 12. Sure, but 12 wasn't a LTS release in 2018, it wasn't even released yet. Over time these things firm up. Here's what I wrote for 8u: All fixes that significantly improve stability, security or performance and do not change behavioural compatibility will be considered for jdk8u. To use the language of the JDK 6 project, by default such fixes are assumed to be applicable to jdk8u, especially if having "soaked" in later JDK releases for a time without incident. By "significant" I mean any bug that affects runtime behaviour in a way that either produces incorrect results, poor performance, or crashes the VM, especially TCK failures. > If there were/are other reasons, I'd appreciate any insight you can provide. So, to be considered a patch has to significantly improve stability, security or performance. >> Please explain why this should be back-ported. > > It looks like a nice stability and readability improvement to > me. Given that it's been baking since 12, I see the backport risk as > minor. How does it make the platform more stable? I guess it might help when back-porting new intrinsics, but I hope that's not going to be a huge thing now. -- 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 li.jiang at oracle.com Mon Jun 15 13:07:13 2020 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Mon, 15 Jun 2020 21:07:13 +0800 Subject: [14u] RFR: JDK-8247585: JDK 14.0.2 L10N resource file update Message-ID: <9fbe5679-b342-9f96-2ffd-507accdeb18a@oracle.com> Hi, Pls help to review the L10N resource files update for JDK 14.0.2. Bug: https://bugs.openjdk.java.net/browse/JDK-8247585 Webrev: http://cr.openjdk.java.net/~ljiang/8247585/read/ This change include the glossary update and new translated messages in the properties files. Thanks, Leo From yan at azul.com Mon Jun 15 14:26:12 2020 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 15 Jun 2020 17:26:12 +0300 Subject: [13u] RFR 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: <89cd6812-7e6f-14fa-01eb-6b44ed4d3391@azul.com> References: <89cd6812-7e6f-14fa-01eb-6b44ed4d3391@azul.com> Message-ID: <06228a83-b011-b390-884a-c44bada7d192@azul.com> Looks good to me --yan On 11.06.2020 11:56, Dmitry Cherepanov wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8241638 > original patch: https://hg.openjdk.java.net/jdk/jdk/rev/3f8d03880bf5 > webrev for 13u: http://cr.openjdk.java.net/~dcherepanov/openjdk13u/8241638/webrev.v0/ > > The patch applies cleanly except the change in LauncherCommon.gmk due to different context (context > changed after 8233410), re-applied this part manually. > > Thanks, > > Dmitry From katya at azul.com Mon Jun 15 14:48:00 2020 From: katya at azul.com (Ekaterina Vergizova) Date: Mon, 15 Jun 2020 14:48:00 +0000 Subject: [13u] RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images Message-ID: <00d6a3b2b39b437db7b922a1269e9383@azul.com> Hello, I would like to backport the fix for 8237192 to 13u. It is already included into 11u. JBS: https://bugs.openjdk.java.net/browse/JDK-8237192 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/9b999cf5e13a Webrev for 13u: http://cr.openjdk.java.net/~yan/8237192/webrev.00/ The patch applies cleanly except for: - some copyright years are changed - in make/common/NativeCompilation.gmk the variable $1_SYMBOLS_DIR of the original patch is replaced by it's equivalent $1_OUTPUT_DIR (8212780 is not in 13u) - in make/scripts/compare.sh a small modification is done due to different context (8233112 is not in 13u) Testing: Windows images with different values of new option '--with-external-symbols-in-bundles' are built successfully, the default configuration is tested with tier1. Thanks, Ekaterina From yan at azul.com Mon Jun 15 14:55:52 2020 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 15 Jun 2020 17:55:52 +0300 Subject: [13u] RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images In-Reply-To: <00d6a3b2b39b437db7b922a1269e9383@azul.com> References: <00d6a3b2b39b437db7b922a1269e9383@azul.com> Message-ID: OK, fine, looks good. --yan On 15.06.2020 17:48, Ekaterina Vergizova wrote: > Hello, > I would like to backport the fix for 8237192 to 13u. It is already included into 11u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8237192 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/9b999cf5e13a > Webrev for 13u: http://cr.openjdk.java.net/~yan/8237192/webrev.00/ > > The patch applies cleanly except for: > - some copyright years are changed > - in make/common/NativeCompilation.gmk the variable $1_SYMBOLS_DIR of the original patch > is replaced by it's equivalent $1_OUTPUT_DIR (8212780 is not in 13u) > - in make/scripts/compare.sh a small modification is done due to different context (8233112 is not in 13u) > > Testing: > Windows images with different values of new option '--with-external-symbols-in-bundles' are built successfully, > the default configuration is tested with tier1. > > Thanks, > Ekaterina > From yan at azul.com Mon Jun 15 15:03:00 2020 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 15 Jun 2020 18:03:00 +0300 Subject: [13u] RFR: 8235563: [TESTBUG] appcds/CommandLineFlagComboNegative.java does not handle archive mapping failure In-Reply-To: References: Message-ID: <47f00e75-4076-8790-0502-118de59278ec@azul.com> Yes, looks good and harmless, OK for the last day before freeze. Thank you! --yan On 11.06.2020 17:47, Ekaterina Vergizova wrote: > Hello, > I would like to backport the fix for 8235563 to 13u. > It's a test only change, and already included into 11u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235563 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/6b8a675f35e1 > Webrev for 13u: http://cr.openjdk.java.net/~yan/8235563/webrev.00/ > > The changes are the same as for 15, but should be applied to > test/hotspot/jtreg/runtime/appcds/CommandLineFlagComboNegative.java instead of > test/hotspot/jtreg/runtime/cds/appcds/CommandLineFlagComboNegative.java, > because 8202339 that modifies the test location is not backported to 13u. > > The affected test passes. > > Thanks, > Ekaterina > From yan at azul.com Mon Jun 15 16:07:50 2020 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 15 Jun 2020 19:07:50 +0300 Subject: [13u notice]: jdk 13.0.4 rampdown started Message-ID: Hi all, the last build tag for jdk 13.0.4 was set. The last merge from jdk13u-dev to jdk13u will be performed shortly, and jdk13u-dev will be reopened for changes targeted to 13.0.5. Critical changes, if any, must be requested with jdk13u-critial-request and pushed to the master jdk13u directly. There will be soon a separate notice about jdk13u-dev reopening. Thanks, --yan From yan at azul.com Mon Jun 15 16:31:28 2020 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 15 Jun 2020 19:31:28 +0300 Subject: [13u] RFR: 8247607: Bump update version for OpenJDK: jdk-13.0.5 Message-ID: <4c8e3e19-8ee1-2454-51bd-1e2b9b592cc5@azul.com> Hi, development of 13.0.5 starts this week. We need to bump the version. Webrev is here: http://cr.openjdk.java.net/~yan/8247607/webrev.0/ Thanks! --yan From abrygin at azul.com Mon Jun 15 16:40:01 2020 From: abrygin at azul.com (Andrew Brygin) Date: Mon, 15 Jun 2020 19:40:01 +0300 Subject: [13u] RFR: 8247607: Bump update version for OpenJDK: jdk-13.0.5 In-Reply-To: <4c8e3e19-8ee1-2454-51bd-1e2b9b592cc5@azul.com> References: <4c8e3e19-8ee1-2454-51bd-1e2b9b592cc5@azul.com> Message-ID: <94fcd172-d863-5750-4e15-080758977b4d@azul.com> Hello Yuri, the change looks fine to me. Thanks, Andrew On 15/06/2020 19:31, Yuri Nesterenko wrote: > Hi, > > development of 13.0.5 starts this week. We need to bump the version. > > Webrev is here: > http://cr.openjdk.java.net/~yan/8247607/webrev.0/ > > Thanks! > --yan > From matthias.baesken at sap.com Tue Jun 16 10:29:07 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 16 Jun 2020 10:29:07 +0000 Subject: [11u] RFR: 8228967: Trust/Key store and SSL context utilities for tests In-Reply-To: References: Message-ID: Hello G?tz, the backport looks good to me . Best regards, Matthias > > Hi, > > I would like to bring this test-only change to 11.0.9. > > This applies clean except for two trivial resolves: > > Previously, when downporting "8234728: Some security tests should > support TLSv1.3", I had to resolve NullHostnameCheck.java because > this change was missing. Now, bringing this to 11u, I had to resolve the > same location again now, obviously. > > Further, I had to resolve the copyright in PacketLossRetransmission.java. > > http://cr.openjdk.java.net/~goetz/wr20/8228967-ssl_test_utilities-jdk11/01/ > > Please review. > https://bugs.openjdk.java.net/browse/JDK-8228967 > https://hg.openjdk.java.net/jdk/jdk/rev/d80e4bce4588 > > Best regards, > Goetz. From li.jiang at oracle.com Tue Jun 16 12:50:48 2020 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Tue, 16 Jun 2020 20:50:48 +0800 Subject: [14u] RFR: JDK-8247585: JDK 14.0.2 L10N resource file update In-Reply-To: <9d06823c-22e2-ee8d-d474-3f80dd528447@oracle.com> References: <9fbe5679-b342-9f96-2ffd-507accdeb18a@oracle.com> <9d06823c-22e2-ee8d-d474-3f80dd528447@oracle.com> Message-ID: I can confirm the English resources haven't changed in this msg drop cycle. Thank you for reviewing. Thanks, Leo On 6/16/20 1:05 AM, naoto.sato at oracle.com wrote: > Hi Leo, > > Looks good, assuming that the original English resources haven't changed. > > Naoto > > On 6/15/20 6:07 AM, li.jiang at oracle.com wrote: >> Hi, >> >> Pls help to review the L10N resource files update for JDK 14.0.2. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8247585 >> >> Webrev: >> http://cr.openjdk.java.net/~ljiang/8247585/read/ >> >> This change include the glossary update and new translated messages in >> the properties files. >> >> Thanks, >> Leo From snazarkin at azul.com Wed Jun 17 21:46:40 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Wed, 17 Jun 2020 21:46:40 +0000 Subject: [13u] RFR: 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint Message-ID: <0E5FCF66-1775-4AE1-927F-69B1ADC2A3DE@azul.com> Hi, I?d like to port this change to openjdk13u. This is aarch64 part of the set where x86 is already integrated, ppc64 is on review. Original case: https://bugs.openjdk.java.net/browse/JDK-8230591 ppc64 impl (mandatory for clean port, requested for integration) https://bugs.openjdk.java.net/browse/JDK-8231649 aarch64 patch http://cr.openjdk.java.net/~snazarki/webrev/8230591/ Original patch applies almost cleanly, only copyright dates is fixed due to missed 8224974(Implement JEP 352) $cat src/hotspot/cpu/aarch64/assembler_aarch64.hpp.rej --- assembler_aarch64.hpp +++ assembler_aarch64.hpp @@ -1,6 +1,6 @@ /* - * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All rights reserved. - * Copyright (c) 2014, 2019, Red Hat Inc. All rights reserved. + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2020, Red Hat Inc. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it Tested with fastdebug/release hotspot tier1 From aph at redhat.com Thu Jun 18 07:19:57 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Jun 2020 08:19:57 +0100 Subject: [13u] RFR: 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint In-Reply-To: <0E5FCF66-1775-4AE1-927F-69B1ADC2A3DE@azul.com> References: <0E5FCF66-1775-4AE1-927F-69B1ADC2A3DE@azul.com> Message-ID: <6d8e3675-d26e-e48b-aa36-acb61e0d7726@redhat.com> On 17/06/2020 22:46, Sergey Nazarkin wrote: > I?d like to port this change to openjdk13u. This is aarch64 part of the set where x86 is already integrated, ppc64 is on review. > > Original case: > https://bugs.openjdk.java.net/browse/JDK-8230591 > > ppc64 impl (mandatory for clean port, requested for integration) > https://bugs.openjdk.java.net/browse/JDK-8231649 > > > aarch64 patch > http://cr.openjdk.java.net/~snazarki/webrev/8230591/ OK, 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 goetz.lindenmaier at sap.com Thu Jun 18 08:01:59 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 18 Jun 2020 08:01:59 +0000 Subject: [11u] RFR: 8228967: Trust/Key store and SSL context utilities for tests In-Reply-To: References: Message-ID: Thanks for your review! Best regards, Goetz. > -----Original Message----- > From: Baesken, Matthias > Sent: Tuesday, June 16, 2020 12:29 PM > To: Lindenmaier, Goetz ; Langer, Christoph > ; 'jdk-updates-dev at openjdk.java.net' updates-dev at openjdk.java.net> > Subject: RE: [11u] RFR: 8228967: Trust/Key store and SSL context utilities for > tests > > Hello G?tz, the backport looks good to me . > > Best regards, Matthias > > > > > Hi, > > > > I would like to bring this test-only change to 11.0.9. > > > > This applies clean except for two trivial resolves: > > > > Previously, when downporting "8234728: Some security tests should > > support TLSv1.3", I had to resolve NullHostnameCheck.java because > > this change was missing. Now, bringing this to 11u, I had to resolve the > > same location again now, obviously. > > > > Further, I had to resolve the copyright in PacketLossRetransmission.java. > > > > http://cr.openjdk.java.net/~goetz/wr20/8228967-ssl_test_utilities- > jdk11/01/ > > > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8228967 > > https://hg.openjdk.java.net/jdk/jdk/rev/d80e4bce4588 > > > > Best regards, > > Goetz. From yan at azul.com Thu Jun 18 08:41:03 2020 From: yan at azul.com (Yuri Nesterenko) Date: Thu, 18 Jun 2020 11:41:03 +0300 Subject: [13u notice]: jdk13u-dev open for 13.0.5 Message-ID: <5a605f21-2898-8b2b-edcf-bd50e5a39e09@azul.com> Hi, version in repository jdk13u-dev is _bumped_ to 13.0.5, it is open for changes targeted to October release. You are welcome! Thanks, --yan From sgehwolf at redhat.com Thu Jun 18 12:47:33 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Jun 2020 14:47:33 +0200 Subject: [11u] RFR: 8245832: JDK build make-static-libs should build all JDK libraries Message-ID: Hi, Could I please get a review of this OpenJDK 11 backport? It's one of the 11.0.9-oracle parity ones. The patch from jdk/jdk didn't apply cleanly due to context changes in make/Main.gmk. Namely, USE_WRAPPER=true, removed with JDK-8245287[1] in head but present in OpenJDK 11 head. Adjusted that bit manually. Other than that, the patch is the same. Bug: https://bugs.openjdk.java.net/browse/JDK-8245832 webrev: https://bugs.openjdk.java.net/browse/JDK-8245832 Testing: Building static-libs-image target comparing before/after[2]. Testing graal build with this. Seems fine. Thoughts? Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8245287 [2] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/before_after.txt From sgehwolf at redhat.com Thu Jun 18 13:16:50 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Jun 2020 15:16:50 +0200 Subject: [11u] RFR: 8245832: JDK build make-static-libs should build all JDK libraries In-Reply-To: References: Message-ID: On Thu, 2020-06-18 at 14:47 +0200, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this OpenJDK 11 backport? It's one of > the 11.0.9-oracle parity ones. > > The patch from jdk/jdk didn't apply cleanly due to context changes in > make/Main.gmk. Namely, USE_WRAPPER=true, removed with JDK-8245287[1] in > head but present in OpenJDK 11 head. Adjusted that bit manually. Other > than that, the patch is the same. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245832 Sorry wrong webrev link previously: webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/webrev/ > > Testing: Building static-libs-image target comparing before/after[2]. > Testing graal build with this. Seems fine. > > Thoughts? > > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8245287 > [2] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/before_after.txt From bob.vandette at oracle.com Thu Jun 18 14:15:03 2020 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 18 Jun 2020 10:15:03 -0400 Subject: [11u] RFR: 8245832: JDK build make-static-libs should build all JDK libraries In-Reply-To: References: Message-ID: <4A3566AE-79DF-4837-8DA8-6996AB9A2DE9@oracle.com> Have you done a Mac and Windows build? My backport is identical to yours except I had to add these additional changes. I?m not sure if they are needed on your 11 update release. --- a/make/lib/Awt2dLibraries.gmk Thu Nov 07 17:47:22 2019 -0800 +++ b/make/lib/Awt2dLibraries.gmk Tue Jun 02 17:58:36 2020 +0000 @@ -743,11 +743,11 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false) $(BUILD_LIBJAWT): $(BUILD_LIBAWT_XAWT) else - $(BUILD_LIBJAWT): $(INSTALL_LIBRARIES_HERE)/$(LIBRARY_PREFIX)awt_headless$(SHARED_LIBRARY_SUFFIX) + $(BUILD_LIBJAWT): $(call FindLib, $(MODULE), awt_headless) endif ifeq ($(OPENJDK_TARGET_OS), macosx) - $(BUILD_LIBJAWT): $(INSTALL_LIBRARIES_HERE)/$(LIBRARY_PREFIX)awt_lwawt$(SHARED_LIBRARY_SUFFIX) + $(BUILD_LIBJAWT): $(call FindLib, $(MODULE), awt_lwawt) endif endif # OPENJDK_TARGET_OS --- a/make/lib/Lib-jdk.accessibility.gmk Thu Nov 07 17:47:22 2019 -0800 +++ b/make/lib/Lib-jdk.accessibility.gmk Tue Jun 02 17:58:36 2020 +0000 @@ -55,7 +55,7 @@ VERSIONINFO_RESOURCE := $(ROOT_SRCDIR)/common/AccessBridgeStatusWindow.rc, \ ) - $$(BUILD_JAVAACCESSBRIDGE$1): $(SUPPORT_OUTPUTDIR)/native/java.desktop/libjawt/jawt.lib + $$(BUILD_JAVAACCESSBRIDGE$1): $(call FindStaticLib, java.desktop, jawt, /libjawt) TARGETS += $$(BUILD_JAVAACCESSBRIDGE$1) endef --- a/make/lib/LibCommon.gmk Thu Nov 07 17:47:22 2019 -0800 +++ b/make/lib/LibCommon.gmk Tue Jun 02 17:58:36 2020 +0000 @@ -83,9 +83,13 @@ # Param 1 - module name # Param 2 - library name # Param 3 - optional subdir for library -FindStaticLib = \ - $(addprefix $(SUPPORT_OUTPUTDIR)/native/, \ - $(strip $1)$(strip $3)/$(LIBRARY_PREFIX)$(strip $2)$(STATIC_LIBRARY_SUFFIX)) +ifneq ($(STATIC_LIBS), true) + FindStaticLib = \ + $(addprefix $(SUPPORT_OUTPUTDIR)/native/, \ + $(strip $1)$(strip $3)/$(LIBRARY_PREFIX)$(strip $2)$(STATIC_LIBRARY_SUFFIX)) +else + FindStaticLib = +endif # Put the libraries here. INSTALL_LIBRARIES_HERE := $(call FindLibDirForModule, $(MODULE)) > On Jun 18, 2020, at 9:16 AM, Severin Gehwolf wrote: > > On Thu, 2020-06-18 at 14:47 +0200, Severin Gehwolf wrote: >> Hi, >> >> Could I please get a review of this OpenJDK 11 backport? It's one of >> the 11.0.9-oracle parity ones. >> >> The patch from jdk/jdk didn't apply cleanly due to context changes in >> make/Main.gmk. Namely, USE_WRAPPER=true, removed with JDK-8245287[1] in >> head but present in OpenJDK 11 head. Adjusted that bit manually. Other >> than that, the patch is the same. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245832 > > Sorry wrong webrev link previously: > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/webrev/ > >> >> Testing: Building static-libs-image target comparing before/after[2]. >> Testing graal build with this. Seems fine. >> >> Thoughts? >> >> Thanks, >> Severin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8245287 >> [2] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/before_after.txt > From sgehwolf at redhat.com Thu Jun 18 15:15:14 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Jun 2020 17:15:14 +0200 Subject: [11u] RFR: 8245832: JDK build make-static-libs should build all JDK libraries In-Reply-To: <4A3566AE-79DF-4837-8DA8-6996AB9A2DE9@oracle.com> References: <4A3566AE-79DF-4837-8DA8-6996AB9A2DE9@oracle.com> Message-ID: Hi Bob, Thanks for the review! On Thu, 2020-06-18 at 10:15 -0400, Bob Vandette wrote: > Have you done a Mac and Windows build? I have not. But I will try to find somebody to do it for me... > My backport is identical to yours except I had to add these > additional changes. I?m not sure if they > are needed on your 11 update release. Thanks for that! Cheers, Severin > --- a/make/lib/Awt2dLibraries.gmk Thu Nov 07 17:47:22 2019 -0800 > +++ b/make/lib/Awt2dLibraries.gmk Tue Jun 02 17:58:36 2020 +0000 > @@ -743,11 +743,11 @@ > ifeq ($(ENABLE_HEADLESS_ONLY), false) > $(BUILD_LIBJAWT): $(BUILD_LIBAWT_XAWT) > else > - $(BUILD_LIBJAWT): > $(INSTALL_LIBRARIES_HERE)/$(LIBRARY_PREFIX)awt_headless$(SHARED_LIBRA > RY_SUFFIX) > + $(BUILD_LIBJAWT): $(call FindLib, $(MODULE), awt_headless) > endif > > ifeq ($(OPENJDK_TARGET_OS), macosx) > - $(BUILD_LIBJAWT): > $(INSTALL_LIBRARIES_HERE)/$(LIBRARY_PREFIX)awt_lwawt$(SHARED_LIBRARY_ > SUFFIX) > + $(BUILD_LIBJAWT): $(call FindLib, $(MODULE), awt_lwawt) > endif > > endif # OPENJDK_TARGET_OS > --- a/make/lib/Lib-jdk.accessibility.gmk Thu Nov 07 17:47:22 > 2019 -0800 > +++ b/make/lib/Lib-jdk.accessibility.gmk Tue Jun 02 17:58:36 > 2020 +0000 > @@ -55,7 +55,7 @@ > VERSIONINFO_RESOURCE := > $(ROOT_SRCDIR)/common/AccessBridgeStatusWindow.rc, \ > ) > > - $$(BUILD_JAVAACCESSBRIDGE$1): > $(SUPPORT_OUTPUTDIR)/native/java.desktop/libjawt/jawt.lib > + $$(BUILD_JAVAACCESSBRIDGE$1): $(call FindStaticLib, > java.desktop, jawt, /libjawt) > > TARGETS += $$(BUILD_JAVAACCESSBRIDGE$1) > endef > --- a/make/lib/LibCommon.gmk Thu Nov 07 17:47:22 2019 -0800 > +++ b/make/lib/LibCommon.gmk Tue Jun 02 17:58:36 2020 +0000 > @@ -83,9 +83,13 @@ > # Param 1 - module name > # Param 2 - library name > # Param 3 - optional subdir for library > -FindStaticLib = \ > - $(addprefix $(SUPPORT_OUTPUTDIR)/native/, \ > - $(strip $1)$(strip $3)/$(LIBRARY_PREFIX)$(strip > $2)$(STATIC_LIBRARY_SUFFIX)) > +ifneq ($(STATIC_LIBS), true) > + FindStaticLib = \ > + $(addprefix $(SUPPORT_OUTPUTDIR)/native/, \ > + $(strip $1)$(strip $3)/$(LIBRARY_PREFIX)$(strip > $2)$(STATIC_LIBRARY_SUFFIX)) > +else > + FindStaticLib = > +endif > > # Put the libraries here. > INSTALL_LIBRARIES_HERE := $(call FindLibDirForModule, $(MODULE)) > > > On Jun 18, 2020, at 9:16 AM, Severin Gehwolf > > wrote: > > > > On Thu, 2020-06-18 at 14:47 +0200, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I please get a review of this OpenJDK 11 backport? It's one > > > of > > > the 11.0.9-oracle parity ones. > > > > > > The patch from jdk/jdk didn't apply cleanly due to context > > > changes in > > > make/Main.gmk. Namely, USE_WRAPPER=true, removed with JDK- > > > 8245287[1] in > > > head but present in OpenJDK 11 head. Adjusted that bit manually. > > > Other > > > than that, the patch is the same. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245832 > > > > Sorry wrong webrev link previously: > > > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/webrev/ > > > > > Testing: Building static-libs-image target comparing > > > before/after[2]. > > > Testing graal build with this. Seems fine. > > > > > > Thoughts? > > > > > > Thanks, > > > Severin > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8245287 > > > [2] > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/before_after.txt > > From jaroslav.bachorik at datadoghq.com Thu Jun 18 15:26:31 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Thu, 18 Jun 2020 17:26:31 +0200 Subject: [11u] RFR 8244287: JFR: Methods samples have line number 0 Message-ID: Hi all, Could I get this simple fix reviewed? It is fixing a regression introduced while backporting JDK-823790 and adding a new test to prevent such regressions in the future. JIRA : https://bugs.openjdk.java.net/browse/JDK-8244287 Webrev : http://cr.openjdk.java.net/~jbachorik/8244287/webrev/ Thanks, -JB- From hohensee at amazon.com Thu Jun 18 19:11:36 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 18 Jun 2020 19:11:36 +0000 Subject: [11u] RFR/A: 8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread Message-ID: <09229907-C812-4974-BF5D-8619FEA083BC@amazon.com> This request is for a pair of backports. 8231209 is the first (and primary), 8231968 is a minor cleanup. There are CSR?s for both. The effect is to add a convenience method getCurrentThreadAllocatedBytes() to com.sun.management.ThreadMXBean that can be implemented more efficiently than the equivalent getThreadAllocatedBytes(long id), and to make the implementation of getThreadAllocatedBytes(long id) and getThreadAllocatedBytes(long[] id) more efficient. These methods are heavily used by heap profiling tools, including Amazon?s, and their efficiency is important to us. There is no effect on the TCK because com.sun.management is a platform-specific package. See the CSRs for more detail. The patches apply cleanly (in sequence) to 11u, but I?m posting a review/approval request because the backport CSRs need approval. Once the backport CSRs are reviewed, finalized, and approved, l can tag 8231209 and 8231968. Tested with hotspot/jtreg/vmTestbase/nsk/monitoring jdk/com/sun/management jdk/jdk/jfr/event/runtime The same tests pass/fail as with unpatched jdk11u-dev. JDK-8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread Original RFE: https://bugs.openjdk.java.net/browse/JDK-8231209 Original Patch: https://hg.openjdk.java.net/jdk/jdk/rev/c29e49148be7 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8231374 Original review thread: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-September/029208.html Backport RFE: https://bugs.openjdk.java.net/browse/JDK-8247806 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8247807 JDK-8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes Original RFE: https://bugs.openjdk.java.net/browse/JDK-8231968 Original Patch: https://hg.openjdk.java.net/jdk/jdk/rev/5bb426e9acc4 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8232072 Original review thread: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029659.html Backport RFE: https://bugs.openjdk.java.net/browse/JDK-8247809 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8247810 Thanks, Paul From snazarkin at azul.com Thu Jun 18 19:50:44 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Thu, 18 Jun 2020 19:50:44 +0000 Subject: [13u] 8247873: [arm32] client vm build failure Message-ID: <374EAD9C-8820-4E47-8020-08B69C342AA9@azul.com> Hi! Please review build failure fix for arm32 client vm. I?ve not traced down last success build but jdk11 is not affected. Bug: https://bugs.openjdk.java.net/browse/JDK-8247873 Webrev: http://cr.openjdk.java.net/~snazarki/webrev/8247873/ From goetz.lindenmaier at sap.com Fri Jun 19 06:18:00 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 19 Jun 2020 06:18:00 +0000 Subject: Result: New OpenJDK Updates Committer: Ichiroh Takiguchi Message-ID: Voting for Ichiroh Takiguchi [1] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best regards, Goetz [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-May/003201.html From sgehwolf at redhat.com Fri Jun 19 07:14:08 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 19 Jun 2020 09:14:08 +0200 Subject: [11u] RFR: 8245832: JDK build make-static-libs should build all JDK libraries In-Reply-To: <4A3566AE-79DF-4837-8DA8-6996AB9A2DE9@oracle.com> References: <4A3566AE-79DF-4837-8DA8-6996AB9A2DE9@oracle.com> Message-ID: Hi Bob, On Thu, 2020-06-18 at 10:15 -0400, Bob Vandette wrote: > Have you done a Mac and Windows build? FYI: I've had a colleague of mine build this on Windows and it builds fine there for OpenJDK jdk11u-dev. Looking at the changes below it appears we don't need them because we have JDK-8210459 backported in OpenJDK 11u. I'd expect a similar outcome for Mac. Thanks, Severin > My backport is identical to yours except I had to add these > additional changes. I?m not sure if they > are needed on your 11 update release. > > --- a/make/lib/Awt2dLibraries.gmk Thu Nov 07 17:47:22 2019 -0800 > +++ b/make/lib/Awt2dLibraries.gmk Tue Jun 02 17:58:36 2020 +0000 > @@ -743,11 +743,11 @@ > ifeq ($(ENABLE_HEADLESS_ONLY), false) > $(BUILD_LIBJAWT): $(BUILD_LIBAWT_XAWT) > else > - $(BUILD_LIBJAWT): > $(INSTALL_LIBRARIES_HERE)/$(LIBRARY_PREFIX)awt_headless$(SHARED_LIBRA > RY_SUFFIX) > + $(BUILD_LIBJAWT): $(call FindLib, $(MODULE), awt_headless) > endif > > ifeq ($(OPENJDK_TARGET_OS), macosx) > - $(BUILD_LIBJAWT): > $(INSTALL_LIBRARIES_HERE)/$(LIBRARY_PREFIX)awt_lwawt$(SHARED_LIBRARY_ > SUFFIX) > + $(BUILD_LIBJAWT): $(call FindLib, $(MODULE), awt_lwawt) > endif > > endif # OPENJDK_TARGET_OS > --- a/make/lib/Lib-jdk.accessibility.gmk Thu Nov 07 17:47:22 > 2019 -0800 > +++ b/make/lib/Lib-jdk.accessibility.gmk Tue Jun 02 17:58:36 > 2020 +0000 > @@ -55,7 +55,7 @@ > VERSIONINFO_RESOURCE := > $(ROOT_SRCDIR)/common/AccessBridgeStatusWindow.rc, \ > ) > > - $$(BUILD_JAVAACCESSBRIDGE$1): > $(SUPPORT_OUTPUTDIR)/native/java.desktop/libjawt/jawt.lib > + $$(BUILD_JAVAACCESSBRIDGE$1): $(call FindStaticLib, > java.desktop, jawt, /libjawt) > > TARGETS += $$(BUILD_JAVAACCESSBRIDGE$1) > endef > --- a/make/lib/LibCommon.gmk Thu Nov 07 17:47:22 2019 -0800 > +++ b/make/lib/LibCommon.gmk Tue Jun 02 17:58:36 2020 +0000 > @@ -83,9 +83,13 @@ > # Param 1 - module name > # Param 2 - library name > # Param 3 - optional subdir for library > -FindStaticLib = \ > - $(addprefix $(SUPPORT_OUTPUTDIR)/native/, \ > - $(strip $1)$(strip $3)/$(LIBRARY_PREFIX)$(strip > $2)$(STATIC_LIBRARY_SUFFIX)) > +ifneq ($(STATIC_LIBS), true) > + FindStaticLib = \ > + $(addprefix $(SUPPORT_OUTPUTDIR)/native/, \ > + $(strip $1)$(strip $3)/$(LIBRARY_PREFIX)$(strip > $2)$(STATIC_LIBRARY_SUFFIX)) > +else > + FindStaticLib = > +endif > > # Put the libraries here. > INSTALL_LIBRARIES_HERE := $(call FindLibDirForModule, $(MODULE)) > > > On Jun 18, 2020, at 9:16 AM, Severin Gehwolf > > wrote: > > > > On Thu, 2020-06-18 at 14:47 +0200, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I please get a review of this OpenJDK 11 backport? It's one > > > of > > > the 11.0.9-oracle parity ones. > > > > > > The patch from jdk/jdk didn't apply cleanly due to context > > > changes in > > > make/Main.gmk. Namely, USE_WRAPPER=true, removed with JDK- > > > 8245287[1] in > > > head but present in OpenJDK 11 head. Adjusted that bit manually. > > > Other > > > than that, the patch is the same. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245832 > > > > Sorry wrong webrev link previously: > > > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/webrev/ > > > > > Testing: Building static-libs-image target comparing > > > before/after[2]. > > > Testing graal build with this. Seems fine. > > > > > > Thoughts? > > > > > > Thanks, > > > Severin > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8245287 > > > [2] > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/before_after.txt > > From yan at azul.com Fri Jun 19 09:27:22 2020 From: yan at azul.com (Yuri Nesterenko) Date: Fri, 19 Jun 2020 12:27:22 +0300 Subject: [13u] 8247873: [arm32] client vm build failure In-Reply-To: <374EAD9C-8820-4E47-8020-08B69C342AA9@azul.com> References: <374EAD9C-8820-4E47-8020-08B69C342AA9@azul.com> Message-ID: Looks good to me. Thanks, --yan On 18.06.2020 22:50, Sergey Nazarkin wrote: > Hi! > > Please review build failure fix for arm32 client vm. I?ve not traced down last success build but jdk11 is not affected. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8247873 > Webrev: http://cr.openjdk.java.net/~snazarki/webrev/8247873/ > > > > > From goetz.lindenmaier at sap.com Fri Jun 19 13:12:41 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 19 Jun 2020 13:12:41 +0000 Subject: [11u] RFR: 8243029: Rewrite javax/net/ssl/compatibility/Compatibility.java with a flexible interop test framework Message-ID: I would like to downport this for parity with 11.0.9-oracle. This change caused me some headache: First, there were some files to resolve: Cert.java could not be deleted because it differs in certificate EC_RSA_PRIME256V1_SHA256 Compatibility.java could not be deleted because it differs in test compile instructions. The test in 11 forces Java 1.6 compatibility, while the test in the patch forces Java 1.7 compatibility. UseCase.java could not be deleted because it differs in one line in Object[][] PARAMS: jdk11u-dev: FULL_CASES ? CIPHER_SUITES : MANDATORY_CIPHER_SUITES, original change: FULL_CASES || FULL_CIPHER_SUITES ? CIPHER_SUITES : MANDATORY_CIPHER_SUITES, test/lib/jdk/test/lib/security/CertUtils.java patched fine after downporting "8228967: Trust/Key store and SSL context utilities for tests" as prerequisite. The test descriptions before required -source/target 1.6 and 1.7. I thought about keeping it that way, but that is not possible as the new code uses Java 8 features as Lambdas and Predicates. So the tests now require 1.8. HrrTest.java still would not work. I removed the test case for TLS_CHACHA20_POLY1305_SHA256 because it only came in 12 with "8140466: ChaCha20 and Poly1305 TLS Cipher Suites" README The readme of jdk11 mentions jdk 6 to 10. The source patched originally by the change mentioned jdk 7 to 10. Because the new test files contain Java 8 coding, I adapted the readme to mention 8 as oldest version. I ran the test as normal jtreg tests (testing with the VM built from the current repo). You need to pass -m to jtreg as the tests are marked as manual tests. This works fine. I also tried to run the test as described in the readme. This did not work. Among others, I get errors that certain enums naming Suites are not known. I tried to run the tests in jdk/jdk, there they do not compile. So I gave up on this. The readme anyways is inprecise and/or wrong, it mentions the wrong test file to call, and omits that '-m' must be set. So please review: http://cr.openjdk.java.net/~goetz/wr20/8243029-ssl_test_framework-jdk11/01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8243029 https://hg.openjdk.java.net/jdk/jdk/rev/b6b4506a7827 Best regards, Goetz. From sgehwolf at redhat.com Fri Jun 19 13:28:47 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 19 Jun 2020 15:28:47 +0200 Subject: [11u] RFR: 8245832: JDK build make-static-libs should build all JDK libraries In-Reply-To: References: <4A3566AE-79DF-4837-8DA8-6996AB9A2DE9@oracle.com> Message-ID: <49c4bf778adc50aa78b86a00c9e48f7e4ed439f0.camel@redhat.com> On Fri, 2020-06-19 at 09:14 +0200, Severin Gehwolf wrote: > Hi Bob, > > On Thu, 2020-06-18 at 10:15 -0400, Bob Vandette wrote: > > Have you done a Mac and Windows build? > > FYI: I've had a colleague of mine build this on Windows and it builds > fine there for OpenJDK jdk11u-dev. Looking at the changes below it > appears we don't need them because we have JDK-8210459 backported in > OpenJDK 11u. I'd expect a similar outcome for Mac. I have now confirmation this also builds fine on Mac (as is). To summarize: it builds fine with this on Linux, Mac, Windows. Thanks, Severin > > > On Jun 18, 2020, at 9:16 AM, Severin Gehwolf > > > wrote: > > > > > > On Thu, 2020-06-18 at 14:47 +0200, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could I please get a review of this OpenJDK 11 backport? It's one > > > > of > > > > the 11.0.9-oracle parity ones. > > > > > > > > The patch from jdk/jdk didn't apply cleanly due to context > > > > changes in > > > > make/Main.gmk. Namely, USE_WRAPPER=true, removed with JDK- > > > > 8245287[1] in > > > > head but present in OpenJDK 11 head. Adjusted that bit manually. > > > > Other > > > > than that, the patch is the same. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245832 > > > > > > Sorry wrong webrev link previously: > > > > > > webrev: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/webrev/ > > > > > > > Testing: Building static-libs-image target comparing > > > > before/after[2]. > > > > Testing graal build with this. Seems fine. > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Severin > > > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8245287 > > > > [2] > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/before_after.txt From sgehwolf at redhat.com Fri Jun 19 13:41:38 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 19 Jun 2020 15:41:38 +0200 Subject: [11u] RFR(xs): 8247874: Replacement in VersionProps.java.template not working when --with-vendor-bug-url contains '&' Message-ID: <8afd7db42265bbf1aa43a884635bd9f16147e1e0.camel@redhat.com> Hi, Could I get a review of this OpenJDK 11 specific patch? This same issue has been solved in OpenJDK 13 and better with JDK-8223319[1] which seems an unrelated issue to the fix of this bug. Also, I have tried applying the JDK 13 patch and it doesn't apply well and would mean some form of rewrite. I'm not sure this is worth it in this case. For this reason, I propose to only backport the small part of the (larger) JDK-8223319 fix which fixes the --with-*vendor-bug-url functionality when those URLs contain '&'. Since this will be pushed (if accepted) under a separate bug there shouldn't be any confusion. Bug: https://bugs.openjdk.java.net/browse/JDK-8247874 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8247874/01/webrev/ Testing: Manual inspection of generated VersionProps.java and manual testing of the crash URL. Thoughts? Thanks, Severin [1] Add copyright footer to specs and man pages https://bugs.openjdk.java.net/browse/JDK-8223319 From goetz.lindenmaier at sap.com Fri Jun 19 14:22:38 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 19 Jun 2020 14:22:38 +0000 Subject: [11u] RFR: 216974: HttpConnection not returned to the pool after 204 response Message-ID: Hi, I would like to downport this for parity with 11.0.9-oracle. I had to do some simple resolved for this change: http://cr.openjdk.java.net/~goetz/wr20/8216974-HttpConnection_1-jdk11/01/ ExchangeImpl.java: Copyright Http1Exchange.java: One import did not apply because of different context. Response204.java: Adding the bug id in the test description failed because there is already another one. The new check for error could not be applied because there is an additional test call in the context (Test 3). I resolved it similar as in jdk/jdk. The VM compiles and the test is passing. Please review. https://bugs.openjdk.java.net/browse/JDK-8216974 http://hg.openjdk.java.net/jdk/jdk/rev/54aa3ea04fe8 Best regards, Goetz. From neugens at redhat.com Fri Jun 19 14:23:27 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 19 Jun 2020 16:23:27 +0200 Subject: Result: New JDK Updates Committer: Jie Kang Message-ID: Hi all! Voting for Jie Kang (jkang) [1] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Cheers, Mario Torre [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-June/003239.html -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Fri Jun 19 14:27:00 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 19 Jun 2020 16:27:00 +0200 Subject: Result: New JDK Updates Committer: Jie Kang In-Reply-To: References: Message-ID: I apologise, This was meant to go out at 19:00 UTC, the voting is still in progress until that time. Cheers, Mario On Fri, Jun 19, 2020 at 4:23 PM Mario Torre wrote: > > Hi all! > > Voting for Jie Kang (jkang) [1] is now closed. > > Yes: 8 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus, this is > sufficient to approve the nomination. > > Cheers, > Mario Torre > > [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-June/003239.html > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Fri Jun 19 15:49:33 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 19 Jun 2020 16:49:33 +0100 Subject: CFV: New JDK Updates Committer: Jie Kang In-Reply-To: References: Message-ID: On 05/06/2020 15:02, Mario Torre wrote: > Hi all! > > I hereby nominate Jie Kang (jkang) [0] to JDK Updates Committer. > > Jie has backported a number of patches to OpenJDK 11u, in particular: > > JDK-8205516 > JDK-8214896 > JDK-8214925 > JDK-8213448 > JDK-8218935 > JDK-8225694 > JDK-8223697 > JDK-8215771 > JDK-8233075 > JDK-8232806 > JDK-8219904 > > Votes are due by 19h00 UTC on Friday, the 19th of June, 2020. > > Only current JDK Updates Committers (and above) [1] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Cheers, > Mario > > [0] https://openjdk.java.net/census#jkang > [1] https://openjdk.java.net/census#jdk-updates > [2] http://openjdk.java.net/projects/#committer-vote > Vote: Yes -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Jun 19 15:54:33 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 19 Jun 2020 16:54:33 +0100 Subject: Result: New JDK Updates Committer: Jie Kang In-Reply-To: References: Message-ID: <6b1a64f0-0ffd-68f2-e24b-6de3432b3bc7@redhat.com> On 19/06/2020 15:27, Mario Torre wrote: > I apologise, > > This was meant to go out at 19:00 UTC, the voting is still in progress > until that time. > > Cheers, > Mario > > Pre-prepared results? I hope this vote is not rigged ;-) I just saw this and voted, so that's one more yes. Cheers, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From neugens at redhat.com Fri Jun 19 16:00:26 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 19 Jun 2020 18:00:26 +0200 Subject: Result: New JDK Updates Committer: Jie Kang In-Reply-To: <6b1a64f0-0ffd-68f2-e24b-6de3432b3bc7@redhat.com> References: <6b1a64f0-0ffd-68f2-e24b-6de3432b3bc7@redhat.com> Message-ID: On Fri, Jun 19, 2020 at 5:54 PM Andrew Hughes wrote: > > > > On 19/06/2020 15:27, Mario Torre wrote: > > I apologise, > > > > This was meant to go out at 19:00 UTC, the voting is still in progress > > until that time. > > > > Cheers, > > Mario > > > > > > Pre-prepared results? I hope this vote is not rigged ;-) Haha! I'm clearly not very good at that ;) > I just saw this and voted, so that's one more yes. Thanks! I wrote the email in a moment of relative calm between meetings and stuff, but I accidentally sent it too. I'll include all the votes arriving until that moment of course! Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Fri Jun 19 19:16:22 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 19 Jun 2020 21:16:22 +0200 Subject: Result: New JDK Updates Committer: Jie Kang Message-ID: Hi all! [This time for real] Voting for Jie Kang (jkang) [1] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks to everyone who voted. Cheers, Mario Torre [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-June/003239.html -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Fri Jun 19 19:33:50 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 19 Jun 2020 20:33:50 +0100 Subject: Result: New OpenJDK Updates Reviewer: Martin Balao Message-ID: <888d9b12-1ed3-4551-89f8-a9632741b9d5@redhat.com> Voting for Martin Balao [0] is now closed. Yes: 13 Veto: 0 Abstain: 0 Turnout: 9% (13/146) According to the Bylaws definition of Three-Vote Consensus [1], this is sufficient to approve the nomination. [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-May/003124.html [1] http://openjdk.java.net/bylaws#three-vote-consensus -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From hohensee at amazon.com Fri Jun 19 20:25:38 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 19 Jun 2020 20:25:38 +0000 Subject: [11u] RFR: 216974: HttpConnection not returned to the pool after 204 response Message-ID: Lgtm. Paul ?On 6/19/20, 7:25 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" wrote: Hi, I would like to downport this for parity with 11.0.9-oracle. I had to do some simple resolved for this change: http://cr.openjdk.java.net/~goetz/wr20/8216974-HttpConnection_1-jdk11/01/ ExchangeImpl.java: Copyright Http1Exchange.java: One import did not apply because of different context. Response204.java: Adding the bug id in the test description failed because there is already another one. The new check for error could not be applied because there is an additional test call in the context (Test 3). I resolved it similar as in jdk/jdk. The VM compiles and the test is passing. Please review. https://bugs.openjdk.java.net/browse/JDK-8216974 http://hg.openjdk.java.net/jdk/jdk/rev/54aa3ea04fe8 Best regards, Goetz. From gnu.andrew at redhat.com Fri Jun 19 20:26:26 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 19 Jun 2020 21:26:26 +0100 Subject: Result: New OpenJDK Updates Committer: Alex Kashchenko Message-ID: <3c83340a-3c55-50ab-afe2-6daa666888ff@redhat.com> Voting for Alex Kashchenko [0] is now closed. Yes: 7 Veto: 0 Abstain: 0 Turnout: 2% (7/302) According to the Bylaws definition of Lazy Consensus [1], this is sufficient to approve the nomination. [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-May/003173.html [1] https://openjdk.java.net/bylaws#lazy-consensus -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From hohensee at amazon.com Fri Jun 19 20:33:37 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 19 Jun 2020 20:33:37 +0000 Subject: [11u] RFR(xs): 8247874: Replacement in VersionProps.java.template not working when --with-vendor-bug-url contains '&' Message-ID: <26913905-B977-4113-8A08-31964FD82832@amazon.com> Makes sense to me: I prefer not changing doc formats, because automated readers can be affected. Reviewed. Thanks Paul ?On 6/19/20, 6:43 AM, "jdk-updates-dev on behalf of Severin Gehwolf" wrote: Hi, Could I get a review of this OpenJDK 11 specific patch? This same issue has been solved in OpenJDK 13 and better with JDK-8223319[1] which seems an unrelated issue to the fix of this bug. Also, I have tried applying the JDK 13 patch and it doesn't apply well and would mean some form of rewrite. I'm not sure this is worth it in this case. For this reason, I propose to only backport the small part of the (larger) JDK-8223319 fix which fixes the --with-*vendor-bug-url functionality when those URLs contain '&'. Since this will be pushed (if accepted) under a separate bug there shouldn't be any confusion. Bug: https://bugs.openjdk.java.net/browse/JDK-8247874 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8247874/01/webrev/ Testing: Manual inspection of generated VersionProps.java and manual testing of the crash URL. Thoughts? Thanks, Severin [1] Add copyright footer to specs and man pages https://bugs.openjdk.java.net/browse/JDK-8223319 From gnu.andrew at redhat.com Mon Jun 22 05:22:26 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 22 Jun 2020 06:22:26 +0100 Subject: [11u] RFR(xs): 8247874: Replacement in VersionProps.java.template not working when --with-vendor-bug-url contains '&' In-Reply-To: <8afd7db42265bbf1aa43a884635bd9f16147e1e0.camel@redhat.com> References: <8afd7db42265bbf1aa43a884635bd9f16147e1e0.camel@redhat.com> Message-ID: <5f26ceb8-ed6f-2f49-a121-ad9e99c97fa3@redhat.com> On 19/06/2020 14:41, Severin Gehwolf wrote: > Hi, > > Could I get a review of this OpenJDK 11 specific patch? This same issue > has been solved in OpenJDK 13 and better with JDK-8223319[1] which > seems an unrelated issue to the fix of this bug. Also, I have tried > applying the JDK 13 patch and it doesn't apply well and would mean some > form of rewrite. I'm not sure this is worth it in this case. > > For this reason, I propose to only backport the small part of the > (larger) JDK-8223319 fix which fixes the --with-*vendor-bug-url > functionality when those URLs contain '&'. Since this will be pushed > (if accepted) under a separate bug there shouldn't be any confusion. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8247874 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8247874/01/webrev/ > > Testing: Manual inspection of generated VersionProps.java and manual > testing of the crash URL. > > Thoughts? > > Thanks, > Severin > > [1] Add copyright footer to specs and man pages > https://bugs.openjdk.java.net/browse/JDK-8223319 > Looks good to me. I picked out the same change when scanning through JDK-8247874. I agree there's no reason to backport JDK-8247874. My guess would be that the issue was discovered while fixing 8247874, so it got bundled in with it. It could just as well have had its own bug ID and separate changeset at the time; one does not depend on the other. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Jun 22 05:23:53 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 22 Jun 2020 06:23:53 +0100 Subject: Result: New JDK Updates Committer: Jie Kang In-Reply-To: References: <6b1a64f0-0ffd-68f2-e24b-6de3432b3bc7@redhat.com> Message-ID: On 19/06/2020 17:00, Mario Torre wrote: > On Fri, Jun 19, 2020 at 5:54 PM Andrew Hughes wrote: >> >> >> >> On 19/06/2020 15:27, Mario Torre wrote: >>> I apologise, >>> >>> This was meant to go out at 19:00 UTC, the voting is still in progress >>> until that time. >>> >>> Cheers, >>> Mario >>> >>> >> >> Pre-prepared results? I hope this vote is not rigged ;-) > > Haha! I'm clearly not very good at that ;) > >> I just saw this and voted, so that's one more yes. > > Thanks! > > I wrote the email in a moment of relative calm between meetings and > stuff, but I accidentally sent it too. I'll include all the votes > arriving until that moment of course! > > Cheers, > Mario > Heh, no harm done and kudos for tracking the deadline so closely. I always manage to miss the ones for mine :( Cheers, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From abrygin at azul.com Mon Jun 22 08:11:02 2020 From: abrygin at azul.com (Andrew Brygin) Date: Mon, 22 Jun 2020 11:11:02 +0300 Subject: [13u] RFR: 8242141: New System Properties to configure the TLS signature schemes Message-ID: <143202c9-d442-ea1a-a639-8f97a696ed8a@azul.com> Hello, I would like to backport the fix for JDK-8242141 to jdk13u (13.0.4): Bug: https://bugs.openjdk.java.net/browse/JDK-8242141 Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/1fbaab79e8e1 Webrev: http://cr.openjdk.java.net/~bae/13u/8242141/webrev.00/ The original change applies almost cleanly, except a context difference in src/java.base/share/classes/sun/security/ssl/SignatureScheme.java: < ss.isPermitted(constraints)) { --- > constraints.permits(SIGNATURE_PRIMITIVE_SET, > ss.algorithm, null)) { The method SignatureScheme.isPermitted() has been introduced in jdk14 as a part of the fix for JDK-8226374, which has not been backported into 13u and 11u, so this part of the change has been adjusted to the current state of 13u. Thanks, Andrew From yan at azul.com Mon Jun 22 08:24:44 2020 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 22 Jun 2020 11:24:44 +0300 Subject: [13u] RFR: 8242141: New System Properties to configure the TLS signature schemes In-Reply-To: <143202c9-d442-ea1a-a639-8f97a696ed8a@azul.com> References: <143202c9-d442-ea1a-a639-8f97a696ed8a@azul.com> Message-ID: OK, looks good to me. --yan On 22.06.2020 11:11, Andrew Brygin wrote: > Hello, > > I would like to backport the fix for JDK-8242141 to jdk13u (13.0.4): > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242141 > Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/1fbaab79e8e1 > Webrev: http://cr.openjdk.java.net/~bae/13u/8242141/webrev.00/ > > The original change applies almost cleanly, except a context difference > in src/java.base/share/classes/sun/security/ssl/SignatureScheme.java: > > < ss.isPermitted(constraints)) { > --- >> constraints.permits(SIGNATURE_PRIMITIVE_SET, >> ss.algorithm, null)) { > > The method SignatureScheme.isPermitted() has been introduced in jdk14 > as a part of the fix for JDK-8226374, which has not been backported into > 13u and 11u, so this part of the change has been adjusted to the current > state of 13u. > > Thanks, > Andrew > From abrygin at azul.com Mon Jun 22 08:51:53 2020 From: abrygin at azul.com (Andrew Brygin) Date: Mon, 22 Jun 2020 11:51:53 +0300 Subject: [13u] RFR: 8229888: (zipfs) Updating an existing zip file does not preserve original permissions Message-ID: <6353f6f8-91ac-3646-6da6-cc5c0325bd73@azul.com> Hello I would like to backport the fix for JDK-8229888 to jdk13u (13.0.4): Bug: https://bugs.openjdk.java.net/browse/JDK-8229888 Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/798c0903fcd0 Webrev: http://cr.openjdk.java.net/~bae/13u/8229888/webrev.00/ The original change does not apply cleanly due to context difference: < private IndexNode getInode(byte[] path) { < return inodes.get(IndexNode.keyOf(Objects.requireNonNull(entryLookup.apply(path), "path"))); --- > IndexNode getInode(byte[] path) { > return inodes.get(IndexNode.keyOf(Objects.requireNonNull(path, "path"))); and it also requires import adjustments in 13u: > @@ -43,6 +43,8 @@ > import java.nio.file.*; > import java.nio.file.attribute.FileAttribute; > import java.nio.file.attribute.FileTime; > +import java.nio.file.attribute.PosixFileAttributes; > +import java.nio.file.attribute.PosixFileAttributeView; > import java.nio.file.attribute.UserPrincipalLookupService; > import java.nio.file.spi.FileSystemProvider; > import java.security.AccessController; The backport has been tested with tier1, and newly introduced regression test. Thanks, Andrew From yan at azul.com Mon Jun 22 09:04:20 2020 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 22 Jun 2020 12:04:20 +0300 Subject: [13u] RFR: 8229888: (zipfs) Updating an existing zip file does not preserve original permissions In-Reply-To: <6353f6f8-91ac-3646-6da6-cc5c0325bd73@azul.com> References: <6353f6f8-91ac-3646-6da6-cc5c0325bd73@azul.com> Message-ID: <0f7d4894-fab4-2ff4-6939-96c40cf96829@azul.com> Looks good to me. --yan On 22.06.2020 11:51, Andrew Brygin wrote: > Hello > > I would like to backport the fix for JDK-8229888 to jdk13u (13.0.4): > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229888 > Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/798c0903fcd0 > Webrev: http://cr.openjdk.java.net/~bae/13u/8229888/webrev.00/ > > The original change does not apply cleanly due to context difference: > > < private IndexNode getInode(byte[] path) { > < return > inodes.get(IndexNode.keyOf(Objects.requireNonNull(entryLookup.apply(path), > "path"))); > --- >> IndexNode getInode(byte[] path) { >> return > inodes.get(IndexNode.keyOf(Objects.requireNonNull(path, "path"))); > > and it also requires import adjustments in 13u: > >> @@ -43,6 +43,8 @@ >> import java.nio.file.*; >> import java.nio.file.attribute.FileAttribute; >> import java.nio.file.attribute.FileTime; >> +import java.nio.file.attribute.PosixFileAttributes; >> +import java.nio.file.attribute.PosixFileAttributeView; >> import java.nio.file.attribute.UserPrincipalLookupService; >> import java.nio.file.spi.FileSystemProvider; >> import java.security.AccessController; > > The backport has been tested with tier1, and newly introduced > regression test. > > Thanks, > Andrew > From goetz.lindenmaier at sap.com Mon Jun 22 12:42:24 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 22 Jun 2020 12:42:24 +0000 Subject: [11u] RFR 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: Hi Jaroslav, The fix looks good to me. Reviewed. Please flag the change with jdk11u-fix-request and add corresponding comment. Best regards, Goetz -----Original Message----- From: jdk-updates-dev On Behalf Of Jaroslav Bachor?k Sent: Donnerstag, 18. Juni 2020 17:27 To: jdk-updates-dev ; hotspot-jfr-dev Subject: [11u] RFR 8244287: JFR: Methods samples have line number 0 Hi all, Could I get this simple fix reviewed? It is fixing a regression introduced while backporting JDK-823790 and adding a new test to prevent such regressions in the future. JIRA : https://bugs.openjdk.java.net/browse/JDK-8244287 Webrev : http://cr.openjdk.java.net/~jbachorik/8244287/webrev/ Thanks, -JB- From goetz.lindenmaier at sap.com Mon Jun 22 13:13:21 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 22 Jun 2020 13:13:21 +0000 Subject: [11u] RFR: JDK-8222074: Enhance auto vectorization for x86 In-Reply-To: References: Message-ID: Hi Dan, I had a look at your change. The patch in the webrev is missing the original change comments, please make sure to push it with the correct information. Besides that the downport looks good, omitting the test coding is fine. You are right, "8224234 compiler/codegen/TestCharVect2.java fails in test_mulc" needs to be pushed with this one. The other follow-up is already downported. Best regards, Goetz -----Original Message----- From: jdk-updates-dev On Behalf Of Lemmond, Dan Sent: Samstag, 6. Juni 2020 00:09 To: jdk-updates-dev at openjdk.java.net Subject: [DMARC FAILURE] [11u] RFR: JDK-8222074: Enhance auto vectorization for x86 Hi, I sent this review out previously but it was moderated. Moderators, feel free to discard the old one. This backport is a prerequisite for backporting JDK-8230591. I plan to backport JDK-8226721 and JDK-8231713 in the coming days before finally backporting JDK-8230591. This review is part of a set and will need to be pushed with the backport for JDK-8224234 which I will be sending out shortly. JBS: https://bugs.openjdk.java.net/browse/JDK-8222074 Webrev: http://cr.openjdk.java.net/~phh/8222074/webrev.11u.00/ Original review thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/033561.html Please review this backport for JDK-8222074 to 11u. The changeset applied cleanly for the most part, only requiring a manual fix for two hunks. The two hunks that needed to be fixed were hunk 3 in assembler_x86.hpp and hunk 3 in x86.ad. The backport compiled without issue and successfully passed the Tier1 Hotspot tests. Please note that the change to CheckGraalIntrinsics.java was omitted from this backport as the check was ?isJDK13OrHigher? which is not relevant for 11u. Thank you, Dan From goetz.lindenmaier at sap.com Mon Jun 22 13:16:39 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 22 Jun 2020 13:16:39 +0000 Subject: [11u] RFR: JDK-8224234: compiler/codegen/TestCharVect2.java fails in test_mulc In-Reply-To: <9EABFF76-EB99-4FE5-B80E-6DC9F2284125@amazon.com> References: <9EABFF76-EB99-4FE5-B80E-6DC9F2284125@amazon.com> Message-ID: Hi, As the change applies clean, no review is needed. I checked anyways that it actually applies clean ??, so Reviewed. But please put the required comment into this bug and 8222074, and tag them accordingly. Best regards, Goetz. -----Original Message----- From: jdk-updates-dev On Behalf Of Lemmond, Dan Sent: Samstag, 6. Juni 2020 00:09 To: jdk-updates-dev at openjdk.java.net Subject: [DMARC FAILURE] [11u] RFR: JDK-8224234: compiler/codegen/TestCharVect2.java fails in test_mulc Hi, I sent this request out previously but it was moderated. Moderators, please feel free to discard the old one. Please review this backport for 11u. This is the second review in the set for JDK-8222074 which has previously been sent out for review. Even though it applies cleanly, I am sending it out for review as it will need to be applied alongside the backport for JDK-8222074. JBS: https://bugs.openjdk.java.net/browse/JDK-8224234 Webrev: http://cr.openjdk.java.net/~phh/8224234/webrev.11u.00/ Original review thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-June/034175.html This patch compiled without issue and passed all Tier1 Hotspot tests. Thanks, Dan From goetz.lindenmaier at sap.com Mon Jun 22 14:30:34 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 22 Jun 2020 14:30:34 +0000 Subject: [11u] RFR: 8228448: Jconsole can't connect to itself Message-ID: Hi, I am downporting this little change for 11.0.9-oracle parity. Patch did not apply because of context. http://cr.openjdk.java.net/~goetz/wr20/8228448-Jconsole_selfconnect-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8228448 https://hg.openjdk.java.net/jdk/jdk/rev/d6fe7d58d994 Best regards, Goetz. From hohensee at amazon.com Mon Jun 22 17:03:51 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 22 Jun 2020 17:03:51 +0000 Subject: [11u] RFR: 8228448: Jconsole can't connect to itself Message-ID: <762A656B-4E7E-40EF-A5B2-5B19305EA642@amazon.com> Lgtm. Paul ?On 6/22/20, 7:35 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" wrote: Hi, I am downporting this little change for 11.0.9-oracle parity. Patch did not apply because of context. http://cr.openjdk.java.net/~goetz/wr20/8228448-Jconsole_selfconnect-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8228448 https://hg.openjdk.java.net/jdk/jdk/rev/d6fe7d58d994 Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Jun 22 18:41:16 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 22 Jun 2020 18:41:16 +0000 Subject: [11u] RFR: 8246153: TestEliminateArrayCopy fails with -XX:+StressReflectiveCode Message-ID: Hi, I would like to downport this for parity with 11.0.9-oracle. The change to opto does not apply at all, but I think I found the Correct code to fix: http://cr.openjdk.java.net/~goetz/wr20/8246153-TestEliminateArrayCopy-jdk11/01/ I can reproduce the error with the modified test without the fix, and adding the fix the test passes. Please review. https://bugs.openjdk.java.net/browse/JDK-8246153 https://hg.openjdk.java.net/jdk/jdk/rev/0b2fc7e19361 Best regards, Goetz. From christoph.langer at sap.com Tue Jun 23 04:20:03 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 23 Jun 2020 04:20:03 +0000 Subject: [11u] RFR: 8172404: Tools should warn if weak algorithms are used before restricting them In-Reply-To: References: Message-ID: Hi Goetz, LGTM. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 5. Juni 2020 15:33 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 8172404: Tools should warn if weak algorithms > are used before restricting them > > Hi > > I downport this for parity with 11.0.9-oracle. > > I had to resolve a row of files. > > Main.java: > This does not apply because 15 uses fullDisplayAlgName(). > I adapted the code to use this, too. It comes with downport of 8233228 which > is in work. > > Resources.java, TsacertOptionTest.java, Warning.java: Copyright only > > ConciseJarsigner.java, DefaultOptions.java, NameClash.java and EC.java are > shell tests > in 11. Moved fixes there. > > http://cr.openjdk.java.net/~goetz/wr20/8172404-warn_weak_algs- > jdk11/01/ > (Webrev somehow mentions 8233228, too, but the patch contains only the > 8172404 > Changes.) > > Please review. > https://bugs.openjdk.java.net/browse/JDK-8172404 > https://hg.openjdk.java.net/jdk/jdk/rev/6611a79f2ddf > > Best regards, > Goetz From christoph.langer at sap.com Tue Jun 23 04:38:19 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 23 Jun 2020 04:38:19 +0000 Subject: [11u] CSR JDK-8245689 Align some one-way conversion in MS950 charset with Windows In-Reply-To: References: Message-ID: Hi Ichiroh, I've just checked your request. The bug-item you created https://bugs.openjdk.java.net/browse/JDK-8245689 is of type "backport". I guess you've intuitively used "More" -> "Create Backport" of the original CSR. Unfortunately, that doesn't work correctly. So, I've made JDK-8245689 a backport of the original bug (https://bugs.openjdk.java.net/browse/JDK-8232161). It should get resolved once you actually push the backport (under its original bug id, of course). However, from that backport bug (JDK-8245689) you'll have to create (and edit) the backport CSR via "More" -> "Create CSR". Please let me know when you've done that and I can review. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ichiroh Takiguchi > Sent: Montag, 25. Mai 2020 03:55 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] CSR JDK-8245689 Align some one-way conversion in MS950 > charset with Windows > > Hello. > > Could you review JDK-8245689 [1] ? > > Parent CSR was JDK-8233385 Align some one-way conversion in MS950 > charset with Windows [2] > > Actual fix was JDK-8232161 Align some one-way conversion in MS950 > charset with Windows [3] > The fix can be applied against 11u-dev without any change. > > [1] https://bugs.openjdk.java.net/browse/JDK-8245689 > [2] https://bugs.openjdk.java.net/browse/JDK-8233385 > [3] https://bugs.openjdk.java.net/browse/JDK-8232161 > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. From sgehwolf at redhat.com Tue Jun 23 08:55:10 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 23 Jun 2020 10:55:10 +0200 Subject: [11u] RFR: 8245832: JDK build make-static-libs should build all JDK libraries In-Reply-To: <49c4bf778adc50aa78b86a00c9e48f7e4ed439f0.camel@redhat.com> References: <4A3566AE-79DF-4837-8DA8-6996AB9A2DE9@oracle.com> <49c4bf778adc50aa78b86a00c9e48f7e4ed439f0.camel@redhat.com> Message-ID: <53e36a3ab4593e629256d40c51f1f4a3c3eb7f07.camel@redhat.com> On Fri, 2020-06-19 at 15:28 +0200, Severin Gehwolf wrote: > On Fri, 2020-06-19 at 09:14 +0200, Severin Gehwolf wrote: > > Hi Bob, > > > > On Thu, 2020-06-18 at 10:15 -0400, Bob Vandette wrote: > > > Have you done a Mac and Windows build? > > > > FYI: I've had a colleague of mine build this on Windows and it builds > > fine there for OpenJDK jdk11u-dev. Looking at the changes below it > > appears we don't need them because we have JDK-8210459 backported in > > OpenJDK 11u. I'd expect a similar outcome for Mac. > > I have now confirmation this also builds fine on Mac (as is). To > summarize: it builds fine with this on Linux, Mac, Windows. Could I get a review from an jdk-updates project reviewer please? Webrev is: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/webrev/ Thanks, Severin > > > > On Jun 18, 2020, at 9:16 AM, Severin Gehwolf > > > > wrote: > > > > > > > > On Thu, 2020-06-18 at 14:47 +0200, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Could I please get a review of this OpenJDK 11 backport? It's one > > > > > of > > > > > the 11.0.9-oracle parity ones. > > > > > > > > > > The patch from jdk/jdk didn't apply cleanly due to context > > > > > changes in > > > > > make/Main.gmk. Namely, USE_WRAPPER=true, removed with JDK- > > > > > 8245287[1] in > > > > > head but present in OpenJDK 11 head. Adjusted that bit manually. > > > > > Other > > > > > than that, the patch is the same. > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245832 > > > > > > > > Sorry wrong webrev link previously: > > > > > > > > webrev: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/webrev/ > > > > > > > > > Testing: Building static-libs-image target comparing > > > > > before/after[2]. > > > > > Testing graal build with this. Seems fine. > > > > > > > > > > Thoughts? > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8245287 > > > > > [2] > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/before_after.txt From christoph.langer at sap.com Tue Jun 23 09:45:51 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 23 Jun 2020 09:45:51 +0000 Subject: RFD: What do we do about programs which set sys_paths to null? In-Reply-To: References: <34fd134b-52ad-a494-3de8-ef9dfdb53644@redhat.com> <47c40da707b7869e449460a52195ace2f95af3dd.camel@redhat.com> Message-ID: Hi, I was going through my mail backlog: Thanks for replying. I agree to keep the backport of JDK-8231584 in 11u, hoping that people transitioning to 11 can fix/update their code. Cheers Christoph > -----Original Message----- > From: Andrew Haley > Sent: Dienstag, 21. April 2020 18:05 > To: Severin Gehwolf ; Langer, Christoph > > Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Subject: Re: RFD: What do we do about programs which set sys_paths to > null? > > On 4/21/20 4:40 PM, Severin Gehwolf wrote: > > On Tue, 2020-04-21 at 16:19 +0100, Andrew Haley wrote: > >> I think that we'd better keep 11 as it is, in the hope that people > >> transitioning to 8 will also transition to fixing the code. > > > > s/8/11/ > > Ah, yes, transitioning to 11. Thx. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Jun 23 10:18:37 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 23 Jun 2020 11:18:37 +0100 Subject: [11u] RFR: 8245832: JDK build make-static-libs should build all JDK libraries In-Reply-To: <53e36a3ab4593e629256d40c51f1f4a3c3eb7f07.camel@redhat.com> References: <4A3566AE-79DF-4837-8DA8-6996AB9A2DE9@oracle.com> <49c4bf778adc50aa78b86a00c9e48f7e4ed439f0.camel@redhat.com> <53e36a3ab4593e629256d40c51f1f4a3c3eb7f07.camel@redhat.com> Message-ID: <83d33f45-1bce-7d7e-7cc5-e63dd670afa4@redhat.com> On 23/06/2020 09:55, Severin Gehwolf wrote: > Could I get a review from an jdk-updates project reviewer please? > Webrev is: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/webrev/ That's one of the most baffling webrevs I've ever seen. Why all the Hg version numbers? But if I ignore all that, the intent of the patch, modulo the MacOS changes is clear. OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Tue Jun 23 11:48:02 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 23 Jun 2020 13:48:02 +0200 Subject: [11u] RFR: 8245832: JDK build make-static-libs should build all JDK libraries In-Reply-To: <83d33f45-1bce-7d7e-7cc5-e63dd670afa4@redhat.com> References: <4A3566AE-79DF-4837-8DA8-6996AB9A2DE9@oracle.com> <49c4bf778adc50aa78b86a00c9e48f7e4ed439f0.camel@redhat.com> <53e36a3ab4593e629256d40c51f1f4a3c3eb7f07.camel@redhat.com> <83d33f45-1bce-7d7e-7cc5-e63dd670afa4@redhat.com> Message-ID: <6b5d50e656d4da3b4a515fc6c4b198dce5c3163f.camel@redhat.com> On Tue, 2020-06-23 at 11:18 +0100, Andrew Haley wrote: > On 23/06/2020 09:55, Severin Gehwolf wrote: > > Could I get a review from an jdk-updates project reviewer please? > > Webrev is: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8245832/01/webrev/ > > That's one of the most baffling webrevs I've ever seen. Why all the > Hg version numbers? I don't know, sorry. Sometimes webrev.ksh behaves that way. I use different heads for development which seems to be causing it. Fast- forward to using skara for OpenJDK 11 and this shouldn't be an issue anymore (hopefully). > But if I ignore all that, the intent of the patch, modulo the MacOS > changes is clear. OK. Thanks for the review! Cheers, Severin From rwestrel at redhat.com Tue Jun 23 15:41:36 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 23 Jun 2020 17:41:36 +0200 Subject: [11u] RFR: 8240676: Meet not symmetric failure when running lucene on jdk8 Message-ID: <87tuz1vlfz.fsf@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8240676 https://hg.openjdk.java.net/jdk/jdk/rev/6ccf082f50d4 The 11u patch is unchanged but context in compile.hpp changed so the original patch requires a small adjustment. 11u webrev: http://cr.openjdk.java.net/~roland/8240676-11u/webrev.00/ Testing: x86_64, verified new test fails with the fix commented out, works otherwise, tier1 Roland. From vladimir.kozlov at oracle.com Tue Jun 23 16:08:57 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 23 Jun 2020 09:08:57 -0700 Subject: [11u] RFR: 8240676: Meet not symmetric failure when running lucene on jdk8 In-Reply-To: <87tuz1vlfz.fsf@redhat.com> References: <87tuz1vlfz.fsf@redhat.com> Message-ID: <68dd5de1-1bc3-b04c-6101-e022c21d3581@oracle.com> Hi Roland, You miss new test you had in original changes. Otherwise it is good. Thanks, Vladimir On 6/23/20 8:41 AM, Roland Westrelin wrote: > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8240676 > https://hg.openjdk.java.net/jdk/jdk/rev/6ccf082f50d4 > > The 11u patch is unchanged but context in compile.hpp changed so the > original patch requires a small adjustment. > > 11u webrev: > http://cr.openjdk.java.net/~roland/8240676-11u/webrev.00/ > > Testing: x86_64, verified new test fails with the fix commented out, > works otherwise, tier1 > > Roland. > From goetz.lindenmaier at sap.com Tue Jun 23 16:00:50 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 23 Jun 2020 16:00:50 +0000 Subject: [11u notice]: jdk11u closed now Message-ID: Hi, Tag jdk-11.0.8+8 was pushed. jdk11u is closed now. Please don't push to jdk11u any more. The closed security changes for 11.0.8 will be prepared on top of this tag. Best regards, Goetz. See also project plan at https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u From hohensee at amazon.com Tue Jun 23 18:15:25 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 23 Jun 2020 18:15:25 +0000 Subject: 11u] RFR: 8246153: TestEliminateArrayCopy fails with -XX:+StressReflectiveCode Message-ID: <6F6856E5-5557-4037-B5F0-FF5ACEE8F46E@amazon.com> Lgtm. Paul ?On 6/22/20, 11:45 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" wrote: Hi, I would like to downport this for parity with 11.0.9-oracle. The change to opto does not apply at all, but I think I found the Correct code to fix: http://cr.openjdk.java.net/~goetz/wr20/8246153-TestEliminateArrayCopy-jdk11/01/ I can reproduce the error with the modified test without the fix, and adding the fix the test passes. Please review. https://bugs.openjdk.java.net/browse/JDK-8246153 https://hg.openjdk.java.net/jdk/jdk/rev/0b2fc7e19361 Best regards, Goetz. From rwestrel at redhat.com Wed Jun 24 07:07:07 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 24 Jun 2020 09:07:07 +0200 Subject: [11u] RFR: 8240676: Meet not symmetric failure when running lucene on jdk8 In-Reply-To: <68dd5de1-1bc3-b04c-6101-e022c21d3581@oracle.com> References: <87tuz1vlfz.fsf@redhat.com> <68dd5de1-1bc3-b04c-6101-e022c21d3581@oracle.com> Message-ID: <87r1u5uelg.fsf@redhat.com> Hi Vladimir, > You miss new test you had in original changes. Otherwise it is good. Thanks for reviewing this! Right. Good catch. Here with the test: http://cr.openjdk.java.net/~roland/8240676-11u/webrev.01/ Roland. From goetz.lindenmaier at sap.com Wed Jun 24 07:12:43 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 24 Jun 2020 07:12:43 +0000 Subject: [11u] RFR: 8228448: Jconsole can't connect to itself In-Reply-To: <762A656B-4E7E-40EF-A5B2-5B19305EA642@amazon.com> References: <762A656B-4E7E-40EF-A5B2-5B19305EA642@amazon.com> Message-ID: Hi Paul, Thanks for reviewing! It really helps that you have a look, too! Best regards, Goetz. > -----Original Message----- > From: Hohensee, Paul > Sent: Monday, June 22, 2020 7:04 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8228448: Jconsole can't connect to itself > > Lgtm. > > Paul > > ?On 6/22/20, 7:35 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" > goetz.lindenmaier at sap.com> wrote: > > Hi, > > I am downporting this little change for 11.0.9-oracle parity. > > Patch did not apply because of context. > http://cr.openjdk.java.net/~goetz/wr20/8228448-Jconsole_selfconnect- > jdk11/01/ > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8228448 > https://hg.openjdk.java.net/jdk/jdk/rev/d6fe7d58d994 > > Best regards, > Goetz. From patrick at os.amperecomputing.com Wed Jun 24 09:55:09 2020 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Wed, 24 Jun 2020 09:55:09 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Message-ID: Hi Could I ask for a review of this simple patch which takes a tiny part from the original ticket JDK-8243326 [1]. The reason that I do not want a full backport is, the majority of the patch at jdk/jdk [2] is to clean up the volatile use and may be not very meaningful to 11u, furthermore the context (dependencies on atomic.hpp refactor) is too complicated to generate a clear backport (I tried, ~81 files need to be changed). The purpose of having this one-line change to 11u is, the two volatile variables in TaskQueuSuper: _bottom, _age and corresponding atomic operations upon, may cause severe cache contention inside GC with larger number of threads, i.e., specified by -XX:ParallelGCThreads=##, adding paddings (up to DEFAULT_CACHE_LINE_SIZE) in-between can reduce the possibility of false-sharing cache contention. I do not need the paddings before _bottom and after _age from the original patch [2], because the instances of TaskQueuSuper are usually (always) allocated in a set of queues, in which they are naturally separated. Please review, thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8248214 Webrev: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.01/ Testing: tier1-2 pass with the patch, commercial benchmarks and small C++ test cases (to simulate the data struct and work-stealing algorithm atomics) validated the performance, no regression. By the way, I am going to request for 8u backport as well once 11u would have it. [1] https://bugs.openjdk.java.net/browse/JDK-8243326 Cleanup use of volatile in taskqueue code [2] https://hg.openjdk.java.net/jdk/jdk/rev/252a1602b4c6 Regards Patrick From goetz.lindenmaier at sap.com Wed Jun 24 13:21:17 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 24 Jun 2020 13:21:17 +0000 Subject: [11u] RFR: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response Message-ID: Hi, I am downporting this for parity with 11.0.9-oracle. I had to resolve the copyright in Stream.java And I had to adapt the test as testlibrary file SimpleSSLContext Is at a different location. All trivial adaptions. http://cr.openjdk.java.net/~goetz/wr20/8238270-Http2_204-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8238270 https://hg.openjdk.java.net/jdk/jdk/rev/fd72cd98180e Best regards, Goetz From vladimir.kozlov at oracle.com Wed Jun 24 15:50:13 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 24 Jun 2020 08:50:13 -0700 Subject: [11u] RFR: 8240676: Meet not symmetric failure when running lucene on jdk8 In-Reply-To: <87r1u5uelg.fsf@redhat.com> References: <87tuz1vlfz.fsf@redhat.com> <68dd5de1-1bc3-b04c-6101-e022c21d3581@oracle.com> <87r1u5uelg.fsf@redhat.com> Message-ID: Good. Thanks, Vladimir On 6/24/20 12:07 AM, Roland Westrelin wrote: > > Hi Vladimir, > >> You miss new test you had in original changes. Otherwise it is good. > > Thanks for reviewing this! Right. Good catch. Here with the test: > > http://cr.openjdk.java.net/~roland/8240676-11u/webrev.01/ > > Roland. > From goetz.lindenmaier at sap.com Wed Jun 24 16:08:15 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 24 Jun 2020 16:08:15 +0000 Subject: [11u] RFR: 8247350: [aarch64] assert(false) failed: wrong size of mach node Message-ID: Hi, I would like to downport this for parity with 11.0.9-oracle. I had to resolve the assert coding in output.cpp: http://cr.openjdk.java.net/~goetz/wr20/8247350-aarch_node_size-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8247350 https://hg.openjdk.java.net/jdk/jdk15/rev/1c81917f228b Best regards, Goetz From vladimir.kozlov at oracle.com Wed Jun 24 16:17:43 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 24 Jun 2020 09:17:43 -0700 Subject: [11u] RFR: 8247350: [aarch64] assert(false) failed: wrong size of mach node In-Reply-To: References: Message-ID: <1dbba986-f8d2-0229-d0c6-5085015de9e0@oracle.com> Hi Goetz, 11u needs additional fix in macroAssembler_aarch64.cpp: void MacroAssembler::stop(const char* msg) { address ip = pc(); pusha(); ! mov(c_rarg0, (address)msg); ! mov(c_rarg1, (address)ip); mov(c_rarg2, sp); mov(c_rarg3, CAST_FROM_FN_PTR(address, MacroAssembler::debug64)); // call(c_rarg3); blrt(c_rarg3, 3, 0, 1); hlt(0); --- 2141,2152 ---- } void MacroAssembler::stop(const char* msg) { address ip = pc(); pusha(); ! movptr(c_rarg0, (uintptr_t)(address)msg); ! movptr(c_rarg1, (uintptr_t)(address)ip); mov(c_rarg2, sp); mov(c_rarg3, CAST_FROM_FN_PTR(address, MacroAssembler::debug64)); // call(c_rarg3); blrt(c_rarg3, 3, 0, 1); hlt(0); Thanks, Vladimir On 6/24/20 9:08 AM, Lindenmaier, Goetz wrote: > Hi, > > I would like to downport this for parity with 11.0.9-oracle. > > I had to resolve the assert coding in output.cpp: > http://cr.openjdk.java.net/~goetz/wr20/8247350-aarch_node_size-jdk11/01/ > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8247350 > https://hg.openjdk.java.net/jdk/jdk15/rev/1c81917f228b > > Best regards, > Goetz > From goetz.lindenmaier at sap.com Wed Jun 24 16:23:03 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 24 Jun 2020 16:23:03 +0000 Subject: [11u] RFR: 8246203: Segmentation fault in verification due to stack overflow with -XX:+VerifyIterativeGVN Message-ID: Hi, I would downport this for parity with 11.0.9-oracle. I had to edit another verify() call to make it compile, see phaseX.cpp. http://cr.openjdk.java.net/~goetz/wr20/8246209-VerifyIterativeGVN-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8246203 https://hg.openjdk.java.net/jdk/jdk/rev/49fee4ea8073 Best regards, Goetz. From goetz.lindenmaier at sap.com Wed Jun 24 16:33:16 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 24 Jun 2020 16:33:16 +0000 Subject: [11u] RFR: 8247350: [aarch64] assert(false) failed: wrong size of mach node In-Reply-To: <1dbba986-f8d2-0229-d0c6-5085015de9e0@oracle.com> References: <1dbba986-f8d2-0229-d0c6-5085015de9e0@oracle.com> Message-ID: Hi Vladimir, Thanks for pointing me to this, I guess I would have not found that ... New webrev: http://cr.openjdk.java.net/~goetz/wr20/8247350-aarch_node_size-jdk11/02/ Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Vladimir Kozlov > Sent: Wednesday, June 24, 2020 6:18 PM > To: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8247350: [aarch64] assert(false) failed: wrong size of > mach node > > Hi Goetz, > > 11u needs additional fix in macroAssembler_aarch64.cpp: > > void MacroAssembler::stop(const char* msg) { > address ip = pc(); > pusha(); > ! mov(c_rarg0, (address)msg); > ! mov(c_rarg1, (address)ip); > mov(c_rarg2, sp); > mov(c_rarg3, CAST_FROM_FN_PTR(address, MacroAssembler::debug64)); > // call(c_rarg3); > blrt(c_rarg3, 3, 0, 1); > hlt(0); > --- 2141,2152 ---- > } > > void MacroAssembler::stop(const char* msg) { > address ip = pc(); > pusha(); > ! movptr(c_rarg0, (uintptr_t)(address)msg); > ! movptr(c_rarg1, (uintptr_t)(address)ip); > mov(c_rarg2, sp); > mov(c_rarg3, CAST_FROM_FN_PTR(address, MacroAssembler::debug64)); > // call(c_rarg3); > blrt(c_rarg3, 3, 0, 1); > hlt(0); > > Thanks, > Vladimir > > On 6/24/20 9:08 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > I would like to downport this for parity with 11.0.9-oracle. > > > > I had to resolve the assert coding in output.cpp: > > http://cr.openjdk.java.net/~goetz/wr20/8247350-aarch_node_size- > jdk11/01/ > > > > Please review. > > > > https://bugs.openjdk.java.net/browse/JDK-8247350 > > https://hg.openjdk.java.net/jdk/jdk15/rev/1c81917f228b > > > > Best regards, > > Goetz > > From vladimir.kozlov at oracle.com Wed Jun 24 16:37:39 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 24 Jun 2020 09:37:39 -0700 Subject: [11u] RFR: 8247350: [aarch64] assert(false) failed: wrong size of mach node In-Reply-To: References: <1dbba986-f8d2-0229-d0c6-5085015de9e0@oracle.com> Message-ID: You also have to adapt output changes to 11u - use _regalloc instead of C->regalloc(). Vladimir On 6/24/20 9:33 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > Thanks for pointing me to this, I guess I would have not > found that ... > New webrev: > http://cr.openjdk.java.net/~goetz/wr20/8247350-aarch_node_size-jdk11/02/ > > Best regards, > Goetz. > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Vladimir Kozlov >> Sent: Wednesday, June 24, 2020 6:18 PM >> To: jdk-updates-dev at openjdk.java.net >> Subject: Re: [11u] RFR: 8247350: [aarch64] assert(false) failed: wrong size of >> mach node >> >> Hi Goetz, >> >> 11u needs additional fix in macroAssembler_aarch64.cpp: >> >> void MacroAssembler::stop(const char* msg) { >> address ip = pc(); >> pusha(); >> ! mov(c_rarg0, (address)msg); >> ! mov(c_rarg1, (address)ip); >> mov(c_rarg2, sp); >> mov(c_rarg3, CAST_FROM_FN_PTR(address, MacroAssembler::debug64)); >> // call(c_rarg3); >> blrt(c_rarg3, 3, 0, 1); >> hlt(0); >> --- 2141,2152 ---- >> } >> >> void MacroAssembler::stop(const char* msg) { >> address ip = pc(); >> pusha(); >> ! movptr(c_rarg0, (uintptr_t)(address)msg); >> ! movptr(c_rarg1, (uintptr_t)(address)ip); >> mov(c_rarg2, sp); >> mov(c_rarg3, CAST_FROM_FN_PTR(address, MacroAssembler::debug64)); >> // call(c_rarg3); >> blrt(c_rarg3, 3, 0, 1); >> hlt(0); >> >> Thanks, >> Vladimir >> >> On 6/24/20 9:08 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I would like to downport this for parity with 11.0.9-oracle. >>> >>> I had to resolve the assert coding in output.cpp: >>> http://cr.openjdk.java.net/~goetz/wr20/8247350-aarch_node_size- >> jdk11/01/ >>> >>> Please review. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8247350 >>> https://hg.openjdk.java.net/jdk/jdk15/rev/1c81917f228b >>> >>> Best regards, >>> Goetz >>> From hohensee at amazon.com Wed Jun 24 17:16:09 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 24 Jun 2020 17:16:09 +0000 Subject: [11u] RFR: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response Message-ID: Lgtm. Paul ?On 6/24/20, 6:28 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" wrote: Hi, I am downporting this for parity with 11.0.9-oracle. I had to resolve the copyright in Stream.java And I had to adapt the test as testlibrary file SimpleSSLContext Is at a different location. All trivial adaptions. http://cr.openjdk.java.net/~goetz/wr20/8238270-Http2_204-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8238270 https://hg.openjdk.java.net/jdk/jdk/rev/fd72cd98180e Best regards, Goetz From hohensee at amazon.com Wed Jun 24 17:44:50 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 24 Jun 2020 17:44:50 +0000 Subject: [11u] RFR: JDK-8222074: Enhance auto vectorization for x86 Message-ID: The 11.0.8 backport of JDK-8230591 was reverted by JDK-8245649 because it required the backport dependencies Dan lists in his email. I'll file a redo JDK-8230591 backport request on Dan's behalf once the prerequisite backports are done. We would like to backport aarch64 performance work because ARM64-based server are being rapidly adopted for high performance floating point applications. JDK 11 will be the primary Java execution platform for them for some time to come. Thanks, Paul ?On 6/22/20, 6:15 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" wrote: Hi Dan, I had a look at your change. The patch in the webrev is missing the original change comments, please make sure to push it with the correct information. Besides that the downport looks good, omitting the test coding is fine. You are right, "8224234 compiler/codegen/TestCharVect2.java fails in test_mulc" needs to be pushed with this one. The other follow-up is already downported. Best regards, Goetz -----Original Message----- From: jdk-updates-dev On Behalf Of Lemmond, Dan Sent: Samstag, 6. Juni 2020 00:09 To: jdk-updates-dev at openjdk.java.net Subject: [DMARC FAILURE] [11u] RFR: JDK-8222074: Enhance auto vectorization for x86 Hi, I sent this review out previously but it was moderated. Moderators, feel free to discard the old one. This backport is a prerequisite for backporting JDK-8230591. I plan to backport JDK-8226721 and JDK-8231713 in the coming days before finally backporting JDK-8230591. This review is part of a set and will need to be pushed with the backport for JDK-8224234 which I will be sending out shortly. JBS: https://bugs.openjdk.java.net/browse/JDK-8222074 Webrev: http://cr.openjdk.java.net/~phh/8222074/webrev.11u.00/ Original review thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/033561.html Please review this backport for JDK-8222074 to 11u. The changeset applied cleanly for the most part, only requiring a manual fix for two hunks. The two hunks that needed to be fixed were hunk 3 in assembler_x86.hpp and hunk 3 in x86.ad. The backport compiled without issue and successfully passed the Tier1 Hotspot tests. Please note that the change to CheckGraalIntrinsics.java was omitted from this backport as the check was ?isJDK13OrHigher? which is not relevant for 11u. Thank you, Dan From goetz.lindenmaier at sap.com Thu Jun 25 07:26:53 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 25 Jun 2020 07:26:53 +0000 Subject: [11u] RFR: 8244719: CTW: C2 compilation fails with "assert(!VerifyHashTableKeys || _hash_lock == 0) failed: remove node from hash table before modifying it" Message-ID: Hi, I am downporting this for parity with 11.0.9-oracle. I had to adapt the bytecode version in the jasm file at line 26 to make it compile with 11. Test passes. http://cr.openjdk.java.net/~goetz/wr20/8244719-remove_from_hash-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8244719 https://hg.openjdk.java.net/jdk/jdk/rev/e8d34f3f6833 Best regards, Goetz From goetz.lindenmaier at sap.com Thu Jun 25 09:49:49 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 25 Jun 2020 09:49:49 +0000 Subject: [11u] RFR: 8247350: [aarch64] assert(false) failed: wrong size of mach node In-Reply-To: References: <1dbba986-f8d2-0229-d0c6-5085015de9e0@oracle.com> Message-ID: Hi Vladimir, Thanks, yes, that makes the code better! http://cr.openjdk.java.net/~goetz/wr20/8247350-aarch_node_size-jdk11/03/ Best regards, Goetz. > -----Original Message----- > From: Vladimir Kozlov > Sent: Wednesday, June 24, 2020 6:38 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8247350: [aarch64] assert(false) failed: wrong size of > mach node > > You also have to adapt output changes to 11u - use _regalloc instead of C- > >regalloc(). > > Vladimir > > On 6/24/20 9:33 AM, Lindenmaier, Goetz wrote: > > Hi Vladimir, > > > > Thanks for pointing me to this, I guess I would have not > > found that ... > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr20/8247350-aarch_node_size- > jdk11/02/ > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: jdk-updates-dev On > >> Behalf Of Vladimir Kozlov > >> Sent: Wednesday, June 24, 2020 6:18 PM > >> To: jdk-updates-dev at openjdk.java.net > >> Subject: Re: [11u] RFR: 8247350: [aarch64] assert(false) failed: wrong size > of > >> mach node > >> > >> Hi Goetz, > >> > >> 11u needs additional fix in macroAssembler_aarch64.cpp: > >> > >> void MacroAssembler::stop(const char* msg) { > >> address ip = pc(); > >> pusha(); > >> ! mov(c_rarg0, (address)msg); > >> ! mov(c_rarg1, (address)ip); > >> mov(c_rarg2, sp); > >> mov(c_rarg3, CAST_FROM_FN_PTR(address, > MacroAssembler::debug64)); > >> // call(c_rarg3); > >> blrt(c_rarg3, 3, 0, 1); > >> hlt(0); > >> --- 2141,2152 ---- > >> } > >> > >> void MacroAssembler::stop(const char* msg) { > >> address ip = pc(); > >> pusha(); > >> ! movptr(c_rarg0, (uintptr_t)(address)msg); > >> ! movptr(c_rarg1, (uintptr_t)(address)ip); > >> mov(c_rarg2, sp); > >> mov(c_rarg3, CAST_FROM_FN_PTR(address, > MacroAssembler::debug64)); > >> // call(c_rarg3); > >> blrt(c_rarg3, 3, 0, 1); > >> hlt(0); > >> > >> Thanks, > >> Vladimir > >> > >> On 6/24/20 9:08 AM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> I would like to downport this for parity with 11.0.9-oracle. > >>> > >>> I had to resolve the assert coding in output.cpp: > >>> http://cr.openjdk.java.net/~goetz/wr20/8247350-aarch_node_size- > >> jdk11/01/ > >>> > >>> Please review. > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8247350 > >>> https://hg.openjdk.java.net/jdk/jdk15/rev/1c81917f228b > >>> > >>> Best regards, > >>> Goetz > >>> From rkennke at redhat.com Thu Jun 25 11:16:27 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 25 Jun 2020 13:16:27 +0200 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> Message-ID: I would like to revive this RFR, I believe we haven't come to a conclusion yet. I still think it would be very useful to have the Shenandoah GC included in jdk11u upstream. I have heard from several vendors who would like to ship Shenandoah, but maintaining the rather huge Shenandoah backport patch is an absolute no-go. This is an updated patch that includes numerous bugfixes and improvements in Shenandoah. It is what Red Hat is going to ship in their 11.0.8 release. Full webrev: https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.04-all/ Webrev only for shared-code changes: https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.04-shared/ Please let me know what you think. Roman > On Fri, 2020-01-17 at 18:05 +0100, Roman Kennke wrote: > Hello, > > The Shenandoah GC has been integrated into jdk12 a little over a year > ago: > > http://hg.openjdk.java.net/jdk/jdk/rev/9c18c9d839d3 > > The Shenandoah team has been maintaining the Shenandoah-enabled > jdk11u > downstream repository since the inception of jdk11 under: > > http://hg.openjdk.java.net/shenandoah/jdk11 > > In order to make it more useful and accessible for users, we would > like > to make it available in upstream jdk11u. The Shenandoah team at Red > Hat > intends to maintain it the same way it had been maintained in > shenandoah/jdk11, in the course of regular jdk11u maintenance Red Hat > already does. > > Thanks to recent changes in Shenandoah over the last year, we are now > able to fit the GC interface in jdk11 almost exactly. There are a few > exceptions though. We tried to follow the following pattern for all > shared-code changes where it made sense: > > #if INCLUDE_SHENANDOAH_GC > if (UseShenandoahGC) { > ... > } > #endif > > This ensures that the Shenandoah-specific changes are cut out of the > build when building without Shenandoah, and avoid those code paths at > runtime when running without Shenandoah. > > Also, there are a few places where this was not possible or where it > didn't seem feasible, but we tried to keep them few and obvious. > Whenever this is the case, we are mirroring as close as possible what > we > have in jdk/jdk. > > Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. Other > architectures still build fine, and Shenandoah gets automatically > disabled during configure if not supported. OS-wise, Shenandoah runs > on > Linux, Windows, and is known to run on MacOS X and Solaris too. > > I wasn't sure which form this should take. I decided to start with > the > easiest possible form this could take: a simple patch/webrev and an > RFR. > Let me know if you need a JIRA issue or any other formalities to > track that. > > Full webrev: > https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.02-all/ > > Webrev only for shared-code changes: > https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.02-shared/ > > The webrevs are based on and depend on the arraycopy patch proposed > for > review here: > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002396.html > > Testing: > The code has been tested many many times, continuously while > maintaining > it. It has also served as the basis for RPMs and shipped to > customers. > We are running all sorts of tests of the hotspot/jtreg testsuite, in > particular hotspot_gc_shenandoah, CTW tests, the regular tier* tests, > several popular benchmarks (specjvm, specjbb on a regular basis), on > a > nightly basis. > > Please let me know what you think. > > Thanks, > Roman > > > > > > > From patrick at os.amperecomputing.com Thu Jun 25 14:00:48 2020 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Thu, 25 Jun 2020 14:00:48 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention Message-ID: Fixed the typo with TaskQueueSuper Regards Patrick -----Original Message----- From: hotspot-gc-dev On Behalf Of Patrick Zhang OS Sent: Wednesday, June 24, 2020 5:55 PM To: jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev Subject: [11u] RFR: 8244214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention Hi Could I ask for a review of this simple patch which takes a tiny part from the original ticket JDK-8243326 [1]. The reason that I do not want a full backport is, the majority of the patch at jdk/jdk [2] is to clean up the volatile use and may be not very meaningful to 11u, furthermore the context (dependencies on atomic.hpp refactor) is too complicated to generate a clear backport (I tried, ~81 files need to be changed). The purpose of having this one-line change to 11u is, the two volatile variables in TaskQueueSuper: _bottom, _age and corresponding atomic operations upon, may cause severe cache contention inside GC with larger number of threads, i.e., specified by -XX:ParallelGCThreads=##, adding paddings (up to DEFAULT_CACHE_LINE_SIZE) in-between can reduce the possibility of false-sharing cache contention. I do not need the paddings before _bottom and after _age from the original patch [2], because the instances of TaskQueueSuper are usually (always) allocated in a set of queues, in which they are naturally separated. Please review, thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8248214 Webrev: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.01/ Testing: tier1-2 pass with the patch, commercial benchmarks and small C++ test cases (to simulate the data struct and work-stealing algorithm atomics) validated the performance, no regression. By the way, I am going to request for 8u backport as well once 11u would have it. [1] https://bugs.openjdk.java.net/browse/JDK-8243326 Cleanup use of volatile in taskqueue code [2] https://hg.openjdk.java.net/jdk/jdk/rev/252a1602b4c6 Regards Patrick From vladimir.kozlov at oracle.com Thu Jun 25 16:22:59 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Jun 2020 09:22:59 -0700 Subject: [11u] RFR: 8247350: [aarch64] assert(false) failed: wrong size of mach node In-Reply-To: References: <1dbba986-f8d2-0229-d0c6-5085015de9e0@oracle.com> Message-ID: <247a8a0e-982e-e6cb-8a34-014a4315c817@oracle.com> Good. Thanks, Vladimir On 6/25/20 2:49 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > Thanks, yes, that makes the code better! > http://cr.openjdk.java.net/~goetz/wr20/8247350-aarch_node_size-jdk11/03/ > > Best regards, > Goetz. > >> -----Original Message----- >> From: Vladimir Kozlov >> Sent: Wednesday, June 24, 2020 6:38 PM >> To: Lindenmaier, Goetz ; jdk-updates- >> dev at openjdk.java.net >> Subject: Re: [11u] RFR: 8247350: [aarch64] assert(false) failed: wrong size of >> mach node >> >> You also have to adapt output changes to 11u - use _regalloc instead of C- >>> regalloc(). >> >> Vladimir >> >> On 6/24/20 9:33 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> Thanks for pointing me to this, I guess I would have not >>> found that ... >>> New webrev: >>> http://cr.openjdk.java.net/~goetz/wr20/8247350-aarch_node_size- >> jdk11/02/ >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: jdk-updates-dev On >>>> Behalf Of Vladimir Kozlov >>>> Sent: Wednesday, June 24, 2020 6:18 PM >>>> To: jdk-updates-dev at openjdk.java.net >>>> Subject: Re: [11u] RFR: 8247350: [aarch64] assert(false) failed: wrong size >> of >>>> mach node >>>> >>>> Hi Goetz, >>>> >>>> 11u needs additional fix in macroAssembler_aarch64.cpp: >>>> >>>> void MacroAssembler::stop(const char* msg) { >>>> address ip = pc(); >>>> pusha(); >>>> ! mov(c_rarg0, (address)msg); >>>> ! mov(c_rarg1, (address)ip); >>>> mov(c_rarg2, sp); >>>> mov(c_rarg3, CAST_FROM_FN_PTR(address, >> MacroAssembler::debug64)); >>>> // call(c_rarg3); >>>> blrt(c_rarg3, 3, 0, 1); >>>> hlt(0); >>>> --- 2141,2152 ---- >>>> } >>>> >>>> void MacroAssembler::stop(const char* msg) { >>>> address ip = pc(); >>>> pusha(); >>>> ! movptr(c_rarg0, (uintptr_t)(address)msg); >>>> ! movptr(c_rarg1, (uintptr_t)(address)ip); >>>> mov(c_rarg2, sp); >>>> mov(c_rarg3, CAST_FROM_FN_PTR(address, >> MacroAssembler::debug64)); >>>> // call(c_rarg3); >>>> blrt(c_rarg3, 3, 0, 1); >>>> hlt(0); >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/24/20 9:08 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I would like to downport this for parity with 11.0.9-oracle. >>>>> >>>>> I had to resolve the assert coding in output.cpp: >>>>> http://cr.openjdk.java.net/~goetz/wr20/8247350-aarch_node_size- >>>> jdk11/01/ >>>>> >>>>> Please review. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8247350 >>>>> https://hg.openjdk.java.net/jdk/jdk15/rev/1c81917f228b >>>>> >>>>> Best regards, >>>>> Goetz >>>>> From goetz.lindenmaier at sap.com Fri Jun 26 06:14:46 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 26 Jun 2020 06:14:46 +0000 Subject: [11u] RFR: 248385: [testbug][11u] Adapt TestInitiExceptions to jtreg 5.1 Message-ID: Hi, we changed our CI to use jtreg 5.1. Now we see TestInitExceptions failing on windows because the path is reported differently. A fix exists in head https://bugs.openjdk.java.net/browse/JDK-8246387 but it contains much more changes than are not needed for 11. So I just want to downport this fix in a change of its own: http://cr.openjdk.java.net/~goetz/wr20/8248385-fix_TestInitException-jdk11/01/ https://bugs.openjdk.java.net/browse/JDK-8248385 Please review. Best regards, Goetz. From goetz.lindenmaier at sap.com Fri Jun 26 07:17:24 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 26 Jun 2020 07:17:24 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention In-Reply-To: References: Message-ID: Hi Patrick, I had a look at your change. I think it makes sense to bring this to 11, if there actually is the performance gain you mention. Reviewed. Please add in the "Fix request" comment in the JBS the risk of downporting this. And I think is should be "Fix request (11u)" because different people will review your fix request for 11 and 8. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Patrick Zhang OS > Sent: Wednesday, June 24, 2020 11:55 AM > To: jdk-updates-dev at openjdk.java.net > Cc: hotspot-gc-dev > Subject: [DMARC FAILURE] [11u] RFR: 8244214: Add paddings for > TaskQueuSuper to reduce false-sharing cache contention > > Hi > > Could I ask for a review of this simple patch which takes a tiny part from the > original ticket JDK-8243326 [1]. The reason that I do not want a full backport > is, the majority of the patch at jdk/jdk [2] is to clean up the volatile use and > may be not very meaningful to 11u, furthermore the context (dependencies > on atomic.hpp refactor) is too complicated to generate a clear backport (I > tried, ~81 files need to be changed). > > The purpose of having this one-line change to 11u is, the two volatile > variables in TaskQueuSuper: _bottom, _age and corresponding atomic > operations upon, may cause severe cache contention inside GC with larger > number of threads, i.e., specified by -XX:ParallelGCThreads=##, adding > paddings (up to DEFAULT_CACHE_LINE_SIZE) in-between can reduce the > possibility of false-sharing cache contention. I do not need the paddings > before _bottom and after _age from the original patch [2], because the > instances of TaskQueuSuper are usually (always) allocated in a set of queues, > in which they are naturally separated. Please review, thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248214 > Webrev: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.01/ > Testing: tier1-2 pass with the patch, commercial benchmarks and small C++ > test cases (to simulate the data struct and work-stealing algorithm atomics) > validated the performance, no regression. > > By the way, I am going to request for 8u backport as well once 11u would > have it. > > [1] https://bugs.openjdk.java.net/browse/JDK-8243326 Cleanup use of > volatile in taskqueue code > [2] https://hg.openjdk.java.net/jdk/jdk/rev/252a1602b4c6 > > Regards > Patrick > From christoph.langer at sap.com Fri Jun 26 10:16:44 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Jun 2020 10:16:44 +0000 Subject: [11u] RFR: 248385: [testbug][11u] Adapt TestInitiExceptions to jtreg 5.1 In-Reply-To: References: Message-ID: Hi Goetz, looks good, thanks for bringing this fix to JDK11. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 26. Juni 2020 08:15 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 248385: [testbug][11u] Adapt > TestInitiExceptions to jtreg 5.1 > > Hi, > > we changed our CI to use jtreg 5.1. Now we see TestInitExceptions > failing on windows because the path is reported differently. > > A fix exists in head > https://bugs.openjdk.java.net/browse/JDK-8246387 > but it contains much more changes than are > not needed for 11. > > So I just want to downport this fix in a change of its own: > http://cr.openjdk.java.net/~goetz/wr20/8248385-fix_TestInitException- > jdk11/01/ > https://bugs.openjdk.java.net/browse/JDK-8248385 > > Please review. > > Best regards, > Goetz. From goetz.lindenmaier at sap.com Fri Jun 26 10:26:14 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 26 Jun 2020 10:26:14 +0000 Subject: [11u] RFR: 248385: [testbug][11u] Adapt TestInitiExceptions to jtreg 5.1 In-Reply-To: References: Message-ID: Hi Christoph, Thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Friday, June 26, 2020 12:17 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 248385: [testbug][11u] Adapt TestInitiExceptions to > jtreg 5.1 > > Hi Goetz, > > looks good, thanks for bringing this fix to JDK11. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Freitag, 26. Juni 2020 08:15 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR: 248385: [testbug][11u] Adapt > > TestInitiExceptions to jtreg 5.1 > > > > Hi, > > > > we changed our CI to use jtreg 5.1. Now we see TestInitExceptions > > failing on windows because the path is reported differently. > > > > A fix exists in head > > https://bugs.openjdk.java.net/browse/JDK-8246387 > > but it contains much more changes than are > > not needed for 11. > > > > So I just want to downport this fix in a change of its own: > > http://cr.openjdk.java.net/~goetz/wr20/8248385-fix_TestInitException- > > jdk11/01/ > > https://bugs.openjdk.java.net/browse/JDK-8248385 > > > > Please review. > > > > Best regards, > > Goetz. From abrygin at azul.com Fri Jun 26 13:44:41 2020 From: abrygin at azul.com (Andrew Brygin) Date: Fri, 26 Jun 2020 16:44:41 +0300 Subject: [13u] RFR: 8248406: Some zipfs tests fail with AccessControlException Message-ID: <7fd33ed5-84d1-ac47-d7cb-7888a6a3b0d5@azul.com> Hello, could you please review a fix for JDK-8248406? Webrev: http://cr.openjdk.java.net/~bae/13u/8248406/webrev.00/ This is a regression in 13.0.4 caused by an incomplete backport of JDK-8229888: https://hg.openjdk.java.net/jdk-updates/jdk13u/rev/cabda0c85f17 Following tests fail in 13.0.4 with AccessControlException: jdk/nio/zipfs/DirectoryStreamTests.java jdk/nio/zipfs/ZFSTests.java jdk/nio/zipfs/ZipFSTester.java The root cause of the failure is that default.policy has not been updated with RuntimePermission "accessUserInformation". In jdk14 this update was a part of the fix for JDK-8213031. This fix has not been backported to 13u, so this permission update shall be done as a part of backport for JDK-8229888, but it has been missed. Suggested solution is to add RuntimePermission "accessUserInformation", as it was done in 11u as a part of the backport of JDK-8229888: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/57fd597352b8#l1.7 Thanks, Andrew From yan at azul.com Fri Jun 26 13:53:57 2020 From: yan at azul.com (Yuri Nesterenko) Date: Fri, 26 Jun 2020 16:53:57 +0300 Subject: [13u] RFR: 8248406: Some zipfs tests fail with AccessControlException In-Reply-To: <7fd33ed5-84d1-ac47-d7cb-7888a6a3b0d5@azul.com> References: <7fd33ed5-84d1-ac47-d7cb-7888a6a3b0d5@azul.com> Message-ID: <3b121f95-db03-4c7a-b38b-2397e6ac520a@azul.com> Looks good to me --yan On 26.06.2020 16:44, Andrew Brygin wrote: > Hello, > > could you please review a fix for JDK-8248406? > > Webrev: http://cr.openjdk.java.net/~bae/13u/8248406/webrev.00/ > > This is a regression in 13.0.4 caused by an incomplete backport of > JDK-8229888: > https://hg.openjdk.java.net/jdk-updates/jdk13u/rev/cabda0c85f17 > > Following tests fail in 13.0.4 with AccessControlException: > > jdk/nio/zipfs/DirectoryStreamTests.java > jdk/nio/zipfs/ZFSTests.java > jdk/nio/zipfs/ZipFSTester.java > > The root cause of the failure is that default.policy has not been > updated with RuntimePermission "accessUserInformation". In jdk14 this > update was a part of the fix for JDK-8213031. This fix has not been > backported to 13u, so this permission update shall be done as a part of > backport for JDK-8229888, but it has been missed. > > Suggested solution is to add RuntimePermission "accessUserInformation", > as it was done in 11u as a part of the backport of JDK-8229888: > > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/57fd597352b8#l1.7 > > Thanks, > Andrew > From vicente.romero at oracle.com Fri Jun 26 16:27:14 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 26 Jun 2020 12:27:14 -0400 Subject: RFR: [Backport] JDK11-8193367 annotated type variables bounds crash javac In-Reply-To: <7BB770AF-AB6A-447F-A8F2-E850851F365D@oracle.com> References: <7BB770AF-AB6A-447F-A8F2-E850851F365D@oracle.com> Message-ID: but isn't the case the the original patch is returning true if the upper bound of the type variable is a union or an intersection while the patch adapted to 11 is only returning true if that upper bound is an intersection? what would happen if is is an union? Vicente On 6/26/20 2:39 AM, Adam Sotona wrote: > Hi Vicente, > I found the code isIntersectionOrUnionType(Type t) is already there - > that is why the patch conflict appears. > > Thanks, > Adam > >> On 25 Jun 2020, at 21:57, Vicente Romero > > wrote: >> >> Hi Adam, >> >> On 6/23/20 6:55 AM, Adam Sotona wrote: >>> Hi, >>> Please review backport of?8193367 into JDK 11. >>> >>> Original patch at >>> http://hg.openjdk.java.net/jdk/jdk/rev/a772e65727c5?has just minor >>> conflicts in copyright headers and in one code fragment with JDK 11 >>> repository. >>> >>> New patch differs in functionality with the original just in one >>> block in >>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java: >>> < -? ? ? ? ? ? ? ? ? ? ? ? ? ??if (tv.bound.getKind() == >>> TypeKind.INTERSECTION) { >>> < +? ? ? ? ? ? ? ? ? ? ? ? ? ??if (tv.getUpperBound().getKind() == >>> TypeKind.INTERSECTION) { >> >> this difference seems like an important semantic change compared to >> what the original patch is doing. I guess you will need to port >> method: `boolean isIntersectionOrUnionType(Type t)` too >>> versus: >>> > -? ? ? ? ? ? ? ? ? ? ? ??return isIntersectionOrUnionType(tv.bound); >>> > +? ? ? ? ? ? ? ? ? ? ? ??return >>> isIntersectionOrUnionType(tv.getUpperBound()); >>> >>> Patched JDK 11 passed all Tier 1, 2 and 3 tests. >>> >>> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8193367 >>> Webrev: http://cr.openjdk.java.net/~asotona/8193367/webrev.00/ >>> Backport JBS: https://bugs.openjdk.java.net/browse/JDK-8248014 >>> >>> Thanks, >>> Adam >> >> Thanks, >> Vicente > From adityam at microsoft.com Fri Jun 26 17:28:51 2020 From: adityam at microsoft.com (Aditya Mandaleeka) Date: Fri, 26 Jun 2020 17:28:51 +0000 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> Message-ID: Hi Roman, I am in favor of this proposed upstreaming of Shenandoah into jdk11u. Microsoft has some long-term commitments to Java 11 customers and having Shenandoah included in jdk11u upstream would definitely be well-received by my team and by our customers. There is demand for this kind of GC option on OpenJDK 11, and it would be beneficial to the community for it to be available on the upstream OpenJDK rather than only in specific downstream releases. Coupled with the fact that Shenandoah has been tested on JDK 11 for quite a while now, I think this upstreaming makes sense. You mentioned in your original mail that your team at RedHat intends to maintain this proposed jdk11u version the same way it has been maintained in shenandoah/jdk11. That is great--from what I?ve seen in these past few months that I?ve been involved, I?ve been impressed by the way backports to shenandoah/jdk11 are being handled, the effort that is made to keep the Shenandoah code closely aligned between sh/11 and jdk/jdk, and the care taken to ensure that the impact on shared code is kept to a minimum. At Microsoft, we?ve already been contributing patches and investigating and reporting issues based on our testing of Shenandoah, both on jdk/jdk and shenandoah/jdk11. We intend to continue this kind of involvement, so if this upstreaming to jdk11u goes through, your team will also have our support in maintaining Shenandoah there. Thanks, Aditya -----Original Message----- From: jdk-updates-dev On Behalf Of Roman Kennke Sent: Thursday, June 25, 2020 4:16 AM To: jdk-updates-dev at openjdk.java.net Subject: Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u I would like to revive this RFR, I believe we haven't come to a conclusion yet. I still think it would be very useful to have the Shenandoah GC included in jdk11u upstream. I have heard from several vendors who would like to ship Shenandoah, but maintaining the rather huge Shenandoah backport patch is an absolute no-go. This is an updated patch that includes numerous bugfixes and improvements in Shenandoah. It is what Red Hat is going to ship in their 11.0.8 release. Full webrev: https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.04-all%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967016879&sdata=G1HjEJ68qFJ2uwRyxfFKNE8gcbsFXEdYi%2B9RyrUeG60%3D&reserved=0 Webrev only for shared-code changes: https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.04-shared%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=RrKNOvxc3%2FheThyi2cMiazE%2BxC9UfARxfTbmuoc640Y%3D&reserved=0 Please let me know what you think. Roman > On Fri, 2020-01-17 at 18:05 +0100, Roman Kennke wrote: > Hello, > > The Shenandoah GC has been integrated into jdk12 a little over a year > ago: > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Frev%2F9c18c9d839d3&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=QJo2xwdHiEuaqsz26P2j%2BZdE6j3AxUvpnHVTjD9XGXI%3D&reserved=0 > > The Shenandoah team has been maintaining the Shenandoah-enabled > jdk11u > downstream repository since the inception of jdk11 under: > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fshenandoah%2Fjdk11&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=P%2FLkJ5VCrq4oWzik3WZ3GTy1a3mA52mxkITasawIMk0%3D&reserved=0 > > In order to make it more useful and accessible for users, we would > like > to make it available in upstream jdk11u. The Shenandoah team at Red > Hat > intends to maintain it the same way it had been maintained in > shenandoah/jdk11, in the course of regular jdk11u maintenance Red Hat > already does. > > Thanks to recent changes in Shenandoah over the last year, we are now > able to fit the GC interface in jdk11 almost exactly. There are a few > exceptions though. We tried to follow the following pattern for all > shared-code changes where it made sense: > > #if INCLUDE_SHENANDOAH_GC > if (UseShenandoahGC) { > ... > } > #endif > > This ensures that the Shenandoah-specific changes are cut out of the > build when building without Shenandoah, and avoid those code paths at > runtime when running without Shenandoah. > > Also, there are a few places where this was not possible or where it > didn't seem feasible, but we tried to keep them few and obvious. > Whenever this is the case, we are mirroring as close as possible what > we > have in jdk/jdk. > > Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. Other > architectures still build fine, and Shenandoah gets automatically > disabled during configure if not supported. OS-wise, Shenandoah runs > on > Linux, Windows, and is known to run on MacOS X and Solaris too. > > I wasn't sure which form this should take. I decided to start with > the > easiest possible form this could take: a simple patch/webrev and an > RFR. > Let me know if you need a JIRA issue or any other formalities to > track that. > > Full webrev: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.02-all%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=eHspbGt5Eox4EMv8hstTBwsqFYefGNO2acGymP7ZfN0%3D&reserved=0 > > Webrev only for shared-code changes: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.02-shared%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=LGghbNRyHPSJLK8l2Oyhxh1lhD46LmvZtN1G5htYBpk%3D&reserved=0 > > The webrevs are based on and depend on the arraycopy patch proposed > for > review here: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk-updates-dev%2F2020-January%2F002396.html&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=Kw0qkfvtVNVrCiMeypwr4BHX9e3bZafJnVCMVY%2BvOOw%3D&reserved=0 > > Testing: > The code has been tested many many times, continuously while > maintaining > it. It has also served as the basis for RPMs and shipped to > customers. > We are running all sorts of tests of the hotspot/jtreg testsuite, in > particular hotspot_gc_shenandoah, CTW tests, the regular tier* tests, > several popular benchmarks (specjvm, specjbb on a regular basis), on > a > nightly basis. > > Please let me know what you think. > > Thanks, > Roman > > > > > > > From mathiske at amazon.com Fri Jun 26 20:51:14 2020 From: mathiske at amazon.com (Mathiske, Bernd) Date: Fri, 26 Jun 2020 20:51:14 +0000 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> Message-ID: <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> Hi Roman, We are also in favor of upstreaming Shenandoah to jdk11u, for the same reasons Aditya listed, and we agree with everything else he has written. Similar to Aditya?s message below, we believe that Shenandoah has strong demand and potential for those running jdk11u. Targeting jdk11u is the most efficient way to reach a large user base and to enable production use of Shenandoah. At Amazon, we plan to continue to contribute to Shenandoah, and we fully intend to help maintain Shenandoah in jdk11u. Best, Bernd, Kelvin, Azeem ?On 6/26/20, 10:36 AM, "jdk-updates-dev on behalf of Aditya Mandaleeka" wrote: Hi Roman, I am in favor of this proposed upstreaming of Shenandoah into jdk11u. Microsoft has some long-term commitments to Java 11 customers and having Shenandoah included in jdk11u upstream would definitely be well-received by my team and by our customers. There is demand for this kind of GC option on OpenJDK 11, and it would be beneficial to the community for it to be available on the upstream OpenJDK rather than only in specific downstream releases. Coupled with the fact that Shenandoah has been tested on JDK 11 for quite a while now, I think this upstreaming makes sense. You mentioned in your original mail that your team at RedHat intends to maintain this proposed jdk11u version the same way it has been maintained in shenandoah/jdk11. That is great--from what I?ve seen in these past few months that I?ve been involved, I?ve been impressed by the way backports to shenandoah/jdk11 are being handled, the effort that is made to keep the Shenandoah code closely aligned between sh/11 and jdk/jdk, and the care taken to ensure that the impact on shared code is kept to a minimum. At Microsoft, we?ve already been contributing patches and investigating and reporting issues based on our testing of Shenandoah, both on jdk/jdk and shenandoah/jdk11. We intend to continue this kind of involvement, so if this upstreaming to jdk11u goes through, your team will also have our support in maintaining Shenandoah there. Thanks, Aditya -----Original Message----- From: jdk-updates-dev On Behalf Of Roman Kennke Sent: Thursday, June 25, 2020 4:16 AM To: jdk-updates-dev at openjdk.java.net Subject: Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u I would like to revive this RFR, I believe we haven't come to a conclusion yet. I still think it would be very useful to have the Shenandoah GC included in jdk11u upstream. I have heard from several vendors who would like to ship Shenandoah, but maintaining the rather huge Shenandoah backport patch is an absolute no-go. This is an updated patch that includes numerous bugfixes and improvements in Shenandoah. It is what Red Hat is going to ship in their 11.0.8 release. Full webrev: https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.04-all%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967016879&sdata=G1HjEJ68qFJ2uwRyxfFKNE8gcbsFXEdYi%2B9RyrUeG60%3D&reserved=0 Webrev only for shared-code changes: https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.04-shared%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=RrKNOvxc3%2FheThyi2cMiazE%2BxC9UfARxfTbmuoc640Y%3D&reserved=0 Please let me know what you think. Roman > On Fri, 2020-01-17 at 18:05 +0100, Roman Kennke wrote: > Hello, > > The Shenandoah GC has been integrated into jdk12 a little over a year > ago: > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Frev%2F9c18c9d839d3&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=QJo2xwdHiEuaqsz26P2j%2BZdE6j3AxUvpnHVTjD9XGXI%3D&reserved=0 > > The Shenandoah team has been maintaining the Shenandoah-enabled > jdk11u > downstream repository since the inception of jdk11 under: > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fshenandoah%2Fjdk11&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=P%2FLkJ5VCrq4oWzik3WZ3GTy1a3mA52mxkITasawIMk0%3D&reserved=0 > > In order to make it more useful and accessible for users, we would > like > to make it available in upstream jdk11u. The Shenandoah team at Red > Hat > intends to maintain it the same way it had been maintained in > shenandoah/jdk11, in the course of regular jdk11u maintenance Red Hat > already does. > > Thanks to recent changes in Shenandoah over the last year, we are now > able to fit the GC interface in jdk11 almost exactly. There are a few > exceptions though. We tried to follow the following pattern for all > shared-code changes where it made sense: > > #if INCLUDE_SHENANDOAH_GC > if (UseShenandoahGC) { > ... > } > #endif > > This ensures that the Shenandoah-specific changes are cut out of the > build when building without Shenandoah, and avoid those code paths at > runtime when running without Shenandoah. > > Also, there are a few places where this was not possible or where it > didn't seem feasible, but we tried to keep them few and obvious. > Whenever this is the case, we are mirroring as close as possible what > we > have in jdk/jdk. > > Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. Other > architectures still build fine, and Shenandoah gets automatically > disabled during configure if not supported. OS-wise, Shenandoah runs > on > Linux, Windows, and is known to run on MacOS X and Solaris too. > > I wasn't sure which form this should take. I decided to start with > the > easiest possible form this could take: a simple patch/webrev and an > RFR. > Let me know if you need a JIRA issue or any other formalities to > track that. > > Full webrev: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.02-all%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=eHspbGt5Eox4EMv8hstTBwsqFYefGNO2acGymP7ZfN0%3D&reserved=0 > > Webrev only for shared-code changes: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.02-shared%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=LGghbNRyHPSJLK8l2Oyhxh1lhD46LmvZtN1G5htYBpk%3D&reserved=0 > > The webrevs are based on and depend on the arraycopy patch proposed > for > review here: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk-updates-dev%2F2020-January%2F002396.html&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=Kw0qkfvtVNVrCiMeypwr4BHX9e3bZafJnVCMVY%2BvOOw%3D&reserved=0 > > Testing: > The code has been tested many many times, continuously while > maintaining > it. It has also served as the basis for RPMs and shipped to > customers. > We are running all sorts of tests of the hotspot/jtreg testsuite, in > particular hotspot_gc_shenandoah, CTW tests, the regular tier* tests, > several popular benchmarks (specjvm, specjbb on a regular basis), on > a > nightly basis. > > Please let me know what you think. > > Thanks, > Roman > > > > > > > From gil at azul.com Fri Jun 26 23:39:03 2020 From: gil at azul.com (Gil Tene) Date: Fri, 26 Jun 2020 23:39:03 +0000 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> Message-ID: As I noted before, we have serious reservations about adding major new features to a stable LTS that is upstream of all of 11u. Based on daily interactions with tons of OpenJDK end users, I can say that the vast majority of end users that are ramping up on 11u are demanding stability and maturity above all else. The addition of such major changes in an 11u update will cause many of them to stall updates, and potentially stall the uptake of 11u altogether, waiting for 11u to actually stabilize first (evidenced by no longer doing such things), so they can keep up with fixes and security issues without having to take on potential regressions driven by late added or experimental features. If you want a modern GA'ed OpenJDK with all the latest features in it, use one. Please please please don't force people who choose to stick with a given OpenJDK version for stability, and knowingly did not move to a later OpenJDK version, to deploy the newly implemented features that you like by pushing for back-porting them to the upstream project that they get their security updates from... I can see a potentially good case for a downstream-from-11u project that incorporates ongoing development (as opposed to bug fixes) from later upstream versions, and would be happy to collaborate on one. But the 11u that is upstream of all other 11u's should not be seen as a developer's playground, or a place to add cool new features to a stable release. The upstream versions are there for that purpose. The valid interests of deep-bench, self-supporting groups making use of OpenJDK, who can take on the stability risks involved due to the depth of their technical bench, should not overcome the interests of the millions of consumers of the 11u builds that do not have that luxury, and who need and expect stable (in the changing only where necessary sense) 11u releases. I'd like to point out that 13u already includes Shenandoah. 15u (expected in 3 months) already includes Shenandoah as a non-experimental feature. And we can all collaborate on back-porting bug-fixes to those to updates to keep a lively version of OpenJDK that includes Shenandoah up to date from a bug fix and security update point of view. For those insisting on waiting for an LTS (on the assumption that LTSs are long term stable and don't get those sort of messing-with-after-the-fact done to them, mind you), 17u will be out in 15 months. So we are not talking about some far-away future for end users that want Shenandoah. It is here, now, in multiple consumable forms, and available for people not looking for the stability of an LTS, and even for people who do (as they can use the Red Hat 11u builds). It it will be available in more forms very soon with no effort, and we don't have to destabilize 11u for others to make that happen. ? Gil. > On Jun 26, 2020, at 1:51 PM, Mathiske, Bernd wrote: > > Hi Roman, > > We are also in favor of upstreaming Shenandoah to jdk11u, for the same reasons Aditya listed, and we agree with everything else he has written. Similar to Aditya?s message below, we believe that Shenandoah has strong demand and potential for those running jdk11u. Targeting jdk11u is the most efficient way to reach a large user base and to enable production use of Shenandoah. > > At Amazon, we plan to continue to contribute to Shenandoah, and we fully intend to help maintain Shenandoah in jdk11u. > > Best, > > Bernd, Kelvin, Azeem > > ?On 6/26/20, 10:36 AM, "jdk-updates-dev on behalf of Aditya Mandaleeka" wrote: > > Hi Roman, > > I am in favor of this proposed upstreaming of Shenandoah into jdk11u. Microsoft > has some long-term commitments to Java 11 customers and having Shenandoah > included in jdk11u upstream would definitely be well-received by my team and by > our customers. There is demand for this kind of GC option on OpenJDK 11, and it > would be beneficial to the community for it to be available on the upstream > OpenJDK rather than only in specific downstream releases. Coupled with the fact > that Shenandoah has been tested on JDK 11 for quite a while now, I think this > upstreaming makes sense. > > You mentioned in your original mail that your team at RedHat intends to maintain > this proposed jdk11u version the same way it has been maintained in > shenandoah/jdk11. That is great--from what I?ve seen in these past few months > that I?ve been involved, I?ve been impressed by the way backports to > shenandoah/jdk11 are being handled, the effort that is made to keep the > Shenandoah code closely aligned between sh/11 and jdk/jdk, and the care taken to > ensure that the impact on shared code is kept to a minimum. > > At Microsoft, we?ve already been contributing patches and investigating and > reporting issues based on our testing of Shenandoah, both on jdk/jdk and > shenandoah/jdk11. We intend to continue this kind of involvement, so if this > upstreaming to jdk11u goes through, your team will also have our support in > maintaining Shenandoah there. > > Thanks, > Aditya > > -----Original Message----- > From: jdk-updates-dev On Behalf Of Roman Kennke > Sent: Thursday, June 25, 2020 4:16 AM > To: jdk-updates-dev at openjdk.java.net > Subject: Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u > > I would like to revive this RFR, I believe we haven't come to a > conclusion yet. I still think it would be very useful to have the > Shenandoah GC included in jdk11u upstream. I have heard from several > vendors who would like to ship Shenandoah, but maintaining the rather > huge Shenandoah backport patch is an absolute no-go. > > This is an updated patch that includes numerous bugfixes and > improvements in Shenandoah. It is what Red Hat is going to ship in > their 11.0.8 release. > > Full webrev: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.04-all%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967016879&sdata=G1HjEJ68qFJ2uwRyxfFKNE8gcbsFXEdYi%2B9RyrUeG60%3D&reserved=0 > > Webrev only for shared-code changes: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.04-shared%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=RrKNOvxc3%2FheThyi2cMiazE%2BxC9UfARxfTbmuoc640Y%3D&reserved=0 > > Please let me know what you think. > > Roman > >> On Fri, 2020-01-17 at 18:05 +0100, Roman Kennke wrote: >> Hello, >> >> The Shenandoah GC has been integrated into jdk12 a little over a year >> ago: >> >> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Frev%2F9c18c9d839d3&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=QJo2xwdHiEuaqsz26P2j%2BZdE6j3AxUvpnHVTjD9XGXI%3D&reserved=0 >> >> The Shenandoah team has been maintaining the Shenandoah-enabled >> jdk11u >> downstream repository since the inception of jdk11 under: >> >> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fshenandoah%2Fjdk11&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=P%2FLkJ5VCrq4oWzik3WZ3GTy1a3mA52mxkITasawIMk0%3D&reserved=0 >> >> In order to make it more useful and accessible for users, we would >> like >> to make it available in upstream jdk11u. The Shenandoah team at Red >> Hat >> intends to maintain it the same way it had been maintained in >> shenandoah/jdk11, in the course of regular jdk11u maintenance Red Hat >> already does. >> >> Thanks to recent changes in Shenandoah over the last year, we are now >> able to fit the GC interface in jdk11 almost exactly. There are a few >> exceptions though. We tried to follow the following pattern for all >> shared-code changes where it made sense: >> >> #if INCLUDE_SHENANDOAH_GC >> if (UseShenandoahGC) { >> ... >> } >> #endif >> >> This ensures that the Shenandoah-specific changes are cut out of the >> build when building without Shenandoah, and avoid those code paths at >> runtime when running without Shenandoah. >> >> Also, there are a few places where this was not possible or where it >> didn't seem feasible, but we tried to keep them few and obvious. >> Whenever this is the case, we are mirroring as close as possible what >> we >> have in jdk/jdk. >> >> Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. Other >> architectures still build fine, and Shenandoah gets automatically >> disabled during configure if not supported. OS-wise, Shenandoah runs >> on >> Linux, Windows, and is known to run on MacOS X and Solaris too. >> >> I wasn't sure which form this should take. I decided to start with >> the >> easiest possible form this could take: a simple patch/webrev and an >> RFR. >> Let me know if you need a JIRA issue or any other formalities to >> track that. >> >> Full webrev: >> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.02-all%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=eHspbGt5Eox4EMv8hstTBwsqFYefGNO2acGymP7ZfN0%3D&reserved=0 >> >> Webrev only for shared-code changes: >> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.02-shared%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=LGghbNRyHPSJLK8l2Oyhxh1lhD46LmvZtN1G5htYBpk%3D&reserved=0 >> >> The webrevs are based on and depend on the arraycopy patch proposed >> for >> review here: >> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk-updates-dev%2F2020-January%2F002396.html&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=Kw0qkfvtVNVrCiMeypwr4BHX9e3bZafJnVCMVY%2BvOOw%3D&reserved=0 >> >> Testing: >> The code has been tested many many times, continuously while >> maintaining >> it. It has also served as the basis for RPMs and shipped to >> customers. >> We are running all sorts of tests of the hotspot/jtreg testsuite, in >> particular hotspot_gc_shenandoah, CTW tests, the regular tier* tests, >> several popular benchmarks (specjvm, specjbb on a regular basis), on >> a >> nightly basis. >> >> Please let me know what you think. >> >> Thanks, >> Roman >> >> >> >> >> >> >> > > From rkennke at redhat.com Sat Jun 27 07:50:50 2020 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 27 Jun 2020 09:50:50 +0200 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> Message-ID: Hi Gil, I understand your concerns. I wouldn't propose this if Shenandoah was actually an experimental/playground feature. The contrary is the case - it is very solid and ready for production use (and infact *in* production use by Red Hat customers and others). It has received tons of testing by us and others. If a downstream vendor doesn't want to ship it, it is easily solved by --with-jvm-features=-shenandoahgc. As I mentioned in my original email, we make sure that we exclude Shenandoah-added code using #ifdef INCLUDE_SHENANDOAHGC whereever reasonably possible. It doesn't zero the risk, but it brings it pretty close. I don't think a downstream jdk11+ or so project/repository would be all that useful. I don't see many other such features to go into jdk11u, so it might well be a Shenandoah-only thing - which we already have in the form of shenandoah/jdk11 repository, which is very well maintained downstream from jdk11u + Shenandoah. If our current backporting practice is a concern I could offer to tighten it up and only backport critical bugfixes, no feature backports, no non-critical bugfixes, etc. That being said, I do understand your point. This is not about somehow making my (or Red Hat's) life easier (it wouldn't - backporting to jdk11u proper seems more bureaucratic than backporting to our own downstream repo). My intention was to avoid fragmentation between vendors. If we cannot get to an agreement here, I'd be fine to keep maintaining shenandoah/jdk11 as we already do, and suggest that vendors who want Shenandoah in their jdk11u builds to use that as a basis for their builds. *I* don't think that is the preferable solution. Best regards, Roman On Fri, 2020-06-26 at 23:39 +0000, Gil Tene wrote: > As I noted before, we have serious reservations about adding major > new features to a > stable LTS that is upstream of all of 11u. Based on daily > interactions with tons of OpenJDK > end users, I can say that the vast majority of end users that are > ramping up on 11u are > demanding stability and maturity above all else. The addition of such > major changes in > an 11u update will cause many of them to stall updates, and > potentially stall the uptake > of 11u altogether, waiting for 11u to actually stabilize first > (evidenced by no longer doing > such things), so they can keep up with fixes and security issues > without having to take on > potential regressions driven by late added or experimental features. > > If you want a modern GA'ed OpenJDK with all the latest features in > it, use one. Please > please please don't force people who choose to stick with a given > OpenJDK version for > stability, and knowingly did not move to a later OpenJDK version, to > deploy the newly > implemented features that you like by pushing for back-porting them > to the upstream > project that they get their security updates from... > > I can see a potentially good case for a downstream-from-11u project > that incorporates > ongoing development (as opposed to bug fixes) from later upstream > versions, and would > be happy to collaborate on one. But the 11u that is upstream of all > other 11u's should not > be seen as a developer's playground, or a place to add cool new > features to a stable > release. The upstream versions are there for that purpose. The valid > interests of > deep-bench, self-supporting groups making use of OpenJDK, who can > take on the stability > risks involved due to the depth of their technical bench, should not > overcome the interests > of the millions of consumers of the 11u builds that do not have that > luxury, and who > need and expect stable (in the changing only where necessary sense) > 11u releases. > > I'd like to point out that 13u already includes Shenandoah. 15u > (expected in 3 months) > already includes Shenandoah as a non-experimental feature. And we can > all collaborate > on back-porting bug-fixes to those to updates to keep a lively > version of OpenJDK that > includes Shenandoah up to date from a bug fix and security update > point of view. For > those insisting on waiting for an LTS (on the assumption that LTSs > are long term stable > and don't get those sort of messing-with-after-the-fact done to them, > mind you), 17u will > be out in 15 months. > > So we are not talking about some far-away future for end users that > want Shenandoah. > It is here, now, in multiple consumable forms, and available for > people not looking for > the stability of an LTS, and even for people who do (as they can use > the Red Hat 11u > builds). It it will be available in more forms very soon with no > effort, and we don't have > to destabilize 11u for others to make that happen. > > ? Gil. > > > On Jun 26, 2020, at 1:51 PM, Mathiske, Bernd > > wrote: > > > > Hi Roman, > > > > We are also in favor of upstreaming Shenandoah to jdk11u, for the > > same reasons Aditya listed, and we agree with everything else he > > has written. Similar to Aditya?s message below, we believe that > > Shenandoah has strong demand and potential for those running > > jdk11u. Targeting jdk11u is the most efficient way to reach a > > large user base and to enable production use of Shenandoah. > > > > At Amazon, we plan to continue to contribute to Shenandoah, and we > > fully intend to help maintain Shenandoah in jdk11u. > > > > Best, > > > > Bernd, Kelvin, Azeem > > > > ?On 6/26/20, 10:36 AM, "jdk-updates-dev on behalf of Aditya > > Mandaleeka" > adityam at microsoft.com> wrote: > > > > Hi Roman, > > > > I am in favor of this proposed upstreaming of Shenandoah into > > jdk11u. Microsoft > > has some long-term commitments to Java 11 customers and having > > Shenandoah > > included in jdk11u upstream would definitely be well-received by > > my team and by > > our customers. There is demand for this kind of GC option on > > OpenJDK 11, and it > > would be beneficial to the community for it to be available on > > the upstream > > OpenJDK rather than only in specific downstream releases. > > Coupled with the fact > > that Shenandoah has been tested on JDK 11 for quite a while now, > > I think this > > upstreaming makes sense. > > > > You mentioned in your original mail that your team at RedHat > > intends to maintain > > this proposed jdk11u version the same way it has been maintained > > in > > shenandoah/jdk11. That is great--from what I?ve seen in these > > past few months > > that I?ve been involved, I?ve been impressed by the way > > backports to > > shenandoah/jdk11 are being handled, the effort that is made to > > keep the > > Shenandoah code closely aligned between sh/11 and jdk/jdk, and > > the care taken to > > ensure that the impact on shared code is kept to a minimum. > > > > At Microsoft, we?ve already been contributing patches and > > investigating and > > reporting issues based on our testing of Shenandoah, both on > > jdk/jdk and > > shenandoah/jdk11. We intend to continue this kind of > > involvement, so if this > > upstreaming to jdk11u goes through, your team will also have our > > support in > > maintaining Shenandoah there. > > > > Thanks, > > Aditya > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Roman Kennke > > Sent: Thursday, June 25, 2020 4:16 AM > > To: jdk-updates-dev at openjdk.java.net > > Subject: Re: RFR (11u, XXL): Upstream/backport Shenandoah to > > JDK11u > > > > I would like to revive this RFR, I believe we haven't come to a > > conclusion yet. I still think it would be very useful to have > > the > > Shenandoah GC included in jdk11u upstream. I have heard from > > several > > vendors who would like to ship Shenandoah, but maintaining the > > rather > > huge Shenandoah backport patch is an absolute no-go. > > > > This is an updated patch that includes numerous bugfixes and > > improvements in Shenandoah. It is what Red Hat is going to ship > > in > > their 11.0.8 release. > > > > Full webrev: > > > > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.04-all%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967016879&sdata=G1HjEJ68qFJ2uwRyxfFKNE8gcbsFXEdYi%2B9RyrUeG60%3D&reserved=0 > > > > Webrev only for shared-code changes: > > > > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.04-shared%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=RrKNOvxc3%2FheThyi2cMiazE%2BxC9UfARxfTbmuoc640Y%3D&reserved=0 > > > > Please let me know what you think. > > > > Roman > > > > > On Fri, 2020-01-17 at 18:05 +0100, Roman Kennke wrote: > > > Hello, > > > > > > The Shenandoah GC has been integrated into jdk12 a little over a > > > year > > > ago: > > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Frev%2F9c18c9d839d3&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=QJo2xwdHiEuaqsz26P2j%2BZdE6j3AxUvpnHVTjD9XGXI%3D&reserved=0 > > > > > > The Shenandoah team has been maintaining the Shenandoah-enabled > > > jdk11u > > > downstream repository since the inception of jdk11 under: > > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fshenandoah%2Fjdk11&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=P%2FLkJ5VCrq4oWzik3WZ3GTy1a3mA52mxkITasawIMk0%3D&reserved=0 > > > > > > In order to make it more useful and accessible for users, we > > > would > > > like > > > to make it available in upstream jdk11u. The Shenandoah team at > > > Red > > > Hat > > > intends to maintain it the same way it had been maintained in > > > shenandoah/jdk11, in the course of regular jdk11u maintenance Red > > > Hat > > > already does. > > > > > > Thanks to recent changes in Shenandoah over the last year, we are > > > now > > > able to fit the GC interface in jdk11 almost exactly. There are a > > > few > > > exceptions though. We tried to follow the following pattern for > > > all > > > shared-code changes where it made sense: > > > > > > #if INCLUDE_SHENANDOAH_GC > > > if (UseShenandoahGC) { > > > ... > > > } > > > #endif > > > > > > This ensures that the Shenandoah-specific changes are cut out of > > > the > > > build when building without Shenandoah, and avoid those code > > > paths at > > > runtime when running without Shenandoah. > > > > > > Also, there are a few places where this was not possible or where > > > it > > > didn't seem feasible, but we tried to keep them few and obvious. > > > Whenever this is the case, we are mirroring as close as possible > > > what > > > we > > > have in jdk/jdk. > > > > > > Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. > > > Other > > > architectures still build fine, and Shenandoah gets automatically > > > disabled during configure if not supported. OS-wise, Shenandoah > > > runs > > > on > > > Linux, Windows, and is known to run on MacOS X and Solaris too. > > > > > > I wasn't sure which form this should take. I decided to start > > > with > > > the > > > easiest possible form this could take: a simple patch/webrev and > > > an > > > RFR. > > > Let me know if you need a JIRA issue or any other formalities to > > > track that. > > > > > > Full webrev: > > > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.02-all%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=eHspbGt5Eox4EMv8hstTBwsqFYefGNO2acGymP7ZfN0%3D&reserved=0 > > > > > > Webrev only for shared-code changes: > > > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.02-shared%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=LGghbNRyHPSJLK8l2Oyhxh1lhD46LmvZtN1G5htYBpk%3D&reserved=0 > > > > > > The webrevs are based on and depend on the arraycopy patch > > > proposed > > > for > > > review here: > > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk-updates-dev%2F2020-January%2F002396.html&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=Kw0qkfvtVNVrCiMeypwr4BHX9e3bZafJnVCMVY%2BvOOw%3D&reserved=0 > > > > > > Testing: > > > The code has been tested many many times, continuously while > > > maintaining > > > it. It has also served as the basis for RPMs and shipped to > > > customers. > > > We are running all sorts of tests of the hotspot/jtreg testsuite, > > > in > > > particular hotspot_gc_shenandoah, CTW tests, the regular tier* > > > tests, > > > several popular benchmarks (specjvm, specjbb on a regular basis), > > > on > > > a > > > nightly basis. > > > > > > Please let me know what you think. > > > > > > Thanks, > > > Roman > > > > > > > > > > > > > > > > > > > > > From patrick at os.amperecomputing.com Sat Jun 27 09:32:37 2020 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Sat, 27 Jun 2020 09:32:37 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- Thanks Goetz I updated the of reviewers, http://cr.openjdk.java.net/~qpzhang/8248214/webrev.02/jdk11u-dev.changeset. Regarding the performance, I had tests on Linux system with a couple of x86_64/aarch64 servers, I am not sure if mentioning specjbb here would be appropriate, by far, most results of this benchmark are positive especially the metrics sensitive to GC stability (G1 or ParallelGC), and no obvious change with others probably due to microarchitecture level differences in handling exclusive load/store. This is similar as the original patch [1]. Updated "Fix request (11u)" with a risk estimation of this downporting, see JBS [1] please. I am not familiar with the process of jdk-updates. Is it ok to push this downporting patch now? or I should still wait for maintainer's approval at JBS (jdk11u-fix-yes?). [1] https://bugs.openjdk.java.net/browse/JDK-8248214?focusedCommentId=14349531&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14349531 Regards Patrick -----Original Message----- From: Lindenmaier, Goetz Sent: Friday, June 26, 2020 3:17 PM To: Patrick Zhang OS ; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention Hi Patrick, I had a look at your change. I think it makes sense to bring this to 11, if there actually is the performance gain you mention. Reviewed. Please add in the "Fix request" comment in the JBS the risk of downporting this. And I think is should be "Fix request (11u)" because different people will review your fix request for 11 and 8. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Patrick Zhang OS > Sent: Wednesday, June 24, 2020 11:55 AM > To: jdk-updates-dev at openjdk.java.net > Cc: hotspot-gc-dev > > Subject: [DMARC FAILURE] [11u] RFR: 8244214: Add paddings for > TaskQueueSuper to reduce false-sharing cache contention > > Hi > > Could I ask for a review of this simple patch which takes a tiny part > from the original ticket JDK-8243326 [1]. The reason that I do not > want a full backport is, the majority of the patch at jdk/jdk [2] is > to clean up the volatile use and may be not very meaningful to 11u, > furthermore the context (dependencies on atomic.hpp refactor) is too > complicated to generate a clear backport (I tried, ~81 files need to be changed). > > The purpose of having this one-line change to 11u is, the two volatile > variables in TaskQueueSuper: _bottom, _age and corresponding atomic > operations upon, may cause severe cache contention inside GC with > larger number of threads, i.e., specified by -XX:ParallelGCThreads=##, > adding paddings (up to DEFAULT_CACHE_LINE_SIZE) in-between can reduce > the possibility of false-sharing cache contention. I do not need the > paddings before _bottom and after _age from the original patch [2], > because the instances of TaskQueueSuper are usually (always) allocated > in a set of queues, in which they are naturally separated. Please review, thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248214 > Webrev: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.01/ > Testing: tier1-2 pass with the patch, commercial benchmarks and small > C++ test cases (to simulate the data struct and work-stealing > algorithm atomics) validated the performance, no regression. > > By the way, I am going to request for 8u backport as well once 11u > would have it. > > [1] https://bugs.openjdk.java.net/browse/JDK-8243326 Cleanup use of > volatile in taskqueue code [2] > https://hg.openjdk.java.net/jdk/jdk/rev/252a1602b4c6 > > Regards > Patrick > From maoliang.ml at alibaba-inc.com Sun Jun 28 04:10:42 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Sun, 28 Jun 2020 12:10:42 +0800 Subject: =?UTF-8?B?UkZSICgxMXUsIFhYTCk6IFVwc3RyZWFtL2JhY2twb3J0IFNoZW5hbmRvYWggdG8gSkRLMTF1?= Message-ID: Hi Roman, We are in favor of having production-ready Shenandoah in 11u as well. A lot of work loads in Alibaba are migrating to 11u and stable Shenandoah GC can definitly help to resolve GC problems. We've been investigating Shenandoah for a while and also report some issues and get some good results. As Shenandoah being deployed in our loads and customers, we would surely take the responsibility of maintanence as well. Thanks, Liang ------------------------------------------------------------------ From:Mathiske, Bernd Send Time:2020 Jun. 27 (Sat.) 04:52 To:Roman Kennke ; jdk-updates-dev at openjdk.java.net Cc:"Nilsen, Kelvin" ; "Jiva, Azeem" Subject:Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u Hi Roman, We are also in favor of upstreaming Shenandoah to jdk11u, for the same reasons Aditya listed, and we agree with everything else he has written. Similar to Aditya?s message below, we believe that Shenandoah has strong demand and potential for those running jdk11u. Targeting jdk11u is the most efficient way to reach a large user base and to enable production use of Shenandoah. At Amazon, we plan to continue to contribute to Shenandoah, and we fully intend to help maintain Shenandoah in jdk11u. Best, Bernd, Kelvin, Azeem On 6/26/20, 10:36 AM, "jdk-updates-dev on behalf of Aditya Mandaleeka" wrote: Hi Roman, I am in favor of this proposed upstreaming of Shenandoah into jdk11u. Microsoft has some long-term commitments to Java 11 customers and having Shenandoah included in jdk11u upstream would definitely be well-received by my team and by our customers. There is demand for this kind of GC option on OpenJDK 11, and it would be beneficial to the community for it to be available on the upstream OpenJDK rather than only in specific downstream releases. Coupled with the fact that Shenandoah has been tested on JDK 11 for quite a while now, I think this upstreaming makes sense. You mentioned in your original mail that your team at RedHat intends to maintain this proposed jdk11u version the same way it has been maintained in shenandoah/jdk11. That is great--from what I?ve seen in these past few months that I?ve been involved, I?ve been impressed by the way backports to shenandoah/jdk11 are being handled, the effort that is made to keep the Shenandoah code closely aligned between sh/11 and jdk/jdk, and the care taken to ensure that the impact on shared code is kept to a minimum. At Microsoft, we?ve already been contributing patches and investigating and reporting issues based on our testing of Shenandoah, both on jdk/jdk and shenandoah/jdk11. We intend to continue this kind of involvement, so if this upstreaming to jdk11u goes through, your team will also have our support in maintaining Shenandoah there. Thanks, Aditya -----Original Message----- From: jdk-updates-dev On Behalf Of Roman Kennke Sent: Thursday, June 25, 2020 4:16 AM To: jdk-updates-dev at openjdk.java.net Subject: Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u I would like to revive this RFR, I believe we haven't come to a conclusion yet. I still think it would be very useful to have the Shenandoah GC included in jdk11u upstream. I have heard from several vendors who would like to ship Shenandoah, but maintaining the rather huge Shenandoah backport patch is an absolute no-go. This is an updated patch that includes numerous bugfixes and improvements in Shenandoah. It is what Red Hat is going to ship in their 11.0.8 release. Full webrev: https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.04-all%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967016879&sdata=G1HjEJ68qFJ2uwRyxfFKNE8gcbsFXEdYi%2B9RyrUeG60%3D&reserved=0 Webrev only for shared-code changes: https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.04-shared%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=RrKNOvxc3%2FheThyi2cMiazE%2BxC9UfARxfTbmuoc640Y%3D&reserved=0 Please let me know what you think. Roman > On Fri, 2020-01-17 at 18:05 +0100, Roman Kennke wrote: > Hello, > > The Shenandoah GC has been integrated into jdk12 a little over a year > ago: > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Frev%2F9c18c9d839d3&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=QJo2xwdHiEuaqsz26P2j%2BZdE6j3AxUvpnHVTjD9XGXI%3D&reserved=0 > > The Shenandoah team has been maintaining the Shenandoah-enabled > jdk11u > downstream repository since the inception of jdk11 under: > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fshenandoah%2Fjdk11&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=P%2FLkJ5VCrq4oWzik3WZ3GTy1a3mA52mxkITasawIMk0%3D&reserved=0 > > In order to make it more useful and accessible for users, we would > like > to make it available in upstream jdk11u. The Shenandoah team at Red > Hat > intends to maintain it the same way it had been maintained in > shenandoah/jdk11, in the course of regular jdk11u maintenance Red Hat > already does. > > Thanks to recent changes in Shenandoah over the last year, we are now > able to fit the GC interface in jdk11 almost exactly. There are a few > exceptions though. We tried to follow the following pattern for all > shared-code changes where it made sense: > > #if INCLUDE_SHENANDOAH_GC > if (UseShenandoahGC) { > ... > } > #endif > > This ensures that the Shenandoah-specific changes are cut out of the > build when building without Shenandoah, and avoid those code paths at > runtime when running without Shenandoah. > > Also, there are a few places where this was not possible or where it > didn't seem feasible, but we tried to keep them few and obvious. > Whenever this is the case, we are mirroring as close as possible what > we > have in jdk/jdk. > > Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. Other > architectures still build fine, and Shenandoah gets automatically > disabled during configure if not supported. OS-wise, Shenandoah runs > on > Linux, Windows, and is known to run on MacOS X and Solaris too. > > I wasn't sure which form this should take. I decided to start with > the > easiest possible form this could take: a simple patch/webrev and an > RFR. > Let me know if you need a JIRA issue or any other formalities to > track that. > > Full webrev: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.02-all%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=eHspbGt5Eox4EMv8hstTBwsqFYefGNO2acGymP7ZfN0%3D&reserved=0 > > Webrev only for shared-code changes: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~rkennke%2Fshenandoah-jdk11u-upstream%2Fwebrev.02-shared%2F&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=LGghbNRyHPSJLK8l2Oyhxh1lhD46LmvZtN1G5htYBpk%3D&reserved=0 > > The webrevs are based on and depend on the arraycopy patch proposed > for > review here: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk-updates-dev%2F2020-January%2F002396.html&data=02%7C01%7Cadityam%40microsoft.com%7C7aec62734d22458243d908d818f974c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286806967026872&sdata=Kw0qkfvtVNVrCiMeypwr4BHX9e3bZafJnVCMVY%2BvOOw%3D&reserved=0 > > Testing: > The code has been tested many many times, continuously while > maintaining > it. It has also served as the basis for RPMs and shipped to > customers. > We are running all sorts of tests of the hotspot/jtreg testsuite, in > particular hotspot_gc_shenandoah, CTW tests, the regular tier* tests, > several popular benchmarks (specjvm, specjbb on a regular basis), on > a > nightly basis. > > Please let me know what you think. > > Thanks, > Roman > > > > > > > From gil at azul.com Sun Jun 28 14:22:21 2020 From: gil at azul.com (Gil Tene) Date: Sun, 28 Jun 2020 14:22:21 +0000 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> Message-ID: <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> > On Jun 27, 2020, at 12:50 AM, Roman Kennke wrote: > > Hi Gil, > > I understand your concerns. > > I wouldn't propose this if Shenandoah was actually an > experimental/playground feature. The contrary is the case - it is very > solid and ready for production use (and infact *in* production use by > Red Hat customers and others). It has received tons of testing by us > and others. I am in no way challenging or debating the effort and testing put into it, or the good practices and experience built up. I'm pointing out that such major features should simply not be added to a stable LTS release. The "playground" comment is not about the maturity of the feature being proposed. It is about the maturity of the release it is being proposed for. Adding features to a stable LTS train without a forcing necessity is the "treating it as a playground" I was talking about. I know a whole bunch of OpenJDK developers here want this. And a lot of external people that like to work and play with leading edge stuff want it (on 11u) too. And I don't doubt that there are tens of thousands of people that would be happy to see it added. I'm pointing out that there will be (literally) Millions of people affected who do not share this view, are not here on these lists speaking out about it, and for whom 11u LTS builds are a critical infrastructure competent where stability matters most. Those are the people who expect LTS releases to only have bug fixes and security updates applied. They represent the vast majority of production consumption of LTS builds. And yes, we occasionally have to go beyond bug fixes and security updates, and add significant features that did not previously exist in that LTS version of Java or OpenJDK in any previous form. When we (very reluctantly) do that, it needs to be as a result of necessity. IMO the trigger we should be looking at as we gauge necessity is "If we don't do this, the LTS will likely break in some way, and many (Millions?) will be affected" A current gut-wrenching example of necessity is TLS 1.3 support in OpenJDK 8u: Java 8 will need to live long past the point where TLS 1.2 may be disallowed by some organizations, and the pressure is already beginning to show. Adding TLS 1.3 to Java 8 is an unavoidable necessity. The Java SE 8 spec was modified to enable TLS 1.3 support, and the externally-driven need is pretty clear. OpenJDK 8u cannot stay behind on this. So this qualifies. If we don't do this, OpenJDK 8u will break. Millions will be negatively affected. A smaller example was the addition of container resource limit awareness in 8u192. The emergence of containers as common deployment environments and the friction between the JDK behavior and resource limit enforcement (throttling/thrashing, OOM killing) created painful enough situations that it was necessary to add a feature to the JDK implementation to allow it to live in acceptable ways in modern hardware deployments. So this one qualified too: If it were not done, 8u would have remained broken on container environments. Millions would have been negatively affected. We simply don't have necessity behind the suggestion for adding a brand new garbage collector to the upstream 11u distribution. We have people who'd like to see it happen, and people who will agree to deal with he issues that may arise and help fix them in future updates. And we have multiple groups that are willing to run it internally within their large organizations and self-support if needed. But we don't have an external forcing event that says that unless we do this we'll be causing tons of end-users to break or start malfunctioning. [And yes, I'm sure some examples of unnecessary things added mid-life of a stable release in the past can be dug up. Nothing is pure in the past. But I doubt anything like "add a new collector to the mature upstream production release" can be found int the last 10 or so years] > > If a downstream vendor doesn't want to ship it, it is easily solved by > --with-jvm-features=-shenandoahgc. As I mentioned in my original email, > we make sure that we exclude Shenandoah-added code using #ifdef > INCLUDE_SHENANDOAHGC whereever reasonably possible. It doesn't zero the > risk, but it brings it pretty close. This is not about how carefully this is applied, or how much "this shouldn't break anything, by design, really, and we tested it a lot" we can point to. The best way to not break things is to not change them, Every experienced IT operator knows this instinctively, and a huge % of those choose to only use LTS versions (and wait 1+ years for them to stabilize before doing so) for that very reason. Those people represent a huge portion of the "customer" consuming the 11u updates this project builds. Just imagine trying to explain this to a room full of SREs or sysadmins, trying to think of a comeback to "Wait! So you are saying that I can't get security updates for 11u any more without accepting that they come with the code changes you made for adding in a brand new garbage collector?" A "we worked hard to minimize actual code change wherever reasonably possible" answer will not fly in that room. > > I don't think a downstream jdk11+ or so project/repository would be all > that useful. I don't see many other such features to go into jdk11u, so > it might well be a Shenandoah-only thing - which we already have in the > form of shenandoah/jdk11 repository, which is very well maintained > downstream from jdk11u + Shenandoah. I think this is one (big) example, and that we will likely face more of the same choices due to similar motivations in the years ahead, with useful features big and small looking to be back-ported, and with those wishes hitting against the primary purpose of an upstream LTS, and against it's main mission and useful role for the vast majority of downstream consumers. I actually do think (and like) the idea of a downstream-from-11u thing that can take on new features can work (hotspot-expres-like or not). I would be interested in collaborating on such a thing, and think that it will have many interested consumers. And there are several interesting improvements I would like to see added to an 11u-that-takes-on-new-feature thing if such a delivery vehicle was available. But I obviously don't think that thing and the upstream stable 11u that is all other 11u's update from should be conflated. > > If our current backporting practice is a concern I could offer to > tighten it up and only backport critical bugfixes, no feature > backports, no non-critical bugfixes, etc. This is a feature backport. What happens after is not the issue. And it will be hard to argue for no additional increments after we add in an entire new collector that didn't previously exist in the release. > > That being said, I do understand your point. This is not about somehow > making my (or Red Hat's) life easier (it wouldn't - backporting to > jdk11u proper seems more bureaucratic than backporting to our own > downstream repo). My intention was to avoid fragmentation between > vendors. If we cannot get to an agreement here, I'd be fine to keep > maintaining shenandoah/jdk11 as we already do, and suggest that vendors > who want Shenandoah in their jdk11u builds to use that as a basis for > their builds. That to me seems like the reasonable way to go, as long as no other downstream-from-11u thing that is better (as in allows multiple of these major feature backports to be consolidated togther) exists. Downstream distros that want Shenandoah can be downstream from shenandoah/jdk11, as Red Hat [presumably] currently is. And those who want both can do both. > *I* don't think that is the preferable solution. And clearly respectfully disagree with each other on that. I, for one, look forward to seeing the non-experimental Shenandoah in 15u come out, and will work to get people to use 15u in production as soon as possible (including making sure it keeps getting updated long enough to last for 18 months past the first 17u release). IMO that is the best path for driving new feature adoption. Unline in 11u, doing fixes to Shenandoah on 15u as we keep 15u up to date with bug fixes and security updates (including back-ports from later releases) will make perfect sense, as it will not be a late added feature. > > Best regards, > Roman > > > > On Fri, 2020-06-26 at 23:39 +0000, Gil Tene wrote: >> As I noted before, we have serious reservations about adding major >> new features to a >> stable LTS that is upstream of all of 11u. Based on daily >> interactions with tons of OpenJDK >> end users, I can say that the vast majority of end users that are >> ramping up on 11u are >> demanding stability and maturity above all else. The addition of such >> major changes in >> an 11u update will cause many of them to stall updates, and >> potentially stall the uptake >> of 11u altogether, waiting for 11u to actually stabilize first >> (evidenced by no longer doing >> such things), so they can keep up with fixes and security issues >> without having to take on >> potential regressions driven by late added or experimental features. >> >> If you want a modern GA'ed OpenJDK with all the latest features in >> it, use one. Please >> please please don't force people who choose to stick with a given >> OpenJDK version for >> stability, and knowingly did not move to a later OpenJDK version, to >> deploy the newly >> implemented features that you like by pushing for back-porting them >> to the upstream >> project that they get their security updates from... >> >> I can see a potentially good case for a downstream-from-11u project >> that incorporates >> ongoing development (as opposed to bug fixes) from later upstream >> versions, and would >> be happy to collaborate on one. But the 11u that is upstream of all >> other 11u's should not >> be seen as a developer's playground, or a place to add cool new >> features to a stable >> release. The upstream versions are there for that purpose. The valid >> interests of >> deep-bench, self-supporting groups making use of OpenJDK, who can >> take on the stability >> risks involved due to the depth of their technical bench, should not >> overcome the interests >> of the millions of consumers of the 11u builds that do not have that >> luxury, and who >> need and expect stable (in the changing only where necessary sense) >> 11u releases. >> >> I'd like to point out that 13u already includes Shenandoah. 15u >> (expected in 3 months) >> already includes Shenandoah as a non-experimental feature. And we can >> all collaborate >> on back-porting bug-fixes to those to updates to keep a lively >> version of OpenJDK that >> includes Shenandoah up to date from a bug fix and security update >> point of view. For >> those insisting on waiting for an LTS (on the assumption that LTSs >> are long term stable >> and don't get those sort of messing-with-after-the-fact done to them, >> mind you), 17u will >> be out in 15 months. >> >> So we are not talking about some far-away future for end users that >> want Shenandoah. >> It is here, now, in multiple consumable forms, and available for >> people not looking for >> the stability of an LTS, and even for people who do (as they can use >> the Red Hat 11u >> builds). It it will be available in more forms very soon with no >> effort, and we don't have >> to destabilize 11u for others to make that happen. >> >> ? Gil. From christoph.langer at sap.com Mon Jun 29 07:48:19 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Jun 2020 07:48:19 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention In-Reply-To: References: Message-ID: Hi Patrick, yes, you need to wait for maintainers approval before pushing. Reason for that process is that apart from the technical review of your change, maintainers will also have a look focusing on whether a change is appropriate at for an update release, e.g. risk assessment etc. But I've approved it now, so you can go ahead ?? When pushing, you should also update the copyright year of the file. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Patrick Zhang OS > Sent: Samstag, 27. Juni 2020 11:33 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Cc: hotspot-gc-dev > Subject: [DMARC FAILURE] RE: [11u] RFR: 8244214: Add paddings for > TaskQueuSuper to reduce false-sharing cache contention > > The message from this sender included one or more files > which could not be scanned for virus detection; do not > open these files unless you are certain of the sender's intent. > > ---------------------------------------------------------------------- > Thanks Goetz > > I updated the of reviewers, > http://cr.openjdk.java.net/~qpzhang/8248214/webrev.02/jdk11u- > dev.changeset. Regarding the performance, I had tests on Linux system with > a couple of x86_64/aarch64 servers, I am not sure if mentioning specjbb here > would be appropriate, by far, most results of this benchmark are positive > especially the metrics sensitive to GC stability (G1 or ParallelGC), and no > obvious change with others probably due to microarchitecture level > differences in handling exclusive load/store. This is similar as the original > patch [1]. > > Updated "Fix request (11u)" with a risk estimation of this downporting, see > JBS [1] please. > > I am not familiar with the process of jdk-updates. Is it ok to push this > downporting patch now? or I should still wait for maintainer's approval at JBS > (jdk11u-fix-yes?). > > [1] https://bugs.openjdk.java.net/browse/JDK- > 8248214?focusedCommentId=14349531&page=com.atlassian.jira.plugin.syst > em.issuetabpanels:comment-tabpanel#comment-14349531 > > > Regards > > Patrick > > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Friday, June 26, 2020 3:17 PM > To: Patrick Zhang OS ; jdk-updates- > dev at openjdk.java.net > Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueueSuper to reduce > false-sharing cache contention > > > > Hi Patrick, > > > > I had a look at your change. > > I think it makes sense to bring this to 11, if there actually is the performance > gain you mention. > > Reviewed. > > > > Please add in the "Fix request" comment in the JBS the risk of downporting > this. And I think is should be "Fix request (11u)" > > because different people will review your fix request for 11 and 8. > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: jdk-updates-dev bounces at openjdk.java.net bounces at openjdk.java.net>> On > > > Behalf Of Patrick Zhang OS > > > Sent: Wednesday, June 24, 2020 11:55 AM > > > To: jdk-updates-dev at openjdk.java.net dev at openjdk.java.net> > > > Cc: hotspot-gc-dev dev at openjdk.java.net>> > > > Subject: [DMARC FAILURE] [11u] RFR: 8244214: Add paddings for > > > TaskQueueSuper to reduce false-sharing cache contention > > > > > > Hi > > > > > > Could I ask for a review of this simple patch which takes a tiny part > > > from the original ticket JDK-8243326 [1]. The reason that I do not > > > want a full backport is, the majority of the patch at jdk/jdk [2] is > > > to clean up the volatile use and may be not very meaningful to 11u, > > > furthermore the context (dependencies on atomic.hpp refactor) is too > > > complicated to generate a clear backport (I tried, ~81 files need to be > changed). > > > > > > The purpose of having this one-line change to 11u is, the two volatile > > > variables in TaskQueueSuper: _bottom, _age and corresponding atomic > > > operations upon, may cause severe cache contention inside GC with > > > larger number of threads, i.e., specified by -XX:ParallelGCThreads=##, > > > adding paddings (up to DEFAULT_CACHE_LINE_SIZE) in-between can > reduce > > > the possibility of false-sharing cache contention. I do not need the > > > paddings before _bottom and after _age from the original patch [2], > > > because the instances of TaskQueueSuper are usually (always) allocated > > > in a set of queues, in which they are naturally separated. Please review, > thanks. > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248214 > > > Webrev: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.01/ > > > Testing: tier1-2 pass with the patch, commercial benchmarks and small > > > C++ test cases (to simulate the data struct and work-stealing > > > algorithm atomics) validated the performance, no regression. > > > > > > By the way, I am going to request for 8u backport as well once 11u > > > would have it. > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8243326 Cleanup use of > > > volatile in taskqueue code [2] > > > https://hg.openjdk.java.net/jdk/jdk/rev/252a1602b4c6 > > > > > > Regards > > > Patrick > > > > From goetz.lindenmaier at sap.com Mon Jun 29 08:19:46 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Jun 2020 08:19:46 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention In-Reply-To: References: Message-ID: Hi Patrick, The change looks good now. Please remove the "Summary:" line. It only repeats the bug title, and thus is redundant. You can use the Summary line if you want to add more than the bug title. You might add "Summary: This is a downport of a part of JDK-8243326" Also, the Bugid in the mail Subject is wrong ... But no matter, it's all set now. Best regards, Goetz. From: Patrick Zhang OS Sent: Saturday, June 27, 2020 11:33 AM To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Thanks Goetz I updated the of reviewers, http://cr.openjdk.java.net/~qpzhang/8248214/webrev.02/jdk11u-dev.changeset. Regarding the performance, I had tests on Linux system with a couple of x86_64/aarch64 servers, I am not sure if mentioning specjbb here would be appropriate, by far, most results of this benchmark are positive especially the metrics sensitive to GC stability (G1 or ParallelGC), and no obvious change with others probably due to microarchitecture level differences in handling exclusive load/store. This is similar as the original patch [1]. Updated "Fix request (11u)" with a risk estimation of this downporting, see JBS [1] please. I am not familiar with the process of jdk-updates. Is it ok to push this downporting patch now? or I should still wait for maintainer's approval at JBS (jdk11u-fix-yes?). [1] https://bugs.openjdk.java.net/browse/JDK-8248214?focusedCommentId=14349531&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14349531 Regards Patrick -----Original Message----- From: Lindenmaier, Goetz > Sent: Friday, June 26, 2020 3:17 PM To: Patrick Zhang OS >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention Hi Patrick, I had a look at your change. I think it makes sense to bring this to 11, if there actually is the performance gain you mention. Reviewed. Please add in the "Fix request" comment in the JBS the risk of downporting this. And I think is should be "Fix request (11u)" because different people will review your fix request for 11 and 8. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Patrick Zhang OS > Sent: Wednesday, June 24, 2020 11:55 AM > To: jdk-updates-dev at openjdk.java.net > Cc: hotspot-gc-dev > > Subject: [DMARC FAILURE] [11u] RFR: 8244214: Add paddings for > TaskQueueSuper to reduce false-sharing cache contention > > Hi > > Could I ask for a review of this simple patch which takes a tiny part > from the original ticket JDK-8243326 [1]. The reason that I do not > want a full backport is, the majority of the patch at jdk/jdk [2] is > to clean up the volatile use and may be not very meaningful to 11u, > furthermore the context (dependencies on atomic.hpp refactor) is too > complicated to generate a clear backport (I tried, ~81 files need to be changed). > > The purpose of having this one-line change to 11u is, the two volatile > variables in TaskQueueSuper: _bottom, _age and corresponding atomic > operations upon, may cause severe cache contention inside GC with > larger number of threads, i.e., specified by -XX:ParallelGCThreads=##, > adding paddings (up to DEFAULT_CACHE_LINE_SIZE) in-between can reduce > the possibility of false-sharing cache contention. I do not need the > paddings before _bottom and after _age from the original patch [2], > because the instances of TaskQueueSuper are usually (always) allocated > in a set of queues, in which they are naturally separated. Please review, thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248214 > Webrev: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.01/ > Testing: tier1-2 pass with the patch, commercial benchmarks and small > C++ test cases (to simulate the data struct and work-stealing > algorithm atomics) validated the performance, no regression. > > By the way, I am going to request for 8u backport as well once 11u > would have it. > > [1] https://bugs.openjdk.java.net/browse/JDK-8243326 Cleanup use of > volatile in taskqueue code [2] > https://hg.openjdk.java.net/jdk/jdk/rev/252a1602b4c6 > > Regards > Patrick > From sgehwolf at redhat.com Mon Jun 29 08:46:18 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 29 Jun 2020 10:46:18 +0200 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention In-Reply-To: References: Message-ID: On Sat, 2020-06-27 at 09:32 +0000, Patrick Zhang OS wrote: > I am not familiar with the process of jdk-updates. Is it ok to push this downporting patch now? or I should still wait for maintainer's approval at JBS (jdk11u-fix-yes?). Yes. Pushes to jdk11u-dev should wait for jdk11u-fix-yes label. Thanks, Severin From goetz.lindenmaier at sap.com Mon Jun 29 08:42:10 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Jun 2020 08:42:10 +0000 Subject: [11u] RFR: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response In-Reply-To: References: Message-ID: Hi Paul, Thaks for reviewing! Best regards, Goetz. > -----Original Message----- > From: Hohensee, Paul > Sent: Wednesday, June 24, 2020 7:16 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8238270: java.net HTTP/2 client does not decrease > stream count when receives 204 response > > Lgtm. > > Paul > > ?On 6/24/20, 6:28 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" > goetz.lindenmaier at sap.com> wrote: > > Hi, > > I am downporting this for parity with 11.0.9-oracle. > I had to resolve the copyright in Stream.java > And I had to adapt the test as testlibrary file SimpleSSLContext > Is at a different location. All trivial adaptions. > > http://cr.openjdk.java.net/~goetz/wr20/8238270-Http2_204-jdk11/01/ > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8238270 > https://hg.openjdk.java.net/jdk/jdk/rev/fd72cd98180e > > Best regards, > Goetz From patrick at os.amperecomputing.com Mon Jun 29 09:38:38 2020 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Mon, 29 Jun 2020 09:38:38 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention In-Reply-To: References: Message-ID: Hi Goetz and Christoph, Thanks for reviewing. I updated the copyright year and summary line accordingly: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.03/jdk11u-dev.changeset. Very appreciate if any committer could do me a favor and help pushing it. Regards Patrick From: Lindenmaier, Goetz Sent: Monday, June 29, 2020 4:20 PM To: Patrick Zhang OS ; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Hi Patrick, The change looks good now. Please remove the "Summary:" line. It only repeats the bug title, and thus is redundant. You can use the Summary line if you want to add more than the bug title. You might add "Summary: This is a downport of a part of JDK-8243326" Also, the Bugid in the mail Subject is wrong ... But no matter, it's all set now. [Patrick Zhang] sorry about the typos there, I could not 'fix' as it would get a new thread in mail list... Best regards, Goetz. From: Patrick Zhang OS > Sent: Saturday, June 27, 2020 11:33 AM To: Lindenmaier, Goetz >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Thanks Goetz I updated the of reviewers, http://cr.openjdk.java.net/~qpzhang/8248214/webrev.02/jdk11u-dev.changeset. Regarding the performance, I had tests on Linux system with a couple of x86_64/aarch64 servers, I am not sure if mentioning specjbb here would be appropriate, by far, most results of this benchmark are positive especially the metrics sensitive to GC stability (G1 or ParallelGC), and no obvious change with others probably due to microarchitecture level differences in handling exclusive load/store. This is similar as the original patch [1]. Updated "Fix request (11u)" with a risk estimation of this downporting, see JBS [1] please. I am not familiar with the process of jdk-updates. Is it ok to push this downporting patch now? or I should still wait for maintainer's approval at JBS (jdk11u-fix-yes?). [1] https://bugs.openjdk.java.net/browse/JDK-8248214?focusedCommentId=14349531&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14349531 Regards Patrick -----Original Message----- From: Lindenmaier, Goetz > Sent: Friday, June 26, 2020 3:17 PM To: Patrick Zhang OS >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention Hi Patrick, I had a look at your change. I think it makes sense to bring this to 11, if there actually is the performance gain you mention. Reviewed. Please add in the "Fix request" comment in the JBS the risk of downporting this. And I think is should be "Fix request (11u)" because different people will review your fix request for 11 and 8. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Patrick Zhang OS > Sent: Wednesday, June 24, 2020 11:55 AM > To: jdk-updates-dev at openjdk.java.net > Cc: hotspot-gc-dev > > Subject: [DMARC FAILURE] [11u] RFR: 8244214: Add paddings for > TaskQueueSuper to reduce false-sharing cache contention > > Hi > > Could I ask for a review of this simple patch which takes a tiny part > from the original ticket JDK-8243326 [1]. The reason that I do not > want a full backport is, the majority of the patch at jdk/jdk [2] is > to clean up the volatile use and may be not very meaningful to 11u, > furthermore the context (dependencies on atomic.hpp refactor) is too > complicated to generate a clear backport (I tried, ~81 files need to be changed). > > The purpose of having this one-line change to 11u is, the two volatile > variables in TaskQueueSuper: _bottom, _age and corresponding atomic > operations upon, may cause severe cache contention inside GC with > larger number of threads, i.e., specified by -XX:ParallelGCThreads=##, > adding paddings (up to DEFAULT_CACHE_LINE_SIZE) in-between can reduce > the possibility of false-sharing cache contention. I do not need the > paddings before _bottom and after _age from the original patch [2], > because the instances of TaskQueueSuper are usually (always) allocated > in a set of queues, in which they are naturally separated. Please review, thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248214 > Webrev: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.01/ > Testing: tier1-2 pass with the patch, commercial benchmarks and small > C++ test cases (to simulate the data struct and work-stealing > algorithm atomics) validated the performance, no regression. > > By the way, I am going to request for 8u backport as well once 11u > would have it. > > [1] https://bugs.openjdk.java.net/browse/JDK-8243326 Cleanup use of > volatile in taskqueue code [2] > https://hg.openjdk.java.net/jdk/jdk/rev/252a1602b4c6 > > Regards > Patrick > From aph at redhat.com Mon Jun 29 09:42:08 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2020 10:42:08 +0100 Subject: ... In-Reply-To: <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> Message-ID: On 28/06/2020 15:22, Gil Tene wrote: > We simply don't have necessity behind the suggestion for adding a > brand new garbage collector to the upstream 11u distribution. We > have people who'd like to see it happen, and people who will agree > to deal with he issues that may arise and help fix them in future > updates. And we have multiple groups that are willing to run it > internally within their large organizations and self-support if > needed. But we don't have an external forcing event that says that > unless we do this we'll be causing tons of end-users to break or > start malfunctioning. So Gil, please help me out here. You ship a (very) heavily modified JDK11u in the shape of Zing to your customers, do you not? So you are presumably not opposed to diverging heavily from 11u as a matter of principle, and least not in your proprietary releases. Perhaps the argument is that the addition of Shenandoah to JDK 11 might have been appropriate had it happened in the past, but it is not appropriate now. Why does that make sense? Is it simply that there has been more time for things in Zing to bake; but some downstream distros have been shipping Shenandoah-ified versions of JDK11u for an considerable time now, so it can't be that. Or is it that it's OK for downstream distributors of JDK11u to modify them heavily, but not JDK11u itself, (presumably) because it has more users than any of them? Or is it that all changes to JDK11u are in-principle bad, regardless of their actual risk, which we should not consider? That possibility seems a little odd. Given that most of your post is couched in terms of risk, to say that we shouldn't strive to evaluate that risk would be downright irrational. -- 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 christoph.langer at sap.com Mon Jun 29 11:47:29 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Jun 2020 11:47:29 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention In-Reply-To: References: Message-ID: Hi Patrick, Matthias just notified me of issues with the Mac build with your patch. So, in case anybody was about to push this, please hold off. We're looking into it... Thanks Christoph From: Patrick Zhang OS Sent: Montag, 29. Juni 2020 11:39 To: Lindenmaier, Goetz ; Langer, Christoph ; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Hi Goetz and Christoph, Thanks for reviewing. I updated the copyright year and summary line accordingly: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.03/jdk11u-dev.changeset. Very appreciate if any committer could do me a favor and help pushing it. Regards Patrick From: Lindenmaier, Goetz > Sent: Monday, June 29, 2020 4:20 PM To: Patrick Zhang OS >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Hi Patrick, The change looks good now. Please remove the "Summary:" line. It only repeats the bug title, and thus is redundant. You can use the Summary line if you want to add more than the bug title. You might add "Summary: This is a downport of a part of JDK-8243326" Also, the Bugid in the mail Subject is wrong ... But no matter, it's all set now. [Patrick Zhang] sorry about the typos there, I could not 'fix' as it would get a new thread in mail list... Best regards, Goetz. From: Patrick Zhang OS > Sent: Saturday, June 27, 2020 11:33 AM To: Lindenmaier, Goetz >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Thanks Goetz I updated the of reviewers, http://cr.openjdk.java.net/~qpzhang/8248214/webrev.02/jdk11u-dev.changeset. Regarding the performance, I had tests on Linux system with a couple of x86_64/aarch64 servers, I am not sure if mentioning specjbb here would be appropriate, by far, most results of this benchmark are positive especially the metrics sensitive to GC stability (G1 or ParallelGC), and no obvious change with others probably due to microarchitecture level differences in handling exclusive load/store. This is similar as the original patch [1]. Updated "Fix request (11u)" with a risk estimation of this downporting, see JBS [1] please. I am not familiar with the process of jdk-updates. Is it ok to push this downporting patch now? or I should still wait for maintainer's approval at JBS (jdk11u-fix-yes?). [1] https://bugs.openjdk.java.net/browse/JDK-8248214?focusedCommentId=14349531&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14349531 Regards Patrick -----Original Message----- From: Lindenmaier, Goetz > Sent: Friday, June 26, 2020 3:17 PM To: Patrick Zhang OS >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention Hi Patrick, I had a look at your change. I think it makes sense to bring this to 11, if there actually is the performance gain you mention. Reviewed. Please add in the "Fix request" comment in the JBS the risk of downporting this. And I think is should be "Fix request (11u)" because different people will review your fix request for 11 and 8. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Patrick Zhang OS > Sent: Wednesday, June 24, 2020 11:55 AM > To: jdk-updates-dev at openjdk.java.net > Cc: hotspot-gc-dev > > Subject: [DMARC FAILURE] [11u] RFR: 8244214: Add paddings for > TaskQueueSuper to reduce false-sharing cache contention > > Hi > > Could I ask for a review of this simple patch which takes a tiny part > from the original ticket JDK-8243326 [1]. The reason that I do not > want a full backport is, the majority of the patch at jdk/jdk [2] is > to clean up the volatile use and may be not very meaningful to 11u, > furthermore the context (dependencies on atomic.hpp refactor) is too > complicated to generate a clear backport (I tried, ~81 files need to be changed). > > The purpose of having this one-line change to 11u is, the two volatile > variables in TaskQueueSuper: _bottom, _age and corresponding atomic > operations upon, may cause severe cache contention inside GC with > larger number of threads, i.e., specified by -XX:ParallelGCThreads=##, > adding paddings (up to DEFAULT_CACHE_LINE_SIZE) in-between can reduce > the possibility of false-sharing cache contention. I do not need the > paddings before _bottom and after _age from the original patch [2], > because the instances of TaskQueueSuper are usually (always) allocated > in a set of queues, in which they are naturally separated. Please review, thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248214 > Webrev: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.01/ > Testing: tier1-2 pass with the patch, commercial benchmarks and small > C++ test cases (to simulate the data struct and work-stealing > algorithm atomics) validated the performance, no regression. > > By the way, I am going to request for 8u backport as well once 11u > would have it. > > [1] https://bugs.openjdk.java.net/browse/JDK-8243326 Cleanup use of > volatile in taskqueue code [2] > https://hg.openjdk.java.net/jdk/jdk/rev/252a1602b4c6 > > Regards > Patrick > From goetz.lindenmaier at sap.com Mon Jun 29 11:52:59 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Jun 2020 11:52:59 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- Hi Patrick, Please give it a moment ... we saw a build error on Mac: In file included from /usr/work/openjdk/nb/darwinintel64/nightly/jdk11u-dev/src/hotspot/share/gc/parallel/asPSYoungGen.cpp:29: In file included from /usr/work/openjdk/nb/darwinintel64/nightly/jdk11u-dev/src/hotspot/share/gc/parallel/psScavenge.inline.hpp:29: In file included from /usr/work/openjdk/nb/darwinintel64/nightly/jdk11u-dev/src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp:32: In file included from /usr/work/openjdk/nb/darwinintel64/nightly/jdk11u-dev/src/hotspot/share/gc/parallel/psPromotionManager.hpp:32: /usr/work/openjdk/nb/darwinintel64/nightly/jdk11u-dev/src/hotspot/share/gc/shared/taskqueue.hpp:153:60: error: invalid use of non-static data member '_bottom' DEFINE_PAD_MINUS_SIZE(0, DEFAULT_CACHE_LINE_SIZE, sizeof(_bottom)); ^~~~~~~ /usr/work/openjdk/nb/darwinintel64/nightly/jdk11u-dev/src/hotspot/share/memory/padded.hpp:87:44: note: expanded from macro 'DEFINE_PAD_MINUS_SIZE' char _pad_buf##id[(alignment) - (size)] ^~~~ In file included from /usr/work/openjdk/nb/darwinintel64/nightly/jdk11u-dev/src/hotspot/share/gc/parallel/asPSYoungGen.cpp:29: In file included from /usr/work/openjdk/nb/darwinintel64/nightly/jdk11u-dev/src/hotspot/share/gc/parallel/psScavenge.inline.hpp:29: In file included from /usr/work/openjdk/nb/darwinintel64/nightly/jdk11u-dev/src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp:32: In file included from /usr/work/openjdk/nb/darwinintel64/nightly/jdk11u-dev/src/hotspot/share/gc/parallel/psPromotionManager.hpp:32: /usr/work/openjdk/nb/darwinintel64/nightly/jdk11u-dev/src/hotspot/share/gc/shared/taskqueue.hpp:257:42: error: 'Age' is a protected member of 'TaskQueueSuper<131072, MemoryType::mtGC>' if test `/usr/bin/wc -l < /usr/work/openjdk/nb/darwinintel64/nightly/output-jdk11-dev-fastdebug/make-support/failure-logs/hotspot_variant-server_libjvm_objs_asPSYoungGen.o.log` -gt 15; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "\n* All command lines available in /usr/work/openjdk/nb/darwinintel64/nightly/output-jdk11-dev-fastdebug/make-support/failure-logs.\n" * All command lines available in /usr/work/openjdk/nb/darwinintel64/nightly/output-jdk11-dev-fastdebug/make-support/failure-logs. Do you have a mac for testing at hand? Else I can have a look later on, currently I'm busy with a bug in 15... Best regards, Goetz. From: Patrick Zhang OS Sent: Monday, June 29, 2020 11:39 AM To: Lindenmaier, Goetz ; Langer, Christoph ; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Hi Goetz and Christoph, Thanks for reviewing. I updated the copyright year and summary line accordingly: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.03/jdk11u-dev.changeset. Very appreciate if any committer could do me a favor and help pushing it. Regards Patrick From: Lindenmaier, Goetz > Sent: Monday, June 29, 2020 4:20 PM To: Patrick Zhang OS >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Hi Patrick, The change looks good now. Please remove the "Summary:" line. It only repeats the bug title, and thus is redundant. You can use the Summary line if you want to add more than the bug title. You might add "Summary: This is a downport of a part of JDK-8243326" Also, the Bugid in the mail Subject is wrong ... But no matter, it's all set now. [Patrick Zhang] sorry about the typos there, I could not 'fix' as it would get a new thread in mail list... Best regards, Goetz. From: Patrick Zhang OS > Sent: Saturday, June 27, 2020 11:33 AM To: Lindenmaier, Goetz >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Thanks Goetz I updated the of reviewers, http://cr.openjdk.java.net/~qpzhang/8248214/webrev.02/jdk11u-dev.changeset. Regarding the performance, I had tests on Linux system with a couple of x86_64/aarch64 servers, I am not sure if mentioning specjbb here would be appropriate, by far, most results of this benchmark are positive especially the metrics sensitive to GC stability (G1 or ParallelGC), and no obvious change with others probably due to microarchitecture level differences in handling exclusive load/store. This is similar as the original patch [1]. Updated "Fix request (11u)" with a risk estimation of this downporting, see JBS [1] please. I am not familiar with the process of jdk-updates. Is it ok to push this downporting patch now? or I should still wait for maintainer's approval at JBS (jdk11u-fix-yes?). [1] https://bugs.openjdk.java.net/browse/JDK-8248214?focusedCommentId=14349531&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14349531 Regards Patrick -----Original Message----- From: Lindenmaier, Goetz > Sent: Friday, June 26, 2020 3:17 PM To: Patrick Zhang OS >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention Hi Patrick, I had a look at your change. I think it makes sense to bring this to 11, if there actually is the performance gain you mention. Reviewed. Please add in the "Fix request" comment in the JBS the risk of downporting this. And I think is should be "Fix request (11u)" because different people will review your fix request for 11 and 8. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Patrick Zhang OS > Sent: Wednesday, June 24, 2020 11:55 AM > To: jdk-updates-dev at openjdk.java.net > Cc: hotspot-gc-dev > > Subject: [DMARC FAILURE] [11u] RFR: 8244214: Add paddings for > TaskQueueSuper to reduce false-sharing cache contention > > Hi > > Could I ask for a review of this simple patch which takes a tiny part > from the original ticket JDK-8243326 [1]. The reason that I do not > want a full backport is, the majority of the patch at jdk/jdk [2] is > to clean up the volatile use and may be not very meaningful to 11u, > furthermore the context (dependencies on atomic.hpp refactor) is too > complicated to generate a clear backport (I tried, ~81 files need to be changed). > > The purpose of having this one-line change to 11u is, the two volatile > variables in TaskQueueSuper: _bottom, _age and corresponding atomic > operations upon, may cause severe cache contention inside GC with > larger number of threads, i.e., specified by -XX:ParallelGCThreads=##, > adding paddings (up to DEFAULT_CACHE_LINE_SIZE) in-between can reduce > the possibility of false-sharing cache contention. I do not need the > paddings before _bottom and after _age from the original patch [2], > because the instances of TaskQueueSuper are usually (always) allocated > in a set of queues, in which they are naturally separated. Please review, thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248214 > Webrev: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.01/ > Testing: tier1-2 pass with the patch, commercial benchmarks and small > C++ test cases (to simulate the data struct and work-stealing > algorithm atomics) validated the performance, no regression. > > By the way, I am going to request for 8u backport as well once 11u > would have it. > > [1] https://bugs.openjdk.java.net/browse/JDK-8243326 Cleanup use of > volatile in taskqueue code [2] > https://hg.openjdk.java.net/jdk/jdk/rev/252a1602b4c6 > > Regards > Patrick > From yan at azul.com Mon Jun 29 15:51:15 2020 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 29 Jun 2020 18:51:15 +0300 Subject: [13u notice] jdk13u closed Message-ID: Hi all, The tag jdk-13.0.4+6 was pushed. Master repository jdk13u is closed now until the July release. Note that there will be also security changes pushed for the release, in due time. Thank you! --yan From aph at redhat.com Mon Jun 29 16:03:38 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2020 17:03:38 +0100 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> Message-ID: <21a4c5b8-1358-b5d1-40dc-33289b3812ff@redhat.com> [broken header fixed] On 28/06/2020 15:22, Gil Tene wrote: > We simply don't have necessity behind the suggestion for adding a > brand new garbage collector to the upstream 11u distribution. We > have people who'd like to see it happen, and people who will agree > to deal with he issues that may arise and help fix them in future > updates. And we have multiple groups that are willing to run it > internally within their large organizations and self-support if > needed. But we don't have an external forcing event that says that > unless we do this we'll be causing tons of end-users to break or > start malfunctioning. So Gil, please help me out here. You ship a (very) heavily modified JDK11u in the shape of Zing to your customers, do you not? So you are presumably not opposed to diverging heavily from 11u as a matter of principle, and least not in your proprietary releases. Perhaps the argument is that the addition of Shenandoah to JDK 11 might have been appropriate had it happened in the past, but it is not appropriate now. Why does that make sense? Is it simply that there has been more time for things in Zing to bake; but some downstream distros have been shipping Shenandoah-ified versions of JDK11u for an considerable time now, so it can't be that. Or is it that it's OK for downstream distributors of JDK11u to modify them heavily, but not JDK11u itself, (presumably) because it has more users than any of them? Or is it that all changes to JDK11u are in-principle bad, regardless of their actual risk, which we should not consider? That possibility seems a little odd. Given that most of your post is couched in terms of risk, to say that we shouldn't strive to evaluate that risk would be downright irrational. -- 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 goetz.lindenmaier at sap.com Mon Jun 29 16:26:03 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Jun 2020 16:26:03 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- Hi Patrick, If you use sizeof(uint) it works on mac. Uint is also the term jdk/jdk uses here. I put it into our CI again to make sure all platforms build. I'll update you tomorrow (or ping me if I forget). Also I think we should move the line below the declaration of _bottom, as it now depends on the type used there. Best regards, Goetz. diff --git a/src/hotspot/share/gc/shared/taskqueue.hpp b/src/hotspot/share/gc/shared/taskqueue.hpp --- a/src/hotspot/share/gc/shared/taskqueue.hpp +++ b/src/hotspot/share/gc/shared/taskqueue.hpp @@ -113,6 +113,8 @@ // The first free element after the last one pushed (mod N). volatile uint _bottom; + // Add paddings to reduce false-sharing cache contention between _bottom and _age + DEFINE_PAD_MINUS_SIZE(0, DEFAULT_CACHE_LINE_SIZE, sizeof(uint)); enum { MOD_N_MASK = N - 1 }; From: Patrick Zhang OS Sent: Saturday, June 27, 2020 11:33 AM To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Thanks Goetz I updated the of reviewers, http://cr.openjdk.java.net/~qpzhang/8248214/webrev.02/jdk11u-dev.changeset. Regarding the performance, I had tests on Linux system with a couple of x86_64/aarch64 servers, I am not sure if mentioning specjbb here would be appropriate, by far, most results of this benchmark are positive especially the metrics sensitive to GC stability (G1 or ParallelGC), and no obvious change with others probably due to microarchitecture level differences in handling exclusive load/store. This is similar as the original patch [1]. Updated "Fix request (11u)" with a risk estimation of this downporting, see JBS [1] please. I am not familiar with the process of jdk-updates. Is it ok to push this downporting patch now? or I should still wait for maintainer's approval at JBS (jdk11u-fix-yes?). [1] https://bugs.openjdk.java.net/browse/JDK-8248214?focusedCommentId=14349531&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14349531 Regards Patrick -----Original Message----- From: Lindenmaier, Goetz > Sent: Friday, June 26, 2020 3:17 PM To: Patrick Zhang OS >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention Hi Patrick, I had a look at your change. I think it makes sense to bring this to 11, if there actually is the performance gain you mention. Reviewed. Please add in the "Fix request" comment in the JBS the risk of downporting this. And I think is should be "Fix request (11u)" because different people will review your fix request for 11 and 8. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Patrick Zhang OS > Sent: Wednesday, June 24, 2020 11:55 AM > To: jdk-updates-dev at openjdk.java.net > Cc: hotspot-gc-dev > > Subject: [DMARC FAILURE] [11u] RFR: 8244214: Add paddings for > TaskQueueSuper to reduce false-sharing cache contention > > Hi > > Could I ask for a review of this simple patch which takes a tiny part > from the original ticket JDK-8243326 [1]. The reason that I do not > want a full backport is, the majority of the patch at jdk/jdk [2] is > to clean up the volatile use and may be not very meaningful to 11u, > furthermore the context (dependencies on atomic.hpp refactor) is too > complicated to generate a clear backport (I tried, ~81 files need to be changed). > > The purpose of having this one-line change to 11u is, the two volatile > variables in TaskQueueSuper: _bottom, _age and corresponding atomic > operations upon, may cause severe cache contention inside GC with > larger number of threads, i.e., specified by -XX:ParallelGCThreads=##, > adding paddings (up to DEFAULT_CACHE_LINE_SIZE) in-between can reduce > the possibility of false-sharing cache contention. I do not need the > paddings before _bottom and after _age from the original patch [2], > because the instances of TaskQueueSuper are usually (always) allocated > in a set of queues, in which they are naturally separated. Please review, thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248214 > Webrev: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.01/ > Testing: tier1-2 pass with the patch, commercial benchmarks and small > C++ test cases (to simulate the data struct and work-stealing > algorithm atomics) validated the performance, no regression. > > By the way, I am going to request for 8u backport as well once 11u > would have it. > > [1] https://bugs.openjdk.java.net/browse/JDK-8243326 Cleanup use of > volatile in taskqueue code [2] > https://hg.openjdk.java.net/jdk/jdk/rev/252a1602b4c6 > > Regards > Patrick > From gil at azul.com Mon Jun 29 16:38:18 2020 From: gil at azul.com (Gil Tene) Date: Mon, 29 Jun 2020 16:38:18 +0000 Subject: ... In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> Message-ID: <1551271D-7BEB-4CE2-A432-A2C62A813143@azul.com> > On Jun 29, 2020, at 2:42 AM, Andrew Haley wrote: > > On 28/06/2020 15:22, Gil Tene wrote: > >> We simply don't have necessity behind the suggestion for adding a >> brand new garbage collector to the upstream 11u distribution. We >> have people who'd like to see it happen, and people who will agree >> to deal with he issues that may arise and help fix them in future >> updates. And we have multiple groups that are willing to run it >> internally within their large organizations and self-support if >> needed. But we don't have an external forcing event that says that >> unless we do this we'll be causing tons of end-users to break or >> start malfunctioning. > > So Gil, please help me out here. You ship a (very) heavily modified > JDK11u in the shape of Zing to your customers, do you not? Yes. And you ship a (very) heavily modified JDK11u in the shape of the RedHat build of OpenJDK to your customers, with similar differences. That's why we cooperate here, in the upstream place where the various downstream distro build and maintain the common ground. > So you are > presumably not opposed to diverging heavily from 11u as a matter of > principle, and least not in your proprietary releases. Right. And not in your proprietary ones either. I'm in no way saying that downstream distros should all be identical to the upstream (I do often, elsewhere, say that they should be at least up to date in fixes and security updates for the same reported update level version, but that's a different matter). > > Perhaps the argument is that the addition of Shenandoah to JDK 11 > might have been appropriate had it happened in the past, but it is not > appropriate now. It would absolutely have been appropriate to put it into 11u before the first 11 GA. Just like it was absolutely appropriate to put into the 12 GA, and why it is part of 13u, will be part of 15u, and will be in the 17u LTS. > Why does that make sense? Is it simply that there > has been more time for things in Zing to bake; but some downstream > distros have been shipping Shenandoah-ified versions of JDK11u for an > considerable time now, so it can't be that. > > Or is it that it's OK for downstream distributors of JDK11u to modify > them heavily, but not JDK11u itself, (presumably) because it has more > users than any of them? Sort of, but not because it has more users. It's because it forces all downstream (and hence ALL users) to do something they are not choosing, anbd that many of them would not choose if they had a choice. People choose their downstream distros. But when they need to run Java 11 code, their choices are pretty the Oracle JDK or a one of the various downstream-from-OpenJDK-11u distros. An 11u upstream change is a forced change for all OpenJDK users. If C4 [which has been "baking" in production use for nearly a decade] or other Zing features were added to OpenJDK tomorrow, I would not be advocating for including them or backporting them to the 8u or 11u upstream LTS code that every downstream distro syncs up with. It would go into some future version before the first GA date for that version. > > Or is it that all changes to JDK11u are in-principle bad, regardless > of their actual risk, which we should not consider? All feature additions in updates for an already released version (as opposed to bug fixes and security updates, which those updates are the vehicle for) are in-principle bad IMO. Sometimes we have to do the bad thing because it is less bad than the alternative (the LTS will break for many people if we don't do it). But it is still bad. > That possibility > seems a little odd. Given that most of your post is couched in terms > of risk, to say that we shouldn't strive to evaluate that risk would > be downright irrational. The weighing of risk for adding a feature in a new OpenJDK version should be very different from the weighing of the same in an update to an existing version. When we add features to new versions (which we now get to do every six months), we don't risk regressing production behavior of people that depend on security updates to keep operating. We then consider the risk in terms of "will this impact adoption rate or make us look bad", and the benefits can be weighed against that risk. That's where the benefits of new features often get to win, and we can choose ways to minimize risk to help them win. In contrast, when we consider adding features in an updates for an existing version (which will be forced on all production users that need to keep up with security, for example), the benefit of a new (did not previously exist in that Java version) feature should simply not be part of the equation unless it meets a base "necessity" requirement. Without meeting that requirement, it should score a 0 on weight IMO. Necessity has to do with fixing broken things, or preventing things from breaking. Not working on some new piece of hardware or a new version of OSs counts as "breaking" IMO, and security, correctness, and stability bugs do to. Even some seriously degenerate performance issues may be (although performance 2+ years into a release should not be something we should be working on improving within that release). > > -- > 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 szegedia at gmail.com Mon Jun 29 16:55:02 2020 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 29 Jun 2020 18:55:02 +0200 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> Message-ID: I agree with everything Gil said and want to provide some additional perspective as a current operator of business-critical infrastructure relying on Java. TL;DR: I?m currently operating a largeish cluster of machines running Java 11. I definitely wouldn't appreciate 11 acquiring new major features, flag-activated or not. I find it natural that if we want new features, we need to migrate to a new feature release of Java. Longer version: At my current job we transitioned from using Java 8 to Java 11 as our runtime maybe about a year ago. As expected, there were some minor adjustments to make, mostly due to some 3rd party libraries? use of unsafe features or unwanted interference with the module system. So, we?re currently _mostly_ happy campers on Java 11. We?d like to try the new low-latency GCs though, both ZGC and Shenandoah (enable both of them in our cluster of many identical nodes all running the same code) and see which one does better for our workloads. The logical way to do this for us in our mind was always to switch to Java 14. I never would consider having a ?Java 11, but with Shenandoah? for this purpose. We understand that LTS is there for stability, and if we want new features, well? that?s what feature releases are for. ?Hiding behind a flag? is also an irrelevant argument. Integration of a new GC algorithm is almost always a change that requires all kinds of plumbing changes to other parts of the runtime and those will be in active code paths, flag or not. As a closing opinionated thought, I think the OpenJDK developer community developed (hah) a quite severe feature-backporting habit mostly out of difficulties of making the Java 8-to-9 barrier with its introduction of modules, so Java 8 became a prime backporting target. It seems that habit, once established, now extends to 11 as well. I also believe this habit is misguided; there?s simply no similar technical hurdle upgrading from 11 to, say, 14 as there was from 8 to 9. (Well, I will allow that it is possible I am not aware of some issue that makes it hard.) I know some people get cold feet thinking of Oracle?s licensing terms for non-LTS versions feeling that forces them into lockstep upgrades if they adopt a non-LTS version at any given time, but that?s not much of an issue either as nowadays you don?t have to use Oracle distributions of Java and there?s plenty of quality alternative OpenJDK-based distributions that don?t come with these licensing terms attached. Attila. > On 2020. Jun 28., at 16:22, Gil Tene wrote: > > > >> On Jun 27, 2020, at 12:50 AM, Roman Kennke wrote: >> >> Hi Gil, >> >> I understand your concerns. >> >> I wouldn't propose this if Shenandoah was actually an >> experimental/playground feature. The contrary is the case - it is very >> solid and ready for production use (and infact *in* production use by >> Red Hat customers and others). It has received tons of testing by us >> and others. > > I am in no way challenging or debating the effort and testing put into it, > or the good practices and experience built up. I'm pointing out that > such major features should simply not be added to a stable LTS release. > > The "playground" comment is not about the maturity of the feature being > proposed. It is about the maturity of the release it is being proposed for. > Adding features to a stable LTS train without a forcing necessity is > the "treating it as a playground" I was talking about. > > I know a whole bunch of OpenJDK developers here want this. And a lot > of external people that like to work and play with leading edge stuff want > it (on 11u) too. And I don't doubt that there are tens of thousands of people > that would be happy to see it added. > > I'm pointing out that there will be (literally) Millions of people affected > who do not share this view, are not here on these lists speaking out > about it, and for whom 11u LTS builds are a critical infrastructure > competent where stability matters most. Those are the people who > expect LTS releases to only have bug fixes and security updates applied. > They represent the vast majority of production consumption of LTS builds. > > And yes, we occasionally have to go beyond bug fixes and security > updates, and add significant features that did not previously exist in > that LTS version of Java or OpenJDK in any previous form. When > we (very reluctantly) do that, it needs to be as a result of necessity. > > IMO the trigger we should be looking at as we gauge necessity is > "If we don't do this, the LTS will likely break in some way, and many > (Millions?) will be affected" > > A current gut-wrenching example of necessity is TLS 1.3 support in > OpenJDK 8u: Java 8 will need to live long past the point where > TLS 1.2 may be disallowed by some organizations, and the pressure > is already beginning to show. Adding TLS 1.3 to Java 8 is an unavoidable > necessity. The Java SE 8 spec was modified to enable TLS 1.3 support, > and the externally-driven need is pretty clear. OpenJDK 8u cannot stay > behind on this. So this qualifies. If we don't do this, OpenJDK 8u will > break. Millions will be negatively affected. > > A smaller example was the addition of container resource limit awareness > in 8u192. The emergence of containers as common deployment > environments and the friction between the JDK behavior and resource > limit enforcement (throttling/thrashing, OOM killing) created painful enough > situations that it was necessary to add a feature to the JDK implementation > to allow it to live in acceptable ways in modern hardware deployments. > So this one qualified too: If it were not done, 8u would have remained > broken on container environments. Millions would have been negatively > affected. > > We simply don't have necessity behind the suggestion for adding > a brand new garbage collector to the upstream 11u distribution. We have > people who'd like to see it happen, and people who will agree to deal with > he issues that may arise and help fix them in future updates. And we have > multiple groups that are willing to run it internally within their large > organizations and self-support if needed. But we don't have an external > forcing event that says that unless we do this we'll be causing tons of > end-users to break or start malfunctioning. > > [And yes, I'm sure some examples of unnecessary things added > mid-life of a stable release in the past can be dug up. Nothing is pure > in the past. But I doubt anything like "add a new collector to the mature > upstream production release" can be found int the last 10 or so years] > >> >> If a downstream vendor doesn't want to ship it, it is easily solved by >> --with-jvm-features=-shenandoahgc. As I mentioned in my original email, >> we make sure that we exclude Shenandoah-added code using #ifdef >> INCLUDE_SHENANDOAHGC whereever reasonably possible. It doesn't zero the >> risk, but it brings it pretty close. > > This is not about how carefully this is applied, or how much "this shouldn't > break anything, by design, really, and we tested it a lot" we can point to. > > The best way to not break things is to not change them, Every experienced > IT operator knows this instinctively, and a huge % of those choose to only use > LTS versions (and wait 1+ years for them to stabilize before doing so) > for that very reason. Those people represent a huge portion of the > "customer" consuming the 11u updates this project builds. > > Just imagine trying to explain this to a room full of SREs or sysadmins, > trying to think of a comeback to "Wait! So you are saying that I can't get > security updates for 11u any more without accepting that they come with > the code changes you made for adding in a brand new garbage collector?" > > A "we worked hard to minimize actual code change wherever reasonably > possible" answer will not fly in that room. > >> >> I don't think a downstream jdk11+ or so project/repository would be all >> that useful. I don't see many other such features to go into jdk11u, so >> it might well be a Shenandoah-only thing - which we already have in the >> form of shenandoah/jdk11 repository, which is very well maintained >> downstream from jdk11u + Shenandoah. > > I think this is one (big) example, and that we will likely face more of the same > choices due to similar motivations in the years ahead, with useful features > big and small looking to be back-ported, and with those wishes hitting > against the primary purpose of an upstream LTS, and against it's main mission > and useful role for the vast majority of downstream consumers. > > I actually do think (and like) the idea of a downstream-from-11u thing that > can take on new features can work (hotspot-expres-like or not). I would be > interested in collaborating on such a thing, and think that it will have many > interested consumers. And there are several interesting improvements I would > like to see added to an 11u-that-takes-on-new-feature thing if such a delivery > vehicle was available. But I obviously don't think that thing and the upstream > stable 11u that is all other 11u's update from should be conflated. > >> >> If our current backporting practice is a concern I could offer to >> tighten it up and only backport critical bugfixes, no feature >> backports, no non-critical bugfixes, etc. > > This is a feature backport. What happens after is not the issue. And > it will be hard to argue for no additional increments after we add in an > entire new collector that didn't previously exist in the release. > >> >> That being said, I do understand your point. This is not about somehow >> making my (or Red Hat's) life easier (it wouldn't - backporting to >> jdk11u proper seems more bureaucratic than backporting to our own >> downstream repo). My intention was to avoid fragmentation between >> vendors. If we cannot get to an agreement here, I'd be fine to keep >> maintaining shenandoah/jdk11 as we already do, and suggest that vendors >> who want Shenandoah in their jdk11u builds to use that as a basis for >> their builds. > > That to me seems like the reasonable way to go, as long as no other > downstream-from-11u thing that is better (as in allows multiple of these > major feature backports to be consolidated togther) exists. > > Downstream distros that want Shenandoah can be downstream from > shenandoah/jdk11, as Red Hat [presumably] currently is. And those who > want both can do both. > >> *I* don't think that is the preferable solution. > > And clearly respectfully disagree with each other on that. > > I, for one, look forward to seeing the non-experimental Shenandoah > in 15u come out, and will work to get people to use 15u in production > as soon as possible (including making sure it keeps getting updated > long enough to last for 18 months past the first 17u release). IMO that > is the best path for driving new feature adoption. Unline in 11u, doing > fixes to Shenandoah on 15u as we keep 15u up to date with bug fixes > and security updates (including back-ports from later releases) will > make perfect sense, as it will not be a late added feature. >> >> Best regards, >> Roman >> >> >> >> On Fri, 2020-06-26 at 23:39 +0000, Gil Tene wrote: >>> As I noted before, we have serious reservations about adding major >>> new features to a >>> stable LTS that is upstream of all of 11u. Based on daily >>> interactions with tons of OpenJDK >>> end users, I can say that the vast majority of end users that are >>> ramping up on 11u are >>> demanding stability and maturity above all else. The addition of such >>> major changes in >>> an 11u update will cause many of them to stall updates, and >>> potentially stall the uptake >>> of 11u altogether, waiting for 11u to actually stabilize first >>> (evidenced by no longer doing >>> such things), so they can keep up with fixes and security issues >>> without having to take on >>> potential regressions driven by late added or experimental features. >>> >>> If you want a modern GA'ed OpenJDK with all the latest features in >>> it, use one. Please >>> please please don't force people who choose to stick with a given >>> OpenJDK version for >>> stability, and knowingly did not move to a later OpenJDK version, to >>> deploy the newly >>> implemented features that you like by pushing for back-porting them >>> to the upstream >>> project that they get their security updates from... >>> >>> I can see a potentially good case for a downstream-from-11u project >>> that incorporates >>> ongoing development (as opposed to bug fixes) from later upstream >>> versions, and would >>> be happy to collaborate on one. But the 11u that is upstream of all >>> other 11u's should not >>> be seen as a developer's playground, or a place to add cool new >>> features to a stable >>> release. The upstream versions are there for that purpose. The valid >>> interests of >>> deep-bench, self-supporting groups making use of OpenJDK, who can >>> take on the stability >>> risks involved due to the depth of their technical bench, should not >>> overcome the interests >>> of the millions of consumers of the 11u builds that do not have that >>> luxury, and who >>> need and expect stable (in the changing only where necessary sense) >>> 11u releases. >>> >>> I'd like to point out that 13u already includes Shenandoah. 15u >>> (expected in 3 months) >>> already includes Shenandoah as a non-experimental feature. And we can >>> all collaborate >>> on back-porting bug-fixes to those to updates to keep a lively >>> version of OpenJDK that >>> includes Shenandoah up to date from a bug fix and security update >>> point of view. For >>> those insisting on waiting for an LTS (on the assumption that LTSs >>> are long term stable >>> and don't get those sort of messing-with-after-the-fact done to them, >>> mind you), 17u will >>> be out in 15 months. >>> >>> So we are not talking about some far-away future for end users that >>> want Shenandoah. >>> It is here, now, in multiple consumable forms, and available for >>> people not looking for >>> the stability of an LTS, and even for people who do (as they can use >>> the Red Hat 11u >>> builds). It it will be available in more forms very soon with no >>> effort, and we don't have >>> to destabilize 11u for others to make that happen. >>> >>> ? Gil. > From aph at redhat.com Mon Jun 29 17:10:43 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2020 18:10:43 +0100 Subject: ... In-Reply-To: <1551271D-7BEB-4CE2-A432-A2C62A813143@azul.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> <1551271D-7BEB-4CE2-A432-A2C62A813143@azul.com> Message-ID: <8bccbed2-0d9a-b198-1366-4b66a2ca5446@redhat.com> On 29/06/2020 17:38, Gil Tene wrote: >> Or is it that all changes to JDK11u are in-principle bad, regardless >> of their actual risk, which we should not consider? > > All feature additions in updates for an already released version (as > opposed to bug fixes and security updates, which those updates > are the vehicle for) are in-principle bad IMO. Sometimes we have to > do the bad thing because it is less bad than the alternative (the LTS > will break for many people if we don't do it). But it is still bad. OK, so that is your position, and the in-principle argument is AFAICS independent of the practical risk. >> That possibility seems a little odd. Given that most of your post >> is couched in terms of risk, to say that we shouldn't strive to >> evaluate that risk would be downright irrational. > > The weighing of risk for adding a feature in a new OpenJDK version > should be very different from the weighing of the same in an update > to an existing version. No question. > When we add features to new versions (which we now get to do every > six months), we don't risk regressing production behavior of people > that depend on security updates to keep operating. We then consider > the risk in terms of "will this impact adoption rate or make us look > bad", and the benefits can be weighed against that risk. That's > where the benefits of new features often get to win, and we can > choose ways to minimize risk to help them win. I agree. The benefits can be weighed against that risk. > In contrast, when we consider adding features in an updates for an > existing version (which will be forced on all production users that > need to keep up with security, for example), the benefit of a new > (did not previously exist in that Java version) feature should > simply not be part of the equation unless it meets a base > "necessity" requirement. Without meeting that requirement, it > should score a 0 on weight IMO. That fits with my understanding of your position: no matter how helpful a feature is, or how low the risk of adding it is, it should not happen. So, your conclusion is *entirely independent* of the actual ratio of risk to reward. No evaluation of either is necessary because the conclusion will always be the same: no. I hope that you will agree that your position on this matter is an extreme one; in fact is the most extreme position it is possible for anyone to take. You also know that this is not the position taken by the whole community. > Necessity has to do with fixing broken things, or preventing things > from breaking. Not working on some new piece of hardware or a new > version of OSs counts as "breaking" IMO, and security, correctness, > and stability bugs do to. Even some seriously degenerate performance > issues may be (although performance 2+ years into a release should > not be something we should be working on improving within that > release). Please allow me to suggest a little thought experiment. Let's say that we could import Feature X (which is Shenandoah, but I'd like to do make this discussion more general) without any risk. Sure, risk is never zero, but let's say: 1. All changes to the source code are surrounded by compile-time #if USE_SHENANDOAH_GC. 2. USE_SHENANDOAH_GC is never set unless it is explicitly requested by a configure argument. 3. All changes to the source code within the USE_SHENANDOAH_GC markers are also guarded by runtime tests of the form if (UseShenandoahGC) { ... I maintain that no-one will ever be forced to use X. Firstly, no downstream builder of our release JDK 11u will even build X unless they explicitly choose to. Also, unless UseShenandoahGC is enabled on the Java command line, no downstream user will be forced to use it either. What, in your opinion, are the practical risks to production users of the above? I'm assuming that we can confirm that the above plan works and does not touch anything it shouldn't by a combination of tooling and several sets of eyeballs. That's not perfect, but nothing is. -- 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 goetz.lindenmaier at sap.com Mon Jun 29 17:32:50 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Jun 2020 17:32:50 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Message-ID: Hi, Christoph and I sent several replies to this mail. For some reason they are not delivered to the archives. I get them back with security scan issues ... So I write a clean answer here, maybe this works: We saw build problems on mac. It does not like sizeof(_bottom). If I use sizeof(uint) it works on mac. Uint is also the term jdk/jdk uses here. I put it into our CI again to make sure all platforms build. I'll update you tomorrow if it worked. Also I think we should move the line up, just below the declaration of _bottom, as it now depends on the type used there. Patrick, the bug id in the subject of this mail is wrong. I kept the wrong one in this answer so the mail thread does not break. Also, please remove the "Summary:" line in webrev.02. It only repeats the bug title, and thus is redundant. You can use the Summary line if you want to add more than the bug title. You might add "Summary: This is a downport of a part of JDK-8243326" Best regards, Goetz. Best regards, Goetz. From aph at redhat.com Mon Jun 29 17:33:41 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2020 18:33:41 +0100 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> Message-ID: <3a340751-987e-9fd4-fa33-8c873a18980b@redhat.com> On 29/06/2020 17:55, Attila Szegedi wrote: > I agree with everything Gil said and want to provide some additional perspective as a current operator of business-critical infrastructure relying on Java. > > TL;DR: > > I?m currently operating a largeish cluster of machines running Java > 11. I definitely wouldn't appreciate 11 acquiring new major > features, flag-activated or not. I find it natural that if we want > new features, we need to migrate to a new feature release of Java. OK. See my reply to Gil; please feel free to reply to it too, if you like. > As a closing opinionated thought, I think the OpenJDK developer > community developed (hah) a quite severe feature-backporting habit > mostly out of difficulties of making the Java 8-to-9 barrier with > its introduction of modules, so Java 8 became a prime backporting > target. It seems that habit, once established, now extends to 11 as > well. I also believe this habit is misguided; there?s simply no > similar technical hurdle upgrading from 11 to, say, 14 as there was > from 8 to 9. (Well, I will allow that it is possible I am not aware > of some issue that makes it hard.) Sure, and I don't disagree, but my job isn't to try to persuade users to adopt new Java versions, it's to provide them with the best free JDK 11. Shenandoah solves a real-world problem that people encounter in production. -- 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 goetz.lindenmaier at sap.com Mon Jun 29 18:29:55 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Jun 2020 18:29:55 +0000 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> Message-ID: Hi, We as SAP would not object against this change. Several reasons: 1. I had a look at the shared changes. If this is all, it is very unlikely that this change breaks the current configuration of jdk11u. Nice job of bringing this to 11. 2. In the past, the VMs got a lot of new features in hotspot every half year. This worked, too. We even delivered Java 4-7 with hotspot of 8, without breaking our huge software stack. Yes, there were errors, but much more were solved by this approach. 3. My experience is that it is much harder to move software to new Java versions than to bring a feature to an older VM. We have lots of software running where the development teams are almost gone. But the maintainers of the VM on SAP side, and the operators of the software at customer side, are still there. These are the ones that have to deal with the bugs introduced by the downport. These are also the ones whose problems are solved by a better GC. The application developers would have to deal with bringing the software to new Java versions, but they are no more available. Naturally, this does not hold for features that break compatibility of the libraries or the language. But please configure the build so that Shenandoah is not built per default. See make/autoconf/hotspot.m4. Shenandoah could be enabled later, but at first I would prefer if it is not compiled into everybodys binary. Best regards, Goetz. PS: I hope this mail gets delivered to the list, a row of my mails today didn't make it there. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Roman Kennke > Sent: Thursday, June 25, 2020 1:16 PM > To: jdk-updates-dev at openjdk.java.net > Subject: Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u > > I would like to revive this RFR, I believe we haven't come to a > conclusion yet. I still think it would be very useful to have the > Shenandoah GC included in jdk11u upstream. I have heard from several > vendors who would like to ship Shenandoah, but maintaining the rather > huge Shenandoah backport patch is an absolute no-go. > > This is an updated patch that includes numerous bugfixes and > improvements in Shenandoah. It is what Red Hat is going to ship in > their 11.0.8 release. > > Full webrev: > https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u- > upstream/webrev.04-all/ > > Webrev only for shared-code changes: > https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u- > upstream/webrev.04-shared/ > > Please let me know what you think. > > Roman > > > On Fri, 2020-01-17 at 18:05 +0100, Roman Kennke wrote: > > Hello, > > > > The Shenandoah GC has been integrated into jdk12 a little over a year > > ago: > > > > http://hg.openjdk.java.net/jdk/jdk/rev/9c18c9d839d3 > > > > The Shenandoah team has been maintaining the Shenandoah-enabled > > jdk11u > > downstream repository since the inception of jdk11 under: > > > > http://hg.openjdk.java.net/shenandoah/jdk11 > > > > In order to make it more useful and accessible for users, we would > > like > > to make it available in upstream jdk11u. The Shenandoah team at Red > > Hat > > intends to maintain it the same way it had been maintained in > > shenandoah/jdk11, in the course of regular jdk11u maintenance Red Hat > > already does. > > > > Thanks to recent changes in Shenandoah over the last year, we are now > > able to fit the GC interface in jdk11 almost exactly. There are a few > > exceptions though. We tried to follow the following pattern for all > > shared-code changes where it made sense: > > > > #if INCLUDE_SHENANDOAH_GC > > if (UseShenandoahGC) { > > ... > > } > > #endif > > > > This ensures that the Shenandoah-specific changes are cut out of the > > build when building without Shenandoah, and avoid those code paths at > > runtime when running without Shenandoah. > > > > Also, there are a few places where this was not possible or where it > > didn't seem feasible, but we tried to keep them few and obvious. > > Whenever this is the case, we are mirroring as close as possible what > > we > > have in jdk/jdk. > > > > Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. Other > > architectures still build fine, and Shenandoah gets automatically > > disabled during configure if not supported. OS-wise, Shenandoah runs > > on > > Linux, Windows, and is known to run on MacOS X and Solaris too. > > > > I wasn't sure which form this should take. I decided to start with > > the > > easiest possible form this could take: a simple patch/webrev and an > > RFR. > > Let me know if you need a JIRA issue or any other formalities to > > track that. > > > > Full webrev: > > https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u- > upstream/webrev.02-all/ > > > > Webrev only for shared-code changes: > > https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u- > upstream/webrev.02-shared/ > > > > The webrevs are based on and depend on the arraycopy patch proposed > > for > > review here: > > > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > January/002396.html > > > > Testing: > > The code has been tested many many times, continuously while > > maintaining > > it. It has also served as the basis for RPMs and shipped to > > customers. > > We are running all sorts of tests of the hotspot/jtreg testsuite, in > > particular hotspot_gc_shenandoah, CTW tests, the regular tier* tests, > > several popular benchmarks (specjvm, specjbb on a regular basis), on > > a > > nightly basis. > > > > Please let me know what you think. > > > > Thanks, > > Roman > > > > > > > > > > > > > > From goetz.lindenmaier at sap.com Mon Jun 29 18:39:19 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Jun 2020 18:39:19 +0000 Subject: [11u] RFR: 8244241: Add paddings for TaskQueueSuper to reduce false-sharing cache contention Message-ID: Hi, Christoph and I sent several replies to this mail. For some reason they are not delivered to the archives. I get them back with security scan issues ... So I write a clean answer here, maybe this works: We saw build problems on mac. It does not like sizeof(_bottom). If I use sizeof(uint) it works on mac. Uint is also the term jdk/jdk uses here. I put it into our CI again to make sure all platforms build. I'll update you tomorrow if it worked. Also I think we should move the line up, just below the declaration of _bottom, as it now depends on the type used there. Patrick, the bug id in the subject of this mail is wrong. I kept the wrong one in this answer so the mail thread does not break. Also, please remove the "Summary:" line in webrev.02. It only repeats the bug title, and thus is redundant. You can use the Summary line if you want to add more than the bug title. You might add Summary: This is a downport of a part of JDK-8243326 Best regards, Goetz. From gil at azul.com Mon Jun 29 19:04:54 2020 From: gil at azul.com (Gil Tene) Date: Mon, 29 Jun 2020 19:04:54 +0000 Subject: ... In-Reply-To: <8bccbed2-0d9a-b198-1366-4b66a2ca5446@redhat.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> <1551271D-7BEB-4CE2-A432-A2C62A813143@azul.com> <8bccbed2-0d9a-b198-1366-4b66a2ca5446@redhat.com> Message-ID: <5DBDA26C-E160-4175-97F7-21CC7FEC0DD8@azul.com> > On Jun 29, 2020, at 10:10 AM, Andrew Haley wrote: > > On 29/06/2020 17:38, Gil Tene wrote: >>> Or is it that all changes to JDK11u are in-principle bad, regardless >>> of their actual risk, which we should not consider? >> >> All feature additions in updates for an already released version (as >> opposed to bug fixes and security updates, which those updates >> are the vehicle for) are in-principle bad IMO. Sometimes we have to >> do the bad thing because it is less bad than the alternative (the LTS >> will break for many people if we don't do it). But it is still bad. > > OK, so that is your position, and the in-principle argument is AFAICS > independent of the practical risk. Right. For non-neccesary *feature additions* to an existing LTS. > >>> That possibility seems a little odd. Given that most of your post >>> is couched in terms of risk, to say that we shouldn't strive to >>> evaluate that risk would be downright irrational. >> >> The weighing of risk for adding a feature in a new OpenJDK version >> should be very different from the weighing of the same in an update >> to an existing version. > > No question. > >> When we add features to new versions (which we now get to do every >> six months), we don't risk regressing production behavior of people >> that depend on security updates to keep operating. We then consider >> the risk in terms of "will this impact adoption rate or make us look >> bad", and the benefits can be weighed against that risk. That's >> where the benefits of new features often get to win, and we can >> choose ways to minimize risk to help them win. > > I agree. The benefits can be weighed against that risk. > >> In contrast, when we consider adding features in an updates for an >> existing version (which will be forced on all production users that >> need to keep up with security, for example), the benefit of a new >> (did not previously exist in that Java version) feature should >> simply not be part of the equation unless it meets a base >> "necessity" requirement. Without meeting that requirement, it >> should score a 0 on weight IMO. > > That fits with my understanding of your position: no matter how > helpful a feature is, or how low the risk of adding it is, it should > not happen. So, your conclusion is *entirely independent* of the > actual ratio of risk to reward. No evaluation of either is necessary > because the conclusion will always be the same: no. Exactly. For non-neccesary *feature additions* to an existing LTS. Necessity is a binary bar. One can argue that a new feature is necessary or not. But how risky adding that feature is should not play a part in that argument. Some features that are necessary may be so risky that we dare not do them. But the opposite should not be happening in stable release updates that people are forced to consume for security reasons. Not even if we are VERY tempted and see all sorts of cool benefits in a feature. > > I hope that you will agree that your position on this matter is an > extreme one; in fact is the most extreme position it is possible for > anyone to take. I disagree. I don't think this is an extreme position at all. In fact, I think it is quite mainstream, and represents the most common understanding of what stable releases are, and what most consumers of updates to such releases think is going on. When those consumers find that's not quite what's going on, we (all) get a lot of flak for doing active feature development on their precious parts of critical infrastructure that depend on stability above and security all else. Attila's sentiments are an example of that. > You also know that this is not the position taken by > the whole community. Obviously ;-) But I think that where you think the vast majority of the community sits on this position being "extreme" or the opposite being the extreme one depends on who you think the community is. This list tends to be dominated by developers of OpenJDK. I claim that our community (for the updates projects) is the *users* of OpenJDK. There is a 10,000:1 or higher ratio between the number of people in those groups. And the larger one tends to be [naturally] underrepresented here, and much much less active. But their interests and their dependence of what we do here is pretty critical. And our dependence on them for having a reason for having these updates projects is critical as well. > >> Necessity has to do with fixing broken things, or preventing things >> from breaking. Not working on some new piece of hardware or a new >> version of OSs counts as "breaking" IMO, and security, correctness, >> and stability bugs do to. Even some seriously degenerate performance >> issues may be (although performance 2+ years into a release should >> not be something we should be working on improving within that >> release). > > Please allow me to suggest a little thought experiment. > > Let's say that we could import Feature X (which is Shenandoah, but I'd > like to do make this discussion more general) without any risk. Sure, > risk is never zero, but let's say: > > 1. All changes to the source code are surrounded by compile-time > #if USE_SHENANDOAH_GC. > > 2. USE_SHENANDOAH_GC is never set unless it is explicitly requested by > a configure argument. > > 3. All changes to the source code within the USE_SHENANDOAH_GC markers > are also guarded by runtime tests of the form > if (UseShenandoahGC) { ... > > I maintain that no-one will ever be forced to use X. Firstly, no > downstream builder of our release JDK 11u will even build X unless > they explicitly choose to. Also, unless UseShenandoahGC is enabled on > the Java command line, no downstream user will be forced to use it > either. > > What, in your opinion, are the practical risks to production users of > the above? I'm assuming that we can confirm that the above plan works > and does not touch anything it shouldn't by a combination of tooling > and several sets of eyeballs. That's not perfect, but nothing is. Let me answer both in general, and then in the specific: General: First, my point i that the practical risk does not matter, as no necessity has been demonstrated or even argued for. And I claim that this is not an extreme position (and that if we want to label things as extreme, the opposite would be the extreme). Next, I'll certainly accept that with careful review of some things it is quite possible to keep risks very low. E.g. in cases where ALL code is protected by #ifdef the risk is somewhat mitigated. And that in cases where ALL non-ifdef-covered runtime flags protect code paths the risk mitigation is not quite as good, but stlll could be good. I'll even go farther and say that risk can (and should) be seriously reduced even when the above stated protections are not practical. Deep review (with an eye to minimizing risk around change, as opposed to the typical review that focuses on correctness, code structure, cleanliness, elegance, reuse, maintainability, etc.) is key to minimizing risk when risk HAS to be taken. And as you well know, we are going through that excercize right now with TLS1.3 in 8u. None of these are good enough to overcome the "no necessity" bar IMO, because how good and low risk a change is is irrelevant (in an LTS update) when it is unnecessary. Specific: The above two are generic policy approaches. When it comes to the specific case here (the addition of a new collector to 11u), which touches a huge number of source files, some of the above description only apply "whereever reasonably possible", and actual code changes to common paths that are not protected by #ifdefs avoided statically via launch time configuration flags exist (i.e. every dynamic execution of some common code is now goigg through different logic that is considering the configuration flags, or worse, common code changes exist where no conditionals are applied at all). That is not a subtle difference. With that said, this last argument is not a logic path I'm looking to go down, because I don't think the additional risk involved in something as big and as intrusive as adding Shenandoah actually matters here. I'd be making the same neccesity-based arguments for other features that don't share that level change and risk, so I don't want to rathole in discussing the specific code risks in this case. > > -- > 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 hohensee at amazon.com Mon Jun 29 20:46:38 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 29 Jun 2020 20:46:38 +0000 Subject: [11u] RFR: 8244719: CTW: C2 compilation fails with "assert(!VerifyHashTableKeys || _hash_lock == 0) failed: remove node from hash table before modifying it" Message-ID: <6DCA03CE-884E-494E-9704-06FC2E2D6666@amazon.com> Lgtm. Paul ?On 6/25/20, 12:33 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" wrote: Hi, I am downporting this for parity with 11.0.9-oracle. I had to adapt the bytecode version in the jasm file at line 26 to make it compile with 11. Test passes. http://cr.openjdk.java.net/~goetz/wr20/8244719-remove_from_hash-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8244719 https://hg.openjdk.java.net/jdk/jdk/rev/e8d34f3f6833 Best regards, Goetz From mathiske at amazon.com Mon Jun 29 21:56:19 2020 From: mathiske at amazon.com (Mathiske, Bernd) Date: Mon, 29 Jun 2020 21:56:19 +0000 Subject: ... In-Reply-To: <5DBDA26C-E160-4175-97F7-21CC7FEC0DD8@azul.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> <1551271D-7BEB-4CE2-A432-A2C62A813143@azul.com> <8bccbed2-0d9a-b198-1366-4b66a2ca5446@redhat.com> <5DBDA26C-E160-4175-97F7-21CC7FEC0DD8@azul.com> Message-ID: From what I read, there seems to be consensus that the risk of the proposed RFR is in fact minimal, assuming deep review and other careful measures, as for the JFR 8u backport. So we are focusing on the reward side. >> Necessity is a binary bar. Don?t we all always ask ?how necessary? or ?necessary for what?? Isn?t necessity simply a strong reading on the reward meter? And, indeed, we ask ?necessary for whom?. >> This list tends to be dominated by developers of OpenJDK. >> I claim that our community (for the updates projects) is the *users* of OpenJDK. The developer minority that is writing to each other here has significant exposure to user opinions and issues. Aren?t average and tail latencies wide-spread user pain points? Shouldn?t we proliferate concurrent GC to address that? And isn?t upgrading to another JDK release also a huge user pain point, at least for some users? See Goetz?s email for an existence proof, but there are many other cases in other companies. Isn?t sticking to LTS versions what users normally do? My experience is that, whether justified or not, most do just that. If you put these aspects together, the necessity to do something about Shenandoah sooner rather than later reveals itself. Individual examples of users to whom this does not apply do not change this. In fact, there are often enough good reasons to not use concurrent GC, depending on the use case. But without concurrent GC we have a serious gap in our ability to run latency-sensitive workloads right now, and we need to fix that. BTW, we were under the impression that Azul fully supports the idea of backporting Shenandoah. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009808.html Looking for preceding guidance on the matter, there is this email thread (spread over two months). https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-October/002053.html https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002075.html I heard that at the Committer?s Workshop session on update releases in February, there was consensus that ?features? should only be backported to an update release if they are already in use and maintained by at least two other major contributors to the updates project. Furthermore, at that point, it becomes a big waste of resources to stay in sync, and by definition there already is a support commitment. Regarding the RFR at hand, there is more than the necessary commitment in this very email thread. Bernd ?On 6/29/20, 12:05 PM, "Gil Tene" wrote: > On Jun 29, 2020, at 10:10 AM, Andrew Haley wrote: > > On 29/06/2020 17:38, Gil Tene wrote: >>> Or is it that all changes to JDK11u are in-principle bad, regardless >>> of their actual risk, which we should not consider? >> >> All feature additions in updates for an already released version (as >> opposed to bug fixes and security updates, which those updates >> are the vehicle for) are in-principle bad IMO. Sometimes we have to >> do the bad thing because it is less bad than the alternative (the LTS >> will break for many people if we don't do it). But it is still bad. > > OK, so that is your position, and the in-principle argument is AFAICS > independent of the practical risk. Right. For non-neccesary *feature additions* to an existing LTS. > >>> That possibility seems a little odd. Given that most of your post >>> is couched in terms of risk, to say that we shouldn't strive to >>> evaluate that risk would be downright irrational. >> >> The weighing of risk for adding a feature in a new OpenJDK version >> should be very different from the weighing of the same in an update >> to an existing version. > > No question. > >> When we add features to new versions (which we now get to do every >> six months), we don't risk regressing production behavior of people >> that depend on security updates to keep operating. We then consider >> the risk in terms of "will this impact adoption rate or make us look >> bad", and the benefits can be weighed against that risk. That's >> where the benefits of new features often get to win, and we can >> choose ways to minimize risk to help them win. > > I agree. The benefits can be weighed against that risk. > >> In contrast, when we consider adding features in an updates for an >> existing version (which will be forced on all production users that >> need to keep up with security, for example), the benefit of a new >> (did not previously exist in that Java version) feature should >> simply not be part of the equation unless it meets a base >> "necessity" requirement. Without meeting that requirement, it >> should score a 0 on weight IMO. > > That fits with my understanding of your position: no matter how > helpful a feature is, or how low the risk of adding it is, it should > not happen. So, your conclusion is *entirely independent* of the > actual ratio of risk to reward. No evaluation of either is necessary > because the conclusion will always be the same: no. Exactly. For non-neccesary *feature additions* to an existing LTS. Necessity is a binary bar. One can argue that a new feature is necessary or not. But how risky adding that feature is should not play a part in that argument. Some features that are necessary may be so risky that we dare not do them. But the opposite should not be happening in stable release updates that people are forced to consume for security reasons. Not even if we are VERY tempted and see all sorts of cool benefits in a feature. > > I hope that you will agree that your position on this matter is an > extreme one; in fact is the most extreme position it is possible for > anyone to take. I disagree. I don't think this is an extreme position at all. In fact, I think it is quite mainstream, and represents the most common understanding of what stable releases are, and what most consumers of updates to such releases think is going on. When those consumers find that's not quite what's going on, we (all) get a lot of flak for doing active feature development on their precious parts of critical infrastructure that depend on stability above and security all else. Attila's sentiments are an example of that. > You also know that this is not the position taken by > the whole community. Obviously ;-) But I think that where you think the vast majority of the community sits on this position being "extreme" or the opposite being the extreme one depends on who you think the community is. This list tends to be dominated by developers of OpenJDK. I claim that our community (for the updates projects) is the *users* of OpenJDK. There is a 10,000:1 or higher ratio between the number of people in those groups. And the larger one tends to be [naturally] underrepresented here, and much much less active. But their interests and their dependence of what we do here is pretty critical. And our dependence on them for having a reason for having these updates projects is critical as well. > >> Necessity has to do with fixing broken things, or preventing things >> from breaking. Not working on some new piece of hardware or a new >> version of OSs counts as "breaking" IMO, and security, correctness, >> and stability bugs do to. Even some seriously degenerate performance >> issues may be (although performance 2+ years into a release should >> not be something we should be working on improving within that >> release). > > Please allow me to suggest a little thought experiment. > > Let's say that we could import Feature X (which is Shenandoah, but I'd > like to do make this discussion more general) without any risk. Sure, > risk is never zero, but let's say: > > 1. All changes to the source code are surrounded by compile-time > #if USE_SHENANDOAH_GC. > > 2. USE_SHENANDOAH_GC is never set unless it is explicitly requested by > a configure argument. > > 3. All changes to the source code within the USE_SHENANDOAH_GC markers > are also guarded by runtime tests of the form > if (UseShenandoahGC) { ... > > I maintain that no-one will ever be forced to use X. Firstly, no > downstream builder of our release JDK 11u will even build X unless > they explicitly choose to. Also, unless UseShenandoahGC is enabled on > the Java command line, no downstream user will be forced to use it > either. > > What, in your opinion, are the practical risks to production users of > the above? I'm assuming that we can confirm that the above plan works > and does not touch anything it shouldn't by a combination of tooling > and several sets of eyeballs. That's not perfect, but nothing is. Let me answer both in general, and then in the specific: General: First, my point i that the practical risk does not matter, as no necessity has been demonstrated or even argued for. And I claim that this is not an extreme position (and that if we want to label things as extreme, the opposite would be the extreme). Next, I'll certainly accept that with careful review of some things it is quite possible to keep risks very low. E.g. in cases where ALL code is protected by #ifdef the risk is somewhat mitigated. And that in cases where ALL non-ifdef-covered runtime flags protect code paths the risk mitigation is not quite as good, but stlll could be good. I'll even go farther and say that risk can (and should) be seriously reduced even when the above stated protections are not practical. Deep review (with an eye to minimizing risk around change, as opposed to the typical review that focuses on correctness, code structure, cleanliness, elegance, reuse, maintainability, etc.) is key to minimizing risk when risk HAS to be taken. And as you well know, we are going through that excercize right now with TLS1.3 in 8u. None of these are good enough to overcome the "no necessity" bar IMO, because how good and low risk a change is is irrelevant (in an LTS update) when it is unnecessary. Specific: The above two are generic policy approaches. When it comes to the specific case here (the addition of a new collector to 11u), which touches a huge number of source files, some of the above description only apply "whereever reasonably possible", and actual code changes to common paths that are not protected by #ifdefs avoided statically via launch time configuration flags exist (i.e. every dynamic execution of some common code is now goigg through different logic that is considering the configuration flags, or worse, common code changes exist where no conditionals are applied at all). That is not a subtle difference. With that said, this last argument is not a logic path I'm looking to go down, because I don't think the additional risk involved in something as big and as intrusive as adding Shenandoah actually matters here. I'd be making the same neccesity-based arguments for other features that don't share that level change and risk, so I don't want to rathole in discussing the specific code risks in this case. > > -- > 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 gil at azul.com Tue Jun 30 03:00:57 2020 From: gil at azul.com (Gil Tene) Date: Tue, 30 Jun 2020 03:00:57 +0000 Subject: ... In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> <1551271D-7BEB-4CE2-A432-A2C62A813143@azul.com> <8bccbed2-0d9a-b198-1366-4b66a2ca5446@redhat.com> <5DBDA26C-E160-4175-97F7-21CC7FEC0DD8@azul.com> Message-ID: <32219A90-E722-43DF-863B-3EF3084DE8F7@azul.com> > On Jun 29, 2020, at 2:56 PM, Mathiske, Bernd > wrote: > > From what I read, there seems to be consensus that the risk of the proposed RFR is in fact minimal, No. Unless you consider "consensus" to not include my voice. Or e.g. Attila's. I consider the risk large. I concede that a lot of admirable work has been done to make it as small as possible given the magnitude of the change. But this is a huge change no matter how you look at it. With significant risk. > assuming deep review and other careful measures, as for the JFR 8u backport. So we are focusing on the reward side. Sure. Some are focusing on the reward. I argue the rewards doesn't matter in an already-out LTS. > >>> Necessity is a binary bar. > Don?t we all always ask ?how necessary? or ?necessary for what?? Isn?t necessity simply a strong reading on the reward meter? And, indeed, we ask ?necessary for whom?. True. The necessity and level of detail we are willing to go into when fixing crashing bugs can be argued too. But at least there we are fixing something that is actually broken. > >>> This list tends to be dominated by developers of OpenJDK. >>> I claim that our community (for the updates projects) is the *users* of OpenJDK. > > The developer minority that is writing to each other here has significant exposure to user opinions and issues. > > Aren?t average and tail latencies wide-spread user pain points? Not for stable production systems that are not looking for change, and just want to keep up with security issues and stability bugs. And that describes the vast majority of deployments of a stable LTS. Suffering existing unhappy metric behavior that has been there all along cannot be compared taking on regression in a stable production system. they don't live in the same operational realm. If the proposed features help with such unhappy pain points, users that look to address them and become happier can already do so by changing to new versions or switching to other distros within the same version that include the desired feature.. > Shouldn?t we proliferate concurrent GC to address that? And isn?t upgrading to another JDK release also a huge user pain point, at least for some users? OpenJDK users that expect stability and security updates have no other place to get them. Forcing all of them to accept the risk of changes to serve the wishes of people who do have plenty of other options (move to newer versions, move to other downstream distros that choose to add features) seems like an obvious wrong to me. There are downstream distros that are comfortable with feature differentiation and during-LTS changes that they can support and deal with. As you know, we (at Azul) are VERY comfortable running downstream distros with significant feature differences (e.g. Zing, where we use a hotspot-express-like model), and we are not alone in that: The Red Hat team is clearly comfortable with the same (to them and to their downstream users, this specific item is not a feature change, as they already ship with it). The Twitter team is clearly very comfortable doing that, and so is the DragonWell team. And the SAP team. And (I think) the Google team too. Each of these teams (and their downstream users) have chosen to take on the burden of feature improvements and changes and the risk involved,. It's their choice. But there are distros that do not aim for feature differentiation or rapid feature development, and simply focus of stability and keeping up with security updates, leaving new features to new versions of OpenJDK, and incorporating only things that are know to be either in the [same-version] upstream or expected to get there quite soon (and with high confidence). Our Zulu distro is one of those, and is massively used for that reason and purpose. AOJ seems to be another. And I can't speak for Liberica, but I suspect they are in this group as well. I'm not quite sure where to place Corretto, as I had expected it to fit in the latter group due to the public (non-Amazon-internal) consumption of the distro, But at least some of the Corretto team is obviously on the side of lets-add-features-to-the-LTS-if-they-are-interesting-enough, and perhaps the huge Amazon-internal use and exposure is what makes the team comfortable with that. For the downstream consumers of the "stay close to vanilla" distros, forcing a feature change in the middle of an LTS's life is counter to what the release (and the distro) they chose to use and stay with is all about. This upstream 11u project is where all these distros coordinate. It is the common denominator. It is where 11u gets stabilized and maintained. Not developed. And the needs of some of the distros require the common denominator of the LTS to not introduce new features without a driving necessity, not matter how cool. The users of those distros, IMO, represent the vast majority of actual production use of OpenJDK in the field. Cool new features simply don't belong in the stable, maintenance-mode upstream LTS updates. They belong in new OpoenJDK versions and in downstream distros willing (and who's users are willing) to accept the implications of during-LTS feature additions. Let's keep the common denominator common, simple, and boring. Arguing for "middle ground" between stability and innovation in an upstream place that is expected (by many of its downstream users) to be in stabilization and maintenance mode will create a a need for a different common place for stable distros who don't seek change. I truly believe that non of us want that. Some of us just seem to think that we can convince all other OpenJDK users to give up on the "stay boring" approach to stability and maintenance. And I'm just a stubborn voice reminding you that it's probably not our choice to make. > See Goetz?s email for an existence proof, but there are many other cases in other companies. Isn?t sticking to LTS versions what users normally do? My experience is that, whether justified or not, most do just that. If you put these aspects together, the necessity to do something about Shenandoah sooner rather than later reveals itself. Individual examples of users to whom this does not apply do not change this. In fact, there are often enough good reasons to not use concurrent GC, depending on the use case. But without concurrent GC we have a serious gap in our ability to run latency-sensitive workloads right now, and we need to fix that. > > BTW, we were under the impression that Azul fully supports the idea of backporting Shenandoah. > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009808.html As I noted elsewhere, to me this (including Aarch64 in 8u) fits as an example of the ?gut wrenching? necessary category, and IMO meets and passes the bar of "if we don't do this, the LTS will break and millions will be affected". As with my prior containers example in 8u192, the already-here approachability and affordability of Aarch64 cloud instances makes and already-here thing. And the clear and already-here-or-near-term-coming desktop Aarch64 wave is also a sign here. Backpoting the upstream MSFT contribution for Windows 10 Aarch64 targets to 8u and 11u will likely make sense for this reason. And Macs... > > Looking for preceding guidance on the matter, there is this email thread (spread over two months). > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-October/002053.html > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002075.html This is not a case of a feature addition. JFR was part of Java 8 from the start, as an integral part of the most common free Java 8 distro until sometime last year. It then was temporarily (and to many quite annoyingly) removed because it was just plain missing in OpenJDK 8u, making it harder to adopt for Oracle shops. Downstream 8u distros (like Zulu and Dragonwell) have closed that gap a long time ago in anticipation of eventual upstream merges, and the gap will finally be closed in 8u itself soon. > > I heard that at the Committer?s Workshop session on update releases in February, there was consensus that ?features? should only be backported to an update release if they are already in use and maintained by at least two other major contributors to the updates project. Again, that depends on what you call "consensus". The interests of the massive numbers of users of stable LTSs is not addressed by that sort of consensus. Having committed people able to readily and heroically fix problems that arise after the fact does nothing for the stability concerns of people who have to apply security updates but cannot afford the problems that invariably arise when innovation is allowed to be bundled with them. We had an unfortunate time overlap between two session at the Committer?s Workshop that dealt with the same high level problem in different ways. At the time this seaming consensus was being arrived at, I was in another room, presenting on the value of OpenJDK MTS update releases (13u, 15u, with continued bug fix and security updates until 18 months after the next LTS comes out) as a means for dealing with the very same need; enabling practical production adoption of new features; but without the need to accept feature backports into LTSs. ? Gil. > Furthermore, at that point, it becomes a big waste of resources to stay in sync, and by definition there already is a support commitment. Regarding the RFR at hand, there is more than the necessary commitment in this very email thread. > > Bernd From patrick at os.amperecomputing.com Tue Jun 30 03:40:56 2020 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Tue, 30 Jun 2020 03:40:56 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention In-Reply-To: References: Message-ID: Thanks for finding out it. I updated the patch: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.04/jdk11u-dev.changeset. Yes, jdk/jdk uses sizeof(uint), and placing the two variables side-by-side can remind people in case of type changes in future. I don't have mac system, so thanks a lot again for having it run in your CI. Regards Patrick From: Lindenmaier, Goetz Sent: Tuesday, June 30, 2020 12:26 AM To: Patrick Zhang OS ; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Hi Patrick, If you use sizeof(uint) it works on mac. Uint is also the term jdk/jdk uses here. I put it into our CI again to make sure all platforms build. I'll update you tomorrow (or ping me if I forget). Also I think we should move the line below the declaration of _bottom, as it now depends on the type used there. Best regards, Goetz. diff --git a/src/hotspot/share/gc/shared/taskqueue.hpp b/src/hotspot/share/gc/shared/taskqueue.hpp --- a/src/hotspot/share/gc/shared/taskqueue.hpp +++ b/src/hotspot/share/gc/shared/taskqueue.hpp @@ -113,6 +113,8 @@ // The first free element after the last one pushed (mod N). volatile uint _bottom; + // Add paddings to reduce false-sharing cache contention between _bottom and _age + DEFINE_PAD_MINUS_SIZE(0, DEFAULT_CACHE_LINE_SIZE, sizeof(uint)); enum { MOD_N_MASK = N - 1 }; From: Patrick Zhang OS > Sent: Saturday, June 27, 2020 11:33 AM To: Lindenmaier, Goetz >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Thanks Goetz I updated the of reviewers, http://cr.openjdk.java.net/~qpzhang/8248214/webrev.02/jdk11u-dev.changeset. Regarding the performance, I had tests on Linux system with a couple of x86_64/aarch64 servers, I am not sure if mentioning specjbb here would be appropriate, by far, most results of this benchmark are positive especially the metrics sensitive to GC stability (G1 or ParallelGC), and no obvious change with others probably due to microarchitecture level differences in handling exclusive load/store. This is similar as the original patch [1]. Updated "Fix request (11u)" with a risk estimation of this downporting, see JBS [1] please. I am not familiar with the process of jdk-updates. Is it ok to push this downporting patch now? or I should still wait for maintainer's approval at JBS (jdk11u-fix-yes?). [1] https://bugs.openjdk.java.net/browse/JDK-8248214?focusedCommentId=14349531&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14349531 Regards Patrick -----Original Message----- From: Lindenmaier, Goetz > Sent: Friday, June 26, 2020 3:17 PM To: Patrick Zhang OS >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention Hi Patrick, I had a look at your change. I think it makes sense to bring this to 11, if there actually is the performance gain you mention. Reviewed. Please add in the "Fix request" comment in the JBS the risk of downporting this. And I think is should be "Fix request (11u)" because different people will review your fix request for 11 and 8. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Patrick Zhang OS > Sent: Wednesday, June 24, 2020 11:55 AM > To: jdk-updates-dev at openjdk.java.net > Cc: hotspot-gc-dev > > Subject: [DMARC FAILURE] [11u] RFR: 8244214: Add paddings for > TaskQueueSuper to reduce false-sharing cache contention > > Hi > > Could I ask for a review of this simple patch which takes a tiny part > from the original ticket JDK-8243326 [1]. The reason that I do not > want a full backport is, the majority of the patch at jdk/jdk [2] is > to clean up the volatile use and may be not very meaningful to 11u, > furthermore the context (dependencies on atomic.hpp refactor) is too > complicated to generate a clear backport (I tried, ~81 files need to be changed). > > The purpose of having this one-line change to 11u is, the two volatile > variables in TaskQueueSuper: _bottom, _age and corresponding atomic > operations upon, may cause severe cache contention inside GC with > larger number of threads, i.e., specified by -XX:ParallelGCThreads=##, > adding paddings (up to DEFAULT_CACHE_LINE_SIZE) in-between can reduce > the possibility of false-sharing cache contention. I do not need the > paddings before _bottom and after _age from the original patch [2], > because the instances of TaskQueueSuper are usually (always) allocated > in a set of queues, in which they are naturally separated. Please review, thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248214 > Webrev: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.01/ > Testing: tier1-2 pass with the patch, commercial benchmarks and small > C++ test cases (to simulate the data struct and work-stealing > algorithm atomics) validated the performance, no regression. > > By the way, I am going to request for 8u backport as well once 11u > would have it. > > [1] https://bugs.openjdk.java.net/browse/JDK-8243326 Cleanup use of > volatile in taskqueue code [2] > https://hg.openjdk.java.net/jdk/jdk/rev/252a1602b4c6 > > Regards > Patrick > From rkennke at redhat.com Tue Jun 30 06:03:14 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 30 Jun 2020 08:03:14 +0200 Subject: ... In-Reply-To: <32219A90-E722-43DF-863B-3EF3084DE8F7@azul.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <6468CB08-3DB5-488E-9122-E3699A95218B@amazon.com> <7FDB6E37-E850-49DF-8255-059E7F9771C5@azul.com> <1551271D-7BEB-4CE2-A432-A2C62A813143@azul.com> <8bccbed2-0d9a-b198-1366-4b66a2ca5446@redhat.com> <5DBDA26C-E160-4175-97F7-21CC7FEC0DD8@azul.com> <32219A90-E722-43DF-863B-3EF3084DE8F7@azul.com> Message-ID: > > assuming deep review and other careful measures, as for the JFR 8u > > backport. So we are focusing on the reward side. > > Sure. Some are focusing on the reward. I argue the rewards doesn't > matter > in an already-out LTS. > How is the JFR backport any different, though? One major vendor included it in their commercial offering. Other vendors wanted to include it too, in an 8u LTS that was arguably much longer down the path of stabilization. There was nothing broken in OpenJDK 8u as it was, that needed fixing IMO. It would have been just as reasonable to tell users who want JFR in their JVM to use a later LTS instead. And it came with very considerable risks, I'd argue with much higher risk than adding Shenandoah, because it required hooks and changes all over the VM. Why is it treated different, then? What qualifies JFR as necessity that justifies taking such high risk in such a mature and stabilized release? Why didn't we have this discussion back then? > > BTW, we were under the impression that Azul fully supports the idea > > of backporting Shenandoah. > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009808.html > > As I noted elsewhere, to me this (including Aarch64 in 8u) fits as an > example of > the ?gut wrenching? necessary category, and IMO meets and passes the > bar of > "if we don't do this, the LTS will break and millions will be > affected". > The original email by Paul was about both Shenandoah and aarch64 (in 8u no less). The reply was that 'Azul supports this idea'. In-fact, two major vendors voicing their support for it was a primary motivator for me to come up with this RFR in the first place. Roman From matthias.baesken at sap.com Tue Jun 30 07:36:18 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 30 Jun 2020 07:36:18 +0000 Subject: RFR [jdk11]: 8212200: assert(on_stack()) failed when shared java.lang.object is redefined by JVMTI agent Message-ID: Hello, please review the jdk11 backport of 8212200 . I had to do a few slight adjustments to adjust the src changes of 8212200 to jdk11 . The test ( test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java.) from the original jdk/jdk webrev of 8212200 did not work. So I had to include adjustments from 8221918 and 8213275 to fix the test . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8212200 http://cr.openjdk.java.net/~mbaesken/webrevs/8212200.0/ Original jdk/jdk webrev : http://hg.openjdk.java.net/jdk/jdk/rev/625f6c742392 Thanks, Matthias From goetz.lindenmaier at sap.com Tue Jun 30 07:45:47 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 30 Jun 2020 07:45:47 +0000 Subject: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention In-Reply-To: References: Message-ID: Hi Patrick, This looks good now, and also our builds all passed. I'll sponsor it. Best regards, Goetz PS: Sorry for the mail flood yesterday, they finally all showed up in the archive. From: Patrick Zhang OS Sent: Tuesday, June 30, 2020 5:41 AM To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Thanks for finding out it. I updated the patch: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.04/jdk11u-dev.changeset. Yes, jdk/jdk uses sizeof(uint), and placing the two variables side-by-side can remind people in case of type changes in future. I don't have mac system, so thanks a lot again for having it run in your CI. Regards Patrick From: Lindenmaier, Goetz > Sent: Tuesday, June 30, 2020 12:26 AM To: Patrick Zhang OS >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Hi Patrick, If you use sizeof(uint) it works on mac. Uint is also the term jdk/jdk uses here. I put it into our CI again to make sure all platforms build. I'll update you tomorrow (or ping me if I forget). Also I think we should move the line below the declaration of _bottom, as it now depends on the type used there. Best regards, Goetz. diff --git a/src/hotspot/share/gc/shared/taskqueue.hpp b/src/hotspot/share/gc/shared/taskqueue.hpp --- a/src/hotspot/share/gc/shared/taskqueue.hpp +++ b/src/hotspot/share/gc/shared/taskqueue.hpp @@ -113,6 +113,8 @@ // The first free element after the last one pushed (mod N). volatile uint _bottom; + // Add paddings to reduce false-sharing cache contention between _bottom and _age + DEFINE_PAD_MINUS_SIZE(0, DEFAULT_CACHE_LINE_SIZE, sizeof(uint)); enum { MOD_N_MASK = N - 1 }; From: Patrick Zhang OS > Sent: Saturday, June 27, 2020 11:33 AM To: Lindenmaier, Goetz >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueuSuper to reduce false-sharing cache contention Thanks Goetz I updated the of reviewers, http://cr.openjdk.java.net/~qpzhang/8248214/webrev.02/jdk11u-dev.changeset. Regarding the performance, I had tests on Linux system with a couple of x86_64/aarch64 servers, I am not sure if mentioning specjbb here would be appropriate, by far, most results of this benchmark are positive especially the metrics sensitive to GC stability (G1 or ParallelGC), and no obvious change with others probably due to microarchitecture level differences in handling exclusive load/store. This is similar as the original patch [1]. Updated "Fix request (11u)" with a risk estimation of this downporting, see JBS [1] please. I am not familiar with the process of jdk-updates. Is it ok to push this downporting patch now? or I should still wait for maintainer's approval at JBS (jdk11u-fix-yes?). [1] https://bugs.openjdk.java.net/browse/JDK-8248214?focusedCommentId=14349531&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14349531 Regards Patrick -----Original Message----- From: Lindenmaier, Goetz > Sent: Friday, June 26, 2020 3:17 PM To: Patrick Zhang OS >; jdk-updates-dev at openjdk.java.net Cc: hotspot-gc-dev > Subject: RE: [11u] RFR: 8244214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention Hi Patrick, I had a look at your change. I think it makes sense to bring this to 11, if there actually is the performance gain you mention. Reviewed. Please add in the "Fix request" comment in the JBS the risk of downporting this. And I think is should be "Fix request (11u)" because different people will review your fix request for 11 and 8. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Patrick Zhang OS > Sent: Wednesday, June 24, 2020 11:55 AM > To: jdk-updates-dev at openjdk.java.net > Cc: hotspot-gc-dev > > Subject: [DMARC FAILURE] [11u] RFR: 8244214: Add paddings for > TaskQueueSuper to reduce false-sharing cache contention > > Hi > > Could I ask for a review of this simple patch which takes a tiny part > from the original ticket JDK-8243326 [1]. The reason that I do not > want a full backport is, the majority of the patch at jdk/jdk [2] is > to clean up the volatile use and may be not very meaningful to 11u, > furthermore the context (dependencies on atomic.hpp refactor) is too > complicated to generate a clear backport (I tried, ~81 files need to be changed). > > The purpose of having this one-line change to 11u is, the two volatile > variables in TaskQueueSuper: _bottom, _age and corresponding atomic > operations upon, may cause severe cache contention inside GC with > larger number of threads, i.e., specified by -XX:ParallelGCThreads=##, > adding paddings (up to DEFAULT_CACHE_LINE_SIZE) in-between can reduce > the possibility of false-sharing cache contention. I do not need the > paddings before _bottom and after _age from the original patch [2], > because the instances of TaskQueueSuper are usually (always) allocated > in a set of queues, in which they are naturally separated. Please review, thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248214 > Webrev: http://cr.openjdk.java.net/~qpzhang/8248214/webrev.01/ > Testing: tier1-2 pass with the patch, commercial benchmarks and small > C++ test cases (to simulate the data struct and work-stealing > algorithm atomics) validated the performance, no regression. > > By the way, I am going to request for 8u backport as well once 11u > would have it. > > [1] https://bugs.openjdk.java.net/browse/JDK-8243326 Cleanup use of > volatile in taskqueue code [2] > https://hg.openjdk.java.net/jdk/jdk/rev/252a1602b4c6 > > Regards > Patrick > From vkempik at azul.com Tue Jun 30 08:55:29 2020 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 30 Jun 2020 08:55:29 +0000 Subject: [13u] RFR 8233787: Break cycle in vm_version* includes Message-ID: <121DA220-90AE-4776-BC33-DF6E8AA5B7B4@azul.com> Hello Please review this backport of JDK-8233787 to jdk13u The patch didn?t apply cleanly, the changes between original path and backport includes: 1) included headers names around changed lines here and there, nothing interesting 2) src/hotspot/share/runtime/vm_version.cpp and src/hotspot/share/runtime/vm_version.hpp. this change moves most of vm_version.[ch]pp to abstract_vm_version.[ch]pp, but vm_version files was slightly different in original changeset. I have moved content of vm_version to abstract_vm_version carefully to make it match 13u files. Testing: tier1, tier2. The bug: https://bugs.openjdk.java.net/browse/JDK-8233787 The webrev: http://cr.openjdk.java.net/~vkempik/8233787/webrev.13u.00/ Original review thread: https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039904.html Thanks, Vladimir From yan at azul.com Tue Jun 30 09:31:42 2020 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 30 Jun 2020 12:31:42 +0300 Subject: [13u] RFR 8233787: Break cycle in vm_version* includes In-Reply-To: <121DA220-90AE-4776-BC33-DF6E8AA5B7B4@azul.com> References: <121DA220-90AE-4776-BC33-DF6E8AA5B7B4@azul.com> Message-ID: Looks good to me. --yan On 30.06.2020 11:55, Vladimir Kempik wrote: > Hello > Please review this backport of JDK-8233787 to jdk13u > The patch didn?t apply cleanly, the changes between original path and backport includes: > 1) included headers names around changed lines here and there, nothing interesting > 2)??src/hotspot/share/runtime/vm_version.cpp and??src/hotspot/share/runtime/vm_version.hpp. > this change moves most of vm_version.[ch]pp to abstract_vm_version.[ch]pp, but vm_version files was > slightly different in original changeset. > I have moved content of vm_version to abstract_vm_version carefully to make it match 13u files. > > Testing: tier1, tier2. > > The bug:?https://bugs.openjdk.java.net/browse/JDK-8233787 > The webrev:?http://cr.openjdk.java.net/~vkempik/8233787/webrev.13u.00/ > Original review thread:?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039904.html > > Thanks, Vladimir From snazarkin at azul.com Tue Jun 30 09:39:32 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Tue, 30 Jun 2020 09:39:32 +0000 Subject: [13u] RFR 8233787: Break cycle in vm_version* includes In-Reply-To: <121DA220-90AE-4776-BC33-DF6E8AA5B7B4@azul.com> References: <121DA220-90AE-4776-BC33-DF6E8AA5B7B4@azul.com> Message-ID: <30EDA557-9C0A-4396-8D18-A7A8D637D4E1@azul.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- looked at aarch64, everything is ok > On Jun 30, 2020, at 11:55, Vladimir Kempik wrote: > > Hello > Please review this backport of JDK-8233787 to jdk13u > The patch didn?t apply cleanly, the changes between original path and backport includes: > 1) included headers names around changed lines here and there, nothing interesting > 2) src/hotspot/share/runtime/vm_version.cpp and src/hotspot/share/runtime/vm_version.hpp. > this change moves most of vm_version.[ch]pp to abstract_vm_version.[ch]pp, but vm_version files was slightly different in original changeset. > I have moved content of vm_version to abstract_vm_version carefully to make it match 13u files. > > Testing: tier1, tier2. > > The bug: https://bugs.openjdk.java.net/browse/JDK-8233787 > The webrev: http://cr.openjdk.java.net/~vkempik/8233787/webrev.13u.00/ > Original review thread: https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039904.html > > Thanks, Vladimir From vkempik at azul.com Tue Jun 30 13:00:30 2020 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 30 Jun 2020 13:00:30 +0000 Subject: [13u] RFR 8238284: [macos] Zero VM build fails due to an obvious typo Message-ID: Hello Please review this backport of JDK-8238284 to jdk13u The patch didn?t apply cleanly. Original 8238284 fixed two issues in jdk15: JDK-8237437 - since jdk14 JDK-8165929 - since jdk11 Jdk13 only has 8165929 so only part of original fix needs to be backported to jdk13, that part applies cleanly. This is part2 out of 3 fixes needed to fix zero vm on macos. Fix has also part for linux but it wasn?t affected in my testing. Risks are low because the patch just adds const keyword to some vars for zerovm The bug: https://bugs.openjdk.java.net/browse/JDK-8238284 The webrev: http://cr.openjdk.java.net/~vkempik/8238284/webrev.13u.00/ Original review https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-January/040681.html Other two mentioned bugs: https://bugs.openjdk.java.net/browse/JDK-8234737 , https://bugs.openjdk.java.net/browse/JDK-8165929 Thanks, Vladimir