From christoph.langer at sap.com Mon Dec 2 09:09:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 2 Dec 2019 09:09:29 +0000 Subject: [11u]: Request for help with backport of 8230706: Waiting on completion of strong nmethod processing causes long pause times with G1 Message-ID: Hi all, the bug "JDK-8230706: Waiting on completion of strong nmethod processing causes long pause times with G1" is currently without backport to OpenJDK 11u. There is an upstream fix in jdk/jdk available but it seems to be quite different and more extensive, compared to a small fix that Oracle claims to have done in their 11.0.6 update release. As Oracle's 11u fix is not publicly available, somebody would have to step up and propose a patch for 11u, otherwise we'll have to accept that this issue can't be fixed in OpenJDK11u. So my call for help goes out to anybody willing and able to provide a fix for this in 11u. In case anybody is working on this, please reply to this mail. Thanks Christoph From goetz.lindenmaier at sap.com Mon Dec 2 13:20:54 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 2 Dec 2019 13:20:54 +0000 Subject: [11u] RFR: 8216180: [AOT] compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled Message-ID: Hi, I would like to downport this for parity with 11.0.7-oracle http://cr.openjdk.java.net/~goetz/wr19/8216180-AOT_TestMulAdd_crashed-jdk11/01/ I had to resolve the chunk adding the new function to the list At the end of whitebox.cpp. The Context differs. Best regards, Goetz. From christoph.langer at sap.com Mon Dec 2 14:54:16 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 2 Dec 2019 14:54:16 +0000 Subject: [11u] RFR: 8235142: JDK-8193255 backport broke bootstrap with JDK 10 (was: Re: 8193255: Root Certificates should be stored in text format and assembled at build time) In-Reply-To: References: <0270fc53952ced4c120ec0bf4b0068be8c35cebe.camel@redhat.com> Message-ID: Hi Severin, Looks good. Please remove the "import java.nio.file.Path;" statement since this is not needed any longer after your change (replaced by java.nio.file.Paths). No need to see a further webrev, though. Approving 11u-critical. Thanks for doing this! Christoph > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 29. November 2019 17:51 > To: 'Severin Gehwolf' ; Langer, Christoph > ; Martin Buchholz ; > Hohensee, Paul > Cc: jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR: 8235142: JDK-8193255 backport broke bootstrap with > JDK 10 (was: Re: 8193255: Root Certificates should be stored in text format > and assembled at build time) > > Hi Severin, > > The change looks good. > I second pushing this to 11.0.6. > > Best regards, > Goetz. > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Severin Gehwolf > > Sent: Friday, November 29, 2019 4:56 PM > > To: Langer, Christoph ; Martin Buchholz > > ; Hohensee, Paul > > Cc: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8235142: JDK-8193255 backport broke bootstrap with > JDK > > 10 (was: Re: 8193255: Root Certificates should be stored in text format and > > assembled at build time) > > > > Hi, > > > > Before people start to work-around this issue, I'd like to address it > > in JDK 11u. Please review. Fix is rather trivial. s/Path.of/Paths.get/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235142 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8235142/01/webrev/ > > > > Builds fine with JDK 10 as boot JDK with this patch. I'd like to flag > > the bug jdk11u-critical-request once reviewed, so that 11.0.6+6 EA > > builds work with JDK 10 again. > > > > Thoughts? > > > > Thanks, > > Severin > > > > On Thu, 2019-11-28 at 07:47 +0000, Langer, Christoph wrote: > > > Hi Martin, > > > > > > I guess you?re right, JDK11 should theoretically be bootstrapable > > > with JDK10. Given that JDK10 is long out of support, though, I guess > > > it just happens that hardly anybody is using it for 11 builds. > > > Nevertheless, I think we should continue to support this > > > configuration, so I?ll have a look and try to fix it. I also plan to > > > bring this enhancement back to JDK8u, so I guess more changes are > > > needed then? > > > > > > Cheers > > > Christoph > > > > > > From: Martin Buchholz > > > Sent: Donnerstag, 28. November 2019 06:13 > > > To: Hohensee, Paul > > > Cc: Langer, Christoph ; > > > jdk-updates-dev at openjdk.java.net > > > Subject: Re: 8193255: Root Certificates should be stored in text > > > format and assembled at build time > > > > > > I'm fiddling my build script to bootstrap 11u with 11u, but > > > building.md still says > > > > > > "The rule of thumb is that the boot JDK for building JDK major > > > version *N* > > > should be a JDK of major version *N-1*" > > > > > > local -ir boot_major=$((major == 11 ? 11 : (major - 1) )) > > > meta_configure --with-boot-jdk="$(jdk_home $boot_major)" > > > > > > On Wed, Nov 27, 2019 at 1:24 PM Hohensee, Paul > > > > ailto:hohensee at amazon.com>> wrote: > > > You probably are. I use 11u to bootstrap 11u builds because 10 is an > > > orphan. > > > > > > Paul > > > > > > From: Martin Buchholz > > > > >> > > > Date: Wednesday, November 27, 2019 at 10:04 AM > > > To: "Hohensee, Paul" > > > > > > > > > Cc: "Langer, Christoph" > > christoph.langer at sap.com>>, "jdk-updates- > dev at openjdk.java.net > > jdk-updates-dev at openjdk.java.net>" > dev at openjdk.java.net< > > > mailto:jdk-updates-dev at openjdk.java.net>> > > > Subject: Re: 8193255: Root Certificates should be stored in text > > > format and assembled at build time > > > > > > This appears to have broken bootstrap with jdk10, because it uses > > > jdk11 Path.of > > > > > > (Am I the only one following the "bootstrap with jdk N-1" rule?) > > > > > > GenerateCacerts.java:84: error: cannot find symbol > > > List entries = Files.list(Path.of(dir)) > > > ^ > > > symbol: method of(String) > > > location: interface Path > > > > > > On Wed, Nov 20, 2019 at 9:06 AM Hohensee, Paul > > > > ailto:hohensee at amazon.com>> wrote: > > > Looks good. > > > > > > Paul > > > > > > On 11/20/19, 8:05 AM, "jdk-updates-dev on behalf of Langer, > > > Christoph" > > jdk-updates-dev-bounces at openjdk.java.net> on behalf of > > > christoph.langer at sap.com> wrote: > > > > > > Hi, > > > > > > please review the 11u backport of the build facility to assemble > > > the root certificate store (cacerts) at build time from certificates > > > stored in text format. This is a prerequisite to enable easy and > > > straightforward backports of certificate updates from head jdk. This > > > fix will be backported together with JDK-8225392 as the latter one > > > fixes a regression of 8193255. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193255 > > > Original Change: > > > http://hg.openjdk.java.net/jdk/jdk/rev/29ab1f3bd353 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8193255.11u/ > > > > > > I had to resolve a copyright header diff in make/copy/Copy- > > > java.base.gmk and a context diff in make/ToolsJdk.gmk. > > > > > > Patch runs successfully through SAP's regression test system. > > > > > > Thanks > > > Christoph > > > From sgehwolf at redhat.com Mon Dec 2 16:18:22 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Dec 2019 17:18:22 +0100 Subject: [11u] RFR: 8235142: JDK-8193255 backport broke bootstrap with JDK 10 (was: Re: 8193255: Root Certificates should be stored in text format and assembled at build time) In-Reply-To: References: <0270fc53952ced4c120ec0bf4b0068be8c35cebe.camel@redhat.com> Message-ID: <05c3e61fec8853d2588401ba57b5500023a431fb.camel@redhat.com> Hi Christoph, On Mon, 2019-12-02 at 14:54 +0000, Langer, Christoph wrote: > Hi Severin, > > Looks good. Please remove the "import java.nio.file.Path;" statement > since this is not needed any longer after your change (replaced by > java.nio.file.Paths). No need to see a further webrev, though. OK, sure. Thanks for the review! > Approving 11u-critical. Thanks! I'll push it later today. Cheers, Severin > Thanks for doing this! > Christoph > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Freitag, 29. November 2019 17:51 > > To: 'Severin Gehwolf' ; Langer, Christoph > > ; Martin Buchholz ; > > Hohensee, Paul > > Cc: jdk-updates-dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8235142: JDK-8193255 backport broke > > bootstrap with > > JDK 10 (was: Re: 8193255: Root Certificates should be stored in > > text format > > and assembled at build time) > > > > Hi Severin, > > > > The change looks good. > > I second pushing this to 11.0.6. > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: jdk-updates-dev > > > On > > > Behalf Of Severin Gehwolf > > > Sent: Friday, November 29, 2019 4:56 PM > > > To: Langer, Christoph ; Martin Buchholz > > > ; Hohensee, Paul > > > Cc: jdk-updates-dev at openjdk.java.net > > > Subject: [11u] RFR: 8235142: JDK-8193255 backport broke bootstrap > > > with > > JDK > > > 10 (was: Re: 8193255: Root Certificates should be stored in text > > > format and > > > assembled at build time) > > > > > > Hi, > > > > > > Before people start to work-around this issue, I'd like to > > > address it > > > in JDK 11u. Please review. Fix is rather trivial. > > > s/Path.of/Paths.get/ > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235142 > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > 8235142/01/webrev/ > > > > > > Builds fine with JDK 10 as boot JDK with this patch. I'd like to > > > flag > > > the bug jdk11u-critical-request once reviewed, so that 11.0.6+6 > > > EA > > > builds work with JDK 10 again. > > > > > > Thoughts? > > > > > > Thanks, > > > Severin > > > > > > On Thu, 2019-11-28 at 07:47 +0000, Langer, Christoph wrote: > > > > Hi Martin, > > > > > > > > I guess you?re right, JDK11 should theoretically be > > > > bootstrapable > > > > with JDK10. Given that JDK10 is long out of support, though, I > > > > guess > > > > it just happens that hardly anybody is using it for 11 builds. > > > > Nevertheless, I think we should continue to support this > > > > configuration, so I?ll have a look and try to fix it. I also > > > > plan to > > > > bring this enhancement back to JDK8u, so I guess more changes > > > > are > > > > needed then? > > > > > > > > Cheers > > > > Christoph > > > > > > > > From: Martin Buchholz > > > > Sent: Donnerstag, 28. November 2019 06:13 > > > > To: Hohensee, Paul > > > > Cc: Langer, Christoph ; > > > > jdk-updates-dev at openjdk.java.net > > > > Subject: Re: 8193255: Root Certificates should be stored in > > > > text > > > > format and assembled at build time > > > > > > > > I'm fiddling my build script to bootstrap 11u with 11u, but > > > > building.md still says > > > > > > > > "The rule of thumb is that the boot JDK for building JDK major > > > > version *N* > > > > should be a JDK of major version *N-1*" > > > > > > > > local -ir boot_major=$((major == 11 ? 11 : (major - > > > > 1) )) > > > > meta_configure --with-boot-jdk="$(jdk_home > > > > $boot_major)" > > > > > > > > On Wed, Nov 27, 2019 at 1:24 PM Hohensee, Paul > > > > > > ailto:hohensee at amazon.com>> wrote: > > > > You probably are. I use 11u to bootstrap 11u builds because 10 > > > > is an > > > > orphan. > > > > > > > > Paul > > > > > > > > From: Martin Buchholz > > > > > > Date: Wednesday, November 27, 2019 at 10:04 AM > > > > To: "Hohensee, Paul" > > > > > > > Cc: "Langer, Christoph" > > > christoph.langer at sap.com>>, "jdk-updates- > > dev at openjdk.java.net > > > jdk-updates-dev at openjdk.java.net>" > > dev at openjdk.java.net< > > > > mailto:jdk-updates-dev at openjdk.java.net>> > > > > Subject: Re: 8193255: Root Certificates should be stored in > > > > text > > > > format and assembled at build time > > > > > > > > This appears to have broken bootstrap with jdk10, because it > > > > uses > > > > jdk11 Path.of > > > > > > > > (Am I the only one following the "bootstrap with jdk N-1" > > > > rule?) > > > > > > > > GenerateCacerts.java:84: error: cannot find symbol > > > > List entries = Files.list(Path.of(dir)) > > > > ^ > > > > symbol: method of(String) > > > > location: interface Path > > > > > > > > On Wed, Nov 20, 2019 at 9:06 AM Hohensee, Paul > > > > > > ailto:hohensee at amazon.com>> wrote: > > > > Looks good. > > > > > > > > Paul > > > > > > > > On 11/20/19, 8:05 AM, "jdk-updates-dev on behalf of Langer, > > > > Christoph" > > > jdk-updates-dev-bounces at openjdk.java.net> on behalf of > > > > christoph.langer at sap.com> > > > > wrote: > > > > > > > > Hi, > > > > > > > > please review the 11u backport of the build facility to > > > > assemble > > > > the root certificate store (cacerts) at build time from > > > > certificates > > > > stored in text format. This is a prerequisite to enable easy > > > > and > > > > straightforward backports of certificate updates from head jdk. > > > > This > > > > fix will be backported together with JDK-8225392 as the latter > > > > one > > > > fixes a regression of 8193255. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193255 > > > > Original Change: > > > > http://hg.openjdk.java.net/jdk/jdk/rev/29ab1f3bd353 > > > > Webrev: > > > > http://cr.openjdk.java.net/~clanger/webrevs/8193255.11u/ > > > > > > > > I had to resolve a copyright header diff in make/copy/Copy- > > > > java.base.gmk and a context diff in make/ToolsJdk.gmk. > > > > > > > > Patch runs successfully through SAP's regression test > > > > system. > > > > > > > > Thanks > > > > Christoph > > > > From vladimir.kozlov at oracle.com Mon Dec 2 20:18:16 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 2 Dec 2019 12:18:16 -0800 Subject: [11u] RFR: 8216180: [AOT] compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled In-Reply-To: References: Message-ID: Hi Goetz, Declaration of aotLibrariesCount in WhiteBox.java is missing: // Decoder public native void disableElfSectionCache(); + + // Number of loaded AOT libraries + public native int aotLibrariesCount(); } thanks, Vladimir On 12/2/19 5:20 AM, Lindenmaier, Goetz wrote: > Hi, > > I would like to downport this for parity with 11.0.7-oracle > http://cr.openjdk.java.net/~goetz/wr19/8216180-AOT_TestMulAdd_crashed-jdk11/01/ > > I had to resolve the chunk adding the new function to the list > At the end of whitebox.cpp. The Context differs. > > Best regards, > Goetz. > From vladimir.kozlov at oracle.com Mon Dec 2 20:22:24 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 2 Dec 2019 12:22:24 -0800 Subject: [11u] RFR: 8208379: compiler/jvmci/events/JvmciNotifyInstallEventTest.java failed with "Got unexpected event count after 2nd install attempt: expected 9 to equal 2" In-Reply-To: References: Message-ID: <1080c7d3-9d91-3a22-3a38-5cf9006d7426@oracle.com> Good. Thanks, Vladimir On 11/29/19 1:41 AM, Lindenmaier, Goetz wrote: > Hi, > > I downport this for parity with 11.0.7-oracle. > > The original change removes a test variation from a test > that has been adapted in 14 by "JDK-8225019: Update JVMCI". > Due to the missing adaption (adding -Djvmci.Compiler=graal) > this change did not apply. > > http://cr.openjdk.java.net/~goetz/wr19/8208379-JvmciNotify_failed-jdk11/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8208379 > http://hg.openjdk.java.net/jdk/jdk/rev/1b17d09e3e05 > > Best regards, > Goetz. > From vladimir.kozlov at oracle.com Mon Dec 2 20:24:46 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 2 Dec 2019 12:24:46 -0800 Subject: [11u] RFR: 8209574: [AOT] breakpoint events are generated in different threads does not meet expected count In-Reply-To: References: Message-ID: Good. Thanks, Vladimir On 11/29/19 2:17 AM, Lindenmaier, Goetz wrote: > Hi > > I downport this for parity with 11.0.7-oracle. > > I had to resolve aotLoader.cpp. > In the context, is_anonymous() was replaced by is_unsafe_anonymous() > in jdk14 which made the change not apply. > http://cr.openjdk.java.net/~goetz/wr19/8209574-JVMTI_Breakpoint-jdk11/01/ > https://bugs.openjdk.java.net/browse/JDK-8209574 > http://hg.openjdk.java.net/jdk/jdk/rev/b19734760ed3 > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Tue Dec 3 14:32:57 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 3 Dec 2019 14:32:57 +0000 Subject: [11u] RFR: 8216180: [AOT] compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled In-Reply-To: References: Message-ID: Hi Vladimir, thanks for pointing me to that omission! New webrev: http://cr.openjdk.java.net/~goetz/wr19/8216180-AOT_TestMulAdd_crashed-jdk11/02/ Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Vladimir Kozlov > Sent: Montag, 2. Dezember 2019 21:18 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8216180: [AOT] > compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled > > Hi Goetz, > > Declaration of aotLibrariesCount in WhiteBox.java is missing: > > // Decoder > public native void disableElfSectionCache(); > + > + // Number of loaded AOT libraries > + public native int aotLibrariesCount(); > } > > thanks, > Vladimir > > On 12/2/19 5:20 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > I would like to downport this for parity with 11.0.7-oracle > > http://cr.openjdk.java.net/~goetz/wr19/8216180- > AOT_TestMulAdd_crashed-jdk11/01/ > > > > I had to resolve the chunk adding the new function to the list > > At the end of whitebox.cpp. The Context differs. > > > > Best regards, > > Goetz. > > From goetz.lindenmaier at sap.com Tue Dec 3 14:33:28 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 3 Dec 2019 14:33:28 +0000 Subject: [11u] RFR: 8208379: compiler/jvmci/events/JvmciNotifyInstallEventTest.java failed with "Got unexpected event count after 2nd install attempt: expected 9 to equal 2" In-Reply-To: <1080c7d3-9d91-3a22-3a38-5cf9006d7426@oracle.com> References: <1080c7d3-9d91-3a22-3a38-5cf9006d7426@oracle.com> Message-ID: Hi Vladimir, thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Vladimir Kozlov > Sent: Montag, 2. Dezember 2019 21:22 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8208379: > compiler/jvmci/events/JvmciNotifyInstallEventTest.java failed with "Got > unexpected event count after 2nd install attempt: expected 9 to equal 2" > > Good. > > Thanks, > Vladimir > > On 11/29/19 1:41 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > I downport this for parity with 11.0.7-oracle. > > > > The original change removes a test variation from a test > > that has been adapted in 14 by "JDK-8225019: Update JVMCI". > > Due to the missing adaption (adding -Djvmci.Compiler=graal) > > this change did not apply. > > > > http://cr.openjdk.java.net/~goetz/wr19/8208379-JvmciNotify_failed- > jdk11/webrev/ > > https://bugs.openjdk.java.net/browse/JDK-8208379 > > http://hg.openjdk.java.net/jdk/jdk/rev/1b17d09e3e05 > > > > Best regards, > > Goetz. > > From goetz.lindenmaier at sap.com Tue Dec 3 14:33:38 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 3 Dec 2019 14:33:38 +0000 Subject: [11u] RFR: 8209574: [AOT] breakpoint events are generated in different threads does not meet expected count In-Reply-To: References: Message-ID: Hi Vladimir, thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Vladimir Kozlov > Sent: Montag, 2. Dezember 2019 21:25 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8209574: [AOT] breakpoint events are generated in > different threads does not meet expected count > > Good. > > Thanks, > Vladimir > > On 11/29/19 2:17 AM, Lindenmaier, Goetz wrote: > > Hi > > > > I downport this for parity with 11.0.7-oracle. > > > > I had to resolve aotLoader.cpp. > > In the context, is_anonymous() was replaced by is_unsafe_anonymous() > > in jdk14 which made the change not apply. > > http://cr.openjdk.java.net/~goetz/wr19/8209574-JVMTI_Breakpoint- > jdk11/01/ > > https://bugs.openjdk.java.net/browse/JDK-8209574 > > http://hg.openjdk.java.net/jdk/jdk/rev/b19734760ed3 > > > > Best regards, > > Goetz. > > From vladimir.kozlov at oracle.com Tue Dec 3 17:32:54 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 3 Dec 2019 09:32:54 -0800 Subject: [11u] RFR: 8216180: [AOT] compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled In-Reply-To: References: Message-ID: <8d74226d-b249-ed52-9222-de8abdbd0372@oracle.com> Good. thanks, Vladimir On 12/3/19 6:32 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > thanks for pointing me to that omission! > New webrev: > http://cr.openjdk.java.net/~goetz/wr19/8216180-AOT_TestMulAdd_crashed-jdk11/02/ > > Best regards, > Goetz. > > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Vladimir Kozlov >> Sent: Montag, 2. Dezember 2019 21:18 >> To: jdk-updates-dev at openjdk.java.net >> Subject: Re: [11u] RFR: 8216180: [AOT] >> compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled >> >> Hi Goetz, >> >> Declaration of aotLibrariesCount in WhiteBox.java is missing: >> >> // Decoder >> public native void disableElfSectionCache(); >> + >> + // Number of loaded AOT libraries >> + public native int aotLibrariesCount(); >> } >> >> thanks, >> Vladimir >> >> On 12/2/19 5:20 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I would like to downport this for parity with 11.0.7-oracle >>> http://cr.openjdk.java.net/~goetz/wr19/8216180- >> AOT_TestMulAdd_crashed-jdk11/01/ >>> >>> I had to resolve the chunk adding the new function to the list >>> At the end of whitebox.cpp. The Context differs. >>> >>> Best regards, >>> Goetz. >>> From yan at azul.com Wed Dec 4 15:06:12 2019 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 4 Dec 2019 18:06:12 +0300 Subject: [11u] RFR: 8213908: AssertionError in DeferredAttr at setOverloadKind Message-ID: <157ea673-cdff-a904-c9a8-c371fbe67ec6@azul.com> Hi, I'd like to backport to 11u this fix first manifested in 11 but fixed in 12. The one-line patch applied cleanly, hotspot and langtools tests had no new failures. Webrev: http://cr.openjdk.java.net/~yan/8213908/webrev.0/ Original discussion: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-November/012634.html Bug: https://bugs.openjdk.java.net/browse/JDK-8213908 (note also https://bugs.openjdk.java.net/browse/JDK-8220767 etc.) Thank you! --yan From hohensee at amazon.com Wed Dec 4 16:15:05 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 4 Dec 2019 16:15:05 +0000 Subject: [11u] RFR: 8213908: AssertionError in DeferredAttr at setOverloadKind In-Reply-To: <157ea673-cdff-a904-c9a8-c371fbe67ec6@azul.com> References: <157ea673-cdff-a904-c9a8-c371fbe67ec6@azul.com> Message-ID: Lgtm. Paul ?On 12/4/19, 7:07 AM, "jdk-updates-dev on behalf of Yuri Nesterenko" wrote: Hi, I'd like to backport to 11u this fix first manifested in 11 but fixed in 12. The one-line patch applied cleanly, hotspot and langtools tests had no new failures. Webrev: http://cr.openjdk.java.net/~yan/8213908/webrev.0/ Original discussion: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-November/012634.html Bug: https://bugs.openjdk.java.net/browse/JDK-8213908 (note also https://bugs.openjdk.java.net/browse/JDK-8220767 etc.) Thank you! --yan From goetz.lindenmaier at sap.com Thu Dec 5 15:05:47 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 5 Dec 2019 15:05:47 +0000 Subject: [11u] RFR: 8216180: [AOT] compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled In-Reply-To: <8d74226d-b249-ed52-9222-de8abdbd0372@oracle.com> References: <8d74226d-b249-ed52-9222-de8abdbd0372@oracle.com> Message-ID: Hi Vladimir, thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: Vladimir Kozlov > Sent: Dienstag, 3. Dezember 2019 18:33 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8216180: [AOT] > compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled > > Good. > > thanks, > Vladimir > > On 12/3/19 6:32 AM, Lindenmaier, Goetz wrote: > > Hi Vladimir, > > > > thanks for pointing me to that omission! > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr19/8216180- > AOT_TestMulAdd_crashed-jdk11/02/ > > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: jdk-updates-dev On > >> Behalf Of Vladimir Kozlov > >> Sent: Montag, 2. Dezember 2019 21:18 > >> To: jdk-updates-dev at openjdk.java.net > >> Subject: Re: [11u] RFR: 8216180: [AOT] > >> compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled > >> > >> Hi Goetz, > >> > >> Declaration of aotLibrariesCount in WhiteBox.java is missing: > >> > >> // Decoder > >> public native void disableElfSectionCache(); > >> + > >> + // Number of loaded AOT libraries > >> + public native int aotLibrariesCount(); > >> } > >> > >> thanks, > >> Vladimir > >> > >> On 12/2/19 5:20 AM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> I would like to downport this for parity with 11.0.7-oracle > >>> http://cr.openjdk.java.net/~goetz/wr19/8216180- > >> AOT_TestMulAdd_crashed-jdk11/01/ > >>> > >>> I had to resolve the chunk adding the new function to the list > >>> At the end of whitebox.cpp. The Context differs. > >>> > >>> Best regards, > >>> Goetz. > >>> From christoph.langer at sap.com Thu Dec 5 22:04:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Dec 2019 22:04:56 +0000 Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to simplify integration with Serviceability Agent In-Reply-To: References: Message-ID: Hi Jiangli, after no objections were raised and I've run the patches through our test system, I've approved them for 11.0.7. You can go ahead and push them to jdk11u-dev now. Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 22. November 2019 00:38 > To: Jiangli Zhou ; jdk-updates- > dev at openjdk.java.net > Cc: Andrew Haley > Subject: RE: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > simplify integration with Serviceability Agent > > Hi, > > for these issues [0] - [3] I'd like to take a similar path as with JDK-8185525. > > These issues can't just be considered as must-have bugfixes, so the question > is whether the stability risk is justifiable. I would feel somewhat comfortable > to approve these fixes early in the 11.0.7 release cycle, though, since I've > seen them work without regressions in our test system. > > So, please raise objections until next Friday (29th of November) - otherwise > I'd then go and approve them. > > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8209385 > [1] https://bugs.openjdk.java.net/browse/JDK-8209389 > [2] https://bugs.openjdk.java.net/browse/JDK-8209657 > [3] https://bugs.openjdk.java.net/browse/JDK-8209826 > > > -----Original Message----- > > From: Jiangli Zhou > > Sent: Donnerstag, 7. November 2019 02:36 > > To: jdk-updates-dev at openjdk.java.net > > Cc: Langer, Christoph ; Andrew Haley > > > > Subject: Re: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > > simplify integration with Serviceability Agent > > > > Hi, > > > > As suggested by Andrew Haley and Christoph, I'd like to take a survey > > to see if there is any interest/needs for backporting the following > > minor CDS fixes to JDK 11u. > > > > https://bugs.openjdk.java.net/browse/JDK-8209385 > > https://bugs.openjdk.java.net/browse/JDK-8209389 > > https://bugs.openjdk.java.net/browse/JDK-8209657 > > https://bugs.openjdk.java.net/browse/JDK-8209826 > > > > Since stability is the highest priority for update release, it would > > only be reasonable for the additional CDS minor bug fix/enhancement > > backports if the community's interest/demand is high enough. Thanks! > > > > Best, > > > > Jiangli > > > > > > On Thu, Oct 10, 2019 at 7:36 AM Jiangli Zhou > > wrote: > > > > > > Thank you so much, Christoph! Will wait. > > > > > > Best regards, > > > Jiangli > > > > > > On Thu, Oct 10, 2019 at 3:14 AM Langer, Christoph > > > wrote: > > > > > > > > Hi Jiangli, > > > > > > > > the webrev looks good to me and I ran it together with the other CDS > > related backports that you requested through our test system. We didn't > see > > regressions. > > > > > > > > Please allow some time to consult with Andrew on whether to approve > > the backports for pushing. > > > > > > > > Thanks > > > > Christoph > > > > > > > > > -----Original Message----- > > > > > From: hotspot-runtime-dev > > > > bounces at openjdk.java.net> On Behalf Of Jiangli Zhou > > > > > Sent: Donnerstag, 3. Oktober 2019 22:42 > > > > > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev > > > > > > runtime-dev at openjdk.java.net> > > > > > Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > > simplify > > > > > integration with Serviceability Agent > > > > > > > > > > Please review the backport of JDK-8209657: Refactor filemap.hpp to > > > > > simplify integration with Serviceability Agent. > > > > > > > > > > webrev: http://cr.openjdk.java.net/~jiangli/backport- > > 8209657/webrev.00/ > > > > > > > > > > The backport applied 99% cleanly. The only manual part involved was > to > > > > > apply the following diff in filemap.hpp: > > > > > > > > > > 311 > > > > > 312 CDSFileMapRegion* space_at(int i) { > > > > > 313 assert(i >= 0 && i < NUM_CDS_REGIONS, "invalid region"); > > > > > 314 return &_header->_space[i]; > > > > > 315 } > > > > > 316 }; > > > > > > > > > > The backport was done with the intention to downporting additional > > CDS > > > > > bug fixes and improvements that are depending on this one. > > > > > > > > > > Best, > > > > > > > > > > Jiangli From christoph.langer at sap.com Thu Dec 5 22:09:34 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Dec 2019 22:09:34 +0000 Subject: [11u] RFR: 8213908: AssertionError in DeferredAttr at setOverloadKind In-Reply-To: <157ea673-cdff-a904-c9a8-c371fbe67ec6@azul.com> References: <157ea673-cdff-a904-c9a8-c371fbe67ec6@azul.com> Message-ID: Hi Yuri, when a patch applies cleanly, it's enough to add a jdk11u-fix-request label and a fix request comment to the Bug to be backported. No need for RFR on the mailing list. I've approved it now. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Yuri Nesterenko > Sent: Mittwoch, 4. Dezember 2019 16:06 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8213908: AssertionError in DeferredAttr at > setOverloadKind > > Hi, > > I'd like to backport to 11u this fix first manifested in 11 but fixed in > 12. The one-line patch applied cleanly, hotspot and langtools tests had > no new failures. > > Webrev: http://cr.openjdk.java.net/~yan/8213908/webrev.0/ > > Original discussion: > http://mail.openjdk.java.net/pipermail/compiler-dev/2018- > November/012634.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213908 (note also > https://bugs.openjdk.java.net/browse/JDK-8220767 etc.) > > Thank you! > > --yan > > > From jianglizhou at google.com Thu Dec 5 22:18:21 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Thu, 5 Dec 2019 14:18:21 -0800 Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to simplify integration with Serviceability Agent In-Reply-To: References: Message-ID: Hi Christoph, We were just discussing this internally in a team meeting now. :) Sounds great. Will push to 11.0.7. Best regards, Jiangli On Thu, Dec 5, 2019 at 2:04 PM Langer, Christoph wrote: > > Hi Jiangli, > > after no objections were raised and I've run the patches through our test system, I've approved them for 11.0.7. You can go ahead and push them to jdk11u-dev now. > > Best regards > Christoph > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Freitag, 22. November 2019 00:38 > > To: Jiangli Zhou ; jdk-updates- > > dev at openjdk.java.net > > Cc: Andrew Haley > > Subject: RE: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > > simplify integration with Serviceability Agent > > > > Hi, > > > > for these issues [0] - [3] I'd like to take a similar path as with JDK-8185525. > > > > These issues can't just be considered as must-have bugfixes, so the question > > is whether the stability risk is justifiable. I would feel somewhat comfortable > > to approve these fixes early in the 11.0.7 release cycle, though, since I've > > seen them work without regressions in our test system. > > > > So, please raise objections until next Friday (29th of November) - otherwise > > I'd then go and approve them. > > > > Thanks > > Christoph > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8209385 > > [1] https://bugs.openjdk.java.net/browse/JDK-8209389 > > [2] https://bugs.openjdk.java.net/browse/JDK-8209657 > > [3] https://bugs.openjdk.java.net/browse/JDK-8209826 > > > > > -----Original Message----- > > > From: Jiangli Zhou > > > Sent: Donnerstag, 7. November 2019 02:36 > > > To: jdk-updates-dev at openjdk.java.net > > > Cc: Langer, Christoph ; Andrew Haley > > > > > > Subject: Re: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > > > simplify integration with Serviceability Agent > > > > > > Hi, > > > > > > As suggested by Andrew Haley and Christoph, I'd like to take a survey > > > to see if there is any interest/needs for backporting the following > > > minor CDS fixes to JDK 11u. > > > > > > https://bugs.openjdk.java.net/browse/JDK-8209385 > > > https://bugs.openjdk.java.net/browse/JDK-8209389 > > > https://bugs.openjdk.java.net/browse/JDK-8209657 > > > https://bugs.openjdk.java.net/browse/JDK-8209826 > > > > > > Since stability is the highest priority for update release, it would > > > only be reasonable for the additional CDS minor bug fix/enhancement > > > backports if the community's interest/demand is high enough. Thanks! > > > > > > Best, > > > > > > Jiangli > > > > > > > > > On Thu, Oct 10, 2019 at 7:36 AM Jiangli Zhou > > > wrote: > > > > > > > > Thank you so much, Christoph! Will wait. > > > > > > > > Best regards, > > > > Jiangli > > > > > > > > On Thu, Oct 10, 2019 at 3:14 AM Langer, Christoph > > > > wrote: > > > > > > > > > > Hi Jiangli, > > > > > > > > > > the webrev looks good to me and I ran it together with the other CDS > > > related backports that you requested through our test system. We didn't > > see > > > regressions. > > > > > > > > > > Please allow some time to consult with Andrew on whether to approve > > > the backports for pushing. > > > > > > > > > > Thanks > > > > > Christoph > > > > > > > > > > > -----Original Message----- > > > > > > From: hotspot-runtime-dev > > > > > bounces at openjdk.java.net> On Behalf Of Jiangli Zhou > > > > > > Sent: Donnerstag, 3. Oktober 2019 22:42 > > > > > > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev > > > > > > > > runtime-dev at openjdk.java.net> > > > > > > Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > > > simplify > > > > > > integration with Serviceability Agent > > > > > > > > > > > > Please review the backport of JDK-8209657: Refactor filemap.hpp to > > > > > > simplify integration with Serviceability Agent. > > > > > > > > > > > > webrev: http://cr.openjdk.java.net/~jiangli/backport- > > > 8209657/webrev.00/ > > > > > > > > > > > > The backport applied 99% cleanly. The only manual part involved was > > to > > > > > > apply the following diff in filemap.hpp: > > > > > > > > > > > > 311 > > > > > > 312 CDSFileMapRegion* space_at(int i) { > > > > > > 313 assert(i >= 0 && i < NUM_CDS_REGIONS, "invalid region"); > > > > > > 314 return &_header->_space[i]; > > > > > > 315 } > > > > > > 316 }; > > > > > > > > > > > > The backport was done with the intention to downporting additional > > > CDS > > > > > > bug fixes and improvements that are depending on this one. > > > > > > > > > > > > Best, > > > > > > > > > > > > Jiangli From christoph.langer at sap.com Thu Dec 5 22:28:21 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Dec 2019 22:28:21 +0000 Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes In-Reply-To: References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com>, <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com> Message-ID: Hi Denghui, since no objections were raised, I?m approving JDK-8185525. I?ll push it, once I get approval for JDK-8223599 as well. Testing in our system doesn?t show regressions. Cheers Christoph From: Langer, Christoph Sent: Freitag, 22. November 2019 00:30 To: Denghui Dong ; jdk-updates-dev Cc: Andrew Haley Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi, we had a discussion on this list regarding JFR feature requests. As a summary, I take we should 1. Generally reject backports of new features from higher releases if these are too extensive or require lots of prerequisites. Exceptions might be made if the feature to be backported exists in lower releases (e.g. OpenJDK8u after the JFR backport has been integrated) 2. Be very careful when it comes to extensive bugfixes for existing features This fix is actually on the edge of category a), since it is a new feature and it is not trivial in its nature. It needs some manual adaption but fortunately no other prerequisites. Given that Denghui has done the effort of backporting it already and the patch together with another small follow up fix runs through our regression testing at SAP successfully, I could imagine to allow it going in to 11u. I would then like to see it submitted at the early stage of the 11.0.7 cycle. So, @all, please raise objections to this decision until next Friday, 29th of November. If I don?t hear any, I?ll approve it after that date. Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 30. Oktober 2019 15:41 To: Denghui Dong >; jdk-updates-dev > Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, sorry for the late reply. I was discussing with Andrew Haley about JFR backports. He encouraged to do a general discussion on the mailing list about the policy regarding non-trivial JFR related backports, which I started just today: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-October/002053.html Let?s see if there?s any feedback? Best regards Christoph From: Denghui Dong > Sent: Dienstag, 22. Oktober 2019 04:09 To: jdk-updates-dev >; Langer, Christoph > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Christoph, What's the status of this backport ? By the way, the previous webrev didn't contain the original commit, so I uploaded a new one in http://cr.openjdk.java.net/~ddong/8185525/webrev/ Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph > Send Time:2019?10?8?(???) 22:34 To:???(??) >; jdk-updates-dev > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, this is quite a large JFR enhancement. Looking at the 11u webrev, I didn't see any obvious issues although there are obviously quite some alterations from the original patch. I'll run it through our regression testing. However, in any case, we need to carefully decide if and when we allow this patch to jdk11u-dev. I'll get back to you soon. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Denghui Dong > Sent: Donnerstag, 26. September 2019 17:03 > To: jdk-updates-dev > > Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi all, > Please review this backport, original patch doesn't apply cleanly, because > SymbolTable has made some changes in upstream (I think it's not necessary > to backport those changes) > and class ClassLoaderDataGraph is located in different files. > 11u-webrev: > http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8185525 > http://hg.openjdk.java.net/jdk/jdk/rev/865ec913f916 > Testing: test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java > > Thanks, > Denghui Dong From yan at azul.com Fri Dec 6 07:15:34 2019 From: yan at azul.com (Yuri Nesterenko) Date: Fri, 6 Dec 2019 10:15:34 +0300 Subject: [11u] RFR: 8213908: AssertionError in DeferredAttr at setOverloadKind In-Reply-To: References: <157ea673-cdff-a904-c9a8-c371fbe67ec6@azul.com> Message-ID: Thank you, Paul! --yan On 04.12.2019 19:15, Hohensee, Paul wrote: > Lgtm. > > Paul > > ?On 12/4/19, 7:07 AM, "jdk-updates-dev on behalf of Yuri Nesterenko" wrote: > > Hi, > > I'd like to backport to 11u this fix first manifested in 11 but fixed in > 12. The one-line patch applied cleanly, hotspot and langtools tests had > no new failures. > > Webrev: http://cr.openjdk.java.net/~yan/8213908/webrev.0/ > > Original discussion: > http://mail.openjdk.java.net/pipermail/compiler-dev/2018-November/012634.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213908 (note also > https://bugs.openjdk.java.net/browse/JDK-8220767 etc.) > > Thank you! > > --yan > > > > > > From yan at azul.com Fri Dec 6 07:22:35 2019 From: yan at azul.com (Yuri Nesterenko) Date: Fri, 6 Dec 2019 10:22:35 +0300 Subject: [11u] RFR: 8213908: AssertionError in DeferredAttr at setOverloadKind In-Reply-To: References: <157ea673-cdff-a904-c9a8-c371fbe67ec6@azul.com> Message-ID: <286ba58b-f732-d482-5ded-fb3fce8628cb@azul.com> Oh great, thank you Christoph! I often do this or opposite misstep, sorry. Last time with trivial fix in JDK-8233886 for jdk8u it was the other way around:-) Cheers, --yan On 06.12.2019 01:09, Langer, Christoph wrote: > Hi Yuri, > > when a patch applies cleanly, it's enough to add a jdk11u-fix-request label and a fix request comment to the Bug to be backported. No need for RFR on the mailing list. I've approved it now. > > Cheers > Christoph > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Yuri Nesterenko >> Sent: Mittwoch, 4. Dezember 2019 16:06 >> To: jdk-updates-dev at openjdk.java.net >> Subject: [11u] RFR: 8213908: AssertionError in DeferredAttr at >> setOverloadKind >> >> Hi, >> >> I'd like to backport to 11u this fix first manifested in 11 but fixed in >> 12. The one-line patch applied cleanly, hotspot and langtools tests had >> no new failures. >> >> Webrev: http://cr.openjdk.java.net/~yan/8213908/webrev.0/ >> >> Original discussion: >> http://mail.openjdk.java.net/pipermail/compiler-dev/2018- >> November/012634.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213908 (note also >> https://bugs.openjdk.java.net/browse/JDK-8220767 etc.) >> >> Thank you! >> >> --yan >> >> >> From christoph.langer at sap.com Fri Dec 6 08:32:03 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Dec 2019 08:32:03 +0000 Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes In-Reply-To: <23451B8D-FE0A-4508-94F4-660CA2DA923B@oracle.com> References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com> <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com> <23451B8D-FE0A-4508-94F4-660CA2DA923B@oracle.com> Message-ID: Hi Erik, thanks for you input on this. I guess you have a very good point here ? the bar for backporting new events should be quite high. @Denghui: Is there any motivation for this backport from your end that comes from support requirements/customer incidents? Thanks Christoph From: Erik Gahlin Sent: Freitag, 6. Dezember 2019 05:14 To: jdk-updates-dev Cc: Denghui Dong ; Langer, Christoph Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi, What?s nice about jFR is that the file format is self-describing, so a program like JMC can see what events exist or does not exist in a recording. Still, I think the bar should be high when backporting events. Not just for stability reasons, but If different JDK distributions or update releases have different events, it will confuse users, or lead to bugs, when users switch from one JDK to another. In my opinion, events should only be backported if support engineers truly need them to diagnose a certain type of bugs in the JVM/JDK. For this happen, there should be at least a few incidents where they have come to the conclusion that the events are needed. If there are no such real cases, the events should not be backported. My $.02 Erik On 5 Dec 2019, at 23:28, Langer, Christoph > wrote: Hi Denghui, since no objections were raised, I?m approving JDK-8185525. I?ll push it, once I get approval for JDK-8223599 as well. Testing in our system doesn?t show regressions. Cheers Christoph From: Langer, Christoph Sent: Freitag, 22. November 2019 00:30 To: Denghui Dong >; jdk-updates-dev > Cc: Andrew Haley > Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi, we had a discussion on this list regarding JFR feature requests. As a summary, I take we should 1. Generally reject backports of new features from higher releases if these are too extensive or require lots of prerequisites. Exceptions might be made if the feature to be backported exists in lower releases (e.g. OpenJDK8u after the JFR backport has been integrated) 2. Be very careful when it comes to extensive bugfixes for existing features This fix is actually on the edge of category a), since it is a new feature and it is not trivial in its nature. It needs some manual adaption but fortunately no other prerequisites. Given that Denghui has done the effort of backporting it already and the patch together with another small follow up fix runs through our regression testing at SAP successfully, I could imagine to allow it going in to 11u. I would then like to see it submitted at the early stage of the 11.0.7 cycle. So, @all, please raise objections to this decision until next Friday, 29th of November. If I don?t hear any, I?ll approve it after that date. Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 30. Oktober 2019 15:41 To: Denghui Dong >; jdk-updates-dev > Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, sorry for the late reply. I was discussing with Andrew Haley about JFR backports. He encouraged to do a general discussion on the mailing list about the policy regarding non-trivial JFR related backports, which I started just today: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-October/002053.html Let?s see if there?s any feedback? Best regards Christoph From: Denghui Dong > Sent: Dienstag, 22. Oktober 2019 04:09 To: jdk-updates-dev >; Langer, Christoph > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Christoph, What's the status of this backport ? By the way, the previous webrev didn't contain the original commit, so I uploaded a new one in http://cr.openjdk.java.net/~ddong/8185525/webrev/ Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph > Send Time:2019?10?8?(???) 22:34 To:???(??) >; jdk-updates-dev > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, this is quite a large JFR enhancement. Looking at the 11u webrev, I didn't see any obvious issues although there are obviously quite some alterations from the original patch. I'll run it through our regression testing. However, in any case, we need to carefully decide if and when we allow this patch to jdk11u-dev. I'll get back to you soon. Best regards Christoph -----Original Message----- From: jdk-updates-dev > On Behalf Of Denghui Dong Sent: Donnerstag, 26. September 2019 17:03 To: jdk-updates-dev > Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi all, Please review this backport, original patch doesn't apply cleanly, because SymbolTable has made some changes in upstream (I think it's not necessary to backport those changes) and class ClassLoaderDataGraph is located in different files. 11u-webrev: http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ Original bug: https://bugs.openjdk.java.net/browse/JDK-8185525 http://hg.openjdk.java.net/jdk/jdk/rev/865ec913f916 Testing: test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java Thanks, Denghui Dong From christoph.langer at sap.com Fri Dec 6 10:48:51 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Dec 2019 10:48:51 +0000 Subject: [11u] [JFR] RFR 8225797: OldObjectSample event creates unexpected amount of checkpoint data Message-ID: Hi Jaroslav, now that we have an 11.0.7 branch, I started looking at this. First of all, I agree that 8225797 is something we'll want to have in 11u eventually, though it's quite invasive with all its predecessors. I imported all your patches in the order below. Some of them apply with fuzz. The whole set does not even build on linux_x86. I had to remove the final patch for JDK-8225797 to get it built. I'll run the other patches through our regression test system and will hopefully be able to share some results on Monday. However, I think that we should review and push each fix one by one, in the order they apply. And we should have a separate review thread for each fix. So I'd like to ask you to start sending out a review mail for JDK-8209850 as a first step. Thanks & Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Jaroslav Bachor?k > Sent: Freitag, 15. November 2019 16:46 > To: jdk-updates-dev > Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event > creates unexpected amount of checkpoint data > > Hi, > > I would like to get this non-trivial JFR related backport reviewed. This > backport is required because OldObjectSample event in the current (JDK 11) > form will cause unlimited growth of the recording thus making this event > unsuitable in production memory leak detection - which is its main purpose. > > The backport for 8225797 requires several other changes to be backported as > well. I am listing the changes and the related webrevs here in order to > have all the pieces in one place. The webrevs, unfortunately, are showing > cumulative changes, so please, disregard that information. Each webrev is > generated for that particular commit. > > The following tests were run successfully: > - jdk_tier1 > - jdk_tier2 > - jdk_jfr > - jdk_core > > --- > > Prerequisites: > # 8209850 : Allow NamedThreads to use GlobalCounter critical sections > - applied almost cleanly with only minimal changes to account for slightly > different code structure (patch diff - > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff) > JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209850 > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/ > > # 8209976: Improve iteration over non-JavaThreads > - applied almost cleanly with only minimal changes to account for slightly > different code structure (patch diff - > http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/patch.diff) > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209976 > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/ > > > # 8210024: JFR calls virtual is_Java_thread from ~Thread() > - applied almost cleanly with only minimal changes to account for slightly > different code structure (patch diff - > http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/patch.diff) > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8210024 > - Webrev : http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/ > > # 8214850: Rename vm_operations.?pp files to vmOperations.?pp files > - applied almost cleanly with only minimal changes to account for slightly > different code structure (patch diff - > http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/patch.diff) > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8214850 > - Webrev : http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/ > > # 8209802: Garbage collectors should register JFR types themselves to avoid > build errors. > - applied almost cleanly with only minimal changes to account for slightly > different code locations for g1 sources (patch diff - > http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/patch.diff) > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209802 > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/ > > > Backport: > # 8225797: OldObjectSample event creates unexpected amount of > checkpoint > data > - the original patch had to be accommodated to the JDK 11 status of JFR to > minimize the number of prerequisite backports and therefore it is slightly > more complex (patch diff - > http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/patch.diff) > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8225797 > - Webrev : http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/ > > > Thanks! > > -JB- From goetz.lindenmaier at sap.com Fri Dec 6 16:44:03 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Dec 2019 16:44:03 +0000 Subject: [11u] RFR: 8221312: test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java failed Message-ID: Hi, could I please get review for these simple resolves: demo/.../BezierAnimationPanel.java: Copyright. ProblemList: the test was never ProblemListed in 11. Skipped. test/.../BezierAnimationPanel.java: Indentation is broken in 11, this spoils the context. http://cr.openjdk.java.net/~goetz/wr19/8221312-CColorChooserDemoTest_failed-jdk11/01/ Best regards, Goetz. From hohensee at amazon.com Fri Dec 6 18:35:14 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 6 Dec 2019 18:35:14 +0000 Subject: [11u] RFR: 8221312: test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java failed In-Reply-To: References: Message-ID: <1076B7E3-BE5A-4E00-BC03-56F0BE9ECB21@amazon.com> Lgtm. Paul ?On 12/6/19, 8:44 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" wrote: Hi, could I please get review for these simple resolves: demo/.../BezierAnimationPanel.java: Copyright. ProblemList: the test was never ProblemListed in 11. Skipped. test/.../BezierAnimationPanel.java: Indentation is broken in 11, this spoils the context. http://cr.openjdk.java.net/~goetz/wr19/8221312-CColorChooserDemoTest_failed-jdk11/01/ Best regards, Goetz. From jianglizhou at google.com Fri Dec 6 21:01:59 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 6 Dec 2019 13:01:59 -0800 Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to simplify integration with Serviceability Agent In-Reply-To: References: Message-ID: Hi Christoph, I pushed all four backports to 11.0.7 today. Best regards, Jiangli On Thu, Dec 5, 2019 at 2:18 PM Jiangli Zhou wrote: > > Hi Christoph, > > We were just discussing this internally in a team meeting now. :) > Sounds great. Will push to 11.0.7. > > Best regards, > Jiangli > > On Thu, Dec 5, 2019 at 2:04 PM Langer, Christoph > wrote: > > > > Hi Jiangli, > > > > after no objections were raised and I've run the patches through our test system, I've approved them for 11.0.7. You can go ahead and push them to jdk11u-dev now. > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Langer, Christoph > > > Sent: Freitag, 22. November 2019 00:38 > > > To: Jiangli Zhou ; jdk-updates- > > > dev at openjdk.java.net > > > Cc: Andrew Haley > > > Subject: RE: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > > > simplify integration with Serviceability Agent > > > > > > Hi, > > > > > > for these issues [0] - [3] I'd like to take a similar path as with JDK-8185525. > > > > > > These issues can't just be considered as must-have bugfixes, so the question > > > is whether the stability risk is justifiable. I would feel somewhat comfortable > > > to approve these fixes early in the 11.0.7 release cycle, though, since I've > > > seen them work without regressions in our test system. > > > > > > So, please raise objections until next Friday (29th of November) - otherwise > > > I'd then go and approve them. > > > > > > Thanks > > > Christoph > > > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8209385 > > > [1] https://bugs.openjdk.java.net/browse/JDK-8209389 > > > [2] https://bugs.openjdk.java.net/browse/JDK-8209657 > > > [3] https://bugs.openjdk.java.net/browse/JDK-8209826 > > > > > > > -----Original Message----- > > > > From: Jiangli Zhou > > > > Sent: Donnerstag, 7. November 2019 02:36 > > > > To: jdk-updates-dev at openjdk.java.net > > > > Cc: Langer, Christoph ; Andrew Haley > > > > > > > > Subject: Re: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > > > > simplify integration with Serviceability Agent > > > > > > > > Hi, > > > > > > > > As suggested by Andrew Haley and Christoph, I'd like to take a survey > > > > to see if there is any interest/needs for backporting the following > > > > minor CDS fixes to JDK 11u. > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8209385 > > > > https://bugs.openjdk.java.net/browse/JDK-8209389 > > > > https://bugs.openjdk.java.net/browse/JDK-8209657 > > > > https://bugs.openjdk.java.net/browse/JDK-8209826 > > > > > > > > Since stability is the highest priority for update release, it would > > > > only be reasonable for the additional CDS minor bug fix/enhancement > > > > backports if the community's interest/demand is high enough. Thanks! > > > > > > > > Best, > > > > > > > > Jiangli > > > > > > > > > > > > On Thu, Oct 10, 2019 at 7:36 AM Jiangli Zhou > > > > wrote: > > > > > > > > > > Thank you so much, Christoph! Will wait. > > > > > > > > > > Best regards, > > > > > Jiangli > > > > > > > > > > On Thu, Oct 10, 2019 at 3:14 AM Langer, Christoph > > > > > wrote: > > > > > > > > > > > > Hi Jiangli, > > > > > > > > > > > > the webrev looks good to me and I ran it together with the other CDS > > > > related backports that you requested through our test system. We didn't > > > see > > > > regressions. > > > > > > > > > > > > Please allow some time to consult with Andrew on whether to approve > > > > the backports for pushing. > > > > > > > > > > > > Thanks > > > > > > Christoph > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: hotspot-runtime-dev > > > > > > bounces at openjdk.java.net> On Behalf Of Jiangli Zhou > > > > > > > Sent: Donnerstag, 3. Oktober 2019 22:42 > > > > > > > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev > > > > > > > > > > runtime-dev at openjdk.java.net> > > > > > > > Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > > > > simplify > > > > > > > integration with Serviceability Agent > > > > > > > > > > > > > > Please review the backport of JDK-8209657: Refactor filemap.hpp to > > > > > > > simplify integration with Serviceability Agent. > > > > > > > > > > > > > > webrev: http://cr.openjdk.java.net/~jiangli/backport- > > > > 8209657/webrev.00/ > > > > > > > > > > > > > > The backport applied 99% cleanly. The only manual part involved was > > > to > > > > > > > apply the following diff in filemap.hpp: > > > > > > > > > > > > > > 311 > > > > > > > 312 CDSFileMapRegion* space_at(int i) { > > > > > > > 313 assert(i >= 0 && i < NUM_CDS_REGIONS, "invalid region"); > > > > > > > 314 return &_header->_space[i]; > > > > > > > 315 } > > > > > > > 316 }; > > > > > > > > > > > > > > The backport was done with the intention to downporting additional > > > > CDS > > > > > > > bug fixes and improvements that are depending on this one. > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > Jiangli From christoph.langer at sap.com Fri Dec 6 21:59:39 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Dec 2019 21:59:39 +0000 Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to simplify integration with Serviceability Agent In-Reply-To: References: Message-ID: Hi Jiangli, Looks good. For the backport of JDK-8209657 it would have been better if you had pushed it with the original metadata - the backport patch was not substantially different to the original, I think. Just as a hint for next time ?? Cheers Christoph > -----Original Message----- > From: Jiangli Zhou > Sent: Freitag, 6. Dezember 2019 22:02 > To: Langer, Christoph > Cc: Andrew Haley ; jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > simplify integration with Serviceability Agent > > Hi Christoph, > > I pushed all four backports to 11.0.7 today. > > Best regards, > > Jiangli > > On Thu, Dec 5, 2019 at 2:18 PM Jiangli Zhou > wrote: > > > > Hi Christoph, > > > > We were just discussing this internally in a team meeting now. :) > > Sounds great. Will push to 11.0.7. > > > > Best regards, > > Jiangli > > > > On Thu, Dec 5, 2019 at 2:04 PM Langer, Christoph > > wrote: > > > > > > Hi Jiangli, > > > > > > after no objections were raised and I've run the patches through our test > system, I've approved them for 11.0.7. You can go ahead and push them to > jdk11u-dev now. > > > > > > Best regards > > > Christoph > > > > > > > -----Original Message----- > > > > From: Langer, Christoph > > > > Sent: Freitag, 22. November 2019 00:38 > > > > To: Jiangli Zhou ; jdk-updates- > > > > dev at openjdk.java.net > > > > Cc: Andrew Haley > > > > Subject: RE: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > > > > simplify integration with Serviceability Agent > > > > > > > > Hi, > > > > > > > > for these issues [0] - [3] I'd like to take a similar path as with JDK- > 8185525. > > > > > > > > These issues can't just be considered as must-have bugfixes, so the > question > > > > is whether the stability risk is justifiable. I would feel somewhat > comfortable > > > > to approve these fixes early in the 11.0.7 release cycle, though, since > I've > > > > seen them work without regressions in our test system. > > > > > > > > So, please raise objections until next Friday (29th of November) - > otherwise > > > > I'd then go and approve them. > > > > > > > > Thanks > > > > Christoph > > > > > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8209385 > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8209389 > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8209657 > > > > [3] https://bugs.openjdk.java.net/browse/JDK-8209826 > > > > > > > > > -----Original Message----- > > > > > From: Jiangli Zhou > > > > > Sent: Donnerstag, 7. November 2019 02:36 > > > > > To: jdk-updates-dev at openjdk.java.net > > > > > Cc: Langer, Christoph ; Andrew Haley > > > > > > > > > > Subject: Re: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > > > > > simplify integration with Serviceability Agent > > > > > > > > > > Hi, > > > > > > > > > > As suggested by Andrew Haley and Christoph, I'd like to take a survey > > > > > to see if there is any interest/needs for backporting the following > > > > > minor CDS fixes to JDK 11u. > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8209385 > > > > > https://bugs.openjdk.java.net/browse/JDK-8209389 > > > > > https://bugs.openjdk.java.net/browse/JDK-8209657 > > > > > https://bugs.openjdk.java.net/browse/JDK-8209826 > > > > > > > > > > Since stability is the highest priority for update release, it would > > > > > only be reasonable for the additional CDS minor bug fix/enhancement > > > > > backports if the community's interest/demand is high enough. > Thanks! > > > > > > > > > > Best, > > > > > > > > > > Jiangli > > > > > > > > > > > > > > > On Thu, Oct 10, 2019 at 7:36 AM Jiangli Zhou > > > > > > wrote: > > > > > > > > > > > > Thank you so much, Christoph! Will wait. > > > > > > > > > > > > Best regards, > > > > > > Jiangli > > > > > > > > > > > > On Thu, Oct 10, 2019 at 3:14 AM Langer, Christoph > > > > > > wrote: > > > > > > > > > > > > > > Hi Jiangli, > > > > > > > > > > > > > > the webrev looks good to me and I ran it together with the other > CDS > > > > > related backports that you requested through our test system. We > didn't > > > > see > > > > > regressions. > > > > > > > > > > > > > > Please allow some time to consult with Andrew on whether to > approve > > > > > the backports for pushing. > > > > > > > > > > > > > > Thanks > > > > > > > Christoph > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: hotspot-runtime-dev > > > > > > > bounces at openjdk.java.net> On Behalf Of Jiangli Zhou > > > > > > > > Sent: Donnerstag, 3. Oktober 2019 22:42 > > > > > > > > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev > > > > > > > > > > > > runtime-dev at openjdk.java.net> > > > > > > > > Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp > to > > > > > simplify > > > > > > > > integration with Serviceability Agent > > > > > > > > > > > > > > > > Please review the backport of JDK-8209657: Refactor > filemap.hpp to > > > > > > > > simplify integration with Serviceability Agent. > > > > > > > > > > > > > > > > webrev: http://cr.openjdk.java.net/~jiangli/backport- > > > > > 8209657/webrev.00/ > > > > > > > > > > > > > > > > The backport applied 99% cleanly. The only manual part involved > was > > > > to > > > > > > > > apply the following diff in filemap.hpp: > > > > > > > > > > > > > > > > 311 > > > > > > > > 312 CDSFileMapRegion* space_at(int i) { > > > > > > > > 313 assert(i >= 0 && i < NUM_CDS_REGIONS, "invalid > region"); > > > > > > > > 314 return &_header->_space[i]; > > > > > > > > 315 } > > > > > > > > 316 }; > > > > > > > > > > > > > > > > The backport was done with the intention to downporting > additional > > > > > CDS > > > > > > > > bug fixes and improvements that are depending on this one. > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > Jiangli From jianglizhou at google.com Fri Dec 6 22:01:01 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 6 Dec 2019 14:01:01 -0800 Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to simplify integration with Serviceability Agent In-Reply-To: References: Message-ID: On Fri, Dec 6, 2019 at 1:59 PM Langer, Christoph wrote: > Hi Jiangli, > > Looks good. > > For the backport of JDK-8209657 it would have been better if you had > pushed it with the original metadata - the backport patch was not > substantially different to the original, I think. Just as a hint for next > time ?? > Good suggestion! Will do next time. Thanks! Best, Jiangli > > Cheers > Christoph > > > -----Original Message----- > > From: Jiangli Zhou > > Sent: Freitag, 6. Dezember 2019 22:02 > > To: Langer, Christoph > > Cc: Andrew Haley ; jdk-updates-dev at openjdk.java.net > > Subject: Re: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to > > simplify integration with Serviceability Agent > > > > Hi Christoph, > > > > I pushed all four backports to 11.0.7 today. > > > > Best regards, > > > > Jiangli > > > > On Thu, Dec 5, 2019 at 2:18 PM Jiangli Zhou > > wrote: > > > > > > Hi Christoph, > > > > > > We were just discussing this internally in a team meeting now. :) > > > Sounds great. Will push to 11.0.7. > > > > > > Best regards, > > > Jiangli > > > > > > On Thu, Dec 5, 2019 at 2:04 PM Langer, Christoph > > > wrote: > > > > > > > > Hi Jiangli, > > > > > > > > after no objections were raised and I've run the patches through our > test > > system, I've approved them for 11.0.7. You can go ahead and push them to > > jdk11u-dev now. > > > > > > > > Best regards > > > > Christoph > > > > > > > > > -----Original Message----- > > > > > From: Langer, Christoph > > > > > Sent: Freitag, 22. November 2019 00:38 > > > > > To: Jiangli Zhou ; jdk-updates- > > > > > dev at openjdk.java.net > > > > > Cc: Andrew Haley > > > > > Subject: RE: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp > to > > > > > simplify integration with Serviceability Agent > > > > > > > > > > Hi, > > > > > > > > > > for these issues [0] - [3] I'd like to take a similar path as with > JDK- > > 8185525. > > > > > > > > > > These issues can't just be considered as must-have bugfixes, so the > > question > > > > > is whether the stability risk is justifiable. I would feel somewhat > > comfortable > > > > > to approve these fixes early in the 11.0.7 release cycle, though, > since > > I've > > > > > seen them work without regressions in our test system. > > > > > > > > > > So, please raise objections until next Friday (29th of November) - > > otherwise > > > > > I'd then go and approve them. > > > > > > > > > > Thanks > > > > > Christoph > > > > > > > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8209385 > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8209389 > > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8209657 > > > > > [3] https://bugs.openjdk.java.net/browse/JDK-8209826 > > > > > > > > > > > -----Original Message----- > > > > > > From: Jiangli Zhou > > > > > > Sent: Donnerstag, 7. November 2019 02:36 > > > > > > To: jdk-updates-dev at openjdk.java.net > > > > > > Cc: Langer, Christoph ; Andrew Haley > > > > > > > > > > > > Subject: Re: [11u] RFR: Backport JDK-8209657: Refactor > filemap.hpp to > > > > > > simplify integration with Serviceability Agent > > > > > > > > > > > > Hi, > > > > > > > > > > > > As suggested by Andrew Haley and Christoph, I'd like to take a > survey > > > > > > to see if there is any interest/needs for backporting the > following > > > > > > minor CDS fixes to JDK 11u. > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8209385 > > > > > > https://bugs.openjdk.java.net/browse/JDK-8209389 > > > > > > https://bugs.openjdk.java.net/browse/JDK-8209657 > > > > > > https://bugs.openjdk.java.net/browse/JDK-8209826 > > > > > > > > > > > > Since stability is the highest priority for update release, it > would > > > > > > only be reasonable for the additional CDS minor bug > fix/enhancement > > > > > > backports if the community's interest/demand is high enough. > > Thanks! > > > > > > > > > > > > Best, > > > > > > > > > > > > Jiangli > > > > > > > > > > > > > > > > > > On Thu, Oct 10, 2019 at 7:36 AM Jiangli Zhou > > > > > > > > wrote: > > > > > > > > > > > > > > Thank you so much, Christoph! Will wait. > > > > > > > > > > > > > > Best regards, > > > > > > > Jiangli > > > > > > > > > > > > > > On Thu, Oct 10, 2019 at 3:14 AM Langer, Christoph > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Jiangli, > > > > > > > > > > > > > > > > the webrev looks good to me and I ran it together with the > other > > CDS > > > > > > related backports that you requested through our test system. We > > didn't > > > > > see > > > > > > regressions. > > > > > > > > > > > > > > > > Please allow some time to consult with Andrew on whether to > > approve > > > > > > the backports for pushing. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Christoph > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: hotspot-runtime-dev > > > > > > > > bounces at openjdk.java.net> On Behalf Of Jiangli Zhou > > > > > > > > > Sent: Donnerstag, 3. Oktober 2019 22:42 > > > > > > > > > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev > > > > > > > > > > > > > > runtime-dev at openjdk.java.net> > > > > > > > > > Subject: [11u] RFR: Backport JDK-8209657: Refactor > filemap.hpp > > to > > > > > > simplify > > > > > > > > > integration with Serviceability Agent > > > > > > > > > > > > > > > > > > Please review the backport of JDK-8209657: Refactor > > filemap.hpp to > > > > > > > > > simplify integration with Serviceability Agent. > > > > > > > > > > > > > > > > > > webrev: http://cr.openjdk.java.net/~jiangli/backport- > > > > > > 8209657/webrev.00/ > > > > > > > > > > > > > > > > > > The backport applied 99% cleanly. The only manual part > involved > > was > > > > > to > > > > > > > > > apply the following diff in filemap.hpp: > > > > > > > > > > > > > > > > > > 311 > > > > > > > > > 312 CDSFileMapRegion* space_at(int i) { > > > > > > > > > 313 assert(i >= 0 && i < NUM_CDS_REGIONS, "invalid > > region"); > > > > > > > > > 314 return &_header->_space[i]; > > > > > > > > > 315 } > > > > > > > > > 316 }; > > > > > > > > > > > > > > > > > > The backport was done with the intention to downporting > > additional > > > > > > CDS > > > > > > > > > bug fixes and improvements that are depending on this one. > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > > > Jiangli > From denghui.ddh at alibaba-inc.com Mon Dec 9 09:05:32 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Mon, 09 Dec 2019 17:05:32 +0800 Subject: =?UTF-8?B?UmU6IFsxMXVdIFJGUiA4MTg1NTI1OiBBZGQgSkZSIGV2ZW50IGZvciBEaWN0aW9uYXJ5U2l6?= =?UTF-8?B?ZXM=?= In-Reply-To: References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com> <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com> <23451B8D-FE0A-4508-94F4-660CA2DA923B@oracle.com>, Message-ID: Hi Christoph, I was on vacation last week, sorry for the late reply. In fact, the backport of 8185525 for 8u was requested by @Andrey at first (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html) For the sake of consistency, I made this backport for 11u. And in my opinion, these events are not very useful for users indeed. Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph Send Time:2019?12?6?(???) 16:32 To:Erik Gahlin ; jdk-updates-dev Cc:???(??) Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Erik, thanks for you input on this. I guess you have a very good point here ? the bar for backporting new events should be quite high. @Denghui: Is there any motivation for this backport from your end that comes from support requirements/customer incidents? Thanks Christoph From: Erik Gahlin Sent: Freitag, 6. Dezember 2019 05:14 To: jdk-updates-dev Cc: Denghui Dong ; Langer, Christoph Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi, What?s nice about jFR is that the file format is self-describing, so a program like JMC can see what events exist or does not exist in a recording. Still, I think the bar should be high when backporting events. Not just for stability reasons, but If different JDK distributions or update releases have different events, it will confuse users, or lead to bugs, when users switch from one JDK to another. In my opinion, events should only be backported if support engineers truly need them to diagnose a certain type of bugs in the JVM/JDK. For this happen, there should be at least a few incidents where they have come to the conclusion that the events are needed. If there are no such real cases, the events should not be backported. My $.02 Erik On 5 Dec 2019, at 23:28, Langer, Christoph wrote: Hi Denghui, since no objections were raised, I?m approving JDK-8185525. I?ll push it, once I get approval for JDK-8223599 as well. Testing in our system doesn?t show regressions. Cheers Christoph From: Langer, Christoph Sent: Freitag, 22. November 2019 00:30 To: Denghui Dong ; jdk-updates-dev Cc: Andrew Haley Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi, we had a discussion on this list regarding JFR feature requests. As a summary, I take we should 1. Generally reject backports of new features from higher releases if these are too extensive or require lots of prerequisites. Exceptions might be made if the feature to be backported exists in lower releases (e.g. OpenJDK8u after the JFR backport has been integrated) 2. Be very careful when it comes to extensive bugfixes for existing features This fix is actually on the edge of category a), since it is a new feature and it is not trivial in its nature. It needs some manual adaption but fortunately no other prerequisites. Given that Denghui has done the effort of backporting it already and the patch together with another small follow up fix runs through our regression testing at SAP successfully, I could imagine to allow it going in to 11u. I would then like to see it submitted at the early stage of the 11.0.7 cycle. So, @all, please raise objections to this decision until next Friday, 29th of November. If I don?t hear any, I?ll approve it after that date. Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 30. Oktober 2019 15:41 To: Denghui Dong >; jdk-updates-dev > Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, sorry for the late reply. I was discussing with Andrew Haley about JFR backports. He encouraged to do a general discussion on the mailing list about the policy regarding non-trivial JFR related backports, which I started just today: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-October/002053.html Let?s see if there?s any feedback? Best regards Christoph From: Denghui Dong > Sent: Dienstag, 22. Oktober 2019 04:09 To: jdk-updates-dev >; Langer, Christoph > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Christoph, What's the status of this backport ? By the way, the previous webrev didn't contain the original commit, so I uploaded a new one in http://cr.openjdk.java.net/~ddong/8185525/webrev/ Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph > Send Time:2019?10?8?(???) 22:34 To:???(??) >; jdk-updates-dev > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, this is quite a large JFR enhancement. Looking at the 11u webrev, I didn't see any obvious issues although there are obviously quite some alterations from the original patch. I'll run it through our regression testing. However, in any case, we need to carefully decide if and when we allow this patch to jdk11u-dev. I'll get back to you soon. Best regards Christoph -----Original Message----- From: jdk-updates-dev > On Behalf Of Denghui Dong Sent: Donnerstag, 26. September 2019 17:03 To: jdk-updates-dev > Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi all, Please review this backport, original patch doesn't apply cleanly, because SymbolTable has made some changes in upstream (I think it's not necessary to backport those changes) and class ClassLoaderDataGraph is located in different files. 11u-webrev: http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ Original bug: https://bugs.openjdk.java.net/browse/JDK-8185525 http://hg.openjdk.java.net/jdk/jdk/rev/865ec913f916 Testing: test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java Thanks, Denghui Dong From christoph.langer at sap.com Mon Dec 9 09:16:51 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 9 Dec 2019 09:16:51 +0000 Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes In-Reply-To: References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com> <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com> <23451B8D-FE0A-4508-94F4-660CA2DA923B@oracle.com>, Message-ID: Hi Denghui, ok, I see. So, taking a glance on http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/, I can?t see that the bug is pushed there. So, if that?s true, I?d rather reject the backport to 11u for now. Would you agree? Thanks Christoph From: Denghui Dong Sent: Montag, 9. Dezember 2019 10:06 To: Erik Gahlin ; jdk-updates-dev ; Langer, Christoph ; Andrey Petushkov ; Mario Torre Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Christoph, I was on vacation last week, sorry for the late reply. In fact, the backport of 8185525 for 8u was requested by @Andrey at first (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html) For the sake of consistency, I made this backport for 11u. And in my opinion, these events are not very useful for users indeed. Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph > Send Time:2019?12?6?(???) 16:32 To:Erik Gahlin >; jdk-updates-dev > Cc:???(??) > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Erik, thanks for you input on this. I guess you have a very good point here ? the bar for backporting new events should be quite high. @Denghui: Is there any motivation for this backport from your end that comes from support requirements/customer incidents? Thanks Christoph From: Erik Gahlin > Sent: Freitag, 6. Dezember 2019 05:14 To: jdk-updates-dev > Cc: Denghui Dong >; Langer, Christoph > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi, What?s nice about jFR is that the file format is self-describing, so a program like JMC can see what events exist or does not exist in a recording. Still, I think the bar should be high when backporting events. Not just for stability reasons, but If different JDK distributions or update releases have different events, it will confuse users, or lead to bugs, when users switch from one JDK to another. In my opinion, events should only be backported if support engineers truly need them to diagnose a certain type of bugs in the JVM/JDK. For this happen, there should be at least a few incidents where they have come to the conclusion that the events are needed. If there are no such real cases, the events should not be backported. My $.02 Erik On 5 Dec 2019, at 23:28, Langer, Christoph > wrote: Hi Denghui, since no objections were raised, I?m approving JDK-8185525. I?ll push it, once I get approval for JDK-8223599 as well. Testing in our system doesn?t show regressions. Cheers Christoph From: Langer, Christoph Sent: Freitag, 22. November 2019 00:30 To: Denghui Dong >; jdk-updates-dev > Cc: Andrew Haley > Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi, we had a discussion on this list regarding JFR feature requests. As a summary, I take we should 1. Generally reject backports of new features from higher releases if these are too extensive or require lots of prerequisites. Exceptions might be made if the feature to be backported exists in lower releases (e.g. OpenJDK8u after the JFR backport has been integrated) 2. Be very careful when it comes to extensive bugfixes for existing features This fix is actually on the edge of category a), since it is a new feature and it is not trivial in its nature. It needs some manual adaption but fortunately no other prerequisites. Given that Denghui has done the effort of backporting it already and the patch together with another small follow up fix runs through our regression testing at SAP successfully, I could imagine to allow it going in to 11u. I would then like to see it submitted at the early stage of the 11.0.7 cycle. So, @all, please raise objections to this decision until next Friday, 29th of November. If I don?t hear any, I?ll approve it after that date. Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 30. Oktober 2019 15:41 To: Denghui Dong >; jdk-updates-dev > Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, sorry for the late reply. I was discussing with Andrew Haley about JFR backports. He encouraged to do a general discussion on the mailing list about the policy regarding non-trivial JFR related backports, which I started just today: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-October/002053.html Let?s see if there?s any feedback? Best regards Christoph From: Denghui Dong > Sent: Dienstag, 22. Oktober 2019 04:09 To: jdk-updates-dev >; Langer, Christoph > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Christoph, What's the status of this backport ? By the way, the previous webrev didn't contain the original commit, so I uploaded a new one in http://cr.openjdk.java.net/~ddong/8185525/webrev/ Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph > Send Time:2019?10?8?(???) 22:34 To:???(??) >; jdk-updates-dev > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, this is quite a large JFR enhancement. Looking at the 11u webrev, I didn't see any obvious issues although there are obviously quite some alterations from the original patch. I'll run it through our regression testing. However, in any case, we need to carefully decide if and when we allow this patch to jdk11u-dev. I'll get back to you soon. Best regards Christoph -----Original Message----- From: jdk-updates-dev > On Behalf Of Denghui Dong Sent: Donnerstag, 26. September 2019 17:03 To: jdk-updates-dev > Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi all, Please review this backport, original patch doesn't apply cleanly, because SymbolTable has made some changes in upstream (I think it's not necessary to backport those changes) and class ClassLoaderDataGraph is located in different files. 11u-webrev: http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ Original bug: https://bugs.openjdk.java.net/browse/JDK-8185525 http://hg.openjdk.java.net/jdk/jdk/rev/865ec913f916 Testing: test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java Thanks, Denghui Dong From denghui.ddh at alibaba-inc.com Mon Dec 9 09:33:11 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Mon, 09 Dec 2019 17:33:11 +0800 Subject: =?UTF-8?B?UmU6IFsxMXVdIFJGUiA4MTg1NTI1OiBBZGQgSkZSIGV2ZW50IGZvciBEaWN0aW9uYXJ5U2l6?= =?UTF-8?B?ZXM=?= In-Reply-To: References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com> <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com> <23451B8D-FE0A-4508-94F4-660CA2DA923B@oracle.com>, , Message-ID: <27f57625-aa64-492b-b97c-1dd11df36c31.denghui.ddh@alibaba-inc.com> I think we could wait for Andrey's reply to this issue before we decide whether to reject the backport. Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph Send Time:2019?12?9?(???) 17:17 To:???(??) ; Erik Gahlin ; jdk-updates-dev ; Andrey Petushkov ; Mario Torre Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, ok, I see. So, taking a glance on http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/, I can?t see that the bug is pushed there. So, if that?s true, I?d rather reject the backport to 11u for now. Would you agree? Thanks Christoph From: Denghui Dong Sent: Montag, 9. Dezember 2019 10:06 To: Erik Gahlin ; jdk-updates-dev ; Langer, Christoph ; Andrey Petushkov ; Mario Torre Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Christoph, I was on vacation last week, sorry for the late reply. In fact, the backport of 8185525 for 8u was requested by @Andrey at first (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html) For the sake of consistency, I made this backport for 11u. And in my opinion, these events are not very useful for users indeed. Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph Send Time:2019?12?6?(???) 16:32 To:Erik Gahlin ; jdk-updates-dev Cc:???(??) Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Erik, thanks for you input on this. I guess you have a very good point here ? the bar for backporting new events should be quite high. @Denghui: Is there any motivation for this backport from your end that comes from support requirements/customer incidents? Thanks Christoph From: Erik Gahlin Sent: Freitag, 6. Dezember 2019 05:14 To: jdk-updates-dev Cc: Denghui Dong ; Langer, Christoph Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi, What?s nice about jFR is that the file format is self-describing, so a program like JMC can see what events exist or does not exist in a recording. Still, I think the bar should be high when backporting events. Not just for stability reasons, but If different JDK distributions or update releases have different events, it will confuse users, or lead to bugs, when users switch from one JDK to another. In my opinion, events should only be backported if support engineers truly need them to diagnose a certain type of bugs in the JVM/JDK. For this happen, there should be at least a few incidents where they have come to the conclusion that the events are needed. If there are no such real cases, the events should not be backported. My $.02 Erik On 5 Dec 2019, at 23:28, Langer, Christoph wrote: Hi Denghui, since no objections were raised, I?m approving JDK-8185525. I?ll push it, once I get approval for JDK-8223599 as well. Testing in our system doesn?t show regressions. Cheers Christoph From: Langer, Christoph Sent: Freitag, 22. November 2019 00:30 To: Denghui Dong ; jdk-updates-dev Cc: Andrew Haley Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi, we had a discussion on this list regarding JFR feature requests. As a summary, I take we should 1. Generally reject backports of new features from higher releases if these are too extensive or require lots of prerequisites. Exceptions might be made if the feature to be backported exists in lower releases (e.g. OpenJDK8u after the JFR backport has been integrated) 2. Be very careful when it comes to extensive bugfixes for existing features This fix is actually on the edge of category a), since it is a new feature and it is not trivial in its nature. It needs some manual adaption but fortunately no other prerequisites. Given that Denghui has done the effort of backporting it already and the patch together with another small follow up fix runs through our regression testing at SAP successfully, I could imagine to allow it going in to 11u. I would then like to see it submitted at the early stage of the 11.0.7 cycle. So, @all, please raise objections to this decision until next Friday, 29th of November. If I don?t hear any, I?ll approve it after that date. Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 30. Oktober 2019 15:41 To: Denghui Dong >; jdk-updates-dev > Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, sorry for the late reply. I was discussing with Andrew Haley about JFR backports. He encouraged to do a general discussion on the mailing list about the policy regarding non-trivial JFR related backports, which I started just today: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-October/002053.html Let?s see if there?s any feedback? Best regards Christoph From: Denghui Dong > Sent: Dienstag, 22. Oktober 2019 04:09 To: jdk-updates-dev >; Langer, Christoph > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Christoph, What's the status of this backport ? By the way, the previous webrev didn't contain the original commit, so I uploaded a new one in http://cr.openjdk.java.net/~ddong/8185525/webrev/ Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph > Send Time:2019?10?8?(???) 22:34 To:???(??) >; jdk-updates-dev > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, this is quite a large JFR enhancement. Looking at the 11u webrev, I didn't see any obvious issues although there are obviously quite some alterations from the original patch. I'll run it through our regression testing. However, in any case, we need to carefully decide if and when we allow this patch to jdk11u-dev. I'll get back to you soon. Best regards Christoph -----Original Message----- From: jdk-updates-dev > On Behalf Of Denghui Dong Sent: Donnerstag, 26. September 2019 17:03 To: jdk-updates-dev > Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi all, Please review this backport, original patch doesn't apply cleanly, because SymbolTable has made some changes in upstream (I think it's not necessary to backport those changes) and class ClassLoaderDataGraph is located in different files. 11u-webrev: http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ Original bug: https://bugs.openjdk.java.net/browse/JDK-8185525 http://hg.openjdk.java.net/jdk/jdk/rev/865ec913f916 Testing: test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java Thanks, Denghui Dong From goetz.lindenmaier at sap.com Mon Dec 9 11:27:25 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 Dec 2019 11:27:25 +0000 Subject: [11u] RFR: 8233954: UnsatisfiedLinkError or NoSuchAlgorithmException after removing sunec.dll Message-ID: Hi, this change was just recently pushed to 11.0.6-oracle and I would like to downport it to 11.0.6 (repo jdk11u). Unfortunately it does not apply well in 11u and I had to implement parts anew. webrev: http://cr.openjdk.java.net/~goetz/wr19/8233954-UnsatisfiedLink_in_EC-jdk11/01/ bug: https://bugs.openjdk.java.net/browse/JDK-8233954 orig. change: https://hg.openjdk.java.net/jdk/jdk/rev/e7df7c86eda1 The patch to file NamedGroup.java did not apply. File NamedGroup.java was only introduced with https://bugs.openjdk.java.net/browse/JDK-8171279: "8171279: Support X25519 and X448 in TLS" Before, the code lived in SupportedGroupsExtension.java. 8171279 added a new constructor to NamedGroup. After introducing NamedGroup.java, https://bugs.openjdk.java.net/browse/JDK-8226374 "8226374: Restrict TLS signature schemes and named groups" changed the new constructor. I had to implement this anew. There are two constructors for "EC" NamedGroups. In these, I check for JsseJce.isEcAvailable(). If this is not available, I mark the whole NamedGroup as not available in new boolean isEcAvailable. The original patch sets 'mediator' which then is assigned to NamedGroup.isAvailable. This field again is checked in the two isAvailable(...) functions. Field NamedGroup.isAvailable is not implemented in 11. Therefor I added a similar check for my field isEcAvailable in these functions. I chose a different name to distinguish from 14's isAvailable because that is used in other contexts, too. For SignatureScheme.java I had to do some adaptions to apply the change. signAlgParamSpec was renamed to signAlgParams in 14, see https://bugs.openjdk.java.net/browse/JDK-8226374: "8226374: Restrict TLS signature schemes and named groups" I had to undo the renaming in the patch. JsseJce.getSignature() was renamed to Signature.getInstance in https://bugs.openjdk.java.net/browse/JDK-8217835: "8217835: Remove the experimental SunJSSE FIPS compliant mode" I had to undo this in the patch, too. I ran the test that is patched into the bug description. It fails without my adapted change, and passes with it. Please review. Best regards, Goetz. From matthias.baesken at sap.com Mon Dec 9 11:36:43 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 9 Dec 2019 11:36:43 +0000 Subject: RFR [XS] : 8235478: [jdk11] handle VS2017 15.9 and VS2019 in vm_version.cpp Message-ID: Hello, please review this small jdk11 change . It handles VS2017 15.9 and VS2019 in vm_version.cpp . More or less it is a jdk11 - downport of what 8235243 + 8235325 do , but in jdk/jdk . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8235478 http://cr.openjdk.java.net/~mbaesken/webrevs/8235478.0/ Thanks, Matthias From andrey at azul.com Mon Dec 9 12:08:25 2019 From: andrey at azul.com (Andrey Petushkov) Date: Mon, 9 Dec 2019 12:08:25 +0000 Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes In-Reply-To: <27f57625-aa64-492b-b97c-1dd11df36c31.denghui.ddh@alibaba-inc.com> References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com> <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com> <23451B8D-FE0A-4508-94F4-660CA2DA923B@oracle.com> <27f57625-aa64-492b-b97c-1dd11df36c31.denghui.ddh@alibaba-inc.com> Message-ID: Hi guys, All, No, there is not special reasoning for back-porting of this particular event type. Feel free to reject the request. A few comments though - we at Azul see JFR as a very useful and successful tool for solving customer issues. So in general we try to keep up with new fixes and features there, unless we consider fix as too risky or inappropriate - all these JFR backports proposed are undergo full test cycle, involving all tests we have (including of course all jtreg) on all platforms supported by Azul (well, a lot) - @Christoph regarding fix not yet pushed to 8u. We (Marrio and team involved into JFR to 8u backporting) have a policy that we don't push into 8u until it's pushed into 11u. Hence it's not pushed Regards, Andrey > On 9 Dec 2019, at 12:33, Denghui Dong wrote: > > I think we could wait for Andrey's reply to this issue before we decide whether to reject the backport. > > Thanks, > Denghui Dong > ------------------------------------------------------------------ > From:Langer, Christoph > > Send Time:2019?12?9?(???) 17:17 > To:???(??) ; Erik Gahlin ; jdk-updates-dev ; Andrey Petushkov ; Mario Torre > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi Denghui, > > ok, I see. So, taking a glance on http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/ , I can?t see that the bug is pushed there. So, if that?s true, I?d rather reject the backport to 11u for now. Would you agree? > > Thanks > Christoph > > From: Denghui Dong > Sent: Montag, 9. Dezember 2019 10:06 > To: Erik Gahlin ; jdk-updates-dev ; Langer, Christoph ; Andrey Petushkov ; Mario Torre > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi Christoph, > I was on vacation last week, sorry for the late reply. > In fact, the backport of 8185525 for 8u was requested by @Andrey at first (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html ) > For the sake of consistency, I made this backport for 11u. > And in my opinion, these events are not very useful for users indeed. > > Thanks, > Denghui Dong > ------------------------------------------------------------------ > From:Langer, Christoph > > Send Time:2019?12?6?(???) 16:32 > To:Erik Gahlin >; jdk-updates-dev > > Cc:???(??) > > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi Erik, > > thanks for you input on this. I guess you have a very good point here ? the bar for backporting new events should be quite high. > > @Denghui: Is there any motivation for this backport from your end that comes from support requirements/customer incidents? > > Thanks > Christoph > > From: Erik Gahlin > > Sent: Freitag, 6. Dezember 2019 05:14 > To: jdk-updates-dev > > Cc: Denghui Dong >; Langer, Christoph > > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi, > > What?s nice about jFR is that the file format is self-describing, so a program like JMC can see what events exist or does not exist in a recording. > > Still, I think the bar should be high when backporting events. Not just for stability reasons, but If different JDK distributions or update releases have different events, it will confuse users, or lead to bugs, when users switch from one JDK to another. > > In my opinion, events should only be backported if support engineers truly need them to diagnose a certain type of bugs in the JVM/JDK. For this happen, there should be at least a few incidents where they have come to the conclusion that the events are needed. If there are no such real cases, the events should not be backported. > > My $.02 > > Erik > > On 5 Dec 2019, at 23:28, Langer, Christoph > wrote: > > Hi Denghui, > > since no objections were raised, I?m approving JDK-8185525. I?ll push it, once I get approval for JDK-8223599 as well. Testing in our system doesn?t show regressions. > > Cheers > Christoph > > From: Langer, Christoph > Sent: Freitag, 22. November 2019 00:30 > To: Denghui Dong >; jdk-updates-dev > > Cc: Andrew Haley > > Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi, > > we had a discussion on this list regarding JFR feature requests. As a summary, I take we should > > 1. Generally reject backports of new features from higher releases if these are too extensive or require lots of prerequisites. Exceptions might be made if the feature to be backported exists in lower releases (e.g. OpenJDK8u after the JFR backport has been integrated) > 2. Be very careful when it comes to extensive bugfixes for existing features > > This fix is actually on the edge of category a), since it is a new feature and it is not trivial in its nature. It needs some manual adaption but fortunately no other prerequisites. > > Given that Denghui has done the effort of backporting it already and the patch together with another small follow up fix runs through our regression testing at SAP successfully, I could imagine to allow it going in to 11u. I would then like to see it submitted at the early stage of the 11.0.7 cycle. > > So, @all, please raise objections to this decision until next Friday, 29th of November. If I don?t hear any, I?ll approve it after that date. > > Thanks > Christoph > > From: Langer, Christoph > Sent: Mittwoch, 30. Oktober 2019 15:41 > To: Denghui Dong >>; jdk-updates-dev >> > Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi Denghui, > > sorry for the late reply. > > I was discussing with Andrew Haley about JFR backports. He encouraged to do a general discussion on the mailing list about the policy regarding non-trivial JFR related backports, which I started just today: > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-October/002053.html > Let?s see if there?s any feedback? > > Best regards > Christoph > > From: Denghui Dong >> > Sent: Dienstag, 22. Oktober 2019 04:09 > To: jdk-updates-dev >>; Langer, Christoph >> > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi Christoph, > What's the status of this backport ? > By the way, the previous webrev didn't contain the original commit, so I uploaded a new one in http://cr.openjdk.java.net/~ddong/8185525/webrev/ > > Thanks, > Denghui Dong > ------------------------------------------------------------------ > From:Langer, Christoph >> > Send Time:2019?10?8?(???) 22:34 > To:???(??) >>; jdk-updates-dev >> > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi Denghui, > > this is quite a large JFR enhancement. > > Looking at the 11u webrev, I didn't see any obvious issues although there are obviously quite some alterations from the original patch. I'll run it through our regression testing. > > However, in any case, we need to carefully decide if and when we allow this patch to jdk11u-dev. I'll get back to you soon. > > Best regards > Christoph > > > -----Original Message----- > From: jdk-updates-dev >> On > Behalf Of Denghui Dong > Sent: Donnerstag, 26. September 2019 17:03 > To: jdk-updates-dev >> > Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi all, > Please review this backport, original patch doesn't apply cleanly, because > SymbolTable has made some changes in upstream (I think it's not necessary > to backport those changes) > and class ClassLoaderDataGraph is located in different files. > 11u-webrev: > http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8185525 > http://hg.openjdk.java.net/jdk/jdk/rev/865ec913f916 > Testing: test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java > > Thanks, > Denghui Dong From goetz.lindenmaier at sap.com Mon Dec 9 15:13:30 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 Dec 2019 15:13:30 +0000 Subject: [11u] RFR 8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing Message-ID: Hi, I would like to downport this change. I assume Oracle downported this change too. They downported 8217613, which changes in the code introduced by this change. Unfortunately, this change is closed. I have asked to open it up, though. I had to do a simple resolve in RunTestsPrebuilt.gmk. 11 passes an additional argument to macro CreateNewSpec (MEMORY_SIZE), therefore the patch did not apply. webrev: http://cr.openjdk.java.net/~goetz/wr19/8152988-AOT_test_definition-jdk11/01/ orig change: http://hg.openjdk.java.net/jdk/jdk/rev/ff10f8f3a583 bug https://bugs.openjdk.java.net/browse/JDK-8152988 Best regards, Goetz. From christoph.langer at sap.com Tue Dec 10 08:44:09 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 10 Dec 2019 08:44:09 +0000 Subject: [11u] RFR 8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing In-Reply-To: References: Message-ID: Hi Goetz, this looks good to me and I see that there are no regressions. So, thumbs up. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 9. Dezember 2019 16:14 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR 8152988: [AOT] Update test batch definitions > to include aot-ed java.base module mode into hs-comp testing > > Hi, > > I would like to downport this change. > I assume Oracle downported this change too. > They downported 8217613, which changes in the code introduced by > this change. Unfortunately, this change is closed. I have asked to > open it up, though. > > I had to do a simple resolve in RunTestsPrebuilt.gmk. > 11 passes an additional argument to macro CreateNewSpec (MEMORY_SIZE), > therefore the patch did not apply. > > webrev: http://cr.openjdk.java.net/~goetz/wr19/8152988- > AOT_test_definition-jdk11/01/ > orig change: http://hg.openjdk.java.net/jdk/jdk/rev/ff10f8f3a583 > bug https://bugs.openjdk.java.net/browse/JDK-8152988 > > Best regards, > Goetz. From fedor.burdun at azul.com Wed Dec 11 14:36:10 2019 From: fedor.burdun at azul.com (Fedor) Date: Wed, 11 Dec 2019 17:36:10 +0300 Subject: [11u,13u] RFR: backport of 8231507: Update Apache Santuario (XML Signature) to version 2.1.4 Message-ID: Hello all, I would like to ask for review backport of JDK-8231507 (Update Apache Santuario (XML Signature) to version 2.1.4) bug: https://bugs.openjdk.java.net/browse/JDK-8231507 webrev: http://cr.openjdk.java.net/~fijiol/8231507/webrev.13u.00/ tests: test/jdk/com/sun/org/apache/xml/ test/jdk/javax/xml/crypto/dsig/ It mostly applied cleanly, the only merge-conflict was in comments of XMLDSigRI.java file, which was updated as in jdk14: >>>>>>>>>>>>>>>> @@ -134,7 +134,8 @@ } public XMLDSigRI() { - /* We are the XMLDSig provider */ + // This is the JDK XMLDSig provider, synced from + // Apache Santuario XML Security for Java, version 2.1.4 super("XMLDSig", VER, INFO); final Provider p = this; >>>>>>>>>>>>>>>> Thanks, Fedor From matthias.baesken at sap.com Wed Dec 11 16:02:05 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 11 Dec 2019 16:02:05 +0000 Subject: RFR [XS] : 8235478: [jdk11] handle VS2017 15.9 and VS2019 in vm_version.cpp Message-ID: Ping ... any reviews please ? Best regards, Matthias From: Baesken, Matthias Sent: Montag, 9. Dezember 2019 12:37 To: jdk-updates-dev at openjdk.java.net Cc: 'hotspot-dev at openjdk.java.net' Subject: RFR [XS] : 8235478: [jdk11] handle VS2017 15.9 and VS2019 in vm_version.cpp Hello, please review this small jdk11 change . It handles VS2017 15.9 and VS2019 in vm_version.cpp . More or less it is a jdk11 - downport of what 8235243 + 8235325 do , but in jdk/jdk . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8235478 http://cr.openjdk.java.net/~mbaesken/webrevs/8235478.0/ Thanks, Matthias From christoph.langer at sap.com Wed Dec 11 19:29:22 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Dec 2019 19:29:22 +0000 Subject: [CAUTION] [11u] RFR: 8233954: UnsatisfiedLinkError or NoSuchAlgorithmException after removing sunec.dll In-Reply-To: References: Message-ID: Hi Goetz, Wow, that was a bit more than just apply/trivial resolve. I'm wondering whether in line 346 one should go with "this.isEcAvailable = true;" since this constructor is used for NamedGroupType.NAMED_GROUP_ARBITRARY. And JDK-8233954 does the mediator check only for NamedGroupSpec.NAMED_GROUP_ECDHE which is covered in line 306. So, this would probably match the behavior of JDK-8233954 more precisely. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 9. Dezember 2019 12:27 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 8233954: UnsatisfiedLinkError or > NoSuchAlgorithmException after removing sunec.dll > > Hi, > > this change was just recently pushed to 11.0.6-oracle and I would > like to downport it to 11.0.6 (repo jdk11u). > > Unfortunately it does not apply well in 11u and I had to implement > parts anew. > webrev: http://cr.openjdk.java.net/~goetz/wr19/8233954- > UnsatisfiedLink_in_EC-jdk11/01/ > bug: https://bugs.openjdk.java.net/browse/JDK-8233954 > orig. change: https://hg.openjdk.java.net/jdk/jdk/rev/e7df7c86eda1 > > The patch to file NamedGroup.java did not apply. > File NamedGroup.java was only introduced with > https://bugs.openjdk.java.net/browse/JDK-8171279: "8171279: Support > X25519 and X448 in TLS" > Before, the code lived in SupportedGroupsExtension.java. > 8171279 added a new constructor to NamedGroup. > After introducing NamedGroup.java, > https://bugs.openjdk.java.net/browse/JDK-8226374 "8226374: Restrict TLS > signature schemes and named groups" > changed the new constructor. > I had to implement this anew. > There are two constructors for "EC" NamedGroups. > In these, I check for JsseJce.isEcAvailable(). > If this is not available, I mark the whole NamedGroup as > not available in new boolean isEcAvailable. > > The original patch sets 'mediator' which then is > assigned to NamedGroup.isAvailable. This field again > is checked in the two isAvailable(...) functions. > > Field NamedGroup.isAvailable is not implemented in 11. > Therefor I added a similar check for my field isEcAvailable in these > functions. I chose a different name to distinguish from 14's > isAvailable because that is used in other contexts, too. > > For SignatureScheme.java I had to do some adaptions to apply the change. > > signAlgParamSpec was renamed to signAlgParams in 14, see > https://bugs.openjdk.java.net/browse/JDK-8226374: "8226374: Restrict TLS > signature schemes and named groups" > I had to undo the renaming in the patch. > > JsseJce.getSignature() was renamed to Signature.getInstance in > https://bugs.openjdk.java.net/browse/JDK-8217835: "8217835: Remove the > experimental SunJSSE FIPS compliant mode" > I had to undo this in the patch, too. > > I ran the test that is patched into the bug description. It fails without my > adapted change, and passes with it. > > Please review. > > Best regards, > Goetz. > > From christoph.langer at sap.com Thu Dec 12 10:46:36 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 Dec 2019 10:46:36 +0000 Subject: RFR [XS] : 8235478: [jdk11] handle VS2017 15.9 and VS2019 in vm_version.cpp In-Reply-To: References: Message-ID: Hi Matthias, the change itself looks good. However, your approach to create a new bug which is actually a backport of two other bugs is not the right thing to do. I converted JDK-8235478 to be a backport of JDK-8235243. Now, please request backport approval in JDK-8235243 and JDK-8235325. Once it's approved, please push your change with a commit message that resolves both items, that is: 8235243: handle VS2017 15.9 and VS2019 in abstract_vm_version 8235325: build failure on Linux after 8235243 Reviewed-by: dholmes, mdoerr This will pick up and resolve JDK-8235478 as backport of 8235243 and create/resolve another backport item for 8235325. Best regards Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Montag, 9. Dezember 2019 12:37 > To: jdk-updates-dev at openjdk.java.net > Cc: 'hotspot-dev at openjdk.java.net' > Subject: RFR [XS] : 8235478: [jdk11] handle VS2017 15.9 and VS2019 in > vm_version.cpp > > Hello, please review this small jdk11 change . > It handles VS2017 15.9 and VS2019 in vm_version.cpp . > > More or less it is a jdk11 - downport of what 8235243 + 8235325 do , but in > jdk/jdk . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8235478 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8235478.0/ > > > Thanks, Matthias From christoph.langer at sap.com Thu Dec 12 10:55:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 Dec 2019 10:55:25 +0000 Subject: [11u, 13u] RFR: backport of 8231507: Update Apache Santuario (XML Signature) to version 2.1.4 In-Reply-To: References: Message-ID: Hi Fedor, thanks for doing this backport. Change looks good - Reviewed. As for the JBS item: Please add a fix request comment with some justification for the backport and a link to this review thread. Then I can approve it. Thanks & Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Fedor > Sent: Mittwoch, 11. Dezember 2019 15:36 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u,13u] RFR: backport of 8231507: Update Apache Santuario (XML > Signature) to version 2.1.4 > > Hello all, > > I would like to ask for review backport of JDK-8231507 (Update Apache > Santuario (XML Signature) to version 2.1.4) > > bug: https://bugs.openjdk.java.net/browse/JDK-8231507 > webrev: http://cr.openjdk.java.net/~fijiol/8231507/webrev.13u.00/ > tests: test/jdk/com/sun/org/apache/xml/ test/jdk/javax/xml/crypto/dsig/ > > It mostly applied cleanly, the only merge-conflict was in comments of > XMLDSigRI.java file, which was updated as in jdk14: > > >>>>>>>>>>>>>>>> > @@ -134,7 +134,8 @@ > } > > public XMLDSigRI() { > - /* We are the XMLDSig provider */ > + // This is the JDK XMLDSig provider, synced from > + // Apache Santuario XML Security for Java, version 2.1.4 > super("XMLDSig", VER, INFO); > > final Provider p = this; > >>>>>>>>>>>>>>>> > > > Thanks, > Fedor From matthias.baesken at sap.com Thu Dec 12 11:19:01 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 12 Dec 2019 11:19:01 +0000 Subject: RFR [XS] : 8235478: [jdk11] handle VS2017 15.9 and VS2019 in vm_version.cpp In-Reply-To: References: Message-ID: Hi Christoph, thanks . > , please request backport approval in JDK- > 8235243 and JDK-8235325. I added the jdk11u-fix-request label to both bugs . Best regards, Matthias > Hi Matthias, > > the change itself looks good. > > However, your approach to create a new bug which is actually a backport of > two other bugs is not the right thing to do. I converted JDK-8235478 to be a > backport of JDK-8235243. Now, please request backport approval in JDK- > 8235243 and JDK-8235325. Once it's approved, please push your change with > a commit message that resolves both items, that is: > > 8235243: handle VS2017 15.9 and VS2019 in abstract_vm_version > 8235325: build failure on Linux after 8235243 > Reviewed-by: dholmes, mdoerr > > This will pick up and resolve JDK-8235478 as backport of 8235243 and > create/resolve another backport item for 8235325. > > Best regards > Christoph > > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Montag, 9. Dezember 2019 12:37 > > To: jdk-updates-dev at openjdk.java.net > > Cc: 'hotspot-dev at openjdk.java.net' > > Subject: RFR [XS] : 8235478: [jdk11] handle VS2017 15.9 and VS2019 in > > vm_version.cpp > > > > Hello, please review this small jdk11 change . > > It handles VS2017 15.9 and VS2019 in vm_version.cpp . > > > > More or less it is a jdk11 - downport of what 8235243 + 8235325 do , but in > > jdk/jdk . > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8235478 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8235478.0/ > > > > > > Thanks, Matthias From fedor.burdun at azul.com Thu Dec 12 13:01:15 2019 From: fedor.burdun at azul.com (Fedor) Date: Thu, 12 Dec 2019 16:01:15 +0300 Subject: [11u, 13u] RFR: backport of 8231507: Update Apache Santuario (XML Signature) to version 2.1.4 In-Reply-To: References: Message-ID: <0e17fc42-4911-0221-d69b-8d4e78947f70@azul.com> Hi Christoph, Fix request comment has been added. Thanks, Fedor On 12.12.2019 13:55, Langer, Christoph wrote: > Hi Fedor, > > thanks for doing this backport. Change looks good - Reviewed. > > As for the JBS item: Please add a fix request comment with some justification for the backport and a link to this review thread. Then I can approve it. > > Thanks & Best regards > Christoph > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Fedor >> Sent: Mittwoch, 11. Dezember 2019 15:36 >> To: jdk-updates-dev at openjdk.java.net >> Subject: [11u,13u] RFR: backport of 8231507: Update Apache Santuario (XML >> Signature) to version 2.1.4 >> >> Hello all, >> >> I would like to ask for review backport of JDK-8231507 (Update Apache >> Santuario (XML Signature) to version 2.1.4) >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8231507 >> webrev: http://cr.openjdk.java.net/~fijiol/8231507/webrev.13u.00/ >> tests: test/jdk/com/sun/org/apache/xml/ test/jdk/javax/xml/crypto/dsig/ >> >> It mostly applied cleanly, the only merge-conflict was in comments of >> XMLDSigRI.java file, which was updated as in jdk14: >> >> >>>>>>>>>>>>>>>> >> @@ -134,7 +134,8 @@ >> } >> >> public XMLDSigRI() { >> - /* We are the XMLDSig provider */ >> + // This is the JDK XMLDSig provider, synced from >> + // Apache Santuario XML Security for Java, version 2.1.4 >> super("XMLDSig", VER, INFO); >> >> final Provider p = this; >> >>>>>>>>>>>>>>>> >> >> >> Thanks, >> Fedor > From christoph.langer at sap.com Thu Dec 12 13:28:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 Dec 2019 13:28:57 +0000 Subject: [11u, 13u] RFR: backport of 8231507: Update Apache Santuario (XML Signature) to version 2.1.4 In-Reply-To: <0e17fc42-4911-0221-d69b-8d4e78947f70@azul.com> References: <0e17fc42-4911-0221-d69b-8d4e78947f70@azul.com> Message-ID: Hi Fedor, Thanks, I approved it. Best regards Christoph > -----Original Message----- > From: Fedor > Sent: Donnerstag, 12. Dezember 2019 14:01 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u,13u] RFR: backport of 8231507: Update Apache Santuario > (XML Signature) to version 2.1.4 > > Hi Christoph, > > Fix request comment has been added. > > Thanks, > Fedor > > On 12.12.2019 13:55, Langer, Christoph wrote: > > Hi Fedor, > > > > thanks for doing this backport. Change looks good - Reviewed. > > > > As for the JBS item: Please add a fix request comment with some > justification for the backport and a link to this review thread. Then I can > approve it. > > > > Thanks & Best regards > > Christoph > > > >> -----Original Message----- > >> From: jdk-updates-dev > On > >> Behalf Of Fedor > >> Sent: Mittwoch, 11. Dezember 2019 15:36 > >> To: jdk-updates-dev at openjdk.java.net > >> Subject: [11u,13u] RFR: backport of 8231507: Update Apache Santuario > (XML > >> Signature) to version 2.1.4 > >> > >> Hello all, > >> > >> I would like to ask for review backport of JDK-8231507 (Update Apache > >> Santuario (XML Signature) to version 2.1.4) > >> > >> bug: https://bugs.openjdk.java.net/browse/JDK-8231507 > >> webrev: http://cr.openjdk.java.net/~fijiol/8231507/webrev.13u.00/ > >> tests: test/jdk/com/sun/org/apache/xml/ > test/jdk/javax/xml/crypto/dsig/ > >> > >> It mostly applied cleanly, the only merge-conflict was in comments of > >> XMLDSigRI.java file, which was updated as in jdk14: > >> > >> >>>>>>>>>>>>>>>> > >> @@ -134,7 +134,8 @@ > >> } > >> > >> public XMLDSigRI() { > >> - /* We are the XMLDSig provider */ > >> + // This is the JDK XMLDSig provider, synced from > >> + // Apache Santuario XML Security for Java, version 2.1.4 > >> super("XMLDSig", VER, INFO); > >> > >> final Provider p = this; > >> >>>>>>>>>>>>>>>> > >> > >> > >> Thanks, > >> Fedor > > From jaroslav.bachorik at datadoghq.com Thu Dec 12 15:39:14 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Thu, 12 Dec 2019 16:39:14 +0100 Subject: [11u] [JFR] RFR 8209850: Allow NamedThreads to use GlobalCounter critical sections Message-ID: Hi all, please, review this backport which is a prerequisite for the planned backport of JDK-8225797 JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209850 Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/ The patch applies with fuzz and the patch diff is listed at http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff Thanks, -JB- From hohensee at amazon.com Thu Dec 12 16:09:45 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 12 Dec 2019 16:09:45 +0000 Subject: [11u] [JFR] RFR 8209850: Allow NamedThreads to use GlobalCounter critical sections In-Reply-To: References: Message-ID: <6F95ACF2-0C4D-4A0B-A56B-A265BCFD2994@amazon.com> Lgtm. Paul ?On 12/12/19, 7:41 AM, "jdk-updates-dev on behalf of Jaroslav Bachor?k" wrote: Hi all, please, review this backport which is a prerequisite for the planned backport of JDK-8225797 JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209850 Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/ The patch applies with fuzz and the patch diff is listed at http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff Thanks, -JB- From goetz.lindenmaier at sap.com Fri Dec 13 08:11:45 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 13 Dec 2019 08:11:45 +0000 Subject: [CAUTION] [11u] RFR: 8233954: UnsatisfiedLinkError or NoSuchAlgorithmException after removing sunec.dll In-Reply-To: References: Message-ID: Hi Christoph, I tested your proposeal, all test pass, as well as the one from the bug description (after removing libsunec from the jdk). http://cr.openjdk.java.net/~goetz/wr19/8233954-UnsatisfiedLink_in_EC-jdk11/02/ And you are right, in case of NamedGroupType.NAMED_GROUP_ARBITRARY the original change does not check the availability of the algorithm. So these non-elliptic encryptions are processed by other code and not the libsunec? Or is just the test not excercising this case? Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Wednesday, December 11, 2019 8:29 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [CAUTION] [11u] RFR: 8233954: UnsatisfiedLinkError or > NoSuchAlgorithmException after removing sunec.dll > > Hi Goetz, > > Wow, that was a bit more than just apply/trivial resolve. > > I'm wondering whether in line 346 one should go with "this.isEcAvailable = > true;" since this constructor is used for > NamedGroupType.NAMED_GROUP_ARBITRARY. And JDK-8233954 does the > mediator check only for NamedGroupSpec.NAMED_GROUP_ECDHE which is > covered in line 306. So, this would probably match the behavior of JDK- > 8233954 more precisely. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Montag, 9. Dezember 2019 12:27 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR: 8233954: UnsatisfiedLinkError or > > NoSuchAlgorithmException after removing sunec.dll > > > > Hi, > > > > this change was just recently pushed to 11.0.6-oracle and I would > > like to downport it to 11.0.6 (repo jdk11u). > > > > Unfortunately it does not apply well in 11u and I had to implement > > parts anew. > > webrev: http://cr.openjdk.java.net/~goetz/wr19/8233954- > > UnsatisfiedLink_in_EC-jdk11/01/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8233954 > > orig. change: https://hg.openjdk.java.net/jdk/jdk/rev/e7df7c86eda1 > > > > The patch to file NamedGroup.java did not apply. > > File NamedGroup.java was only introduced with > > https://bugs.openjdk.java.net/browse/JDK-8171279: "8171279: Support > > X25519 and X448 in TLS" > > Before, the code lived in SupportedGroupsExtension.java. > > 8171279 added a new constructor to NamedGroup. > > After introducing NamedGroup.java, > > https://bugs.openjdk.java.net/browse/JDK-8226374 "8226374: Restrict TLS > > signature schemes and named groups" > > changed the new constructor. > > I had to implement this anew. > > There are two constructors for "EC" NamedGroups. > > In these, I check for JsseJce.isEcAvailable(). > > If this is not available, I mark the whole NamedGroup as > > not available in new boolean isEcAvailable. > > > > The original patch sets 'mediator' which then is > > assigned to NamedGroup.isAvailable. This field again > > is checked in the two isAvailable(...) functions. > > > > Field NamedGroup.isAvailable is not implemented in 11. > > Therefor I added a similar check for my field isEcAvailable in these > > functions. I chose a different name to distinguish from 14's > > isAvailable because that is used in other contexts, too. > > > > For SignatureScheme.java I had to do some adaptions to apply the change. > > > > signAlgParamSpec was renamed to signAlgParams in 14, see > > https://bugs.openjdk.java.net/browse/JDK-8226374: "8226374: Restrict TLS > > signature schemes and named groups" > > I had to undo the renaming in the patch. > > > > JsseJce.getSignature() was renamed to Signature.getInstance in > > https://bugs.openjdk.java.net/browse/JDK-8217835: "8217835: Remove > the > > experimental SunJSSE FIPS compliant mode" > > I had to undo this in the patch, too. > > > > I ran the test that is patched into the bug description. It fails without my > > adapted change, and passes with it. > > > > Please review. > > > > Best regards, > > Goetz. > > > > From christoph.langer at sap.com Fri Dec 13 08:28:03 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 13 Dec 2019 08:28:03 +0000 Subject: [CAUTION] [11u] RFR: 8233954: UnsatisfiedLinkError or NoSuchAlgorithmException after removing sunec.dll In-Reply-To: References: Message-ID: Hi Goetz, > I tested your proposeal, all test pass, as well as the one from > the bug description (after removing libsunec from the jdk). > http://cr.openjdk.java.net/~goetz/wr19/8233954-UnsatisfiedLink_in_EC- > jdk11/02/ Looks good then. > And you are right, in case of > NamedGroupType.NAMED_GROUP_ARBITRARY > the original change does not check the availability of the > algorithm. > So these non-elliptic encryptions are processed by other code > and not the libsunec? > Or is just the test not excercising this case? As my knowledge in that area is limited, I can't answer this question. But in that case I guess it's even more important to do exactly what the upstream patch does ?? Cheers Christoph From goetz.lindenmaier at sap.com Fri Dec 13 11:42:57 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 13 Dec 2019 11:42:57 +0000 Subject: [11u] Downport closed changes? Message-ID: Hi, Although Oracle has the policy to push only changes that have publicly visible JBS bugs, they once in a while push changes where the bug is hidden. Currently, we can see which changes are downported by Oracle to their internal 11u project, and do so for OpenJDK, too. This is not the case for such closed bugs. Therefore I enumerated these closed bugs and want to ask the 11u community to scan the list and eventually downport changes that seem useful in 11u. Overall, there are 78 bugs to look at, see this list: http://cr.openjdk.java.net/~goetz/closed_bugs_not_in_11/closed_bugs_not_in_11.html Often, Oracle engineers are so friendly to open up the issues if asked to do so. This is helpful to process a downport to 11. Find the script to generate the content of the list at the bottom. Best regards, Goetz From chris.hegarty at oracle.com Fri Dec 13 12:05:04 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 13 Dec 2019 12:05:04 +0000 Subject: [11u] Downport closed changes? In-Reply-To: References: Message-ID: Hi, > On 13 Dec 2019, at 11:42, Lindenmaier, Goetz wrote: > > Hi, > > Although Oracle has the policy to push only changes that have > publicly visible JBS bugs, they once in a while push changes > where the bug is hidden. > Currently, we can see which changes are downported by Oracle > to their internal 11u project, and do so for OpenJDK, too. > This is not the case for such closed bugs. > > Therefore I enumerated these closed bugs and want to ask > the 11u community to scan the list and eventually downport > changes that seem useful in 11u. > > Overall, there are 78 bugs to look at, see this list: > http://cr.openjdk.java.net/~goetz/closed_bugs_not_in_11/closed_bugs_not_in_11.html Maybe I don?t understand what this list is trying to convey, so as an example: 8223892 is on the list, but is also in jdk11u [1]. Why is 8223892 on the list if it is already in 11u? -Chris. [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/log?rev=8223892 From goetz.lindenmaier at sap.com Fri Dec 13 12:11:30 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 13 Dec 2019 12:11:30 +0000 Subject: [11u] Downport closed changes? In-Reply-To: References: Message-ID: Hi Chris, The list has two parts: First changes that are not in 11u. Second changes that are closed but already in 11u. Second holds for all the security fixes, e.g.. Maybe I should put it on two pages ... it's easy to miss the heading in the middle. Best, Goetz. > -----Original Message----- > From: Chris Hegarty > Sent: Friday, December 13, 2019 1:05 PM > To: Lindenmaier, Goetz > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] Downport closed changes? > > Hi, > > > On 13 Dec 2019, at 11:42, Lindenmaier, Goetz > wrote: > > > > Hi, > > > > Although Oracle has the policy to push only changes that have > > publicly visible JBS bugs, they once in a while push changes > > where the bug is hidden. > > Currently, we can see which changes are downported by Oracle > > to their internal 11u project, and do so for OpenJDK, too. > > This is not the case for such closed bugs. > > > > Therefore I enumerated these closed bugs and want to ask > > the 11u community to scan the list and eventually downport > > changes that seem useful in 11u. > > > > Overall, there are 78 bugs to look at, see this list: > > > http://cr.openjdk.java.net/~goetz/closed_bugs_not_in_11/closed_bugs_no > t_in_11.html > > > Maybe I don?t understand what this list is trying to convey, so as an > example: 8223892 is on the list, but is also in jdk11u [1]. Why is > 8223892 on the list if it is already in 11u? > > -Chris. > > [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/log?rev=8223892 From goetz.lindenmaier at sap.com Fri Dec 13 12:19:01 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 13 Dec 2019 12:19:01 +0000 Subject: [11u] Downport closed changes? In-Reply-To: References: Message-ID: Hi, To avoid confusion, I split the page in two ... Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Friday, December 13, 2019 1:12 PM > To: 'Chris Hegarty' > Cc: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] RE: [11u] Downport closed changes? > > Hi Chris, > > The list has two parts: > First changes that are not in 11u. > Second changes that are closed but already in 11u. > Second holds for all the security fixes, e.g.. > > Maybe I should put it on two pages ... it's easy to > miss the heading in the middle. > > Best, > Goetz. > > > -----Original Message----- > > From: Chris Hegarty > > Sent: Friday, December 13, 2019 1:05 PM > > To: Lindenmaier, Goetz > > Cc: jdk-updates-dev at openjdk.java.net > > Subject: Re: [11u] Downport closed changes? > > > > Hi, > > > > > On 13 Dec 2019, at 11:42, Lindenmaier, Goetz > > > wrote: > > > > > > Hi, > > > > > > Although Oracle has the policy to push only changes that have > > > publicly visible JBS bugs, they once in a while push changes > > > where the bug is hidden. > > > Currently, we can see which changes are downported by Oracle > > > to their internal 11u project, and do so for OpenJDK, too. > > > This is not the case for such closed bugs. > > > > > > Therefore I enumerated these closed bugs and want to ask > > > the 11u community to scan the list and eventually downport > > > changes that seem useful in 11u. > > > > > > Overall, there are 78 bugs to look at, see this list: > > > > > > http://cr.openjdk.java.net/~goetz/closed_bugs_not_in_11/closed_bugs_no > > t_in_11.html > > > > > > Maybe I don?t understand what this list is trying to convey, so as an > > example: 8223892 is on the list, but is also in jdk11u [1]. Why is > > 8223892 on the list if it is already in 11u? > > > > -Chris. > > > > [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/log?rev=8223892 From chris.hegarty at oracle.com Fri Dec 13 12:25:00 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 13 Dec 2019 12:25:00 +0000 Subject: [11u] Downport closed changes? In-Reply-To: References: Message-ID: <3431DBAB-ACA7-4FC2-B4BE-1E7E34E77176@oracle.com> Hi Goetz, > On 13 Dec 2019, at 12:19, Lindenmaier, Goetz wrote: > > Hi, > > To avoid confusion, I split the page in two ? Thanks for the clarification. I quickly scanned the list and opened any bug that I am confident was mistakenly not-open in the first place. So, just 8203672 ( that I know of ). -Chris. > Best regards, > Goetz. > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Lindenmaier, Goetz >> Sent: Friday, December 13, 2019 1:12 PM >> To: 'Chris Hegarty' >> Cc: jdk-updates-dev at openjdk.java.net >> Subject: [CAUTION] RE: [11u] Downport closed changes? >> >> Hi Chris, >> >> The list has two parts: >> First changes that are not in 11u. >> Second changes that are closed but already in 11u. >> Second holds for all the security fixes, e.g.. >> >> Maybe I should put it on two pages ... it's easy to >> miss the heading in the middle. >> >> Best, >> Goetz. >> >>> -----Original Message----- >>> From: Chris Hegarty >>> Sent: Friday, December 13, 2019 1:05 PM >>> To: Lindenmaier, Goetz >>> Cc: jdk-updates-dev at openjdk.java.net >>> Subject: Re: [11u] Downport closed changes? >>> >>> Hi, >>> >>>> On 13 Dec 2019, at 11:42, Lindenmaier, Goetz >> >>> wrote: >>>> >>>> Hi, >>>> >>>> Although Oracle has the policy to push only changes that have >>>> publicly visible JBS bugs, they once in a while push changes >>>> where the bug is hidden. >>>> Currently, we can see which changes are downported by Oracle >>>> to their internal 11u project, and do so for OpenJDK, too. >>>> This is not the case for such closed bugs. >>>> >>>> Therefore I enumerated these closed bugs and want to ask >>>> the 11u community to scan the list and eventually downport >>>> changes that seem useful in 11u. >>>> >>>> Overall, there are 78 bugs to look at, see this list: >>>> >>> >> http://cr.openjdk.java.net/~goetz/closed_bugs_not_in_11/closed_bugs_no >>> t_in_11.html >>> >>> >>> Maybe I don?t understand what this list is trying to convey, so as an >>> example: 8223892 is on the list, but is also in jdk11u [1]. Why is >>> 8223892 on the list if it is already in 11u? >>> >>> -Chris. >>> >>> [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/log?rev=8223892 From david.holmes at oracle.com Fri Dec 13 12:35:53 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Dec 2019 22:35:53 +1000 Subject: [11u] Downport closed changes? In-Reply-To: References: Message-ID: FYI: Closed bug: "8212608: Minimal VM build failure after JDK-8210498 (nmethod entry barriers)" https://bugs.openjdk.java.net/browse/JDK-8212608 https://hg.openjdk.java.net/jdk/jdk/rev/199658d1ef86 Used the wrong bug id. Should have been the open bug: https://bugs.openjdk.java.net/browse/JDK-8212609 David On 13/12/2019 9:42 pm, Lindenmaier, Goetz wrote: > Hi, > > Although Oracle has the policy to push only changes that have > publicly visible JBS bugs, they once in a while push changes > where the bug is hidden. > Currently, we can see which changes are downported by Oracle > to their internal 11u project, and do so for OpenJDK, too. > This is not the case for such closed bugs. > > Therefore I enumerated these closed bugs and want to ask > the 11u community to scan the list and eventually downport > changes that seem useful in 11u. > > Overall, there are 78 bugs to look at, see this list: > http://cr.openjdk.java.net/~goetz/closed_bugs_not_in_11/closed_bugs_not_in_11.html > > Often, Oracle engineers are so friendly to open up the issues > if asked to do so. This is helpful to process a downport to 11. > > Find the script to generate the content of the list at the bottom. > > Best regards, > Goetz > From goetz.lindenmaier at sap.com Fri Dec 13 14:00:08 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 13 Dec 2019 14:00:08 +0000 Subject: [11u] Downport closed changes? In-Reply-To: <3431DBAB-ACA7-4FC2-B4BE-1E7E34E77176@oracle.com> References: <3431DBAB-ACA7-4FC2-B4BE-1E7E34E77176@oracle.com> Message-ID: Hi Chris, Thanks a lot! Would have been great if it had been 77 and not 1, but still ?? ! Best regards, Goetz. > -----Original Message----- > From: Chris Hegarty > Sent: Friday, December 13, 2019 1:25 PM > To: Lindenmaier, Goetz > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] Downport closed changes? > > Hi Goetz, > > > On 13 Dec 2019, at 12:19, Lindenmaier, Goetz > wrote: > > > > Hi, > > > > To avoid confusion, I split the page in two ? > > Thanks for the clarification. I quickly scanned the list and opened any > bug that I am confident was mistakenly not-open in the first place. So, > just 8203672 ( that I know of ). > > -Chris. > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: jdk-updates-dev > On > >> Behalf Of Lindenmaier, Goetz > >> Sent: Friday, December 13, 2019 1:12 PM > >> To: 'Chris Hegarty' > >> Cc: jdk-updates-dev at openjdk.java.net > >> Subject: [CAUTION] RE: [11u] Downport closed changes? > >> > >> Hi Chris, > >> > >> The list has two parts: > >> First changes that are not in 11u. > >> Second changes that are closed but already in 11u. > >> Second holds for all the security fixes, e.g.. > >> > >> Maybe I should put it on two pages ... it's easy to > >> miss the heading in the middle. > >> > >> Best, > >> Goetz. > >> > >>> -----Original Message----- > >>> From: Chris Hegarty > >>> Sent: Friday, December 13, 2019 1:05 PM > >>> To: Lindenmaier, Goetz > >>> Cc: jdk-updates-dev at openjdk.java.net > >>> Subject: Re: [11u] Downport closed changes? > >>> > >>> Hi, > >>> > >>>> On 13 Dec 2019, at 11:42, Lindenmaier, Goetz > >> > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> Although Oracle has the policy to push only changes that have > >>>> publicly visible JBS bugs, they once in a while push changes > >>>> where the bug is hidden. > >>>> Currently, we can see which changes are downported by Oracle > >>>> to their internal 11u project, and do so for OpenJDK, too. > >>>> This is not the case for such closed bugs. > >>>> > >>>> Therefore I enumerated these closed bugs and want to ask > >>>> the 11u community to scan the list and eventually downport > >>>> changes that seem useful in 11u. > >>>> > >>>> Overall, there are 78 bugs to look at, see this list: > >>>> > >>> > >> > http://cr.openjdk.java.net/~goetz/closed_bugs_not_in_11/closed_bugs_no > >>> t_in_11.html > >>> > >>> > >>> Maybe I don?t understand what this list is trying to convey, so as an > >>> example: 8223892 is on the list, but is also in jdk11u [1]. Why is > >>> 8223892 on the list if it is already in 11u? > >>> > >>> -Chris. > >>> > >>> [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/log?rev=8223892 From chris.hegarty at oracle.com Fri Dec 13 14:04:18 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 13 Dec 2019 14:04:18 +0000 Subject: [11u] Downport closed changes? In-Reply-To: References: <3431DBAB-ACA7-4FC2-B4BE-1E7E34E77176@oracle.com> Message-ID: <7DBEFBED-A7ED-44BF-9476-6F2D30F57B6F@oracle.com> > On 13 Dec 2019, at 14:00, Lindenmaier, Goetz wrote: > > Hi Chris, > > Thanks a lot! > Would have been great if it had been 77 and not 1, but still ?? ! Sure, I don?t disagree. To clarify, I only actioned issues that I know of and have confidence to open. Don?t take my opening of one issue as ?only one of the 78 issues can be opened?. -Chris. From goetz.lindenmaier at sap.com Fri Dec 13 14:08:55 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 13 Dec 2019 14:08:55 +0000 Subject: [11u] Downport closed changes? In-Reply-To: <7DBEFBED-A7ED-44BF-9476-6F2D30F57B6F@oracle.com> References: <3431DBAB-ACA7-4FC2-B4BE-1E7E34E77176@oracle.com> <7DBEFBED-A7ED-44BF-9476-6F2D30F57B6F@oracle.com> Message-ID: Yes, sure! I appreciate a lot you acted right away! Best regards, Goetz. > -----Original Message----- > From: Chris Hegarty > Sent: Friday, December 13, 2019 3:04 PM > To: Lindenmaier, Goetz > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] Downport closed changes? > > > > > On 13 Dec 2019, at 14:00, Lindenmaier, Goetz > wrote: > > > > Hi Chris, > > > > Thanks a lot! > > Would have been great if it had been 77 and not 1, but still ?? ! > > Sure, I don?t disagree. > > To clarify, I only actioned issues that I know of and have > confidence to open. Don?t take my opening of one issue > as ?only one of the 78 issues can be opened?. > > -Chris. From goetz.lindenmaier at sap.com Mon Dec 16 08:32:31 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 16 Dec 2019 08:32:31 +0000 Subject: [CAUTION] [11u] RFR: 8233954: UnsatisfiedLinkError or NoSuchAlgorithmException after removing sunec.dll In-Reply-To: References: Message-ID: Hi Christoph, ok, so I'll push webrev 02. Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 13. Dezember 2019 09:28 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [CAUTION] [11u] RFR: 8233954: UnsatisfiedLinkError or > NoSuchAlgorithmException after removing sunec.dll > > Hi Goetz, > > > I tested your proposeal, all test pass, as well as the one from > > the bug description (after removing libsunec from the jdk). > > http://cr.openjdk.java.net/~goetz/wr19/8233954-UnsatisfiedLink_in_EC- > > jdk11/02/ > > Looks good then. > > > And you are right, in case of > > NamedGroupType.NAMED_GROUP_ARBITRARY > > the original change does not check the availability of the > > algorithm. > > So these non-elliptic encryptions are processed by other code > > and not the libsunec? > > Or is just the test not excercising this case? > > As my knowledge in that area is limited, I can't answer this question. But in > that case I guess it's even more important to do exactly what the upstream > patch does ?? > > Cheers > Christoph From goetz.lindenmaier at sap.com Mon Dec 16 08:43:24 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 16 Dec 2019 08:43:24 +0000 Subject: [11u] RFR 8213348: jdk.internal.vm.compiler.management service providers missing in module descriptor Message-ID: Hi, The patch applied clean, but I had to do an adaption to get the build working. http://cr.openjdk.java.net/~goetz/wr19/8213348-service_provider_missing-jdk11/01/ The new makefile generates module-info.java files. It adds an export for the inner class GraalServices$JMXService. In the module-info, the $ must be replaced by .. In 14, the inner class GraalServices$JMXService was transferred into a real class, thus the problem does not show there. Fix: --- a/make/gensrc/Gensrc-jdk.internal.vm.compiler.management.gmk Thu Nov 08 15:19:14 2018 -0800 +++ b/make/gensrc/Gensrc-jdk.internal.vm.compiler.management.gmk Tue Dec 10 19:16:43 2019 +0100 @@ -74,7 +74,7 @@ p=""; \ impl=""; \ for i in $$($(GREP) '^' * | $(SORT) -t ':' -k 2 | $(SED) 's/:.*//'); do \ - c=$$($(CAT) $$i | $(TR) -d '\n\r'); \ + c=$$($(CAT) $$i | $(TR) -d '\n\r' | $(TR) '$$' '.' ); \ if test x$$p != x$$c; then \ if test x$$p != x; then \ $(ECHO) " ;" >> $@; \ Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Dec 16 08:49:04 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 16 Dec 2019 08:49:04 +0000 Subject: [11u] RFR: 8203687: javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3 Message-ID: Hi, I had to resolve several files: Compatibility.java The change to the test description does not apply because 14 mentions 1.7 in the -source/-target statement, but jdk11 mentions 1.6. Parameter.java It could not be deleted because 14 mentions JdkRelease.JDK7 in places where 11 mentions JdkRelease.JDK6. README I had to resolve the copyright. Please review: http://cr.openjdk.java.net/~goetz/wr19/8203687-test_TLS1.3-jdk11/01/ Best regards, Goetz. From rene.schuenemann at gmail.com Mon Dec 16 14:50:48 2019 From: rene.schuenemann at gmail.com (=?UTF-8?B?UmVuw6kgU2Now7xuZW1hbm4=?=) Date: Mon, 16 Dec 2019 15:50:48 +0100 Subject: [11u] RFR: 8235585: Enable macOS codesigning for all libraries and executables Message-ID: Hi, can I please get a review for this 11u backport, code signing all libraries and executables on macOS? I had to resolve "make/launcher/LauncherCommon.gmk". https://bugs.openjdk.java.net/browse/JDK-8235585 http://cr.openjdk.java.net/~rschuenemann/wr/2019/8235585-macOS_Signing-jdk11/01/ http://hg.openjdk.java.net/jdk/jdk/rev/dcf88e5c8c07 Best Regards Rene From christoph.langer at sap.com Mon Dec 16 14:55:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 16 Dec 2019 14:55:45 +0000 Subject: [11u] RFR: 8235585: Enable macOS codesigning for all libraries and executables In-Reply-To: References: Message-ID: Hi Ren?, this backport looks good to me. I think we should even bring it to 11.0.6 to facilitate MacOS notarization. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ren? Sch?nemann > Sent: Montag, 16. Dezember 2019 15:51 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8235585: Enable macOS codesigning for all libraries and > executables > > Hi, > > can I please get a review for this 11u backport, code signing all > libraries and executables on macOS? > > I had to resolve "make/launcher/LauncherCommon.gmk". > > https://bugs.openjdk.java.net/browse/JDK-8235585 > http://cr.openjdk.java.net/~rschuenemann/wr/2019/8235585- > macOS_Signing-jdk11/01/ > http://hg.openjdk.java.net/jdk/jdk/rev/dcf88e5c8c07 > > Best Regards > Rene From rene.schuenemann at gmail.com Tue Dec 17 09:24:09 2019 From: rene.schuenemann at gmail.com (=?UTF-8?B?UmVuw6kgU2Now7xuZW1hbm4=?=) Date: Tue, 17 Dec 2019 10:24:09 +0100 Subject: [11u] RFR: 8235687: Contents/MacOS/libjli.dylib cannot be a symlink Message-ID: Hi, can I please get a review for this 11u backport? This change is needed for Apple notarization on macOS. I had to resolve "make/MacBundles.gmk" since the libjli.dylib" path in 11u differs from jdk/jdk. https://bugs.openjdk.java.net/browse/JDK-8235687 http://cr.openjdk.java.net/~rschuenemann/wr/2019/8235687-macOS_libjli_symlink-jdk11/01/ https://hg.openjdk.java.net/jdk/jdk14/rev/7a1e6bd6a836 Best Regards Rene From martin.doerr at sap.com Tue Dec 17 10:54:53 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 17 Dec 2019 10:54:53 +0000 Subject: [11u] RFR 8213348: jdk.internal.vm.compiler.management service providers missing in module descriptor In-Reply-To: References: Message-ID: Hi G?tz, Ok, replacing '$' by '.' in the new make file makes sense. Looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 16. Dezember 2019 09:43 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR 8213348: > jdk.internal.vm.compiler.management service providers missing in module > descriptor > > Hi, > > The patch applied clean, but I had to do an adaption > to get the build working. > http://cr.openjdk.java.net/~goetz/wr19/8213348-service_provider_missing- > jdk11/01/ > > The new makefile generates module-info.java files. > It adds an export for the inner class GraalServices$JMXService. > In the module-info, the $ must be replaced by .. > > In 14, the inner class GraalServices$JMXService was > transferred into a real class, thus the problem does not show there. > > Fix: > > --- a/make/gensrc/Gensrc-jdk.internal.vm.compiler.management.gmk Thu > Nov 08 15:19:14 2018 -0800 > +++ b/make/gensrc/Gensrc-jdk.internal.vm.compiler.management.gmk > Tue Dec 10 19:16:43 2019 +0100 > @@ -74,7 +74,7 @@ > p=""; \ > impl=""; \ > for i in $$($(GREP) '^' * | $(SORT) -t ':' -k 2 | $(SED) 's/:.*//'); do \ > - c=$$($(CAT) $$i | $(TR) -d '\n\r'); \ > + c=$$($(CAT) $$i | $(TR) -d '\n\r' | $(TR) '$$' '.' ); \ > if test x$$p != x$$c; then \ > if test x$$p != x; then \ > $(ECHO) " ;" >> $@; \ > > Best regards, > Goetz. From martin.doerr at sap.com Tue Dec 17 11:10:43 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 17 Dec 2019 11:10:43 +0000 Subject: [11u] RFR: 8203687: javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3 In-Reply-To: References: Message-ID: Hi G?tz, > Compatibility.java Ok. > Parameter.java Deletion is fine. So looks good to me. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 16. Dezember 2019 09:49 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8203687: > javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3 > > Hi, > > I had to resolve several files: > > Compatibility.java > The change to the test description does not apply because 14 mentions 1.7 in > the -source/-target statement, but jdk11 mentions 1.6. > > Parameter.java > It could not be deleted because 14 mentions > JdkRelease.JDK7 in places where 11 mentions JdkRelease.JDK6. > > README > I had to resolve the copyright. > > Please review: > http://cr.openjdk.java.net/~goetz/wr19/8203687-test_TLS1.3-jdk11/01/ > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Tue Dec 17 11:12:57 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 17 Dec 2019 11:12:57 +0000 Subject: [11u] RFR: 8203687: javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3 In-Reply-To: References: Message-ID: Hi Martin, thanks for the review! Best regards, Goetz > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 17. Dezember 2019 12:11 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8203687: > javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3 > > Hi G?tz, > > > Compatibility.java > Ok. > > > Parameter.java > Deletion is fine. > > So looks good to me. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Montag, 16. Dezember 2019 09:49 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8203687: > > javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3 > > > > Hi, > > > > I had to resolve several files: > > > > Compatibility.java > > The change to the test description does not apply because 14 mentions 1.7 in > > the -source/-target statement, but jdk11 mentions 1.6. > > > > Parameter.java > > It could not be deleted because 14 mentions > > JdkRelease.JDK7 in places where 11 mentions JdkRelease.JDK6. > > > > README > > I had to resolve the copyright. > > > > Please review: > > http://cr.openjdk.java.net/~goetz/wr19/8203687-test_TLS1.3-jdk11/01/ > > > > Best regards, > > Goetz. > > From rene.schuenemann at gmail.com Tue Dec 17 11:37:22 2019 From: rene.schuenemann at gmail.com (=?UTF-8?B?UmVuw6kgU2Now7xuZW1hbm4=?=) Date: Tue, 17 Dec 2019 12:37:22 +0100 Subject: [11u] RFR: 8235585: Enable macOS codesigning for all libraries and executables In-Reply-To: References: Message-ID: Hi Christoph, thank you for the review. Rene On Mon, Dec 16, 2019 at 3:55 PM Langer, Christoph wrote: > > Hi Ren?, > > this backport looks good to me. I think we should even bring it to 11.0.6 to facilitate MacOS notarization. > > Cheers > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Ren? Sch?nemann > > Sent: Montag, 16. Dezember 2019 15:51 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8235585: Enable macOS codesigning for all libraries and > > executables > > > > Hi, > > > > can I please get a review for this 11u backport, code signing all > > libraries and executables on macOS? > > > > I had to resolve "make/launcher/LauncherCommon.gmk". > > > > https://bugs.openjdk.java.net/browse/JDK-8235585 > > http://cr.openjdk.java.net/~rschuenemann/wr/2019/8235585- > > macOS_Signing-jdk11/01/ > > http://hg.openjdk.java.net/jdk/jdk/rev/dcf88e5c8c07 > > > > Best Regards > > Rene From goetz.lindenmaier at sap.com Tue Dec 17 11:38:11 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 17 Dec 2019 11:38:11 +0000 Subject: [11u] RFR: 8235687: Contents/MacOS/libjli.dylib cannot be a symlink In-Reply-To: References: Message-ID: Hi Rene, the only difference I spotted is that 11 calls $(MKDIR) and 14 calls MakeTargetDir in the deleted code. This is encapsulated in SetupCopyFiles which is called by the new code. Looks good. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ren? Sch?nemann > Sent: Dienstag, 17. Dezember 2019 10:24 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8235687: Contents/MacOS/libjli.dylib cannot be a symlink > > Hi, > > can I please get a review for this 11u backport? > This change is needed for Apple notarization on macOS. > > I had to resolve "make/MacBundles.gmk" since the libjli.dylib" path in > 11u differs from jdk/jdk. > > https://bugs.openjdk.java.net/browse/JDK-8235687 > http://cr.openjdk.java.net/~rschuenemann/wr/2019/8235687- > macOS_libjli_symlink-jdk11/01/ > https://hg.openjdk.java.net/jdk/jdk14/rev/7a1e6bd6a836 > > Best Regards > Rene From matthias.baesken at sap.com Tue Dec 17 12:14:19 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 17 Dec 2019 12:14:19 +0000 Subject: [11u] RFR: 8235585: Enable macOS codesigning for all libraries and executables Message-ID: Hi Rene, the backport looks good to me . I am not sure about the MACOSX_PRIVILEGED settings , there might be more j-tools needing it. Here http://cr.openjdk.java.net/~rschuenemann/wr/2019/8235585-macOS_Signing-jdk11/01/make/launcher/Launcher-jdk.jcmd.gmk.frames.html I see the setting MACOSX_PRIVILEGED added for jinfo, jmap, jstack . Have you checked jcmd itself ( I have no Catalina at hand so cannot check it myself, maybe it is fine as is ) ? Best regards, Matthias > > Message: 1 > Date: Mon, 16 Dec 2019 15:50:48 +0100 > From: Ren? Sch?nemann > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8235585: Enable macOS codesigning for all > libraries and executables > Message-ID: > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi, > > can I please get a review for this 11u backport, code signing all > libraries and executables on macOS? > > I had to resolve "make/launcher/LauncherCommon.gmk". > > https://bugs.openjdk.java.net/browse/JDK-8235585 > http://cr.openjdk.java.net/~rschuenemann/wr/2019/8235585- > macOS_Signing-jdk11/01/ > http://hg.openjdk.java.net/jdk/jdk/rev/dcf88e5c8c07 > > Best Regards > Rene > > From rene.schuenemann at gmail.com Wed Dec 18 09:23:57 2019 From: rene.schuenemann at gmail.com (=?UTF-8?B?UmVuw6kgU2Now7xuZW1hbm4=?=) Date: Wed, 18 Dec 2019 10:23:57 +0100 Subject: [11u] RFR: 8235585: Enable macOS codesigning for all libraries and executables In-Reply-To: References: Message-ID: Hi Matthias, thank you. I didn't change which tools should be privileged, I just changed the parameter name, but I agree, we should check if more tools should be privileged. Best Regards Rene On Tue, Dec 17, 2019 at 1:14 PM Baesken, Matthias wrote: > > Hi Rene, the backport looks good to me . > > > I am not sure about the MACOSX_PRIVILEGED settings , there might be more j-tools needing it. > Here > > http://cr.openjdk.java.net/~rschuenemann/wr/2019/8235585-macOS_Signing-jdk11/01/make/launcher/Launcher-jdk.jcmd.gmk.frames.html > > I see the setting MACOSX_PRIVILEGED added for jinfo, jmap, jstack . > > Have you checked jcmd itself ( I have no Catalina at hand so cannot check it myself, maybe it is fine as is ) ? > > Best regards, Matthias > > > > > > Message: 1 > > Date: Mon, 16 Dec 2019 15:50:48 +0100 > > From: Ren? Sch?nemann > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8235585: Enable macOS codesigning for all > > libraries and executables > > Message-ID: > > > gmail.com> > > Content-Type: text/plain; charset="UTF-8" > > > > Hi, > > > > can I please get a review for this 11u backport, code signing all > > libraries and executables on macOS? > > > > I had to resolve "make/launcher/LauncherCommon.gmk". > > > > https://bugs.openjdk.java.net/browse/JDK-8235585 > > http://cr.openjdk.java.net/~rschuenemann/wr/2019/8235585- > > macOS_Signing-jdk11/01/ > > http://hg.openjdk.java.net/jdk/jdk/rev/dcf88e5c8c07 > > > > Best Regards > > Rene > > > > > From rene.schuenemann at gmail.com Wed Dec 18 11:16:06 2019 From: rene.schuenemann at gmail.com (=?UTF-8?B?UmVuw6kgU2Now7xuZW1hbm4=?=) Date: Wed, 18 Dec 2019 12:16:06 +0100 Subject: [11u] RFR: 8235687: Contents/MacOS/libjli.dylib cannot be a symlink In-Reply-To: References: Message-ID: Hi Goetz, thank you for the review. Rene On Tue, Dec 17, 2019 at 12:38 PM Lindenmaier, Goetz wrote: > > Hi Rene, > > the only difference I spotted is that 11 calls $(MKDIR) and > 14 calls MakeTargetDir in the deleted code. > This is encapsulated in SetupCopyFiles which is called > by the new code. > > Looks good. > > Best regards, > Goetz. > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Ren? Sch?nemann > > Sent: Dienstag, 17. Dezember 2019 10:24 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8235687: Contents/MacOS/libjli.dylib cannot be a symlink > > > > Hi, > > > > can I please get a review for this 11u backport? > > This change is needed for Apple notarization on macOS. > > > > I had to resolve "make/MacBundles.gmk" since the libjli.dylib" path in > > 11u differs from jdk/jdk. > > > > https://bugs.openjdk.java.net/browse/JDK-8235687 > > http://cr.openjdk.java.net/~rschuenemann/wr/2019/8235687- > > macOS_libjli_symlink-jdk11/01/ > > https://hg.openjdk.java.net/jdk/jdk14/rev/7a1e6bd6a836 > > > > Best Regards > > Rene From jkang at redhat.com Wed Dec 18 13:50:07 2019 From: jkang at redhat.com (Jie Kang) Date: Wed, 18 Dec 2019 08:50:07 -0500 Subject: [11u] RFR: 8232806: Introduce a system property to disable eager lambda initialization Message-ID: Hi, Please review this backport for JDK-8232806. This is useful for graalvm and has also already been backported into 11.0.7-oracle, so should be included at least for parity. Backport Webrev http://cr.openjdk.java.net/~jkang/JDK-8232806/webrev.1/ Original Commit https://hg.openjdk.java.net/jdk/jdk/rev/27c2d2a4b695 Original Bug https://bugs.openjdk.java.net/browse/JDK-8232806 The patch did not function cleanly due to missing GetBooleanAction.privilegedGetProperty in 11u. The call to this has been replaced by the lengthier form used elsewhere and also prior to the introduction of above static helper method: disableEagerInitialization = AccessController.doPrivileged( new GetBooleanAction(disableEagerInitializationKey)).booleanValue(); Let me know what you think about this adjustment. The tier one tests including the modified LambdaTest6 passed for me. Regards, From sgehwolf at redhat.com Wed Dec 18 14:15:27 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 18 Dec 2019 15:15:27 +0100 Subject: [11u] RFR: 8232806: Introduce a system property to disable eager lambda initialization In-Reply-To: References: Message-ID: <75dbf5e0d9e2d3d203d33101ba545ed79d5a6313.camel@redhat.com> Hi Jie, On Wed, 2019-12-18 at 08:50 -0500, Jie Kang wrote: > Hi, > > Please review this backport for JDK-8232806. This is useful for > graalvm and has also already been backported into 11.0.7-oracle, so > should be included at least for parity. > > Backport Webrev > http://cr.openjdk.java.net/~jkang/JDK-8232806/webrev.1/ > > Original Commit > https://hg.openjdk.java.net/jdk/jdk/rev/27c2d2a4b695 > Original Bug > https://bugs.openjdk.java.net/browse/JDK-8232806 The original change required a CSR. So does this backport. Please create a backport bug manually and attach the CSR to that. The patch would only be allowed for backport approval if the CSR gets approved. I recommend to get started with that process now. Thanks, Severin From jkang at redhat.com Wed Dec 18 14:42:41 2019 From: jkang at redhat.com (Jie Kang) Date: Wed, 18 Dec 2019 09:42:41 -0500 Subject: [11u] RFR: 8232806: Introduce a system property to disable eager lambda initialization In-Reply-To: <75dbf5e0d9e2d3d203d33101ba545ed79d5a6313.camel@redhat.com> References: <75dbf5e0d9e2d3d203d33101ba545ed79d5a6313.camel@redhat.com> Message-ID: On Wed, Dec 18, 2019 at 9:15 AM Severin Gehwolf wrote: > > Hi Jie, > > On Wed, 2019-12-18 at 08:50 -0500, Jie Kang wrote: > > Hi, > > > > Please review this backport for JDK-8232806. This is useful for > > graalvm and has also already been backported into 11.0.7-oracle, so > > should be included at least for parity. > > > > Backport Webrev > > http://cr.openjdk.java.net/~jkang/JDK-8232806/webrev.1/ > > > > Original Commit > > https://hg.openjdk.java.net/jdk/jdk/rev/27c2d2a4b695 > > Original Bug > > https://bugs.openjdk.java.net/browse/JDK-8232806 > > The original change required a CSR. So does this backport. Please > create a backport bug manually and attach the CSR to that. The patch > would only be allowed for backport approval if the CSR gets approved. > > I recommend to get started with that process now. Right, thanks for seeing this. I have created a backport bug and attached CSR bug with contents of the initial CSR. Will re-ping this after the CSR is approved. Sorry for the fluff. Regards, Backport: https://bugs.openjdk.java.net/browse/JDK-8236185 CSR: https://bugs.openjdk.java.net/browse/JDK-8236186 > > Thanks, > Severin > From sgehwolf at redhat.com Wed Dec 18 14:55:33 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 18 Dec 2019 15:55:33 +0100 Subject: [11u] RFR: 8232806: Introduce a system property to disable eager lambda initialization In-Reply-To: References: <75dbf5e0d9e2d3d203d33101ba545ed79d5a6313.camel@redhat.com> Message-ID: On Wed, 2019-12-18 at 09:42 -0500, Jie Kang wrote: > Right, thanks for seeing this. I have created a backport bug and > attached CSR bug with contents of the initial CSR. Will re-ping this > after the CSR is approved. Sorry for the fluff. No worries. Reviews can happen in parallel to the CSR. Thanks, Severin From christoph.langer at sap.com Thu Dec 19 10:41:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Dec 2019 10:41:45 +0000 Subject: [11u]: RFR(S): 8232370: Refactor some com.sun.jdi tests to enable IDE integration Message-ID: Hi, please review this backport of a test-only change to better support JDK11 development in the Eclipse IDE. The Original change applies cleanly for 2 files but test/jdk/com/sun/jdi/RedefineImplementor.java does not exist in 11u, so I simply dropped this part. Bug: https://bugs.openjdk.java.net/browse/JDK-8232370 Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/5f14a659a8cb Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232370.11u/ Thanks Christoph From goetz.lindenmaier at sap.com Thu Dec 19 10:59:25 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Dec 2019 10:59:25 +0000 Subject: [11u] RFR: 8213009: Refactoring existing SunMSCAPI classes Message-ID: Hi, I would like to downport this change for parity with 11.0.7-oracle. It required some non-trivial resolves: http://cr.openjdk.java.net/~goetz/wr19/8213009-refactor_mscapi-jdk11/01/ Patching file src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/KeyStore.java failed. The file was deleted. 11 differes a lot to the file deleted in 13. Most diffs are comments though, except for this: @@ -47,6 +44,8 @@ import java.security.interfaces.RSAPrivateCrtKey; import java.util.*; +import sun.security.util.Debug; + /** * Implementation of key store for Windows using the Microsoft Crypto API. * @@ -188,6 +187,7 @@ private static final String KEYSTORE_COMPATIBILITY_MODE_PROP = "sun.security.mscapi.keyStoreCompatibilityMode"; private final boolean keyStoreCompatibilityMode; + private static final Debug debug = Debug.getInstance("keystore"); /* * The keystore entries. @@ -731,6 +731,11 @@ } catch (KeyStoreException e) { throw new IOException(e); } + + if (debug != null) { + debug.println("MSCAPI keystore load: entry count: " + + entries.size()); + } } /** This code was introduced by "8218553: Enhance keystore load debug output" which was downported to 11.0.5 and had to be modified. I applied the coding to CKeyStore.java where it was in the original patch of 8218553. In patching file src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp Two hunks failed that were easy to resolve: --- security.cpp +++ security.cpp @@ -570,9 +586,8 @@ // Determine key type: RSA or DSA DWORD dwData = CALG_RSA_KEYX; DWORD dwSize = sizeof(DWORD); - ::CryptGetKeyParam(hUserKey, KP_ALGID, (BYTE*)&dwData, + ::CryptGetKeyParam(hUserKey, KP_ALGID, (BYTE*)&dwData, //deprecated &dwSize, NULL); - if ((dwData & ALG_TYPE_RSA) == ALG_TYPE_RSA) { // Generate RSA certificate chain and store into cert @@ -966,7 +981,7 @@ NULL, &hk, hCryptProv, - hKey, + hCryptKey, NULL, 0)); Best regards, Goetz From goetz.lindenmaier at sap.com Thu Dec 19 11:21:35 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Dec 2019 11:21:35 +0000 Subject: [11u]: RFR(S): 8232370: Refactor some com.sun.jdi tests to enable IDE integration In-Reply-To: References: Message-ID: Hi Christoph, change looks good. The test is a shell test in 11 and was reimplemented in Java in 14. I guess this will never be downported, so dropping the change is absolutely fine. Best regards, Geotz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Donnerstag, 19. Dezember 2019 11:42 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u]: RFR(S): 8232370: Refactor some com.sun.jdi tests to > enable IDE integration > > Hi, > > please review this backport of a test-only change to better support JDK11 > development in the Eclipse IDE. The Original change applies cleanly for 2 files > but test/jdk/com/sun/jdi/RedefineImplementor.java does not exist in 11u, so I > simply dropped this part. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232370 > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/5f14a659a8cb > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232370.11u/ > > Thanks > Christoph From christoph.langer at sap.com Thu Dec 19 12:08:51 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Dec 2019 12:08:51 +0000 Subject: [11u] [JFR] RFR 8209850: Allow NamedThreads to use GlobalCounter critical sections In-Reply-To: <6F95ACF2-0C4D-4A0B-A56B-A265BCFD2994@amazon.com> References: <6F95ACF2-0C4D-4A0B-A56B-A265BCFD2994@amazon.com> Message-ID: Hi Jaroslav, I just ran the patch through our test system and found that it wouldn't build. I had to change one include in test_singleWriterSynchronizer.cpp: #include "threadHelper.inline.hpp" -> #include "utilitiesHelper.inline.hpp". I think you have that change in your webrev for JDK- 8209976 which comes next in your queue. So, I think the correct backport of JDK-8209850 would look like this: http://cr.openjdk.java.net/~clanger/webrevs/8209850.11u/ Can I please get a review for this? I'd approve & push after I have a review and build results on Windows. The Linux/Unix world looks good so far. Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Donnerstag, 12. Dezember 2019 17:10 > To: Jaroslav Bachor?k ; jdk-updates-dev > > Subject: Re: [11u] [JFR] RFR 8209850: Allow NamedThreads to use > GlobalCounter critical sections > > Lgtm. > > Paul > > ?On 12/12/19, 7:41 AM, "jdk-updates-dev on behalf of Jaroslav Bachor?k" > jaroslav.bachorik at datadoghq.com> wrote: > > Hi all, > > please, review this backport which is a prerequisite for the planned > backport of JDK-8225797 > > JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209850 > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/ > > The patch applies with fuzz and the patch diff is listed at > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff > > Thanks, > > -JB- > From christoph.langer at sap.com Thu Dec 19 12:25:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Dec 2019 12:25:56 +0000 Subject: [11u]: RFR(S): 8232370: Refactor some com.sun.jdi tests to enable IDE integration In-Reply-To: References: Message-ID: Hi Goetz, thanks for reviewing this. Cheers Christoph > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 19. Dezember 2019 12:22 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u]: RFR(S): 8232370: Refactor some com.sun.jdi tests to > enable IDE integration > > Hi Christoph, > > change looks good. > The test is a shell test in 11 and was reimplemented in Java in 14. > I guess this will never be downported, so dropping the change > is absolutely fine. > > Best regards, > Geotz. > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Langer, Christoph > > Sent: Donnerstag, 19. Dezember 2019 11:42 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u]: RFR(S): 8232370: Refactor some com.sun.jdi > tests to > > enable IDE integration > > > > Hi, > > > > please review this backport of a test-only change to better support JDK11 > > development in the Eclipse IDE. The Original change applies cleanly for 2 > files > > but test/jdk/com/sun/jdi/RedefineImplementor.java does not exist in 11u, > so I > > simply dropped this part. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232370 > > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/5f14a659a8cb > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232370.11u/ > > > > Thanks > > Christoph From jaroslav.bachorik at datadoghq.com Thu Dec 19 12:42:45 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Thu, 19 Dec 2019 13:42:45 +0100 Subject: [11u] [JFR] RFR 8209850: Allow NamedThreads to use GlobalCounter critical sections In-Reply-To: References: <6F95ACF2-0C4D-4A0B-A56B-A265BCFD2994@amazon.com> Message-ID: Hi Christoph, I can confirm that your proposed patch is identical to the original backport patch and the only change is in test_singleWriterSynchronizer.cpp: #include "threadHelper.inline.hpp" -> #include "utilitiesHelper.inline.hpp" LGTM -JB- On Thu, Dec 19, 2019 at 1:08 PM Langer, Christoph wrote: > Hi Jaroslav, > > I just ran the patch through our test system and found that it wouldn't > build. > > I had to change one include in test_singleWriterSynchronizer.cpp: #include > "threadHelper.inline.hpp" -> #include "utilitiesHelper.inline.hpp". I think > you have that change in your webrev for JDK- 8209976 which comes next in > your queue. > > So, I think the correct backport of JDK-8209850 would look like this: > http://cr.openjdk.java.net/~clanger/webrevs/8209850.11u/ > > Can I please get a review for this? I'd approve & push after I have a > review and build results on Windows. The Linux/Unix world looks good so far. > > Thanks > Christoph > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Hohensee, Paul > > Sent: Donnerstag, 12. Dezember 2019 17:10 > > To: Jaroslav Bachor?k ; jdk-updates-dev > > > > Subject: Re: [11u] [JFR] RFR 8209850: Allow NamedThreads to use > > GlobalCounter critical sections > > > > Lgtm. > > > > Paul > > > > ?On 12/12/19, 7:41 AM, "jdk-updates-dev on behalf of Jaroslav Bachor?k" > > > jaroslav.bachorik at datadoghq.com> wrote: > > > > Hi all, > > > > please, review this backport which is a prerequisite for the planned > > backport of JDK-8225797 > > > > JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209850 > > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/ > > > > The patch applies with fuzz and the patch diff is listed at > > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff > > > > Thanks, > > > > -JB- > > > > From christoph.langer at sap.com Thu Dec 19 13:48:04 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Dec 2019 13:48:04 +0000 Subject: [11u] RFR: 8232806: Introduce a system property to disable eager lambda initialization In-Reply-To: References: Message-ID: Hi Jie, backport looks good, thanks for doing this. As for the CSR: It would not have been necessary as Oracle did that already for 11-pool: https://bugs.openjdk.java.net/browse/JDK-8233134. However, I also saw that your new CSR got approved (for their backport https://bugs.openjdk.java.net/browse/JDK-8233133)... So, now it's double safe ?? Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Jie Kang > Sent: Mittwoch, 18. Dezember 2019 14:50 > To: jdk-updates-dev > Subject: [11u] RFR: 8232806: Introduce a system property to disable eager > lambda initialization > > Hi, > > Please review this backport for JDK-8232806. This is useful for > graalvm and has also already been backported into 11.0.7-oracle, so > should be included at least for parity. > > Backport Webrev > http://cr.openjdk.java.net/~jkang/JDK-8232806/webrev.1/ > > Original Commit > https://hg.openjdk.java.net/jdk/jdk/rev/27c2d2a4b695 > Original Bug > https://bugs.openjdk.java.net/browse/JDK-8232806 > > The patch did not function cleanly due to missing > GetBooleanAction.privilegedGetProperty in 11u. The call to this has > been replaced by the lengthier form used elsewhere and also prior to > the introduction of above static helper method: > > disableEagerInitialization = AccessController.doPrivileged( > new GetBooleanAction(disableEagerInitializationKey)).booleanValue(); > > Let me know what you think about this adjustment. The tier one tests > including the modified LambdaTest6 passed for me. > > > Regards, From matthias.baesken at sap.com Thu Dec 19 13:58:26 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 19 Dec 2019 13:58:26 +0000 Subject: RFR [XS] jdk11 - 8234809: set relro in linker flags when building with gcc Message-ID: Hello, please review the jdk11 downport of 8234809 . The patch form jdk/jdk did not apply directly so make/autoconf/flags-ldflags.m4 had to be adjusted a little bit for jdk11 . Original discussion : https://mail.openjdk.java.net/pipermail/build-dev/2019-November/026347.html + https://mail.openjdk.java.net/pipermail/build-dev/2019-November/026365.html Bug/ jdk11 webrev : https://bugs.openjdk.java.net/browse/JDK-8234809 http://cr.openjdk.java.net/~mbaesken/webrevs/8234809_jdk11.0/ Thanks, Matthias From christoph.langer at sap.com Thu Dec 19 13:55:11 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Dec 2019 13:55:11 +0000 Subject: Open JDK 8 Road Map In-Reply-To: References: Message-ID: Hi Joshi, the right list for this question is rather jdk8u-dev at o.j.n, so I'm sending my response there and put jdk-updates-dev on bcc. Since RedHat is the maintainer of OpenJDK8 and OpenJDK11, I guess you can bear with their statements about support. You can find this article: https://access.redhat.com/articles/1299013 So I assume, as long as RedHat supports OpenJDK 8, you can be quite sure that there will be periodic security updates. HTH Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Dheeraj Joshi > Sent: Dienstag, 20. August 2019 07:14 > To: jdk-updates-dev at openjdk.java.net > Subject: Open JDK 8 Road Map > > How long Open JDK 8 is supported by https://openjdk.java.net/ > We are currently analyzing impact of upgrading from Java 8 to Java 11. We > need to know for how long JDK 8 will get periodic security upgrades and > general patches for JDK 8 from https://openjdk.java.net/? > > Is there a Road map available for public viewing? > > Kind Regards > Dheeraj Joshi From christoph.langer at sap.com Thu Dec 19 13:57:33 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Dec 2019 13:57:33 +0000 Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes In-Reply-To: References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com> <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com> <23451B8D-FE0A-4508-94F4-660CA2DA923B@oracle.com> <27f57625-aa64-492b-b97c-1dd11df36c31.denghui.ddh@alibaba-inc.com> Message-ID: Hi Andrey, thanks for your comments about these JFR event backports. Can you compile a list of items that you?d like to backport to both, 8u JFR and 11u? Then we can sync together with Mario and Andrew Haley and take a decision about what we want to approve. Cheers Christoph From: Andrey Petushkov Sent: Montag, 9. Dezember 2019 13:08 To: Denghui Dong ; Erik Gahlin ; jdk-updates-dev ; Mario Torre ; Langer, Christoph Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi guys, All, No, there is not special reasoning for back-porting of this particular event type. Feel free to reject the request. A few comments though - we at Azul see JFR as a very useful and successful tool for solving customer issues. So in general we try to keep up with new fixes and features there, unless we consider fix as too risky or inappropriate - all these JFR backports proposed are undergo full test cycle, involving all tests we have (including of course all jtreg) on all platforms supported by Azul (well, a lot) - @Christoph regarding fix not yet pushed to 8u. We (Marrio and team involved into JFR to 8u backporting) have a policy that we don't push into 8u until it's pushed into 11u. Hence it's not pushed Regards, Andrey On 9 Dec 2019, at 12:33, Denghui Dong > wrote: I think we could wait for Andrey's reply to this issue before we decide whether to reject the backport. Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph > Send Time:2019?12?9?(???) 17:17 To:???(??) >; Erik Gahlin >; jdk-updates-dev >; Andrey Petushkov >; Mario Torre > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, ok, I see. So, taking a glance on http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/, I can?t see that the bug is pushed there. So, if that?s true, I?d rather reject the backport to 11u for now. Would you agree? Thanks Christoph From: Denghui Dong > Sent: Montag, 9. Dezember 2019 10:06 To: Erik Gahlin >; jdk-updates-dev >; Langer, Christoph >; Andrey Petushkov >; Mario Torre > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Christoph, I was on vacation last week, sorry for the late reply. In fact, the backport of 8185525 for 8u was requested by @Andrey at first (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html) For the sake of consistency, I made this backport for 11u. And in my opinion, these events are not very useful for users indeed. Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph > Send Time:2019?12?6?(???) 16:32 To:Erik Gahlin >; jdk-updates-dev > Cc:???(??) > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Erik, thanks for you input on this. I guess you have a very good point here ? the bar for backporting new events should be quite high. @Denghui: Is there any motivation for this backport from your end that comes from support requirements/customer incidents? Thanks Christoph From: Erik Gahlin > Sent: Freitag, 6. Dezember 2019 05:14 To: jdk-updates-dev > Cc: Denghui Dong >; Langer, Christoph > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi, What?s nice about jFR is that the file format is self-describing, so a program like JMC can see what events exist or does not exist in a recording. Still, I think the bar should be high when backporting events. Not just for stability reasons, but If different JDK distributions or update releases have different events, it will confuse users, or lead to bugs, when users switch from one JDK to another. In my opinion, events should only be backported if support engineers truly need them to diagnose a certain type of bugs in the JVM/JDK. For this happen, there should be at least a few incidents where they have come to the conclusion that the events are needed. If there are no such real cases, the events should not be backported. My $.02 Erik On 5 Dec 2019, at 23:28, Langer, Christoph > wrote: Hi Denghui, since no objections were raised, I?m approving JDK-8185525. I?ll push it, once I get approval for JDK-8223599 as well. Testing in our system doesn?t show regressions. Cheers Christoph From: Langer, Christoph Sent: Freitag, 22. November 2019 00:30 To: Denghui Dong >; jdk-updates-dev > Cc: Andrew Haley > Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi, we had a discussion on this list regarding JFR feature requests. As a summary, I take we should 1. Generally reject backports of new features from higher releases if these are too extensive or require lots of prerequisites. Exceptions might be made if the feature to be backported exists in lower releases (e.g. OpenJDK8u after the JFR backport has been integrated) 2. Be very careful when it comes to extensive bugfixes for existing features This fix is actually on the edge of category a), since it is a new feature and it is not trivial in its nature. It needs some manual adaption but fortunately no other prerequisites. Given that Denghui has done the effort of backporting it already and the patch together with another small follow up fix runs through our regression testing at SAP successfully, I could imagine to allow it going in to 11u. I would then like to see it submitted at the early stage of the 11.0.7 cycle. So, @all, please raise objections to this decision until next Friday, 29th of November. If I don?t hear any, I?ll approve it after that date. Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 30. Oktober 2019 15:41 To: Denghui Dong >; jdk-updates-dev > Subject: RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, sorry for the late reply. I was discussing with Andrew Haley about JFR backports. He encouraged to do a general discussion on the mailing list about the policy regarding non-trivial JFR related backports, which I started just today: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-October/002053.html Let?s see if there?s any feedback? Best regards Christoph From: Denghui Dong > Sent: Dienstag, 22. Oktober 2019 04:09 To: jdk-updates-dev >; Langer, Christoph > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Christoph, What's the status of this backport ? By the way, the previous webrev didn't contain the original commit, so I uploaded a new one in http://cr.openjdk.java.net/~ddong/8185525/webrev/ Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph > Send Time:2019?10?8?(???) 22:34 To:???(??) >; jdk-updates-dev > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, this is quite a large JFR enhancement. Looking at the 11u webrev, I didn't see any obvious issues although there are obviously quite some alterations from the original patch. I'll run it through our regression testing. However, in any case, we need to carefully decide if and when we allow this patch to jdk11u-dev. I'll get back to you soon. Best regards Christoph -----Original Message----- From: jdk-updates-dev > On Behalf Of Denghui Dong Sent: Donnerstag, 26. September 2019 17:03 To: jdk-updates-dev > Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi all, Please review this backport, original patch doesn't apply cleanly, because SymbolTable has made some changes in upstream (I think it's not necessary to backport those changes) and class ClassLoaderDataGraph is located in different files. 11u-webrev: http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ Original bug: https://bugs.openjdk.java.net/browse/JDK-8185525 http://hg.openjdk.java.net/jdk/jdk/rev/865ec913f916 Testing: test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java Thanks, Denghui Dong From goetz.lindenmaier at sap.com Thu Dec 19 14:20:51 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Dec 2019 14:20:51 +0000 Subject: RFR [XS] jdk11 - 8234809: set relro in linker flags when building with gcc In-Reply-To: References: Message-ID: Hi Matthias, change looks good. The context is different because "8209817: stack is executable when building with Clang on Linux" is missing in 11. This is a special build fix for google. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Baesken, Matthias > Sent: Donnerstag, 19. Dezember 2019 14:58 > To: jdk-updates-dev at openjdk.java.net; 'build-dev at openjdk.java.net' dev at openjdk.java.net> > Cc: Zeller, Arno > Subject: [CAUTION] RFR [XS] jdk11 - 8234809: set relro in linker flags when > building with gcc > > Hello, please review the jdk11 downport of 8234809 . > > The patch form jdk/jdk did not apply directly so make/autoconf/flags- > ldflags.m4 had to be adjusted a little bit for jdk11 . > > Original discussion : > > https://mail.openjdk.java.net/pipermail/build-dev/2019- > November/026347.html > > + > > https://mail.openjdk.java.net/pipermail/build-dev/2019- > November/026365.html > > > > Bug/ jdk11 webrev : > > https://bugs.openjdk.java.net/browse/JDK-8234809 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234809_jdk11.0/ > > Thanks, Matthias From christoph.langer at sap.com Thu Dec 19 16:27:51 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Dec 2019 16:27:51 +0000 Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes In-Reply-To: References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com> <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com> <23451B8D-FE0A-4508-94F4-660CA2DA923B@oracle.com> <27f57625-aa64-492b-b97c-1dd11df36c31.denghui.ddh@alibaba-inc.com> Message-ID: Hi Andrey, thanks for your comments about these JFR event backports. Can you compile a list of items that you?d like to backport to both, 8u JFR and 11u? Then we can sync together with Mario and Andrew Haley and take a decision about what we want to approve. Cheers Christoph From: Andrey Petushkov Sent: Montag, 9. Dezember 2019 13:08 To: Denghui Dong ; Erik Gahlin ; jdk-updates-dev ; Mario Torre ; Langer, Christoph Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi guys, All, No, there is not special reasoning for back-porting of this particular event type. Feel free to reject the request. A few comments though - we at Azul see JFR as a very useful and successful tool for solving customer issues. So in general we try to keep up with new fixes and features there, unless we consider fix as too risky or inappropriate - all these JFR backports proposed are undergo full test cycle, involving all tests we have (including of course all jtreg) on all platforms supported by Azul (well, a lot) - @Christoph regarding fix not yet pushed to 8u. We (Marrio and team involved into JFR to 8u backporting) have a policy that we don't push into 8u until it's pushed into 11u. Hence it's not pushed Regards, Andrey From neugens.limasoftware at gmail.com Thu Dec 19 16:39:36 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 19 Dec 2019 17:39:36 +0100 Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes In-Reply-To: References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com> <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com> <23451B8D-FE0A-4508-94F4-660CA2DA923B@oracle.com> <27f57625-aa64-492b-b97c-1dd11df36c31.denghui.ddh@alibaba-inc.com> Message-ID: I think we need to carefully consider the number of backports we want related to JFR. I can't comment on the specific of this patch but I think we should avoid backporting every feature of JFR that happens to be introduced. That said, there are indeed a number of useful things, for example the streaming API, so I'm not sure where to draw the line, this is probably for the maintainers to decide. I don't think we have a list of back ports we want to do, so far we only backported ported everything that was necessary, but with this work mostly over we are now thinking with features, so it may make more sense to write down what we want and discuss the backports with the maintainers before committing work. Cheers, Mario Il giorno gio 19 dic 2019 alle ore 17:28 Langer, Christoph ha scritto: > > Hi Andrey, > > thanks for your comments about these JFR event backports. > > Can you compile a list of items that you?d like to backport to both, 8u JFR and 11u? Then we can sync together with Mario and Andrew Haley and take a decision about what we want to approve. > > Cheers > Christoph > > > From: Andrey Petushkov > Sent: Montag, 9. Dezember 2019 13:08 > To: Denghui Dong ; Erik Gahlin ; jdk-updates-dev ; Mario Torre ; Langer, Christoph > Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi guys, All, > > No, there is not special reasoning for back-porting of this particular event type. Feel free to reject the request. A few comments though > - we at Azul see JFR as a very useful and successful tool for solving customer issues. So in general we try to keep up with new fixes and features there, unless we consider fix as too risky or inappropriate > - all these JFR backports proposed are undergo full test cycle, involving all tests we have (including of course all jtreg) on all platforms supported by Azul (well, a lot) > - @Christoph regarding fix not yet pushed to 8u. We (Marrio and team involved into JFR to 8u backporting) have a policy that we don't push into 8u until it's pushed into 11u. Hence it's not pushed > > Regards, > Andrey > > -- 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 jkang at redhat.com Thu Dec 19 17:39:00 2019 From: jkang at redhat.com (Jie Kang) Date: Thu, 19 Dec 2019 12:39:00 -0500 Subject: [11u] RFR: 8232806: Introduce a system property to disable eager lambda initialization In-Reply-To: References: Message-ID: On Thu, Dec 19, 2019 at 8:48 AM Langer, Christoph wrote: > Hi Jie, > > backport looks good, thanks for doing this. > > As for the CSR: It would not have been necessary as Oracle did that > already for 11-pool: https://bugs.openjdk.java.net/browse/JDK-8233134. > However, I also saw that your new CSR got approved (for their backport > https://bugs.openjdk.java.net/browse/JDK-8233133)... So, now it's double > safe ?? > Hey Christoph Thanks for reviewing this. I have submitted the fix-request label and comment on the original bug: https://bugs.openjdk.java.net/browse/JDK-8232806 Regards, > Cheers > Christoph > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Jie Kang > > Sent: Mittwoch, 18. Dezember 2019 14:50 > > To: jdk-updates-dev > > Subject: [11u] RFR: 8232806: Introduce a system property to disable eager > > lambda initialization > > > > Hi, > > > > Please review this backport for JDK-8232806. This is useful for > > graalvm and has also already been backported into 11.0.7-oracle, so > > should be included at least for parity. > > > > Backport Webrev > > http://cr.openjdk.java.net/~jkang/JDK-8232806/webrev.1/ > > > > Original Commit > > https://hg.openjdk.java.net/jdk/jdk/rev/27c2d2a4b695 > > Original Bug > > https://bugs.openjdk.java.net/browse/JDK-8232806 > > > > The patch did not function cleanly due to missing > > GetBooleanAction.privilegedGetProperty in 11u. The call to this has > > been replaced by the lengthier form used elsewhere and also prior to > > the introduction of above static helper method: > > > > disableEagerInitialization = AccessController.doPrivileged( > > new GetBooleanAction(disableEagerInitializationKey)).booleanValue(); > > > > Let me know what you think about this adjustment. The tier one tests > > including the modified LambdaTest6 passed for me. > > > > > > Regards, > > From christoph.langer at sap.com Fri Dec 20 15:09:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 20 Dec 2019 15:09:28 +0000 Subject: [11u] [JFR] RFR 8209850: Allow NamedThreads to use GlobalCounter critical sections In-Reply-To: References: <6F95ACF2-0C4D-4A0B-A56B-A265BCFD2994@amazon.com> Message-ID: Hi Jaroslav, Ok, change is tested, approved and pushed now. ?? I?ll take on JDK-8209976 then. Will run it through tests and have an updated version reviewed in a separate thread. Best regards Christoph From: Jaroslav Bachor?k Sent: Donnerstag, 19. Dezember 2019 13:43 To: Langer, Christoph Cc: jdk-updates-dev ; Hohensee, Paul Subject: Re: [11u] [JFR] RFR 8209850: Allow NamedThreads to use GlobalCounter critical sections Hi Christoph, I can confirm that your proposed patch is identical to the original backport patch and the only change is in test_singleWriterSynchronizer.cpp: #include "threadHelper.inline.hpp" -> #include "utilitiesHelper.inline.hpp" LGTM -JB- On Thu, Dec 19, 2019 at 1:08 PM Langer, Christoph > wrote: Hi Jaroslav, I just ran the patch through our test system and found that it wouldn't build. I had to change one include in test_singleWriterSynchronizer.cpp: #include "threadHelper.inline.hpp" -> #include "utilitiesHelper.inline.hpp". I think you have that change in your webrev for JDK- 8209976 which comes next in your queue. So, I think the correct backport of JDK-8209850 would look like this: http://cr.openjdk.java.net/~clanger/webrevs/8209850.11u/ Can I please get a review for this? I'd approve & push after I have a review and build results on Windows. The Linux/Unix world looks good so far. Thanks Christoph > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Hohensee, Paul > Sent: Donnerstag, 12. Dezember 2019 17:10 > To: Jaroslav Bachor?k >; jdk-updates-dev > > > Subject: Re: [11u] [JFR] RFR 8209850: Allow NamedThreads to use > GlobalCounter critical sections > > Lgtm. > > Paul > > ?On 12/12/19, 7:41 AM, "jdk-updates-dev on behalf of Jaroslav Bachor?k" > on behalf of > jaroslav.bachorik at datadoghq.com> wrote: > > Hi all, > > please, review this backport which is a prerequisite for the planned > backport of JDK-8225797 > > JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209850 > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/ > > The patch applies with fuzz and the patch diff is listed at > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff > > Thanks, > > -JB- > From jaroslav.bachorik at datadoghq.com Fri Dec 20 15:48:19 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 20 Dec 2019 16:48:19 +0100 Subject: [11u] [JFR] RFR 8209850: Allow NamedThreads to use GlobalCounter critical sections In-Reply-To: References: <6F95ACF2-0C4D-4A0B-A56B-A265BCFD2994@amazon.com> Message-ID: Hi Christoph, thanks! Are you going to do the separate RFR for 8209976? Not completely clear so better asking. Cheers, -JB- On Fri, Dec 20, 2019 at 4:09 PM Langer, Christoph wrote: > Hi Jaroslav, > > > > Ok, change is tested, approved and pushed now. ?? > > > > I?ll take on JDK-8209976 then. Will run it through tests and have an > updated version reviewed in a separate thread. > > > > Best regards > > Christoph > > > > *From:* Jaroslav Bachor?k > *Sent:* Donnerstag, 19. Dezember 2019 13:43 > *To:* Langer, Christoph > *Cc:* jdk-updates-dev ; Hohensee, Paul < > hohensee at amazon.com> > *Subject:* Re: [11u] [JFR] RFR 8209850: Allow NamedThreads to use > GlobalCounter critical sections > > > > Hi Christoph, > > > > I can confirm that your proposed patch is identical to the > original backport patch and the only change is in > test_singleWriterSynchronizer.cpp: #include "threadHelper.inline.hpp" -> > #include "utilitiesHelper.inline.hpp" > > > > LGTM > > > > -JB- > > > > On Thu, Dec 19, 2019 at 1:08 PM Langer, Christoph < > christoph.langer at sap.com> wrote: > > Hi Jaroslav, > > I just ran the patch through our test system and found that it wouldn't > build. > > I had to change one include in test_singleWriterSynchronizer.cpp: #include > "threadHelper.inline.hpp" -> #include "utilitiesHelper.inline.hpp". I think > you have that change in your webrev for JDK- 8209976 which comes next in > your queue. > > So, I think the correct backport of JDK-8209850 would look like this: > http://cr.openjdk.java.net/~clanger/webrevs/8209850.11u/ > > Can I please get a review for this? I'd approve & push after I have a > review and build results on Windows. The Linux/Unix world looks good so far. > > Thanks > Christoph > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Hohensee, Paul > > Sent: Donnerstag, 12. Dezember 2019 17:10 > > To: Jaroslav Bachor?k ; jdk-updates-dev > > > > Subject: Re: [11u] [JFR] RFR 8209850: Allow NamedThreads to use > > GlobalCounter critical sections > > > > Lgtm. > > > > Paul > > > > ?On 12/12/19, 7:41 AM, "jdk-updates-dev on behalf of Jaroslav Bachor?k" > > > jaroslav.bachorik at datadoghq.com> wrote: > > > > Hi all, > > > > please, review this backport which is a prerequisite for the planned > > backport of JDK-8225797 > > > > JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209850 > > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/ > > > > The patch applies with fuzz and the patch diff is listed at > > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff > > > > Thanks, > > > > -JB- > > > > From christoph.langer at sap.com Fri Dec 20 16:14:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 20 Dec 2019 16:14:05 +0000 Subject: [11u] [JFR] RFR 8209850: Allow NamedThreads to use GlobalCounter critical sections In-Reply-To: References: <6F95ACF2-0C4D-4A0B-A56B-A265BCFD2994@amazon.com> Message-ID: Hi Jaroslav, yep, I will do it. /Christoph From: Jaroslav Bachor?k Sent: Freitag, 20. Dezember 2019 16:48 To: Langer, Christoph Cc: jdk-updates-dev ; Hohensee, Paul Subject: Re: [11u] [JFR] RFR 8209850: Allow NamedThreads to use GlobalCounter critical sections Hi Christoph, thanks! Are you going to do the separate RFR for 8209976? Not completely clear so better asking. Cheers, -JB- On Fri, Dec 20, 2019 at 4:09 PM Langer, Christoph > wrote: Hi Jaroslav, Ok, change is tested, approved and pushed now. ?? I?ll take on JDK-8209976 then. Will run it through tests and have an updated version reviewed in a separate thread. Best regards Christoph From: Jaroslav Bachor?k > Sent: Donnerstag, 19. Dezember 2019 13:43 To: Langer, Christoph > Cc: jdk-updates-dev >; Hohensee, Paul > Subject: Re: [11u] [JFR] RFR 8209850: Allow NamedThreads to use GlobalCounter critical sections Hi Christoph, I can confirm that your proposed patch is identical to the original backport patch and the only change is in test_singleWriterSynchronizer.cpp: #include "threadHelper.inline.hpp" -> #include "utilitiesHelper.inline.hpp" LGTM -JB- On Thu, Dec 19, 2019 at 1:08 PM Langer, Christoph > wrote: Hi Jaroslav, I just ran the patch through our test system and found that it wouldn't build. I had to change one include in test_singleWriterSynchronizer.cpp: #include "threadHelper.inline.hpp" -> #include "utilitiesHelper.inline.hpp". I think you have that change in your webrev for JDK- 8209976 which comes next in your queue. So, I think the correct backport of JDK-8209850 would look like this: http://cr.openjdk.java.net/~clanger/webrevs/8209850.11u/ Can I please get a review for this? I'd approve & push after I have a review and build results on Windows. The Linux/Unix world looks good so far. Thanks Christoph > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Hohensee, Paul > Sent: Donnerstag, 12. Dezember 2019 17:10 > To: Jaroslav Bachor?k >; jdk-updates-dev > > > Subject: Re: [11u] [JFR] RFR 8209850: Allow NamedThreads to use > GlobalCounter critical sections > > Lgtm. > > Paul > > ?On 12/12/19, 7:41 AM, "jdk-updates-dev on behalf of Jaroslav Bachor?k" > on behalf of > jaroslav.bachorik at datadoghq.com> wrote: > > Hi all, > > please, review this backport which is a prerequisite for the planned > backport of JDK-8225797 > > JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209850 > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/ > > The patch applies with fuzz and the patch diff is listed at > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff > > Thanks, > > -JB- > From jai.forums2013 at gmail.com Fri Dec 20 16:16:05 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 20 Dec 2019 21:46:05 +0530 Subject: [11u] RFR: 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs Message-ID: <69105c6f-0a18-172f-6d05-e3d71887a308@gmail.com> Can I please get a review and a sponsor for the 11u backport of https://bugs.openjdk.java.net/browse/JDK-8218268? For the patch to apply cleanly, I had to first apply the patch for https://bugs.openjdk.java.net/browse/JDK-8232170 (which deals with a related issue). The webrev containing both these patches resides at http://cr.openjdk.java.net/~jpai/webrev/8218268-11u-backport/webrev/ -Jaikiran From jai.forums2013 at gmail.com Fri Dec 20 16:26:12 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 20 Dec 2019 21:56:12 +0530 Subject: [11u] RFR: 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: <69105c6f-0a18-172f-6d05-e3d71887a308@gmail.com> References: <69105c6f-0a18-172f-6d05-e3d71887a308@gmail.com> Message-ID: <17fe7142-76fa-a843-9818-7470124471c2@gmail.com> JBS isn't loading for me right now, so I haven't been able to add a "jdk11u-fix-request" label and a RFR comment to that issue. I'll do that tomorrow or as soon as JBS starts loading again. -Jaikiran On 20/12/19 9:46 PM, Jaikiran Pai wrote: > Can I please get a review and a sponsor for the 11u backport of > https://bugs.openjdk.java.net/browse/JDK-8218268? > > For the patch to apply cleanly, I had to first apply the patch for > https://bugs.openjdk.java.net/browse/JDK-8232170 (which deals with a > related issue). > > The webrev containing both these patches resides at > http://cr.openjdk.java.net/~jpai/webrev/8218268-11u-backport/webrev/ > > -Jaikiran > > From goetz.lindenmaier at sap.com Sat Dec 21 12:20:33 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 21 Dec 2019 12:20:33 +0000 Subject: [11u] RFR: 8213010: Supporting keys created with certmgr.exe Message-ID: Hi, I would like to downport this for parity with 11.0.7-Oracle. It does not apply clean because in 11 changes were applied in a different order than in 14. http://cr.openjdk.java.net/~goetz/wr19/8213010-certmgr.exe_keys-jdk11/ In ECUtil.java I had to resolve the Copyright. patching file src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp This fails because "8221407: Windows 32bit build error in libsunmscapi/security.cpp" and "8210870: Libsunmscapi improved interactions" are already in 11, but in 14 they come on top of this change. I resolved this file so that it looks the same as in 14 after 8221407. After pushing 8213009 and this, jdk11u-dev and jdk/jdk will have the same changes for security.cpp: jdk11 Filelog for security.cpp: 8213010: Supporting keys created with certmgr.exe 8213009: Refactoring existing SunMSCAPI classes 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow 8201355: Avoid native memory allocation in sun.security.mscapi.PRNG.generateSeed 8221407: Windows 32bit build error in libsunmscapi/security.cpp 8210870: Libsunmscapi improved interactions 8196897: Improve PRNG supportjdk-11.0.1+0 8205445: Add RSASSA-PSS Signature support to SunMSCAPI 8204572: SetupJdkLibrary should setup SRC and -I flags automatically 8193262: JNI array not released in libsunmscapi convertToLittleEndian 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017 8199198: Remove unused functions in jdk.crypto.mscapi native code 8187443: Forest Consolidation: Move files to unified layout Jdk/jdk filelog for security.cpp: 8221407: Windows 32bit build error in libsunmscapi/security.cpp 8210870: Libsunmscapi improved interactions 8213010: Supporting keys created with certmgr.exe 8213009: Refactoring existing SunMSCAPI classes 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow 8201355: Avoid native memory allocation in sun.security.mscapi.PRNG.generateSeed 8196897: Improve PRNG support 8205445: Add RSASSA-PSS Signature support to SunMSCAPI 8204572: SetupJdkLibrary should setup SRC and -I flags automatically 8193262: JNI array not released in libsunmscapi convertToLittleEndian 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017 8199198: Remove unused functions in jdk.crypto.mscapi native code 8187443: Forest Consolidation: Move files to unified layout Jdk/jdk has two changes on top of this. But if updating to 8221407 in jdk/jdk, security.cpp are Similar in both repos. Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Dec 23 09:21:44 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Dec 2019 09:21:44 +0000 Subject: [11u] RFR: 8209807: improve handling exception in requires.VMProps Message-ID: Hi I would like to downport this for parity with 11.0.7-oracle. I had to resolve because isNvdimmTestEnabled() is not in 11. Skipped corresponding parts. http://cr.openjdk.java.net/~goetz/wr19/8209807-exc_requires-jdk11/01/ https://bugs.openjdk.java.net/browse/JDK-8209807 http://hg.openjdk.java.net/jdk/jdk/rev/a6fb5e60588f Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Dec 23 09:51:20 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Dec 2019 09:51:20 +0000 Subject: [11u] RFR: 8229345: Memory leak due to vtable stubs not being shared on SPARC Message-ID: Hi, I would like to downport this for parity with 11.0.7-oracle. I only had to do trivial resolves. Flag can be removed also in 11 as it's only a debug flag. http://cr.openjdk.java.net/~goetz/wr19/8229345-vtable_stub_SPARC-jdk11/01/ https://bugs.openjdk.java.net/browse/JDK-8229345 https://hg.openjdk.java.net/jdk/jdk/rev/0a8407a78a2f Best regards, Goetz. From martin.doerr at sap.com Mon Dec 23 11:28:03 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 23 Dec 2019 11:28:03 +0000 Subject: [11u] RFR: 8213009: Refactoring existing SunMSCAPI classes In-Reply-To: References: Message-ID: Hi G?tz, src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java: The manually integrated Debug code for "java.security.debug" or " java.security.auth.debug" = "keystore" looks correct. src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp: I'd consider these changes trivial: comment insertion, variable renamed. Reviewed. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Donnerstag, 19. Dezember 2019 11:59 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8213009: Refactoring existing SunMSCAPI > classes > > Hi, > > I would like to downport this change for parity with 11.0.7-oracle. > It required some non-trivial resolves: > http://cr.openjdk.java.net/~goetz/wr19/8213009-refactor_mscapi-jdk11/01/ > > Patching file > src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/KeyStore.java > failed. The file was deleted. > 11 differes a lot to the file deleted in 13. Most diffs are comments though, > except for this: > > @@ -47,6 +44,8 @@ > import java.security.interfaces.RSAPrivateCrtKey; > import java.util.*; > +import sun.security.util.Debug; > + > /** > * Implementation of key store for Windows using the Microsoft Crypto API. > * > @@ -188,6 +187,7 @@ > private static final String KEYSTORE_COMPATIBILITY_MODE_PROP = > "sun.security.mscapi.keyStoreCompatibilityMode"; > private final boolean keyStoreCompatibilityMode; > + private static final Debug debug = Debug.getInstance("keystore"); > /* > * The keystore entries. > @@ -731,6 +731,11 @@ > } catch (KeyStoreException e) { > throw new IOException(e); > } > + > + if (debug != null) { > + debug.println("MSCAPI keystore load: entry count: " + > + entries.size()); > + } > } > /** > > This code was introduced by "8218553: Enhance keystore load debug output" > which was downported to 11.0.5 and had to be modified. > I applied the coding to CKeyStore.java where it was in the original > patch of 8218553. > > In > patching file > src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp > Two hunks failed that were easy to resolve: > > --- security.cpp > +++ security.cpp > @@ -570,9 +586,8 @@ > // Determine key type: RSA or DSA > DWORD dwData = CALG_RSA_KEYX; > DWORD dwSize = sizeof(DWORD); > - ::CryptGetKeyParam(hUserKey, KP_ALGID, (BYTE*)&dwData, > + ::CryptGetKeyParam(hUserKey, KP_ALGID, (BYTE*)&dwData, > //deprecated > &dwSize, NULL); > - > if ((dwData & ALG_TYPE_RSA) == ALG_TYPE_RSA) > { > // Generate RSA certificate chain and store into cert > @@ -966,7 +981,7 @@ > NULL, > &hk, > hCryptProv, > - hKey, > + hCryptKey, > NULL, > 0)); > > Best regards, > Goetz > > From goetz.lindenmaier at sap.com Mon Dec 23 11:31:36 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Dec 2019 11:31:36 +0000 Subject: [11u] RFR: 8213009: Refactoring existing SunMSCAPI classes In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing! Best regards, Goetz > -----Original Message----- > From: Doerr, Martin > Sent: Monday, December 23, 2019 12:28 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8213009: Refactoring existing SunMSCAPI classes > > Hi G?tz, > > src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java: > The manually integrated Debug code for "java.security.debug" or " > java.security.auth.debug" = "keystore" looks correct. > > src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp: > I'd consider these changes trivial: comment insertion, variable renamed. > > Reviewed. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Donnerstag, 19. Dezember 2019 11:59 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8213009: Refactoring existing SunMSCAPI > > classes > > > > Hi, > > > > I would like to downport this change for parity with 11.0.7-oracle. > > It required some non-trivial resolves: > > http://cr.openjdk.java.net/~goetz/wr19/8213009-refactor_mscapi- > jdk11/01/ > > > > Patching file > > > src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/KeyStore.java > > failed. The file was deleted. > > 11 differes a lot to the file deleted in 13. Most diffs are comments though, > > except for this: > > > > @@ -47,6 +44,8 @@ > > import java.security.interfaces.RSAPrivateCrtKey; > > import java.util.*; > > +import sun.security.util.Debug; > > + > > /** > > * Implementation of key store for Windows using the Microsoft Crypto > API. > > * > > @@ -188,6 +187,7 @@ > > private static final String KEYSTORE_COMPATIBILITY_MODE_PROP = > > "sun.security.mscapi.keyStoreCompatibilityMode"; > > private final boolean keyStoreCompatibilityMode; > > + private static final Debug debug = Debug.getInstance("keystore"); > > /* > > * The keystore entries. > > @@ -731,6 +731,11 @@ > > } catch (KeyStoreException e) { > > throw new IOException(e); > > } > > + > > + if (debug != null) { > > + debug.println("MSCAPI keystore load: entry count: " + > > + entries.size()); > > + } > > } > > /** > > > > This code was introduced by "8218553: Enhance keystore load debug > output" > > which was downported to 11.0.5 and had to be modified. > > I applied the coding to CKeyStore.java where it was in the original > > patch of 8218553. > > > > In > > patching file > > src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp > > Two hunks failed that were easy to resolve: > > > > --- security.cpp > > +++ security.cpp > > @@ -570,9 +586,8 @@ > > // Determine key type: RSA or DSA > > DWORD dwData = CALG_RSA_KEYX; > > DWORD dwSize = sizeof(DWORD); > > - ::CryptGetKeyParam(hUserKey, KP_ALGID, (BYTE*)&dwData, > > + ::CryptGetKeyParam(hUserKey, KP_ALGID, (BYTE*)&dwData, > > //deprecated > > &dwSize, NULL); > > - > > if ((dwData & ALG_TYPE_RSA) == ALG_TYPE_RSA) > > { > > // Generate RSA certificate chain and store into cert > > @@ -966,7 +981,7 @@ > > NULL, > > &hk, > > hCryptProv, > > - hKey, > > + hCryptKey, > > NULL, > > 0)); > > > > Best regards, > > Goetz > > > > From martin.doerr at sap.com Mon Dec 23 11:32:50 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 23 Dec 2019 11:32:50 +0000 Subject: [11u] RFR: 8229345: Memory leak due to vtable stubs not being shared on SPARC In-Reply-To: References: Message-ID: Hi G?tz, thanks for backporting. Looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 23. Dezember 2019 10:51 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 8229345: Memory leak due to vtable stubs not > being shared on SPARC > > Hi, > > I would like to downport this for parity with 11.0.7-oracle. > I only had to do trivial resolves. > Flag can be removed also in 11 as it's only a debug flag. > > http://cr.openjdk.java.net/~goetz/wr19/8229345-vtable_stub_SPARC- > jdk11/01/ > > https://bugs.openjdk.java.net/browse/JDK-8229345 > https://hg.openjdk.java.net/jdk/jdk/rev/0a8407a78a2f > > Best regards, > Goetz. From christoph.langer at sap.com Mon Dec 23 14:00:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 Dec 2019 14:00:14 +0000 Subject: [11u] RFR: 8232167: Visual Studio install found through --with-tools-dir value is discarded Message-ID: Hi, please review this simple backport of a simple build system fix which unfortunately did not apply cleanly. It's just context changes that needed to be resolved. I ran into this with jdk11u after I reinstalled my Visual Studio to a non-default folder and used configure option --with-tools-dir. So it should be backported. Bug: https://bugs.openjdk.java.net/browse/JDK-8232167 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/5a4b4544b810 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232167.11u/ Thanks Christoph From martin.doerr at sap.com Mon Dec 23 14:11:50 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 23 Dec 2019 14:11:50 +0000 Subject: [11u] RFR: 8232167: Visual Studio install found through --with-tools-dir value is discarded In-Reply-To: References: Message-ID: Hi Christoph, looks good. Thanks for backporting. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Montag, 23. Dezember 2019 15:00 > To: jdk-updates-dev > Cc: build-dev > Subject: [11u] RFR: 8232167: Visual Studio install found through -- > with-tools-dir value is discarded > > Hi, > > please review this simple backport of a simple build system fix which > unfortunately did not apply cleanly. It's just context changes that needed to > be resolved. I ran into this with jdk11u after I reinstalled my Visual Studio to a > non-default folder and used configure option --with-tools-dir. So it should be > backported. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232167 > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/5a4b4544b810 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232167.11u/ > > Thanks > Christoph From christoph.langer at sap.com Mon Dec 23 14:29:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 Dec 2019 14:29:46 +0000 Subject: [11u] RFR: 8236500: Windows ucrt.dll should be looked up in versioned WINSDK subdirectory Message-ID: Hi, please review a backport of a carveout of JDK-8215445: "Enable building for Windows in WSL" [0]. When building 11u after I've reinstalled Visual Studio and the Windows Devkit to non-default folder locations, I ran into the issue that ucrt.dll would not be correctly resolved, since it sits in a versioned subdirectory of ...\WindowsKits, e.g. ...\WindowsKits\10\Lib\10.0.17763.0\ucrt\. This problem was fixed as part of JDK-8215445. However, I don't want to backport the whole change, at least not at the moment, so I created a new bug to fix this specific issue in OpenJDK 11 Updates. Please review. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8236500.11u/ Bug: https://bugs.openjdk.java.net/browse/JDK-8236500 Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8215445 From martin.doerr at sap.com Mon Dec 23 15:02:17 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 23 Dec 2019 15:02:17 +0000 Subject: [11u] RFR: 8236500: Windows ucrt.dll should be looked up in versioned WINSDK subdirectory In-Reply-To: References: Message-ID: Hi Christoph, looks good. Thanks for fixing this part in 11u. Best regards, Martin > -----Original Message----- > From: build-dev On Behalf Of > Langer, Christoph > Sent: Montag, 23. Dezember 2019 15:30 > To: jdk-updates-dev > Cc: build-dev > Subject: [11u] RFR: 8236500: Windows ucrt.dll should be looked > up in versioned WINSDK subdirectory > > Hi, > > please review a backport of a carveout of JDK-8215445: "Enable building for > Windows in WSL" [0]. When building 11u after I've reinstalled Visual Studio > and the Windows Devkit to non-default folder locations, I ran into the issue > that ucrt.dll would not be correctly resolved, since it sits in a versioned > subdirectory of ...\WindowsKits, e.g. > ...\WindowsKits\10\Lib\10.0.17763.0\ucrt\. This problem was fixed as part of > JDK-8215445. However, I don't want to backport the whole change, at least > not at the moment, so I created a new bug to fix this specific issue in > OpenJDK 11 Updates. Please review. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8236500.11u/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8236500 > > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8215445 From christoph.langer at sap.com Mon Dec 23 16:42:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 Dec 2019 16:42:00 +0000 Subject: [11u] RFR: 8213010: Supporting keys created with certmgr.exe In-Reply-To: References: Message-ID: Hi Goetz, this looks good to me. I compared security.cpp after I've applied your changes to the version in jdk/jdk and there are only the changes missing that come with newer changes JDK-8223003 and JDK-8223063. Thanks for backporting this. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Samstag, 21. Dezember 2019 13:21 > To: jdk-updates-dev at openjdk.java.net; OpenJDK Dev list dev at openjdk.java.net> > Subject: [CAUTION] [11u] RFR: 8213010: Supporting keys created with > certmgr.exe > > Hi, > > I would like to downport this for parity with 11.0.7-Oracle. > It does not apply clean because in 11 changes were applied in > a different order than in 14. > > http://cr.openjdk.java.net/~goetz/wr19/8213010-certmgr.exe_keys-jdk11/ > > In ECUtil.java I had to resolve the Copyright. > > patching file > src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp > This fails because "8221407: Windows 32bit build error in > libsunmscapi/security.cpp" and > "8210870: Libsunmscapi improved interactions" are already in 11, but in 14 > they come > on top of this change. > I resolved this file so that it looks the same as in 14 after 8221407. > > After pushing 8213009 and this, jdk11u-dev and jdk/jdk will have the same > changes > for security.cpp: > > jdk11 Filelog for security.cpp: > > 8213010: Supporting keys created with certmgr.exe > 8213009: Refactoring existing SunMSCAPI classes > 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow > 8201355: Avoid native memory allocation in > sun.security.mscapi.PRNG.generateSeed > 8221407: Windows 32bit build error in libsunmscapi/security.cpp > 8210870: Libsunmscapi improved interactions > 8196897: Improve PRNG supportjdk-11.0.1+0 > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI > 8204572: SetupJdkLibrary should setup SRC and -I flags automatically > 8193262: JNI array not released in libsunmscapi convertToLittleEndian > 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017 > 8199198: Remove unused functions in jdk.crypto.mscapi native code > 8187443: Forest Consolidation: Move files to unified layout > > Jdk/jdk filelog for security.cpp: > > 8221407: Windows 32bit build error in libsunmscapi/security.cpp > 8210870: Libsunmscapi improved interactions > 8213010: Supporting keys created with certmgr.exe > 8213009: Refactoring existing SunMSCAPI classes > 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow > 8201355: Avoid native memory allocation in > sun.security.mscapi.PRNG.generateSeed > 8196897: Improve PRNG support > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI > 8204572: SetupJdkLibrary should setup SRC and -I flags automatically > 8193262: JNI array not released in libsunmscapi convertToLittleEndian > 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017 > 8199198: Remove unused functions in jdk.crypto.mscapi native code > 8187443: Forest Consolidation: Move files to unified layout > > Jdk/jdk has two changes on top of this. > But if updating to 8221407 in jdk/jdk, security.cpp are > Similar in both repos. > > Best regards, > Goetz. From christoph.langer at sap.com Mon Dec 23 16:47:03 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 Dec 2019 16:47:03 +0000 Subject: [11u] RFR: 8209807: improve handling exception in requires.VMProps In-Reply-To: References: Message-ID: Hi Goetz, the backport seems correct to me. Assuming that there are no regressions, I think this is good to go. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 23. Dezember 2019 10:22 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 8209807: improve handling exception in > requires.VMProps > > Hi > > I would like to downport this for parity with 11.0.7-oracle. > > I had to resolve because isNvdimmTestEnabled() is not in 11. > Skipped corresponding parts. > > http://cr.openjdk.java.net/~goetz/wr19/8209807-exc_requires-jdk11/01/ > > https://bugs.openjdk.java.net/browse/JDK-8209807 > http://hg.openjdk.java.net/jdk/jdk/rev/a6fb5e60588f > > Best regards, > Goetz. From christoph.langer at sap.com Mon Dec 23 16:52:39 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 Dec 2019 16:52:39 +0000 Subject: [11u] RFR: 8236500: Windows ucrt.dll should be looked up in versioned WINSDK subdirectory In-Reply-To: References: Message-ID: Thanks for the review, Martin. > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 23. Dezember 2019 16:02 > To: Langer, Christoph ; jdk-updates-dev updates-dev at openjdk.java.net> > Cc: build-dev > Subject: RE: [11u] RFR: 8236500: Windows ucrt.dll should be looked up in > versioned WINSDK subdirectory > > Hi Christoph, > > looks good. Thanks for fixing this part in 11u. > > Best regards, > Martin > > > > -----Original Message----- > > From: build-dev On Behalf Of > > Langer, Christoph > > Sent: Montag, 23. Dezember 2019 15:30 > > To: jdk-updates-dev > > Cc: build-dev > > Subject: [11u] RFR: 8236500: Windows ucrt.dll should be looked > > up in versioned WINSDK subdirectory > > > > Hi, > > > > please review a backport of a carveout of JDK-8215445: "Enable building for > > Windows in WSL" [0]. When building 11u after I've reinstalled Visual Studio > > and the Windows Devkit to non-default folder locations, I ran into the issue > > that ucrt.dll would not be correctly resolved, since it sits in a versioned > > subdirectory of ...\WindowsKits, e.g. > > ...\WindowsKits\10\Lib\10.0.17763.0\ucrt\. This problem was fixed as part > of > > JDK-8215445. However, I don't want to backport the whole change, at least > > not at the moment, so I created a new bug to fix this specific issue in > > OpenJDK 11 Updates. Please review. > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8236500.11u/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236500 > > > > Thanks > > Christoph > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8215445 From christoph.langer at sap.com Mon Dec 23 16:52:49 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 Dec 2019 16:52:49 +0000 Subject: [11u] RFR: 8232167: Visual Studio install found through --with-tools-dir value is discarded In-Reply-To: References: Message-ID: Thanks for the review, Martin. > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 23. Dezember 2019 15:12 > To: Langer, Christoph ; jdk-updates-dev updates-dev at openjdk.java.net> > Cc: build-dev > Subject: RE: [11u] RFR: 8232167: Visual Studio install found through --with- > tools-dir value is discarded > > Hi Christoph, > > looks good. Thanks for backporting. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Langer, Christoph > > Sent: Montag, 23. Dezember 2019 15:00 > > To: jdk-updates-dev > > Cc: build-dev > > Subject: [11u] RFR: 8232167: Visual Studio install found through -- > > with-tools-dir value is discarded > > > > Hi, > > > > please review this simple backport of a simple build system fix which > > unfortunately did not apply cleanly. It's just context changes that needed > to > > be resolved. I ran into this with jdk11u after I reinstalled my Visual Studio to > a > > non-default folder and used configure option --with-tools-dir. So it should > be > > backported. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232167 > > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/5a4b4544b810 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232167.11u/ > > > > Thanks > > Christoph From goetz.lindenmaier at sap.com Mon Dec 23 17:30:13 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Dec 2019 17:30:13 +0000 Subject: [11u] RFR: 8213010: Supporting keys created with certmgr.exe In-Reply-To: References: Message-ID: Hi Christoph, Thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Monday, December 23, 2019 5:42 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net; OpenJDK Dev list > Subject: RE: [11u] RFR: 8213010: Supporting keys created with certmgr.exe > > Hi Goetz, > > this looks good to me. I compared security.cpp after I've applied your > changes to the version in jdk/jdk and there are only the changes missing that > come with newer changes JDK-8223003 and JDK-8223063. > > Thanks for backporting this. > > Cheers > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Samstag, 21. Dezember 2019 13:21 > > To: jdk-updates-dev at openjdk.java.net; OpenJDK Dev list > dev at openjdk.java.net> > > Subject: [CAUTION] [11u] RFR: 8213010: Supporting keys created with > > certmgr.exe > > > > Hi, > > > > I would like to downport this for parity with 11.0.7-Oracle. > > It does not apply clean because in 11 changes were applied in > > a different order than in 14. > > > > http://cr.openjdk.java.net/~goetz/wr19/8213010-certmgr.exe_keys- > jdk11/ > > > > In ECUtil.java I had to resolve the Copyright. > > > > patching file > > src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp > > This fails because "8221407: Windows 32bit build error in > > libsunmscapi/security.cpp" and > > "8210870: Libsunmscapi improved interactions" are already in 11, but in 14 > > they come > > on top of this change. > > I resolved this file so that it looks the same as in 14 after 8221407. > > > > After pushing 8213009 and this, jdk11u-dev and jdk/jdk will have the same > > changes > > for security.cpp: > > > > jdk11 Filelog for security.cpp: > > > > 8213010: Supporting keys created with certmgr.exe > > 8213009: Refactoring existing SunMSCAPI classes > > 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow > > 8201355: Avoid native memory allocation in > > sun.security.mscapi.PRNG.generateSeed > > 8221407: Windows 32bit build error in libsunmscapi/security.cpp > > 8210870: Libsunmscapi improved interactions > > 8196897: Improve PRNG supportjdk-11.0.1+0 > > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI > > 8204572: SetupJdkLibrary should setup SRC and -I flags automatically > > 8193262: JNI array not released in libsunmscapi convertToLittleEndian > > 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017 > > 8199198: Remove unused functions in jdk.crypto.mscapi native code > > 8187443: Forest Consolidation: Move files to unified layout > > > > Jdk/jdk filelog for security.cpp: > > > > 8221407: Windows 32bit build error in libsunmscapi/security.cpp > > 8210870: Libsunmscapi improved interactions > > 8213010: Supporting keys created with certmgr.exe > > 8213009: Refactoring existing SunMSCAPI classes > > 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow > > 8201355: Avoid native memory allocation in > > sun.security.mscapi.PRNG.generateSeed > > 8196897: Improve PRNG support > > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI > > 8204572: SetupJdkLibrary should setup SRC and -I flags automatically > > 8193262: JNI array not released in libsunmscapi convertToLittleEndian > > 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017 > > 8199198: Remove unused functions in jdk.crypto.mscapi native code > > 8187443: Forest Consolidation: Move files to unified layout > > > > Jdk/jdk has two changes on top of this. > > But if updating to 8221407 in jdk/jdk, security.cpp are > > Similar in both repos. > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Tue Dec 24 08:31:25 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Dec 2019 08:31:25 +0000 Subject: [11u] RFR: 8229345: Memory leak due to vtable stubs not being shared on SPARC In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Monday, December 23, 2019 12:33 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8229345: Memory leak due to vtable stubs not being > shared on SPARC > > Hi G?tz, > > thanks for backporting. Looks good. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Montag, 23. Dezember 2019 10:51 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR: 8229345: Memory leak due to vtable stubs > not > > being shared on SPARC > > > > Hi, > > > > I would like to downport this for parity with 11.0.7-oracle. > > I only had to do trivial resolves. > > Flag can be removed also in 11 as it's only a debug flag. > > > > http://cr.openjdk.java.net/~goetz/wr19/8229345-vtable_stub_SPARC- > > jdk11/01/ > > > > https://bugs.openjdk.java.net/browse/JDK-8229345 > > https://hg.openjdk.java.net/jdk/jdk/rev/0a8407a78a2f > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Tue Dec 24 08:32:15 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Dec 2019 08:32:15 +0000 Subject: [11u] RFR: 8209807: improve handling exception in requires.VMProps In-Reply-To: References: Message-ID: Hi Christoph, Yes, it passed the testing. Thanks for reviewing. Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Monday, December 23, 2019 5:47 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8209807: improve handling exception in > requires.VMProps > > Hi Goetz, > > the backport seems correct to me. Assuming that there are no regressions, I > think this is good to go. > > Cheers > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Montag, 23. Dezember 2019 10:22 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR: 8209807: improve handling exception in > > requires.VMProps > > > > Hi > > > > I would like to downport this for parity with 11.0.7-oracle. > > > > I had to resolve because isNvdimmTestEnabled() is not in 11. > > Skipped corresponding parts. > > > > http://cr.openjdk.java.net/~goetz/wr19/8209807-exc_requires-jdk11/01/ > > > > https://bugs.openjdk.java.net/browse/JDK-8209807 > > http://hg.openjdk.java.net/jdk/jdk/rev/a6fb5e60588f > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Tue Dec 24 09:05:56 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Dec 2019 09:05:56 +0000 Subject: [11u] RFR: 8210632: Add key exchange algorithm to javax/net/ssl/TLSCommon/CipherSuite.java Message-ID: Hi had to resolve because the change "8140466: ChaCha20 and Poly1305 TLS Cipher Suites" added test case TLS_CHACHA20_POLY1305_SHA256() to CipherSuite.java which is not in 11. http://cr.openjdk.java.net/~goetz/wr19/8210632-add_key_exchange-jdk11/01/ https://bugs.openjdk.java.net/browse/JDK-8210632 http://hg.openjdk.java.net/jdk/jdk/rev/e3c221bc1711 Best regards, Goetz. From goetz.lindenmaier at sap.com Tue Dec 24 09:43:07 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Dec 2019 09:43:07 +0000 Subject: [11u] RFR: 8217634: RunTest documentation and usability update Message-ID: Hi, I had to do a lot of resolves for this one. It passed Our build and testing. This change has a lot of syntactic corrections, like adding line breaks. Many of these are in code not in 11. I skipped them. The change adds documentation for JCOV. This is not supported by 11 (and I can't see "8215729: Enhance makefiles to allow collecting code coverage with JCov" https://bugs.openjdk.java.net/browse/JDK-8215729 was downported), so I removed the sections. patching file doc/testing.html I added the documentation text for AOT Modules. Skipped renaming id vm_options-1 to vm_options-2 because it does not exist in this file. patching file doc/testing.md Two hunks failed. The first corrects a sentence that is not in 11, skipped. The second adds text about AOT, added. patching file make/RunTests.gmk AOT_MODULES is moved from the SINGLE_KEYWPORDS list to the STRING_KEYWORDS list. This didin't apply due to different context, resolved. Skipped adding a line break because code does not exist in 11. Change in comment for ParseMicroTestSelection skipped, not in 11. Change in comment for ParseSpecialTestSelection skipped, not in 11. Syntactic Change to $1_MICRO_BASIC_OPTIONS skipped, not in 11. Syntactic Change to $1_MICRO_VM_OPTION skipped, not in 11. http://cr.openjdk.java.net/~goetz/wr19/8217634-RunTest_doc-jdk11/01/ https://bugs.openjdk.java.net/browse/JDK-8217634 http://hg.openjdk.java.net/jdk/jdk/rev/650527b39f00 Best regards, Goetz. From goetz.lindenmaier at sap.com Tue Dec 24 11:20:54 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Dec 2019 11:20:54 +0000 Subject: [11u] RFR: 8223464: Improve version string for Oracle CI builds Message-ID: Hi I would like to downport this for parity with 11.0.7-oracle. It does not apply due to changes in context. http://cr.openjdk.java.net/~goetz/wr19/8223464-OracleCI_version_string-jdk11/01/ https://bugs.openjdk.java.net/browse/JDK-8223464 http://hg.openjdk.java.net/jdk/jdk/rev/5600f5c38b0b Best regards, Goetz. From goetz.lindenmaier at sap.com Wed Dec 25 16:06:06 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 25 Dec 2019 16:06:06 +0000 Subject: [11u notice]: jdk11u closed now Message-ID: Hi, Tag jdk-11.0.6+9 was pushed. jdk11u is closed now. Please don't push to jdk11u any more. The closed security changes for 11.0.6 will be prepared on top of this tag. Best regards, Goetz. See also https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u From goetz.lindenmaier at sap.com Fri Dec 27 09:08:16 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 27 Dec 2019 09:08:16 +0000 Subject: [11u] RFR: 8225766: Curve in certificate should not affect signature scheme when using TLSv1.3 Message-ID: Hi, I would like to downport this for parity with 11.0.7-oracle. I had to resolve the added import in SignatureScheme.java ... trivial ... http://cr.openjdk.java.net/~goetz/wr19/8225766-Curve_affects-jdk11/01/ https://bugs.openjdk.java.net/browse/JDK-8225766 http://hg.openjdk.java.net/jdk/jdk13/rev/1170b6d92d1c Best regards, Goetz. From goetz.lindenmaier at sap.com Fri Dec 27 09:30:32 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 27 Dec 2019 09:30:32 +0000 Subject: [11u] RFR: 8228479: Correct the format of ColorChooserDemoTest Message-ID: Hi I would like to downport this for parity with 11.0.7-oracle. It only corrects indentation. It did not apply because 11 has a newline at the end of the file 14 did not have. Trivial. http://cr.openjdk.java.net/~goetz/wr19/8228479-ColorChooserDemo_format-jdk11/01/ https://bugs.openjdk.java.net/browse/JDK-8228479 https://hg.openjdk.java.net/jdk/jdk/rev/8538b1f28a71 Best regards, Goetz. From goetz.lindenmaier at sap.com Fri Dec 27 10:13:20 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 27 Dec 2019 10:13:20 +0000 Subject: [11u] RFR: 8223638: Replace wildcard address with loopback or local host in tests - part 6 Message-ID: Hi, I would like to downport this because a later 11.0.7-oracle change Applies clean with this. I had to do a simple resolve due to context in UnreferencedSockets.java http://cr.openjdk.java.net/~goetz/wr19/8223638-replace_wildcard_6-jdk11/01/ https://bugs.openjdk.java.net/browse/JDK-8223638 http://hg.openjdk.java.net/jdk/jdk/rev/43439afaab4a Best regards, Goetz. From martin.doerr at sap.com Fri Dec 27 14:36:13 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 27 Dec 2019 14:36:13 +0000 Subject: [11u] RFR: 8223638: Replace wildcard address with loopback or local host in tests - part 6 In-Reply-To: References: Message-ID: Hi G?tz, looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 27. Dezember 2019 11:13 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8223638: Replace wildcard address with > loopback or local host in tests - part 6 > > Hi, > > I would like to downport this because a later 11.0.7-oracle change > Applies clean with this. > I had to do a simple resolve due to context in UnreferencedSockets.java > > http://cr.openjdk.java.net/~goetz/wr19/8223638-replace_wildcard_6- > jdk11/01/ > https://bugs.openjdk.java.net/browse/JDK-8223638 > http://hg.openjdk.java.net/jdk/jdk/rev/43439afaab4a > > Best regards, > Goetz. From martin.doerr at sap.com Fri Dec 27 14:37:02 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 27 Dec 2019 14:37:02 +0000 Subject: [11u] RFR: 8228479: Correct the format of ColorChooserDemoTest In-Reply-To: References: Message-ID: Ok. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 27. Dezember 2019 10:31 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8228479: Correct the format of > ColorChooserDemoTest > > Hi > > I would like to downport this for parity with 11.0.7-oracle. > It only corrects indentation. > It did not apply because 11 has a newline at the end of the file > 14 did not have. Trivial. > > http://cr.openjdk.java.net/~goetz/wr19/8228479- > ColorChooserDemo_format-jdk11/01/ > https://bugs.openjdk.java.net/browse/JDK-8228479 > https://hg.openjdk.java.net/jdk/jdk/rev/8538b1f28a71 > > Best regards, > Goetz. From martin.doerr at sap.com Fri Dec 27 14:38:18 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 27 Dec 2019 14:38:18 +0000 Subject: [11u] RFR: 8225766: Curve in certificate should not affect signature scheme when using TLSv1.3 In-Reply-To: References: Message-ID: Ok. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 27. Dezember 2019 10:08 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8225766: Curve in certificate should not affect > signature scheme when using TLSv1.3 > > Hi, > > I would like to downport this for parity with 11.0.7-oracle. > I had to resolve the added import in SignatureScheme.java ... trivial ... > > http://cr.openjdk.java.net/~goetz/wr19/8225766-Curve_affects-jdk11/01/ > https://bugs.openjdk.java.net/browse/JDK-8225766 > http://hg.openjdk.java.net/jdk/jdk13/rev/1170b6d92d1c > > Best regards, > Goetz. From martin.doerr at sap.com Fri Dec 27 14:42:43 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 27 Dec 2019 14:42:43 +0000 Subject: [11u] RFR: 8223464: Improve version string for Oracle CI builds In-Reply-To: References: Message-ID: Ok. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 24. Dezember 2019 12:21 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8223464: Improve version string for Oracle CI > builds > > Hi > > I would like to downport this for parity with 11.0.7-oracle. > It does not apply due to changes in context. > > http://cr.openjdk.java.net/~goetz/wr19/8223464-OracleCI_version_string- > jdk11/01/ > https://bugs.openjdk.java.net/browse/JDK-8223464 > > http://hg.openjdk.java.net/jdk/jdk/rev/5600f5c38b0b > > Best regards, > Goetz. From christoph.langer at sap.com Sun Dec 29 17:38:17 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 29 Dec 2019 17:38:17 +0000 Subject: [11u] RFR: 8210632: Add key exchange algorithm to javax/net/ssl/TLSCommon/CipherSuite.java In-Reply-To: References: Message-ID: Hi Goetz, Looks good. I compared test/jdk/javax/net/ssl/TLSCommon/CipherSuite.java after your patch with the version of jdk13u and - as expected - it's only TLS_CHACHA20_POLY1305_SHA256 that's missing. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 24. Dezember 2019 10:06 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 8210632: Add key exchange algorithm to > javax/net/ssl/TLSCommon/CipherSuite.java > > Hi > > had to resolve because the change > "8140466: ChaCha20 and Poly1305 TLS Cipher Suites" > added test case TLS_CHACHA20_POLY1305_SHA256() to CipherSuite.java > which is not in 11. > > http://cr.openjdk.java.net/~goetz/wr19/8210632-add_key_exchange- > jdk11/01/ > > https://bugs.openjdk.java.net/browse/JDK-8210632 > http://hg.openjdk.java.net/jdk/jdk/rev/e3c221bc1711 > > Best regards, > Goetz. From jai.forums2013 at gmail.com Mon Dec 30 03:08:44 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 30 Dec 2019 08:38:44 +0530 Subject: [11u] RFR: 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: <69105c6f-0a18-172f-6d05-e3d71887a308@gmail.com> References: <69105c6f-0a18-172f-6d05-e3d71887a308@gmail.com> Message-ID: <93262ab5-b687-2642-b28e-9bf7ca0c040f@gmail.com> Anyone willing to review and sponsor, please? -Jaikiran On 20/12/19 9:46 PM, Jaikiran Pai wrote: > Can I please get a review and a sponsor for the 11u backport of > https://bugs.openjdk.java.net/browse/JDK-8218268? > > For the patch to apply cleanly, I had to first apply the patch for > https://bugs.openjdk.java.net/browse/JDK-8232170 (which deals with a > related issue). > > The webrev containing both these patches resides at > http://cr.openjdk.java.net/~jpai/webrev/8218268-11u-backport/webrev/ > > -Jaikiran > > From christoph.langer at sap.com Mon Dec 30 08:58:52 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 30 Dec 2019 08:58:52 +0000 Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event creates unexpected amount of checkpoint data In-Reply-To: References: Message-ID: Hi Jaroslav, I just reviewed and tested the backport for JDK-8210024. It mostly applies, just one trivial resolve in thread.cpp is necessary. I end up with the same patch as in your webrev. Running it through jdk11u-dev build & testing shows no problems so I'll approve and push it now and continue with JDK-8214850. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Jaroslav Bachor?k > Sent: Freitag, 15. November 2019 16:46 > To: jdk-updates-dev > Subject: [DMARC FAILURE] [11u] [JFR] RFR 8225797: OldObjectSample event > creates unexpected amount of checkpoint data > > Hi, > > I would like to get this non-trivial JFR related backport reviewed. This > backport is required because OldObjectSample event in the current (JDK 11) > form will cause unlimited growth of the recording thus making this event > unsuitable in production memory leak detection - which is its main purpose. > > The backport for 8225797 requires several other changes to be backported as > well. I am listing the changes and the related webrevs here in order to > have all the pieces in one place. The webrevs, unfortunately, are showing > cumulative changes, so please, disregard that information. Each webrev is > generated for that particular commit. > > The following tests were run successfully: > - jdk_tier1 > - jdk_tier2 > - jdk_jfr > - jdk_core > > --- > > Prerequisites: > # 8209850 : Allow NamedThreads to use GlobalCounter critical sections > - applied almost cleanly with only minimal changes to account for slightly > different code structure (patch diff - > http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/patch.diff) > JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209850 > Webrev : http://cr.openjdk.java.net/~jbachorik/8209850/webrev.00/ > > # 8209976: Improve iteration over non-JavaThreads > - applied almost cleanly with only minimal changes to account for slightly > different code structure (patch diff - > http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/patch.diff) > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209976 > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209976/webrev.00/ > > > # 8210024: JFR calls virtual is_Java_thread from ~Thread() > - applied almost cleanly with only minimal changes to account for slightly > different code structure (patch diff - > http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/patch.diff) > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8210024 > - Webrev : http://cr.openjdk.java.net/~jbachorik/8210024/webrev.00/ > > # 8214850: Rename vm_operations.?pp files to vmOperations.?pp files > - applied almost cleanly with only minimal changes to account for slightly > different code structure (patch diff - > http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/patch.diff) > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8214850 > - Webrev : http://cr.openjdk.java.net/~jbachorik/8214850/webrev.00/ > > # 8209802: Garbage collectors should register JFR types themselves to avoid > build errors. > - applied almost cleanly with only minimal changes to account for slightly > different code locations for g1 sources (patch diff - > http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/patch.diff) > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8209802 > - Webrev : http://cr.openjdk.java.net/~jbachorik/8209802/webrev.00/ > > > Backport: > # 8225797: OldObjectSample event creates unexpected amount of > checkpoint > data > - the original patch had to be accommodated to the JDK 11 status of JFR to > minimize the number of prerequisite backports and therefore it is slightly > more complex (patch diff - > http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/patch.diff) > - JIRA . : https://bugs.openjdk.java.net/browse/JDK-8225797 > - Webrev : http://cr.openjdk.java.net/~jbachorik/8225797/webrev.00/ > > > Thanks! > > -JB- From christoph.langer at sap.com Mon Dec 30 10:06:52 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 30 Dec 2019 10:06:52 +0000 Subject: [11u] RFR: 8217634: RunTest documentation and usability update In-Reply-To: References: Message-ID: Hi Goetz, I skimmed over your change and the rejects and it looks correct to me. I also agree about not backporting the parts about JCOV since it's not in available in 11. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 24. Dezember 2019 10:43 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 8217634: RunTest documentation and > usability update > > Hi, > > I had to do a lot of resolves for this one. It passed > Our build and testing. > > This change has a lot of syntactic corrections, like > adding line breaks. Many of these are in code not in 11. > I skipped them. > > The change adds documentation for JCOV. This is not > supported by 11 (and I can't see "8215729: Enhance makefiles > to allow collecting code coverage with JCov" > https://bugs.openjdk.java.net/browse/JDK-8215729 was downported), > so I removed the sections. > > patching file doc/testing.html > > I added the documentation text for AOT Modules. > Skipped renaming id vm_options-1 to vm_options-2 because > it does not exist in this file. > > patching file doc/testing.md > Two hunks failed. The first corrects a > sentence that is not in 11, skipped. > The second adds text about AOT, added. > > patching file make/RunTests.gmk > > AOT_MODULES is moved from the SINGLE_KEYWPORDS list > to the STRING_KEYWORDS list. This didin't apply due > to different context, resolved. > > Skipped adding a line break because code does not > exist in 11. > > Change in comment for ParseMicroTestSelection skipped, > not in 11. > > Change in comment for ParseSpecialTestSelection > skipped, not in 11. > > Syntactic Change to $1_MICRO_BASIC_OPTIONS skipped, not in 11. > Syntactic Change to $1_MICRO_VM_OPTION skipped, not in 11. > > http://cr.openjdk.java.net/~goetz/wr19/8217634-RunTest_doc-jdk11/01/ > https://bugs.openjdk.java.net/browse/JDK-8217634 > http://hg.openjdk.java.net/jdk/jdk/rev/650527b39f00 > > Best regards, > Goetz. From christoph.langer at sap.com Mon Dec 30 10:13:51 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 30 Dec 2019 10:13:51 +0000 Subject: [11u] RFR: 8223638: Replace wildcard address with loopback or local host in tests - part 6 In-Reply-To: References: Message-ID: Hi Goetz, I think you have to do some additional work. When running the test we now see this: test/jdk/java/net/URL/PerConnectionProxy.java:54: error: no suitable constructor found for TestHttpServer(PerConnectionProxy,int,int,InetAddress,int) server = new TestHttpServer(new PerConnectionProxy(), 1, 10, loopbackAddress, 0); ^ constructor TestHttpServer.TestHttpServer(HttpCallback) is not applicable (actual and formal argument lists differ in length) constructor TestHttpServer.TestHttpServer(HttpCallback,int,int) is not applicable (actual and formal argument lists differ in length) constructor TestHttpServer.TestHttpServer(HttpCallback,int,int,int) is not applicable (actual and formal argument lists differ in length) 1 error result: Failed. Compilation failed: Compilation failed Also, after applying JDK-8225430 which goes clean, there will be another error: test/jdk/java/net/URLClassLoader/closetest/CloseTest.java:165: error: cannot find symbol new InetSocketAddress(InetAddress.getLoopbackAddress(), 0), ^ symbol: variable InetAddress location: class CloseTest Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 27. Dezember 2019 11:13 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 8223638: Replace wildcard address with > loopback or local host in tests - part 6 > > Hi, > > I would like to downport this because a later 11.0.7-oracle change > Applies clean with this. > I had to do a simple resolve due to context in UnreferencedSockets.java > > http://cr.openjdk.java.net/~goetz/wr19/8223638-replace_wildcard_6- > jdk11/01/ > https://bugs.openjdk.java.net/browse/JDK-8223638 > http://hg.openjdk.java.net/jdk/jdk/rev/43439afaab4a > > Best regards, > Goetz. From goetz.lindenmaier at sap.com Mon Dec 30 10:23:22 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Dec 2019 10:23:22 +0000 Subject: [11u] RFR: 8210632: Add key exchange algorithm to javax/net/ssl/TLSCommon/CipherSuite.java In-Reply-To: References: Message-ID: Hi Christoph, thanks for reviewing! Best regards Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Sonntag, 29. Dezember 2019 18:38 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8210632: Add key exchange algorithm to > javax/net/ssl/TLSCommon/CipherSuite.java > > Hi Goetz, > > Looks good. > > I compared test/jdk/javax/net/ssl/TLSCommon/CipherSuite.java after your > patch with the version of jdk13u and - as expected - it's only > TLS_CHACHA20_POLY1305_SHA256 that's missing. > > Cheers > Christoph > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Dienstag, 24. Dezember 2019 10:06 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR: 8210632: Add key exchange algorithm to > > javax/net/ssl/TLSCommon/CipherSuite.java > > > > Hi > > > > had to resolve because the change > > "8140466: ChaCha20 and Poly1305 TLS Cipher Suites" > > added test case TLS_CHACHA20_POLY1305_SHA256() to CipherSuite.java > > which is not in 11. > > > > http://cr.openjdk.java.net/~goetz/wr19/8210632-add_key_exchange- > > jdk11/01/ > > > > https://bugs.openjdk.java.net/browse/JDK-8210632 > > http://hg.openjdk.java.net/jdk/jdk/rev/e3c221bc1711 > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Mon Dec 30 10:24:37 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Dec 2019 10:24:37 +0000 Subject: [11u] RFR: 8217634: RunTest documentation and usability update In-Reply-To: References: Message-ID: Hi Christoph, thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 30. Dezember 2019 11:07 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8217634: RunTest documentation and usability update > > Hi Goetz, > > I skimmed over your change and the rejects and it looks correct to me. I also > agree about not backporting the parts about JCOV since it's not in available in > 11. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Dienstag, 24. Dezember 2019 10:43 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR: 8217634: RunTest documentation and > > usability update > > > > Hi, > > > > I had to do a lot of resolves for this one. It passed > > Our build and testing. > > > > This change has a lot of syntactic corrections, like > > adding line breaks. Many of these are in code not in 11. > > I skipped them. > > > > The change adds documentation for JCOV. This is not > > supported by 11 (and I can't see "8215729: Enhance makefiles > > to allow collecting code coverage with JCov" > > https://bugs.openjdk.java.net/browse/JDK-8215729 was downported), > > so I removed the sections. > > > > patching file doc/testing.html > > > > I added the documentation text for AOT Modules. > > Skipped renaming id vm_options-1 to vm_options-2 because > > it does not exist in this file. > > > > patching file doc/testing.md > > Two hunks failed. The first corrects a > > sentence that is not in 11, skipped. > > The second adds text about AOT, added. > > > > patching file make/RunTests.gmk > > > > AOT_MODULES is moved from the SINGLE_KEYWPORDS list > > to the STRING_KEYWORDS list. This didin't apply due > > to different context, resolved. > > > > Skipped adding a line break because code does not > > exist in 11. > > > > Change in comment for ParseMicroTestSelection skipped, > > not in 11. > > > > Change in comment for ParseSpecialTestSelection > > skipped, not in 11. > > > > Syntactic Change to $1_MICRO_BASIC_OPTIONS skipped, not in 11. > > Syntactic Change to $1_MICRO_VM_OPTION skipped, not in 11. > > > > http://cr.openjdk.java.net/~goetz/wr19/8217634-RunTest_doc-jdk11/01/ > > https://bugs.openjdk.java.net/browse/JDK-8217634 > > http://hg.openjdk.java.net/jdk/jdk/rev/650527b39f00 > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Mon Dec 30 10:27:11 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Dec 2019 10:27:11 +0000 Subject: [11u] RFR: 8225766: Curve in certificate should not affect signature scheme when using TLSv1.3 In-Reply-To: References: Message-ID: Hi Martin, thanks for reviewing. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Freitag, 27. Dezember 2019 15:38 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8225766: Curve in certificate should not affect > signature scheme when using TLSv1.3 > > Ok. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Freitag, 27. Dezember 2019 10:08 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8225766: Curve in certificate should not affect > > signature scheme when using TLSv1.3 > > > > Hi, > > > > I would like to downport this for parity with 11.0.7-oracle. > > I had to resolve the added import in SignatureScheme.java ... trivial ... > > > > http://cr.openjdk.java.net/~goetz/wr19/8225766-Curve_affects-jdk11/01/ > > https://bugs.openjdk.java.net/browse/JDK-8225766 > > http://hg.openjdk.java.net/jdk/jdk13/rev/1170b6d92d1c > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Mon Dec 30 10:29:11 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Dec 2019 10:29:11 +0000 Subject: [11u] RFR: 8228479: Correct the format of ColorChooserDemoTest In-Reply-To: References: Message-ID: Hi Martin, thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Freitag, 27. Dezember 2019 15:37 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8228479: Correct the format of ColorChooserDemoTest > > Ok. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Freitag, 27. Dezember 2019 10:31 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8228479: Correct the format of > > ColorChooserDemoTest > > > > Hi > > > > I would like to downport this for parity with 11.0.7-oracle. > > It only corrects indentation. > > It did not apply because 11 has a newline at the end of the file > > 14 did not have. Trivial. > > > > http://cr.openjdk.java.net/~goetz/wr19/8228479- > > ColorChooserDemo_format-jdk11/01/ > > https://bugs.openjdk.java.net/browse/JDK-8228479 > > https://hg.openjdk.java.net/jdk/jdk/rev/8538b1f28a71 > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Mon Dec 30 10:30:29 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Dec 2019 10:30:29 +0000 Subject: [11u] RFR: 8223464: Improve version string for Oracle CI builds In-Reply-To: References: Message-ID: Hi Martin, thanks for reviewing! Best regards, Goetz > -----Original Message----- > From: Doerr, Martin > Sent: Freitag, 27. Dezember 2019 15:43 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8223464: Improve version string for Oracle CI builds > > Ok. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Dienstag, 24. Dezember 2019 12:21 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8223464: Improve version string for Oracle CI > > builds > > > > Hi > > > > I would like to downport this for parity with 11.0.7-oracle. > > It does not apply due to changes in context. > > > > http://cr.openjdk.java.net/~goetz/wr19/8223464-OracleCI_version_string- > > jdk11/01/ > > https://bugs.openjdk.java.net/browse/JDK-8223464 > > > > http://hg.openjdk.java.net/jdk/jdk/rev/5600f5c38b0b > > > > Best regards, > > Goetz. From christoph.langer at sap.com Mon Dec 30 10:42:43 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 30 Dec 2019 10:42:43 +0000 Subject: [11u] RFR: 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: <69105c6f-0a18-172f-6d05-e3d71887a308@gmail.com> References: <69105c6f-0a18-172f-6d05-e3d71887a308@gmail.com> Message-ID: Hi Jaikiran, I guess it's holiday season so you ran into a little delay. Your request involves two bugfixes, one is JDK-8232170 and the other is JDK-8218268. They should be backported separately. From looking at their description, I guess they are viable candidates for a backport. They alter the behavior of javac a bit - but I'd assume only in the sense of fixing bugs ??. Since both patches apply cleanly, I have added them to our build&test system. We should have results on whether there are regressions by tomorrow. Can you please add a fix request comment&label to JDK-8232170 as well? In case everything goes fine I'll approve and sponsor for you. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Jaikiran Pai > Sent: Freitag, 20. Dezember 2019 17:16 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8218268: Javac treats Manifest Class-Path entries as Paths > instead of URLs > > Can I please get a review and a sponsor for the 11u backport of > https://bugs.openjdk.java.net/browse/JDK-8218268? > > For the patch to apply cleanly, I had to first apply the patch for > https://bugs.openjdk.java.net/browse/JDK-8232170 (which deals with a > related issue). > > The webrev containing both these patches resides at > http://cr.openjdk.java.net/~jpai/webrev/8218268-11u-backport/webrev/ > > -Jaikiran > From christoph.langer at sap.com Mon Dec 30 13:19:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 30 Dec 2019 13:19:57 +0000 Subject: [11u] Plan to backport 8184193(JFR Streaming) to jdk11u In-Reply-To: <36577ea6-fb74-40f3-ac41-4c226932274b.denghui.ddh@alibaba-inc.com> References: <36577ea6-fb74-40f3-ac41-4c226932274b.denghui.ddh@alibaba-inc.com> Message-ID: Hi Denghui, just going through the backlog of jdk-updates mails... I think we should sync on the items that we want to backport to jdk11u in the JFR space at the upcoming OpenJDK committers workshop. As for the prerequisite bugfixes: I agree to the comments of others that it probably is a good idea to backport them separately as probably each of them addresses some issue on its own and the backports will pave the road. So, please feel free to request those backports. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Denghui Dong > Sent: Freitag, 22. November 2019 11:09 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] Plan to backport 8184193(JFR Streaming) to jdk11u > > Hi team, > Currently, the status of JET 349: JFR streaming is integrated. > This feature is useful for continuous monitoring, can provide the > monitoring system with more detailed information. > jdk-11u is a LTS version, and I think 11u will become the mainstream > version in the next few years, so I plan to backport JFR streaming to 11u. > > The backport for 8184193 requires several other changes as follows to be > backported as > well: > - 8225797: OldObjectSample event creates unexpected amount of > checkpoint data > RFR for 8225797 has been created by > Jaroslav.(https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > November/002115.html) > so my webrev is based on it. > > - 8231081: TestMetadataRetention fails due to missing symbol id > Need to do some manual adjustments, because 8209301 (JVM rename > is_anonymous, host_klass to unsafe specific terminology ahead of > Unsafe.defineAnonymousClass deprecation) has not been ported to 11u, > and I think it's not necessary. > > - 8230400: Missing constant pool entry for a method in stacktrace > Need to do some manual adjustments, because of some different code > structures, such as the different name of JfrStump in jfrTypeSetUtils.hpp > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226511 > Webrev: http://cr.openjdk.java.net/~ddong/8226511/webrev.00/ > > What's your comment? > > Thanks > Denghui Dong From christoph.langer at sap.com Mon Dec 30 13:36:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 30 Dec 2019 13:36:27 +0000 Subject: RFD: JDK-8221477, JDK-8221397, JDK-8221696, JDK-8224974 In-Reply-To: <3773d39f-ed7b-e416-c4a0-808babd0b305@redhat.com> References: <94AB154C-271B-45AC-BB8A-781308CE85F3@azul.com> <264bb587-5f12-353c-6367-f85ca9752cab@redhat.com> <3773d39f-ed7b-e416-c4a0-808babd0b305@redhat.com> Message-ID: Hi Andrew, when you're going to backport these items (in a way that is suitable for backporting, e.g. no spec breaking changes, obviously), I would suggest that you tackle each bug one by one. E.g. you can immediately start with JDK-8221477 which to me looks like it could be backported straight away without involving a CSR process. The other 3 items should undergo a CSR review one by one and some adoptions will have to be taken to make sure they don't break the spec, e.g. add new public API methods as private methods... Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Dinn > Sent: Donnerstag, 21. November 2019 13:05 > To: Andrew Haley ; Gil Tene > Cc: Jonathan Halliday ; jdk-updates- > dev at openjdk.java.net > Subject: Re: RFD: JDK-8221477, JDK-8221397, JDK-8221696, JDK-8224974 > > On 21/11/2019 08:25, Andrew Haley wrote: > > On 11/19/19 3:51 PM, Gil Tene wrote: > >> As a rule, any in-version changes to the public Java SE APIs, including > >> the addition of new methods, are a ?don?t do this? sort of thing. In the > >> extremely rare cases where they are necessary (e.g. security driven) > >> a rev to the spec (and often to the TCKs) is required. > > > > I don't think we need to do that. As I understand it, we can make the > changes > > to jdk.internal.misc.Unsafe without breaching anything. We can use these > > Unsafe methods in an external library, and we can do the mapping itself > > in a library too. > Yes, I have had a talk with Jonathan Halliday about this and I believe > we can ensure that the functionality can be made available via a 3rd > party library without changing JDSK11 SE at all i.e. without the > addition of any new modules or packages and without modifying any of the > public API surface of the JDK11 class base. We can follwo Gil's lead and > do this via a library that will work on jdk11u and continue to work on > jdk14+. > > I will prepare a new patch that includes much the same changes to the > underlying implementation. However, it will make be tweaked to make the > new FileChannel map and MappedByteBuffer force behaviours available via > private methods only (these methods will also be exposed in private > method handle fields). This mode of proceeding will mean we can omit the > need for any changes to the public FileChannel MapMode enum. > > Access to this new, fully private functionality will then be provided by > a non-SE module library. On jdk11u it will need to use Unsafe to access > the private method handles and employ them to provide a safe public API > for invoking the required map and force behaviours. Making that work > will require the user to explicitly export access to Unsafe to the > library. Obviously on jdk14+ the same library can simply call the > relevant public APIs directly and the need to export access to Unsafe > will disappear. > > Regarding Martin's comments, I will be happy to delay this backport > until the relevant functionality was available in a jdk14 release. I > understand why he would prefer for the current behaviour to have baked a > bit longer in jdk14. > > 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 jai.forums2013 at gmail.com Mon Dec 30 14:19:12 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 30 Dec 2019 19:49:12 +0530 Subject: [11u] RFR: 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs In-Reply-To: References: <69105c6f-0a18-172f-6d05-e3d71887a308@gmail.com> Message-ID: <8a24c155-9dbf-ae9e-e829-cd116de00b30@gmail.com> Hello Christoph, On 30/12/19 4:12 PM, Langer, Christoph wrote: > Hi Jaikiran, > > I guess it's holiday season so you ran into a little delay. > > Your request involves two bugfixes, one is JDK-8232170 and the other is JDK-8218268. They should be backported separately. From looking at their description, I guess they are viable candidates for a backport. They alter the behavior of javac a bit - but I'd assume only in the sense of fixing bugs ??. > > Since both patches apply cleanly, I have added them to our build&test system. We should have results on whether there are regressions by tomorrow. Thank you very much for doing that. > > Can you please add a fix request comment&label to JDK-8232170 as well? In case everything goes fine I'll approve and sponsor for you. I've now updated that JBS issue to include a backport RFR comment as well as added the jdk11u-fix-request label. Thanks again for sponsoring this :) -Jaikiran From volker.simonis at gmail.com Mon Dec 30 20:18:24 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 30 Dec 2019 21:18:24 +0100 Subject: [11u] RFR: 8210459, 8218807, 8223678: Support for creating Visual Studio Code projects Message-ID: Hi, I'd like to downport the support for Visual Studio Code project creation to 11u. I think we will have to support 11u for quite some years and it makes sense to have as good as possible tool support in 11u as well. This mail is especially intended to get a review from the build team that the few changes to the patches are OK: https://bugs.openjdk.java.net/browse/JDK-8210459 http://cr.openjdk.java.net/~simonis/webrevs/2019/8210459/ https://bugs.openjdk.java.net/browse/JDK-8218807 http://cr.openjdk.java.net/~simonis/webrevs/2019/8218807/ https://bugs.openjdk.java.net/browse/JDK-8223678 http://cr.openjdk.java.net/~simonis/webrevs/2019/8223678/ The downport consists of three changes which are additive (i.e. later changes depend on earlier ones). That's why I decided to post just one RFR, because looking at a single change makes no sense without the corresponding context. The changes mostly apply cleanly except for very few places where we need manual adjustments because of changed context. These changes only touch make files and actually only add new features to the make system, so the normal build results shouldn't be affected. I've tested that the build still works on Linux and Windows and "make test-make" succeeds. Following some details on the three changes: 8210459: Add support for generating compile_commands.json The initial change which creates the compile_commands.json file (i.e. "make compile_commands"). This file can be used for many tools (e.g. CLion IDE, clangd, etc..) Applies cleanly except for the following hunk, which has a different context: ORIGINAL ======== CFLAGS_solaris := -KPIC, \ CFLAGS_macosx := -fPIC, \ DISABLED_WARNINGS_clang := format-nonliteral, \ - LDFLAGS := $(UNPACKEXE_ZIPOBJS) \ - $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \ + LDFLAGS := $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \ JDK11u ====== CFLAGS_linux := -fPIC, \ CFLAGS_solaris := -KPIC, \ CFLAGS_macosx := -fPIC, \ - LDFLAGS := $(UNPACKEXE_ZIPOBJS) \ - $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \ + LDFLAGS := $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \ 8218807: Compilation database (compile_commands.json) may contain obsolete items This is a simple fix for 8210459 and applies cleanly 8223678: Add Visual Studio Code workspace generation support (for native code) This change actually creates the VS Code project files (i.e. "make vscode-project-ccls"). See http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/ide.html for more details. Applies cleanly except the following two hunks. The first one had to be moved back from "make/common/Utils.gmk" to "make/common/MakeBase.gmk" where it still applies cleanly, because the "RelativePath" macro is still in "MakeBase.gmk" in jdk11u. ORIGINAL ======== diff -r a82a367b2d8c -r 2ae056696b15 make/common/Utils.gmk --- a/make/common/Utils.gmk Mon Jun 03 17:14:23 2019 -0700 +++ b/make/common/Utils.gmk Mon Jun 03 10:28:03 2019 +0200 @@ -122,7 +122,8 @@ # $2 - Directory to compute the relative path from RelativePath = \ $(eval $1_prefix := $(call FindCommonPathPrefix, $1, $2)) \ - $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip $1)_prefix)/%, %, $2))) \ + $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip $1)_prefix)%, %, $2))) \ + $(eval $1_dotdots := $(if $($(strip $1)_dotdots),$($(strip $1)_dotdots),.)) \ $(eval $1_suffix := $(patsubst $($(strip $1)_prefix)/%, %, $1)) \ $($(strip $1)_dotdots)/$($(strip $1)_suffix) JDK11u ====== diff -r 8599975f5b33 make/common/MakeBase.gmk --- a/make/common/MakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 +++ b/make/common/MakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 @@ -611,7 +611,8 @@ # $2 - Directory to compute the relative path from RelativePath = \ $(eval $1_prefix := $(call FindCommonPathPrefix, $1, $2)) \ - $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip $1)_prefix)/%, %, $2))) \ + $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip $1)_prefix)%, %, $2))) \ + $(eval $1_dotdots := $(if $($(strip $1)_dotdots),$($(strip $1)_dotdots),.)) \ $(eval $1_suffix := $(patsubst $($(strip $1)_prefix)/%, %, $1)) \ $($(strip $1)_dotdots)/$($(strip $1)_suffix) For the second changed hunk, the simple call of the "AssertEquals" macro had to be renamed to "assert-equals" and wrapped with "eval" because the corresponding macros haven't been updated in jdk11u yet. Notice that these are only test changes (for testing the make system iteslf) and don't effect the build at all. ORIGINAL ======== diff -r a82a367b2d8c -r 2ae056696b15 test/make/TestMakeBase.gmk --- a/test/make/TestMakeBase.gmk Mon Jun 03 17:14:23 2019 -0700 +++ b/test/make/TestMakeBase.gmk Mon Jun 03 10:28:03 2019 +0200 @@ -361,6 +361,18 @@ RelativePath, \ ) +$(call AssertEquals, \ + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz), \ + ./banan/kung, \ + RelativePath, \ +) + +$(call AssertEquals, \ + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz/), \ + ./banan/kung, \ + RelativePath, \ +) JDK11u ====== diff -r 8599975f5b33 test/make/TestMakeBase.gmk --- a/test/make/TestMakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 +++ b/test/make/TestMakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 @@ -325,13 +325,25 @@ RelativePath, \ )) +$(eval $(call assert-equals, \ + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz), \ + ./banan/kung, \ + RelativePath, \ +)) + +$(eval $(call assert-equals, \ + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz/), \ + ./banan/kung, \ + RelativePath, \ +)) Finally, I've added an additional fix to this last change, whch fixes the make tests (i.e. "make test-make"). These tests are currently broken in jdk11u. They have been broken by JDK-8212028 (which has already been downported to jdk11u) and fixed in jdk 12 as part of "8210958: Rename "make run-test" to "make test"" (which hasn't been downported yet and probably won't be donwported at all). Because the fix is trivial (that's why it was done as part of 8210958 without an extra bug ID) and because I wanted to run "make test-make" in jdk11u as well to verify my changes, I've decided to downport this fix as part of 8223678: diff -r 8599975f5b33 test/make/TestMakeBase.gmk --- a/test/make/TestMakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 +++ b/test/make/TestMakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 KWBASE := APA=banan;GURKA=tomat;COUNT=1%202%203%204%205;SUM=1+2+3+4+5;MANY_WORDS=I have the best words. $(eval $(call ParseKeywordVariable, KWBASE, \ - KEYWORDS := APA GURKA SUM, \ + SINGLE_KEYWORDS := APA GURKA SUM, \ STRING_KEYWORDS := COUNT MANY_WORDS, \ )) @@ -364,7 +376,7 @@ KWBASE_WEIRD := ;;APA=banan;;;GURKA=apelsin;APA=skansen;; $(eval $(call ParseKeywordVariable, KWBASE_WEIRD, \ - KEYWORDS := APA GURKA SUM, \ + SINGLE_KEYWORDS := APA GURKA SUM, \ STRING_KEYWORDS := COUNT, \ )) From denghui.ddh at alibaba-inc.com Tue Dec 31 02:24:57 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 31 Dec 2019 10:24:57 +0800 Subject: =?UTF-8?B?UmU6IFsxMXVdIFBsYW4gdG8gYmFja3BvcnQgODE4NDE5MyhKRlIgU3RyZWFtaW5nKSB0byBq?= =?UTF-8?B?ZGsxMXU=?= In-Reply-To: References: <36577ea6-fb74-40f3-ac41-4c226932274b.denghui.ddh@alibaba-inc.com>, Message-ID: <88a83c07-7acf-4352-9534-b2984ececc90.denghui.ddh@alibaba-inc.com> Hi Christoph Thanks for the reply. I planned to request reviews for JDK-8231081 and JDK-8230400 after JDK-8225797 (OldObjectSample event creates unexpected amount of checkpoint data) is approved. And it seems that JDK-8225797 will be approved soon, so I will do it this week. ?? Cheers, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph Send Time:2019?12?30?(???) 21:20 To:???(??) ; jdk-updates-dev at openjdk.java.net Subject:RE: [11u] Plan to backport 8184193(JFR Streaming) to jdk11u Hi Denghui, just going through the backlog of jdk-updates mails... I think we should sync on the items that we want to backport to jdk11u in the JFR space at the upcoming OpenJDK committers workshop. As for the prerequisite bugfixes: I agree to the comments of others that it probably is a good idea to backport them separately as probably each of them addresses some issue on its own and the backports will pave the road. So, please feel free to request those backports. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Denghui Dong > Sent: Freitag, 22. November 2019 11:09 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] Plan to backport 8184193(JFR Streaming) to jdk11u > > Hi team, > Currently, the status of JET 349: JFR streaming is integrated. > This feature is useful for continuous monitoring, can provide the > monitoring system with more detailed information. > jdk-11u is a LTS version, and I think 11u will become the mainstream > version in the next few years, so I plan to backport JFR streaming to 11u. > > The backport for 8184193 requires several other changes as follows to be > backported as > well: > - 8225797: OldObjectSample event creates unexpected amount of > checkpoint data > RFR for 8225797 has been created by > Jaroslav.(https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > November/002115.html) > so my webrev is based on it. > > - 8231081: TestMetadataRetention fails due to missing symbol id > Need to do some manual adjustments, because 8209301 (JVM rename > is_anonymous, host_klass to unsafe specific terminology ahead of > Unsafe.defineAnonymousClass deprecation) has not been ported to 11u, > and I think it's not necessary. > > - 8230400: Missing constant pool entry for a method in stacktrace > Need to do some manual adjustments, because of some different code > structures, such as the different name of JfrStump in jfrTypeSetUtils.hpp > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226511 > Webrev: http://cr.openjdk.java.net/~ddong/8226511/webrev.00/ > > What's your comment? > > Thanks > Denghui Dong From gil at azul.com Thu Dec 19 17:35:57 2019 From: gil at azul.com (Gil Tene) Date: Thu, 19 Dec 2019 17:35:57 -0000 Subject: Open JDK 8 Road Map In-Reply-To: References: Message-ID: Sent from my iPad On Dec 19, 2019, at 6:07 AM, Langer, Christoph wrote: ?Hi Joshi, the right list for this question is rather jdk8u-dev at o.j.n, so I'm sending my response there and put jdk-updates-dev on bcc. Since RedHat is the maintainer of OpenJDK8 and OpenJDK11, I guess you can bear with their statements about support. You can find this article: https://access.redhat.com/articles/1299013 So I assume, as long as RedHat supports OpenJDK 8, you can be quite sure that there will be periodic security updates. This needs some correction IMO. Saying that ?RedHat is the maintainer of OpenJDK8 and OpenJDK11? would be a mis-statement of the situation. OpenJDK 8 and 11 are maintained through a community effort. There is no official or specific Red Hat position, stewardship, or control of these projects. AFAIK Andrew Haley, a Red Hat employee and a significant OpenJDK contributor with a long history of OSS leadership is the project lead for OpenJDK 8u and and the lead maintainer for 11u. A multitude of engineers from various companies (including significant work by teams at Red Hat, Azul, Amazon, SAP, and several others) as well as individuals, regularly contribute to and coordinate on update work on the upstream OpenJDK 8 and 11 source code projects, with multiple downstream binary distributions being built and offered at various places. Binary distributions of OpenJDK typically make curation choices on contents and packaging, perform extensive platform testing and verification, and may include various modifications not included in the upstream OpenJDK 8u and 11u source code. Red Hat?s distribution of a OpenJDK is one of those distributions. It differs in some specific ways from the upstream source code in (described in e.g. https://access.redhat.com/solutions/2489791 ) and, like other binary distributions, the source code for it is separately available elsewhere (not as part of the OpenJDK project). Per the link mentioned ( https://access.redhat.com/articles/1299013 ) the Red Hat distribution is commercially supported specifically on RHEL and on Windows, with updates available for certain timelines under support entitlements. The binaries for such updates may also be available for download without a support contract, but that is probably detailed elsewhere. Other distributions are available under commercial support, as well as for Free download, with varying statements about the length of time they are expected to continue to do so. E.g. the timeline for Zulu Community support can be found at https://www.azul.com/products/zulu-community/ , and includes support for a wide range of JDK versions, Linux variants, CPU types, and packaging mechanisms. Corretto, Liberia, Dragonwell, and Adopt are other OpenJDK distributions that come to mind (and there are several others as well). It is likely fair to assume that as long as at least one binary distribution exists that employs engineers to regularly maintain and update the distribution, the sources for such updates will be freely available, and that most of the changes will likely end up upstream in the OpenJDK 8u and 11u source code projects. We all seem to happily work together to coordinate work on an agreed upon upstream version when it comes to the bulk of bug fixes, backports, and security fixes, with downstream differences being mostly a matter of curation choices. But there is no one company who owns or controls the maintenance of OpenJDK 8u or 11u source code projects, and the limits on time that one company or organization?s statements suggest about their plans to continue providing downstream distributions and updates should not be interpreted as statements about project?s plans or commitments, or about what other downstream distributions may or may not end up doing. Specifically, the link specific provided would suggest Red Hat?s commitment to 8u lasts to June 2023, while the Zulu Community link shows March 2026 for 8u. And I?m sure there are several other dates one can dig up. This is all ?a good thing (TM)?. It?s a lively and active community. HTH Christoph -----Original Message----- From: jdk-updates-dev On Behalf Of Dheeraj Joshi Sent: Dienstag, 20. August 2019 07:14 To: jdk-updates-dev at openjdk.java.net Subject: Open JDK 8 Road Map How long Open JDK 8 is supported by https://openjdk.java.net/ We are currently analyzing impact of upgrading from Java 8 to Java 11. We need to know for how long JDK 8 will get periodic security upgrades and general patches for JDK 8 from https://openjdk.java.net/? Is there a Road map available for public viewing? Kind Regards Dheeraj Joshi