From goetz.lindenmaier at sap.com Thu Oct 1 06:17:45 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Oct 2020 06:17:45 +0000 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS Message-ID: Hi, I am downporting this change for 11.0.10-oracle parity. It required quite some work. http://cr.openjdk.java.net/~goetz/wr20/8171279-X25519_in_TLS-jdk11/01/ file src/java.base/share/classes/sun/security/ssl/CipherSuite.java Non-applying chunk fixes typo in a comment that is not in 11. I copied the comment to 11. file src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java Deleting class DHEKAKeyDerivation failed because the code in 11 uses JsseJce.getKeyAgreement() where the patch uses KeyAgreement.getInstance(). file src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchange.java 11 has different imports. The remaining conflicts arise from different usages of KeyFactory, ECUtil and JsseJce. file src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java The conflicts arise from different usages of KeyAgreement and JsseJce. file src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java Different imports. The remaining conflicts arise from different usages of KeyFactory, ECUtil and JsseJce. file src/java.base/share/classes/sun/security/ssl/SSLExtension.java Copyright file src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java Copyright file src/java.base/share/classes/sun/security/ssl/SignatureScheme.java imports file src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.java Different imports. Enums are moved to a file of their own: NamedGroup.java Removing the enums does not apply because in 13 FIPS support was removed. Also, a name string was added. The supported group types differ, too. In 11, the enums have a row of additional functionality that I now removed, too. E.g., additional constructors, isSupported(), isECAvailable. Some further differences are again usages of ECUtil, JsseJce etc. The original patch has more NamedGroups: "// Secondary NIST curves" file test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java configureClientSocket() already in 11. We downported this with a previous change. The NamedGroups enum is moved to a file of it's own. Before this change, the named Groups knew about FIPS in 11. The new ones don't. https://bugs.openjdk.java.net/browse/JDK-8217835 "Remove the experimental SunJSSE FIPS compliant mode" removed FIPS support in 13 before this change was implemented. As I understand 8217835, the experimental FIPS feature cannot be used in 11, it just remained in the code. So I skipped adapting NamedGroups to the old behaviour, I can not test it anyways. What do you think, do we need to add this code to NamedGroupd.java again? There are two follow ups, 8224650: Add tests to support X25519 and X448 in TLS 8243549: sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java failed with Unsupported signature algorithm: DSA I have downported these too, and will send RFR once this is stable. Existing and new test are all passing. https://bugs.openjdk.java.net/browse/JDK-8171279 http://hg.openjdk.java.net/jdk/jdk/rev/946f7f2d321c Best regards, Goetz. From goetz.lindenmaier at sap.com Thu Oct 1 11:29:26 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Oct 2020 11:29:26 +0000 Subject: [11u] RFR 8239477: jdk/jfr/jcmd/TestJcmdStartStopDefault.java fails -XX:+VerifyOops with "verify_oop: rsi: broken oop" In-Reply-To: <07a07c67-cad3-4c14-cf79-abcc3114f4d0@redhat.com> References: <07a07c67-cad3-4c14-cf79-abcc3114f4d0@redhat.com> Message-ID: Hi Aleksey, This looks good to me. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Aleksey Shipilev > Sent: Monday, September 7, 2020 10:06 AM > To: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR 8239477: jdk/jfr/jcmd/TestJcmdStartStopDefault.java > fails -XX:+VerifyOops with "verify_oop: rsi: broken oop" > > This seems to have fallen through the cracks: > > On 7/31/20 12:53 PM, Aleksey Shipilev wrote: > > Original fix: > > https://bugs.openjdk.java.net/browse/JDK-8239477 > > https://hg.openjdk.java.net/jdk/jdk/rev/1dfb43020070 > > > > CIs that run testing -XX:+VerifyOops with 11u fail without this. > > > > 11u fix is a bit different, because the context is a bit different around this > line: > > __ branch(lir_cond_equal, T_OBJECT, L_end->label()); > > > > 11u webrev: > > http://cr.openjdk.java.net/~shade/8239477/webrev.11u.01/ > > > > Testing: affected test (used to fail, now it passes); tier{1,2}; jdk_jfr > > -- > Thanks, > -Aleksey From goetz.lindenmaier at sap.com Thu Oct 1 11:45:24 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Oct 2020 11:45:24 +0000 Subject: [11u] RFR: 8208677: Move inner metaspace cleaning out of class unloading In-Reply-To: <3f386b3bfefe471f8a7bbd73e6bb9427@azul.com> References: <3f386b3bfefe471f8a7bbd73e6bb9427@azul.com> Message-ID: Hi Ekaterina, I understand you want to downport 5 changes to fix https://bugs.openjdk.java.net/browse/JDK-8251945, starting with this one. 8251945 is fixed in 11.0.10-oracle. But Oracle did not mark these five changes as downported, as they usually would do. So I assume they applied a tailored fix to 11 we unfortunately can not see, but they did not downport these 5 changes. This particular change here seem quite risky to me. It changes the behavior of the VM by scheduling tasks differently and changing safe points. Isn't it possible to fix the issue more defensively? Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Ekaterina Vergizova > Sent: Wednesday, September 23, 2020 11:10 PM > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8208677: Move inner metaspace cleaning out of class > unloading > > Hello, > I would like to backport 8208677 to 11u as a prerequisite for 8210422. > 8210422 fixes the crash described in 8251945 that is already fixed in 11.0.10- > oracle. > The full list of suggested prerequisites is specified in [1]. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8208677 > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/aa3bfacc912c > Webrev for 11u: > https://cr.openjdk.java.net/~apetushkov/8208677/webrev.00/ > > The patch applies almost cleanly except for the change in > src/hotspot/share/code/nmethod.cpp. > It is already included in 11u by 8220718. > > Tested with tier1; the full list of backports specified in [1] is tested with full > regression. > > Thanks, > Ekaterina > > [1] https://bugs.openjdk.java.net/browse/JDK- > 8251945?focusedCommentId=14363860&page=com.atlassian.jira.plugin.sys > tem.issuetabpanels%3Acomment-tabpanel#comment-14363860 From suenaga at oss.nttdata.com Fri Oct 2 06:45:39 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 2 Oct 2020 15:45:39 +0900 Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: <97fdf61a-06d4-1fdd-d028-561cea7f965e@oss.nttdata.com> References: <4a75d2b8-7980-a90b-8142-333c402ea0da@gmail.com> <6a36d15f-07f3-a895-ed1a-06e872396d80@oss.nttdata.com> <56fd7f5f-a610-5699-a5aa-c119756d2023@oss.nttdata.com> <97fdf61a-06d4-1fdd-d028-561cea7f965e@oss.nttdata.com> Message-ID: <1b27c9ea-6a12-a00b-c0fd-eee146415f21@oss.nttdata.com> PING: could you approve it? >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 >>>>> Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924 >>>>> webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/jdk11u/webrev.00/ We can still apply the webrev for head of 11u-dev, and I haven't heared any problem about this change on upstream. Thanks, Yasumasa On 2020/09/11 9:25, Yasumasa Suenaga wrote: > Hi all, > > I think this change for 11u is ready to review. > I haven't heard any problems on jdk/jdk. > > Could you review it? > >>>>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 >>>>> ????? Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924 >>>>> ????? webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/jdk11u/webrev.00/ > > > Thanks, > > Yasumasa > > > On 2020/08/31 20:02, Yasumasa Suenaga wrote: >> Hi Christoph, >> >> JDK 11 is LTS version, so we might see hs_err logs which relates to this fix in production system. It is the reason why I want to backport it to 11.0.9 if possible. >> >> OTOH it is not so critical and JDK 11 will enter rampdown, I understand that we have to be careful. >> I will comply the timing when "jdk11u-fix-yes" is added to JBS. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/08/31 19:04, Langer, Christoph wrote: >>> Hi Yasumasa, >>> >>> is there any specific reason why it should be part of 11.0.9? >>> >>> Without having more detailed knowledge of the matter, I'd say it's cautious enough to postpone this backport to 11.0.10, given that we're about to enter rampdown... >>> >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: jdk-updates-dev On >>>> Behalf Of Yasumasa Suenaga >>>> Sent: Freitag, 28. August 2020 10:02 >>>> To: Baesken, Matthias ; Yasumasa Suenaga >>>> ; jdk-updates-dev at openjdk.java.net >>>> Subject: Re: [11u] RFR: 8250598: Hyper-V is detected in spite of running on >>>> host OS >>>> >>>> Hi Matthias, >>>> >>>> On 2020/08/28 16:22, Baesken, Matthias wrote: >>>>> Hi Yasumasa ,I suggest to let the? change? "rest"? in? jdk/jdk for? a couple of >>>> weeks? before? going for downports . >>>>> (not saying that downporting it is a bad thing) >>>> >>>> I understand what you say, but I want to backport it to 11.0.9 if possible. >>>> 11.0.9 will enter rampdown in 1 Sep... >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>>> Best regards, Matthias >>>>> >>>>> -----Original Message----- >>>>> From: Yasumasa Suenaga >>>>> Sent: Freitag, 28. August 2020 02:55 >>>>> To: jdk-updates-dev at openjdk.java.net >>>>> Cc: Baesken, Matthias >>>>> Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on host >>>> OS >>>>> >>>>> Hi all, >>>>> >>>>> Please approve backport of JDK-8250598: >>>>> >>>>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 >>>>> ????? Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924 >>>>> ????? webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK- >>>> 8250598/jdk11u/webrev.00/ >>>>> >>>>> The patch does not apply cleanly on 11u due to additional enhancements to >>>> x86 / x86_64 processors. >>>>> So I've prepared another webrev for 11u. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> From goetz.lindenmaier at sap.com Fri Oct 2 12:58:00 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 2 Oct 2020 12:58:00 +0000 Subject: [11u] RFR: 8250894: Provide a configure option to build and run against the platform libharfbuzz Message-ID: Hi, I am downporting this for parity with 11.0.10-oracle. I had to do a row of simple resolves: http://cr.openjdk.java.net/~goetz/wr20/8250894-configure_harfbuzz-jdk11/01/ file make/autoconf/help.m4 zypper_help() is not in 11. Thus, I omitted the help message for zypper. unable to find 'make/modules/java.desktop/Copy.gmk' for patching Patch had to be applied to make/copy/Copy-java.desktop.gmk unable to find 'make/modules/java.desktop/lib/Awt2dLibraries.gmk' for patching Patch had to be applied to make/lib/Awt2dLibraries.gmk It does not apply because of the solaris port coding that is in 11. But the patch basically indents the harfbuzz build instructions and wraps it in an if, so resolving was trivial. Built with and without libharfbuzz. https://bugs.openjdk.java.net/browse/JDK-8250894 https://hg.openjdk.java.net/jdk/jdk/rev/880cfb985f8e Best regards, Goetz. From hohensee at amazon.com Fri Oct 2 18:58:23 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 2 Oct 2020 18:58:23 +0000 Subject: Nothing posted to jdk-updates-changes for 11u since Sep 30 Message-ID: Has anyone else noticed that nothing has been posted to jdk-updates-changes for 11u since Sep 30? Maybe it?s just me, or maybe just outside Oracle like the hotspot-dev problem awhile ago. Thanks, Paul From martin.doerr at sap.com Sat Oct 3 17:13:51 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Sat, 3 Oct 2020 17:13:51 +0000 Subject: [11u] RFR: 8250894: Provide a configure option to build and run against the platform libharfbuzz In-Reply-To: References: Message-ID: Hi G?tz, thanks for backporting this change. Looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 2. Oktober 2020 14:58 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8250894: Provide a configure option to build > and run against the platform libharfbuzz > > Hi, > > I am downporting this for parity with 11.0.10-oracle. > I had to do a row of simple resolves: > http://cr.openjdk.java.net/~goetz/wr20/8250894-configure_harfbuzz- > jdk11/01/ > > file make/autoconf/help.m4 > zypper_help() is not in 11. > Thus, I omitted the help message for zypper. > > unable to find 'make/modules/java.desktop/Copy.gmk' for patching > Patch had to be applied to make/copy/Copy-java.desktop.gmk > > unable to find 'make/modules/java.desktop/lib/Awt2dLibraries.gmk' for > patching > Patch had to be applied to make/lib/Awt2dLibraries.gmk > It does not apply because of the solaris port coding that is in 11. > But the patch basically indents the harfbuzz build instructions > and wraps it in an if, so resolving was trivial. > > Built with and without libharfbuzz. > > https://bugs.openjdk.java.net/browse/JDK-8250894 > https://hg.openjdk.java.net/jdk/jdk/rev/880cfb985f8e > > Best regards, > Goetz. From gnu.andrew at redhat.com Mon Oct 5 05:42:46 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 5 Oct 2020 06:42:46 +0100 Subject: [11u] Is 11u now frozen for 11.0.9? Message-ID: <20201005054246.GA551773@stopbrexit> I see a jdk-11.0.9+10 tag on 2020-09-30, which matches with what should be the last promotion according to the 11u wiki [0], but no announcement om the mailing list regarding this. What is the current state of 11u? [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From christoph.langer at sap.com Mon Oct 5 06:12:48 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Oct 2020 06:12:48 +0000 Subject: [11u] Is 11u now frozen for 11.0.9? In-Reply-To: <20201005054246.GA551773@stopbrexit> References: <20201005054246.GA551773@stopbrexit> Message-ID: Hi Andrew, correct, with 11.0.9+10, the 11u repo is frozen. You can go ahead with CPU work ?? Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Hughes > Sent: Montag, 5. Oktober 2020 07:43 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] Is 11u now frozen for 11.0.9? > > I see a jdk-11.0.9+10 tag on 2020-09-30, which matches with what > should be the last promotion according to the 11u wiki [0], but no > announcement om the mailing list regarding this. > > What is the current state of 11u? > > [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From christoph.langer at sap.com Mon Oct 5 06:41:24 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Oct 2020 06:41:24 +0000 Subject: Nothing posted to jdk-updates-changes for 11u since Sep 30 In-Reply-To: References: Message-ID: Hi Paul, I'm not registered on jdk-updates-changes, but looking at the web frontend, it seems there is normal traffic: https://mail.openjdk.java.net/pipermail/jdk-updates-changes/2020-September/date.html https://mail.openjdk.java.net/pipermail/jdk-updates-changes/2020-October/date.html So, could be a mailing list issue... Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Freitag, 2. Oktober 2020 20:58 > To: jdk-updates-dev at openjdk.java.net > Subject: [DMARC FAILURE] Nothing posted to jdk-updates-changes for 11u > since Sep 30 > > Has anyone else noticed that nothing has been posted to jdk-updates- > changes for 11u since Sep 30? Maybe it?s just me, or maybe just outside > Oracle like the hotspot-dev problem awhile ago. > > Thanks, > Paul From goetz.lindenmaier at sap.com Mon Oct 5 06:41:35 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 5 Oct 2020 06:41:35 +0000 Subject: [11u] RFR: 8250894: Provide a configure option to build and run against the platform libharfbuzz In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Saturday, October 3, 2020 7:14 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8250894: Provide a configure option to build and run > against the platform libharfbuzz > > Hi G?tz, > > thanks for backporting this change. Looks good. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Freitag, 2. Oktober 2020 14:58 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8250894: Provide a configure option to build > > and run against the platform libharfbuzz > > > > Hi, > > > > I am downporting this for parity with 11.0.10-oracle. > > I had to do a row of simple resolves: > > http://cr.openjdk.java.net/~goetz/wr20/8250894-configure_harfbuzz- > > jdk11/01/ > > > > file make/autoconf/help.m4 > > zypper_help() is not in 11. > > Thus, I omitted the help message for zypper. > > > > unable to find 'make/modules/java.desktop/Copy.gmk' for patching > > Patch had to be applied to make/copy/Copy-java.desktop.gmk > > > > unable to find 'make/modules/java.desktop/lib/Awt2dLibraries.gmk' for > > patching > > Patch had to be applied to make/lib/Awt2dLibraries.gmk > > It does not apply because of the solaris port coding that is in 11. > > But the patch basically indents the harfbuzz build instructions > > and wraps it in an if, so resolving was trivial. > > > > Built with and without libharfbuzz. > > > > https://bugs.openjdk.java.net/browse/JDK-8250894 > > https://hg.openjdk.java.net/jdk/jdk/rev/880cfb985f8e > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Mon Oct 5 06:58:18 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 5 Oct 2020 06:58:18 +0000 Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: <97fdf61a-06d4-1fdd-d028-561cea7f965e@oss.nttdata.com> References: <4a75d2b8-7980-a90b-8142-333c402ea0da@gmail.com> <6a36d15f-07f3-a895-ed1a-06e872396d80@oss.nttdata.com> <56fd7f5f-a610-5699-a5aa-c119756d2023@oss.nttdata.com> <97fdf61a-06d4-1fdd-d028-561cea7f965e@oss.nttdata.com> Message-ID: Hi, Yes, I also think this can go to 11.0.10. Looks good, reviewed. And passed our tests. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Yasumasa Suenaga > Sent: Friday, September 11, 2020 2:26 AM > To: Yasumasa Suenaga > Cc: Langer, Christoph ; Baesken, Matthias > ; jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8250598: Hyper-V is detected in spite of running on > host OS > > Hi all, > > I think this change for 11u is ready to review. > I haven't heard any problems on jdk/jdk. > > Could you review it? > > >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 > >>>> Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924 > >>>> webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK- > 8250598/jdk11u/webrev.00/ > > > Thanks, > > Yasumasa > > > On 2020/08/31 20:02, Yasumasa Suenaga wrote: > > Hi Christoph, > > > > JDK 11 is LTS version, so we might see hs_err logs which relates to this fix in > production system. It is the reason why I want to backport it to 11.0.9 if > possible. > > > > OTOH it is not so critical and JDK 11 will enter rampdown, I understand that > we have to be careful. > > I will comply the timing when "jdk11u-fix-yes" is added to JBS. > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2020/08/31 19:04, Langer, Christoph wrote: > >> Hi Yasumasa, > >> > >> is there any specific reason why it should be part of 11.0.9? > >> > >> Without having more detailed knowledge of the matter, I'd say it's > cautious enough to postpone this backport to 11.0.10, given that we're > about to enter rampdown... > >> > >> Best regards > >> Christoph > >> > >>> -----Original Message----- > >>> From: jdk-updates-dev On > >>> Behalf Of Yasumasa Suenaga > >>> Sent: Freitag, 28. August 2020 10:02 > >>> To: Baesken, Matthias ; Yasumasa > Suenaga > >>> ; jdk-updates-dev at openjdk.java.net > >>> Subject: Re: [11u] RFR: 8250598: Hyper-V is detected in spite of running > on > >>> host OS > >>> > >>> Hi Matthias, > >>> > >>> On 2020/08/28 16:22, Baesken, Matthias wrote: > >>>> Hi Yasumasa ,I suggest to let the? change? "rest"? in? jdk/jdk for? a couple > of > >>> weeks? before? going for downports . > >>>> (not saying that downporting it is a bad thing) > >>> > >>> I understand what you say, but I want to backport it to 11.0.9 if possible. > >>> 11.0.9 will enter rampdown in 1 Sep... > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >>> > >>> > >>>> Best regards, Matthias > >>>> > >>>> -----Original Message----- > >>>> From: Yasumasa Suenaga > >>>> Sent: Freitag, 28. August 2020 02:55 > >>>> To: jdk-updates-dev at openjdk.java.net > >>>> Cc: Baesken, Matthias > >>>> Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on > host > >>> OS > >>>> > >>>> Hi all, > >>>> > >>>> Please approve backport of JDK-8250598: > >>>> > >>>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 > >>>> ????? Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924 > >>>> ????? webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK- > >>> 8250598/jdk11u/webrev.00/ > >>>> > >>>> The patch does not apply cleanly on 11u due to additional > enhancements to > >>> x86 / x86_64 processors. > >>>> So I've prepared another webrev for 11u. > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Yasumasa > >>>> From shade at redhat.com Mon Oct 5 06:59:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 5 Oct 2020 08:59:23 +0200 Subject: [11u] RFR 8239477: jdk/jfr/jcmd/TestJcmdStartStopDefault.java fails -XX:+VerifyOops with "verify_oop: rsi: broken oop" In-Reply-To: References: <07a07c67-cad3-4c14-cf79-abcc3114f4d0@redhat.com> Message-ID: On 10/1/20 1:29 PM, Lindenmaier, Goetz wrote: > This looks good to me. Thanks, tagged. -- Thanks, -Aleksey From christoph.langer at sap.com Mon Oct 5 07:00:22 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Oct 2020 07:00:22 +0000 Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <4a75d2b8-7980-a90b-8142-333c402ea0da@gmail.com> <6a36d15f-07f3-a895-ed1a-06e872396d80@oss.nttdata.com> <56fd7f5f-a610-5699-a5aa-c119756d2023@oss.nttdata.com> <97fdf61a-06d4-1fdd-d028-561cea7f965e@oss.nttdata.com> Message-ID: Hi, thanks for reviewing (and testing), Goetz ?? I have approved the backport then. Cheers Christoph > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 5. Oktober 2020 08:58 > To: 'Yasumasa Suenaga' ; Yasumasa Suenaga > > Cc: Langer, Christoph ; Baesken, Matthias > ; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR: 8250598: Hyper-V is detected in spite of running on > host OS > > Hi, > > Yes, I also think this can go to 11.0.10. > Looks good, reviewed. And passed our tests. > > Best regards, > Goetz. > > > -----Original Message----- > > From: jdk-updates-dev On > Behalf > > Of Yasumasa Suenaga > > Sent: Friday, September 11, 2020 2:26 AM > > To: Yasumasa Suenaga > > Cc: Langer, Christoph ; Baesken, Matthias > > ; jdk-updates-dev at openjdk.java.net > > Subject: Re: [11u] RFR: 8250598: Hyper-V is detected in spite of running on > > host OS > > > > Hi all, > > > > I think this change for 11u is ready to review. > > I haven't heard any problems on jdk/jdk. > > > > Could you review it? > > > > >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 > > >>>> Original fix: > https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924 > > >>>> webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK- > > 8250598/jdk11u/webrev.00/ > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2020/08/31 20:02, Yasumasa Suenaga wrote: > > > Hi Christoph, > > > > > > JDK 11 is LTS version, so we might see hs_err logs which relates to this fix > in > > production system. It is the reason why I want to backport it to 11.0.9 if > > possible. > > > > > > OTOH it is not so critical and JDK 11 will enter rampdown, I understand > that > > we have to be careful. > > > I will comply the timing when "jdk11u-fix-yes" is added to JBS. > > > > > > > > > Thanks, > > > > > > Yasumasa > > > > > > > > > On 2020/08/31 19:04, Langer, Christoph wrote: > > >> Hi Yasumasa, > > >> > > >> is there any specific reason why it should be part of 11.0.9? > > >> > > >> Without having more detailed knowledge of the matter, I'd say it's > > cautious enough to postpone this backport to 11.0.10, given that we're > > about to enter rampdown... > > >> > > >> Best regards > > >> Christoph > > >> > > >>> -----Original Message----- > > >>> From: jdk-updates-dev On > > >>> Behalf Of Yasumasa Suenaga > > >>> Sent: Freitag, 28. August 2020 10:02 > > >>> To: Baesken, Matthias ; Yasumasa > > Suenaga > > >>> ; jdk-updates-dev at openjdk.java.net > > >>> Subject: Re: [11u] RFR: 8250598: Hyper-V is detected in spite of running > > on > > >>> host OS > > >>> > > >>> Hi Matthias, > > >>> > > >>> On 2020/08/28 16:22, Baesken, Matthias wrote: > > >>>> Hi Yasumasa ,I suggest to let the? change? "rest"? in? jdk/jdk for? a > couple > > of > > >>> weeks? before? going for downports . > > >>>> (not saying that downporting it is a bad thing) > > >>> > > >>> I understand what you say, but I want to backport it to 11.0.9 if > possible. > > >>> 11.0.9 will enter rampdown in 1 Sep... > > >>> > > >>> > > >>> Thanks, > > >>> > > >>> Yasumasa > > >>> > > >>> > > >>>> Best regards, Matthias > > >>>> > > >>>> -----Original Message----- > > >>>> From: Yasumasa Suenaga > > >>>> Sent: Freitag, 28. August 2020 02:55 > > >>>> To: jdk-updates-dev at openjdk.java.net > > >>>> Cc: Baesken, Matthias > > >>>> Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running > on > > host > > >>> OS > > >>>> > > >>>> Hi all, > > >>>> > > >>>> Please approve backport of JDK-8250598: > > >>>> > > >>>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 > > >>>> ????? Original fix: > https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924 > > >>>> ????? webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK- > > >>> 8250598/jdk11u/webrev.00/ > > >>>> > > >>>> The patch does not apply cleanly on 11u due to additional > > enhancements to > > >>> x86 / x86_64 processors. > > >>>> So I've prepared another webrev for 11u. > > >>>> > > >>>> > > >>>> Thanks, > > >>>> > > >>>> Yasumasa > > >>>> From christoph.langer at sap.com Mon Oct 5 07:01:33 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Oct 2020 07:01:33 +0000 Subject: [11u] RFR 8239477: jdk/jfr/jcmd/TestJcmdStartStopDefault.java fails -XX:+VerifyOops with "verify_oop: rsi: broken oop" In-Reply-To: References: <07a07c67-cad3-4c14-cf79-abcc3114f4d0@redhat.com> Message-ID: And approved ?? > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Montag, 5. Oktober 2020 08:59 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR 8239477: jdk/jfr/jcmd/TestJcmdStartStopDefault.java > fails -XX:+VerifyOops with "verify_oop: rsi: broken oop" > > On 10/1/20 1:29 PM, Lindenmaier, Goetz wrote: > > This looks good to me. > > Thanks, tagged. > > -- > Thanks, > -Aleksey From akozlov at azul.com Mon Oct 5 08:07:17 2020 From: akozlov at azul.com (Anton Kozlov) Date: Mon, 5 Oct 2020 11:07:17 +0300 Subject: [aarch64-port-dev ] [jdk11u] 8253947: Implementation: JEP 388: Windows AArch64 Support In-Reply-To: References: Message-ID: Hi, Adding jdk-updates, where jdk11u is developed. In general, it looks it clearly falls into the category of changes worth backporting[1] (although written for jdk8u) > New features should not generally be back-ported to 8u, except where it is necessary to adapt OpenJDK to new computing environments. For example, [...] ports to new hardware or operating systems [might qualify]. These are necessary for JDK 8u to remain relevant. Process-wise, you don't need to create backports, this is done automatically by a push hook on the HG repo. You need to commit changes under the same bug IDs that were used for integration into the mainline. [2] IMHO, to simplify reviewing (I'm not a reviewer, just expressing what I would find beneficial), it may be useful to split the patch into two. One patch for changes that carry the risk for an existing jdk11u functionality, including support of other operating systems. Another patch for the the new platform support only, like a new file or an extra #ifdef that is turns to nothing on the rest of the platforms. The second patch review could then be reduced to ensure it actually does not harm. Thanks, Anton [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html [2] https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix On 02.10.2020 22:49, Ludovic Henry wrote: > Hi, > > As we are getting closer to merge JEP 388 (Windows/AArch64 Port), I wanted to share the work I've done for the backport to JDK 11. > > This email is not an RFR as the webrev is not finalized yet (the JEP implementation hasn't landed on JDK tip). I'm sharing it just to give an idea of the work which will be required, what kind of changes we are facing, and for other parties who have expressed interest in this backport. I'll keep updating it as we get reviews on [1]. > > Once we've landed the JEP implementation into JDK tip, I'll create the appropriate bug IDs for all the necessary backports, and contact the relevant mailing lists with the different webrevs and JBS. > > I've tested this change on Windows-AArch64 against hotspot:tier1, jdk:tier1 and langtools, but not yet on Linux-AArch64. > > Webrev: http://cr.openjdk.java.net/~luhenry/8253947/webrev.00/ > > Thank you, > Ludovic > > [1] https://github.com/openjdk/jdk/pull/212 > From suenaga at oss.nttdata.com Mon Oct 5 12:10:42 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 5 Oct 2020 21:10:42 +0900 Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: References: <4a75d2b8-7980-a90b-8142-333c402ea0da@gmail.com> <6a36d15f-07f3-a895-ed1a-06e872396d80@oss.nttdata.com> <56fd7f5f-a610-5699-a5aa-c119756d2023@oss.nttdata.com> <97fdf61a-06d4-1fdd-d028-561cea7f965e@oss.nttdata.com> Message-ID: <7481d837-2c73-4448-6a0d-9fefc23eeee3@oss.nttdata.com> Thanks Goetz and Christoph! I will push it to jdk11u-dev later. Yasumasa On 2020/10/05 16:00, Langer, Christoph wrote: > Hi, > > thanks for reviewing (and testing), Goetz ?? I have approved the backport then. > > Cheers > Christoph > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Montag, 5. Oktober 2020 08:58 >> To: 'Yasumasa Suenaga' ; Yasumasa Suenaga >> >> Cc: Langer, Christoph ; Baesken, Matthias >> ; jdk-updates-dev at openjdk.java.net >> Subject: RE: [11u] RFR: 8250598: Hyper-V is detected in spite of running on >> host OS >> >> Hi, >> >> Yes, I also think this can go to 11.0.10. >> Looks good, reviewed. And passed our tests. >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: jdk-updates-dev On >> Behalf >>> Of Yasumasa Suenaga >>> Sent: Friday, September 11, 2020 2:26 AM >>> To: Yasumasa Suenaga >>> Cc: Langer, Christoph ; Baesken, Matthias >>> ; jdk-updates-dev at openjdk.java.net >>> Subject: Re: [11u] RFR: 8250598: Hyper-V is detected in spite of running on >>> host OS >>> >>> Hi all, >>> >>> I think this change for 11u is ready to review. >>> I haven't heard any problems on jdk/jdk. >>> >>> Could you review it? >>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 >>>>>>> Original fix: >> https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924 >>>>>>> webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK- >>> 8250598/jdk11u/webrev.00/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/08/31 20:02, Yasumasa Suenaga wrote: >>>> Hi Christoph, >>>> >>>> JDK 11 is LTS version, so we might see hs_err logs which relates to this fix >> in >>> production system. It is the reason why I want to backport it to 11.0.9 if >>> possible. >>>> >>>> OTOH it is not so critical and JDK 11 will enter rampdown, I understand >> that >>> we have to be careful. >>>> I will comply the timing when "jdk11u-fix-yes" is added to JBS. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/08/31 19:04, Langer, Christoph wrote: >>>>> Hi Yasumasa, >>>>> >>>>> is there any specific reason why it should be part of 11.0.9? >>>>> >>>>> Without having more detailed knowledge of the matter, I'd say it's >>> cautious enough to postpone this backport to 11.0.10, given that we're >>> about to enter rampdown... >>>>> >>>>> Best regards >>>>> Christoph >>>>> >>>>>> -----Original Message----- >>>>>> From: jdk-updates-dev On >>>>>> Behalf Of Yasumasa Suenaga >>>>>> Sent: Freitag, 28. August 2020 10:02 >>>>>> To: Baesken, Matthias ; Yasumasa >>> Suenaga >>>>>> ; jdk-updates-dev at openjdk.java.net >>>>>> Subject: Re: [11u] RFR: 8250598: Hyper-V is detected in spite of running >>> on >>>>>> host OS >>>>>> >>>>>> Hi Matthias, >>>>>> >>>>>> On 2020/08/28 16:22, Baesken, Matthias wrote: >>>>>>> Hi Yasumasa ,I suggest to let the? change? "rest"? in? jdk/jdk for? a >> couple >>> of >>>>>> weeks? before? going for downports . >>>>>>> (not saying that downporting it is a bad thing) >>>>>> >>>>>> I understand what you say, but I want to backport it to 11.0.9 if >> possible. >>>>>> 11.0.9 will enter rampdown in 1 Sep... >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>> Best regards, Matthias >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Yasumasa Suenaga >>>>>>> Sent: Freitag, 28. August 2020 02:55 >>>>>>> To: jdk-updates-dev at openjdk.java.net >>>>>>> Cc: Baesken, Matthias >>>>>>> Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running >> on >>> host >>>>>> OS >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Please approve backport of JDK-8250598: >>>>>>> >>>>>>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 >>>>>>> ????? Original fix: >> https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924 >>>>>>> ????? webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK- >>>>>> 8250598/jdk11u/webrev.00/ >>>>>>> >>>>>>> The patch does not apply cleanly on 11u due to additional >>> enhancements to >>>>>> x86 / x86_64 processors. >>>>>>> So I've prepared another webrev for 11u. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> From katya at azul.com Mon Oct 5 13:03:47 2020 From: katya at azul.com (Ekaterina Vergizova) Date: Mon, 5 Oct 2020 13:03:47 +0000 Subject: [11u] RFR: 8208677: Move inner metaspace cleaning out of class unloading In-Reply-To: References: <3f386b3bfefe471f8a7bbd73e6bb9427@azul.com> Message-ID: <8b9097a0d3ff44aab11ad1fcf7bb17a3@azul.com> Hi Goetz, I agree that Oracle probably fixed 8251945 in a different way, although JDK-8210422 has an unresolved backport in 11-pool. But as sometimes discussed (e.g. [1]), it would be preferable to backport changes that were tested in the parent repos rather than to make manual unsafe changes. That's why I suggested that approach. If somebody can suggest an alternative safe fix it would be great. >From my side, I'm ready to provide the full list of suggested backports. All of them passed through extensive testing including full regression on multiple platforms. Thanks, Ekaterina [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-January/010997.html -----Original Message----- From: Lindenmaier, Goetz Sent: Thursday, October 1, 2020 2:45 PM To: Ekaterina Vergizova ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8208677: Move inner metaspace cleaning out of class unloading Hi Ekaterina, I understand you want to downport 5 changes to fix https://bugs.openjdk.java.net/browse/JDK-8251945, starting with this one. 8251945 is fixed in 11.0.10-oracle. But Oracle did not mark these five changes as downported, as they usually would do. So I assume they applied a tailored fix to 11 we unfortunately can not see, but they did not downport these 5 changes. This particular change here seem quite risky to me. It changes the behavior of the VM by scheduling tasks differently and changing safe points. Isn't it possible to fix the issue more defensively? Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ekaterina Vergizova > Sent: Wednesday, September 23, 2020 11:10 PM > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8208677: Move inner metaspace cleaning out of > class unloading > > Hello, > I would like to backport 8208677 to 11u as a prerequisite for 8210422. > 8210422 fixes the crash described in 8251945 that is already fixed in > 11.0.10- oracle. > The full list of suggested prerequisites is specified in [1]. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8208677 > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/aa3bfacc912c > Webrev for 11u: > https://cr.openjdk.java.net/~apetushkov/8208677/webrev.00/ > > The patch applies almost cleanly except for the change in > src/hotspot/share/code/nmethod.cpp. > It is already included in 11u by 8220718. > > Tested with tier1; the full list of backports specified in [1] is > tested with full regression. > > Thanks, > Ekaterina > > [1] https://bugs.openjdk.java.net/browse/JDK- > 8251945?focusedCommentId=14363860&page=com.atlassian.jira.plugin.sys > tem.issuetabpanels%3Acomment-tabpanel#comment-14363860 From tiago.daitx at canonical.com Mon Oct 5 19:15:43 2020 From: tiago.daitx at canonical.com (Tiago Daitx) Date: Mon, 5 Oct 2020 16:15:43 -0300 Subject: TextPane.background property is not being set in GTKLookAndFeel Message-ID: Hi, We got a report [1] for a very simple fix so GTKLookAndFeel will return the right TextPane.background color. Currently UIManager.getColor("TextPane.background") will ignore the theme color and always return a white color for GTKLookAndFeel due to inheritance from BasicLookAndFeel - that is incorrect and fails badly for dark themes. Seems to affect various OpenJDK versions - I can confirm it from 8 to 16 after looking at the source code, haven't checked on 7. Please note that the JTextPane opens using all the correct theme colors, it's the UIManager.getColor("TextPane.background") call that fails since GTKLookAndFeel does not currently set it. If the patch below fails to display correctly the original one can be fetched directly from the bug report [2]. --- a/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java +++ b/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java @@ -349,6 +349,7 @@ Double defaultCaretAspectRatio = Double.valueOf(0.025); Color caretColor = table.getColor("caretColor"); Color controlText = table.getColor("controlText"); + Color text = table.getColor("text"); Object fieldInputMap = new UIDefaults.LazyInputMap(new Object[] { "ctrl C", DefaultEditorKit.copyAction, @@ -1150,6 +1151,7 @@ "TextField.font", new FontLazyValue(Region.TEXT_FIELD), + "TextPane.background", text, "TextPane.caretForeground", caretColor, "TextPane.caretAspectRatio", defaultCaretAspectRatio, "TextPane.caretBlinkRate", caretBlinkRate, References: [1] https://launchpad.net/bugs/1894419 [2] https://launchpadlibrarian.net/496501072/gtk-laf-textpane-respect-dark-mode.diff Cheers! -- Tiago St?rmer Daitx Software Engineer tiago.daitx at canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE From goetz.lindenmaier at sap.com Tue Oct 6 08:52:30 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 6 Oct 2020 08:52:30 +0000 Subject: [11u] RFR: 8216324: GetClassMethods is confused by the presence of default methods in super interfaces Message-ID: Hi, I am downporting this for 11.0.10-oracle parity. http://cr.openjdk.java.net/~goetz/wr20/8216324-GetClassMethods_confused-jdk11/01/ I had to resolve the test library files. In 11, these are C, in the source they are C++. Please review. https://bugs.openjdk.java.net/browse/JDK-8216324 https://hg.openjdk.java.net/jdk/jdk/rev/c379dc750a02 Best regards, Goetz. From martin.doerr at sap.com Tue Oct 6 10:18:52 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 6 Oct 2020 10:18:52 +0000 Subject: [11u] RFR: 8216324: GetClassMethods is confused by the presence of default methods in super interfaces In-Reply-To: References: Message-ID: Hi G?tz, thanks for doing this work. Backport looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 6. Oktober 2020 10:53 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8216324: GetClassMethods is confused by the > presence of default methods in super interfaces > > Hi, > > I am downporting this for 11.0.10-oracle parity. > http://cr.openjdk.java.net/~goetz/wr20/8216324- > GetClassMethods_confused-jdk11/01/ > > I had to resolve the test library files. In 11, these are C, in the source > they are C++. > > Please review. > https://bugs.openjdk.java.net/browse/JDK-8216324 > https://hg.openjdk.java.net/jdk/jdk/rev/c379dc750a02 > > Best regards, > Goetz. From martin.doerr at sap.com Tue Oct 6 18:11:50 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 6 Oct 2020 18:11:50 +0000 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: Message-ID: Hi G?tz, thanks for backporting this change. I think it's good to put it into 11.0.10, now, so we have enough testing time. Please find comments and questions inline. > file src/java.base/share/classes/sun/security/ssl/CipherSuite.java > Non-applying chunk fixes typo in a comment that is not in 11. > I copied the comment to 11. Good. > file src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java > Deleting class DHEKAKeyDerivation failed because the code in 11 uses > JsseJce.getKeyAgreement() > where the patch uses KeyAgreement.getInstance(). Right. > file > src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchange.java > 11 has different imports. > The remaining conflicts arise from different usages of KeyFactory, ECUtil and > JsseJce. Good. > file src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java > The conflicts arise from different usages of KeyAgreement and JsseJce. Ok. > file > src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java > Different imports. > The remaining conflicts arise from different usages of KeyFactory, ECUtil and > JsseJce. Ok. > file src/java.base/share/classes/sun/security/ssl/SSLExtension.java > Copyright > > file src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java > Copyright We don't edit Copyright headers for backports. Ok. > file src/java.base/share/classes/sun/security/ssl/SignatureScheme.java > imports Ok. > file > src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.jav > a > Different imports. Ok. > Enums are moved to a file of their own: NamedGroup.java > Removing the enums does not apply because in 13 FIPS support was > removed. So you just deleted them manually. Fine. > Also, a name string was added. You mean "String name" in the code you removed? > The supported group types differ, too. That's expected. Did that cause manual integration? > In 11, the enums have a row of additional functionality that > I now removed, too. E.g., additional constructors, isSupported(), > isECAvailable. That's in the code which is gone. That's fine. > Some further differences are again usages of ECUtil, JsseJce etc. > The original patch has more NamedGroups: "// Secondary NIST curves" Ok. > file test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java > configureClientSocket() already in 11. We downported this with > a previous change. Ok. I can see this code is already there. > The NamedGroups enum is moved to a file of it's own. > Before this change, the named Groups knew about FIPS in 11. The new ones > don't. > https://bugs.openjdk.java.net/browse/JDK-8217835 "Remove the > experimental SunJSSE FIPS compliant mode" > removed FIPS support in 13 before this change was implemented. > > As I understand 8217835, the experimental FIPS feature cannot be used in > 11, it just remained in the code. So I skipped adapting NamedGroups to the > old behaviour, I can not test it anyways. > What do you think, do we need to add this code to NamedGroupd.java > again? Sounds like this is ok according to the CSR https://bugs.openjdk.java.net/browse/JDK-8217907 Since this file is new with this backport, I prefer keeping it like the original one for the backport. We could open a new bug in case anybody wants it back, but I guess that's not the case. There's still some Fips code there: (!requireFips || namedGroup.isFips)*/ ) { // GL fix isFips With a comment! What are you planning to do with it? > There are two follow ups, > 8224650: Add tests to support X25519 and X448 in TLS > 8243549: sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java > failed with Unsupported signature algorithm: DSA > > I have downported these too, and will send RFR once this is stable. > Existing and new test are all passing. > > https://bugs.openjdk.java.net/browse/JDK-8171279 > http://hg.openjdk.java.net/jdk/jdk/rev/946f7f2d321c Ok. That's an important point. There may be more to come, but that's all we currently have AFAICS. Best regards, Martin From goetz.lindenmaier at sap.com Wed Oct 7 07:36:22 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Oct 2020 07:36:22 +0000 Subject: [11u] RFR: 8216324: GetClassMethods is confused by the presence of default methods in super interfaces In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing. Unfortunately, the windows and solaris builds boiled up an issue in the test C-file: --- a/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMethods.c +++ b/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMethods.c @@ -61,7 +61,9 @@ if (options != NULL && strcmp(options, "maintain_original_method_order") == 0) { printf("Enabled capability: maintain_original_method_order\n"); - jvmtiCapabilities caps = {}; + jvmtiCapabilities caps; + memset(&caps, 0, sizeof(jvmtiCapabilities)); + caps.can_maintain_original_method_order = 1; jvmtiError err = JNI_ENV_PTR(jvmti)->AddCapabilities(JNI_ENV_ARG(jvmti, &caps)); New webrev: http://cr.openjdk.java.net/~goetz/wr20/8216324-GetClassMethods_confused-jdk11/02/ Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Tuesday, October 6, 2020 12:19 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8216324: GetClassMethods is confused by the > presence of default methods in super interfaces > > Hi G?tz, > > thanks for doing this work. Backport looks good. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Dienstag, 6. Oktober 2020 10:53 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8216324: GetClassMethods is confused by the > > presence of default methods in super interfaces > > > > Hi, > > > > I am downporting this for 11.0.10-oracle parity. > > http://cr.openjdk.java.net/~goetz/wr20/8216324- > > GetClassMethods_confused-jdk11/01/ > > > > I had to resolve the test library files. In 11, these are C, in the source > > they are C++. > > > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8216324 > > https://hg.openjdk.java.net/jdk/jdk/rev/c379dc750a02 > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Wed Oct 7 07:47:47 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Oct 2020 07:47:47 +0000 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing this! > thanks for backporting this change. I think it's good to put it into 11.0.10, > now, so we have enough testing time. > > Enums are moved to a file of their own: NamedGroup.java > > Removing the enums does not apply because in 13 FIPS support was > > removed. > So you just deleted them manually. Fine. Yes. > > Also, a name string was added. > You mean "String name" in the code you removed? Yes. > > The supported group types differ, too. > That's expected. Did that cause manual integration? Yes, I had to resolve these parts. It is chunk @@ -531,24 +211,33 @@ in http://cr.openjdk.java.net/~goetz/wr20/8171279-X25519_in_TLS-jdk11/01/src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.java.udiff.html > > The NamedGroups enum is moved to a file of it's own. > > Before this change, the named Groups knew about FIPS in 11. The new > > ones don't. > > https://bugs.openjdk.java.net/browse/JDK-8217835 "Remove the > > experimental SunJSSE FIPS compliant mode" > > removed FIPS support in 13 before this change was implemented. > > > > As I understand 8217835, the experimental FIPS feature cannot be used in > > 11, it just remained in the code. So I skipped adapting NamedGroups to the > > old behaviour, I can not test it anyways. > > What do you think, do we need to add this code to NamedGroupd.java > > again? > Sounds like this is ok according to the CSR > https://bugs.openjdk.java.net/browse/JDK-8217907 > Since this file is new with this backport, I prefer keeping it like the original > one for the backport. > We could open a new bug in case anybody wants it back, but I guess that's > not the case. Ok, good. I think restoring that functionality would be a wasted effort. > There's still some Fips code there: > (!requireFips || namedGroup.isFips)*/ ) { // GL fix isFips > With a comment! > What are you planning to do with it? Remove it if we decide to drop FIPS support. Else I would have to reactivate it I guess. I would like to get a second opinion on the FIPS issue from someone outside SAP. Thanks and best regards, Goetz. From goetz.lindenmaier at sap.com Wed Oct 7 07:50:53 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Oct 2020 07:50:53 +0000 Subject: [11u] Second opinion? RFR: 8171279: Support X25519 and X448 in TLS Message-ID: Hi, I would like to get a second opinion on how to deal with the lost FIPS coding in this downport. Could someone from outside SAP have a look please? Thanks, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Tuesday, October 6, 2020 8:12 PM > To: Lindenmaier, Goetz ; jdk-updates-dev > > Subject: RE: [11u] RFR: 8171279: Support X25519 and X448 in TLS > > Hi G?tz, > > thanks for backporting this change. I think it's good to put it into 11.0.10, > now, so we have enough testing time. > Please find comments and questions inline. > > > > file src/java.base/share/classes/sun/security/ssl/CipherSuite.java > > Non-applying chunk fixes typo in a comment that is not in 11. > > I copied the comment to 11. > Good. > > > > file src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java > > Deleting class DHEKAKeyDerivation failed because the code in 11 uses > > JsseJce.getKeyAgreement() > > where the patch uses KeyAgreement.getInstance(). > Right. > > > > file > > src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchange.java > > 11 has different imports. > > The remaining conflicts arise from different usages of KeyFactory, ECUtil > and > > JsseJce. > Good. > > > > file src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java > > The conflicts arise from different usages of KeyAgreement and JsseJce. > Ok. > > > > file > > src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java > > Different imports. > > The remaining conflicts arise from different usages of KeyFactory, ECUtil > and > > JsseJce. > Ok. > > > > file src/java.base/share/classes/sun/security/ssl/SSLExtension.java > > Copyright > > > > file > src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java > > Copyright > We don't edit Copyright headers for backports. Ok. > > > > file src/java.base/share/classes/sun/security/ssl/SignatureScheme.java > > imports > Ok. > > > > file > > > src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.jav > > a > > Different imports. > Ok. > > > Enums are moved to a file of their own: NamedGroup.java > > Removing the enums does not apply because in 13 FIPS support was > > removed. > So you just deleted them manually. Fine. > > > Also, a name string was added. > You mean "String name" in the code you removed? > > > The supported group types differ, too. > That's expected. Did that cause manual integration? > > > In 11, the enums have a row of additional functionality that > > I now removed, too. E.g., additional constructors, isSupported(), > > isECAvailable. > That's in the code which is gone. That's fine. > > > Some further differences are again usages of ECUtil, JsseJce etc. > > The original patch has more NamedGroups: "// Secondary NIST curves" > Ok. > > > file test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java > > configureClientSocket() already in 11. We downported this with > > a previous change. > Ok. I can see this code is already there. > > > The NamedGroups enum is moved to a file of it's own. > > Before this change, the named Groups knew about FIPS in 11. The new > ones > > don't. > > https://bugs.openjdk.java.net/browse/JDK-8217835 "Remove the > > experimental SunJSSE FIPS compliant mode" > > removed FIPS support in 13 before this change was implemented. > > > > As I understand 8217835, the experimental FIPS feature cannot be used in > > 11, it just remained in the code. So I skipped adapting NamedGroups to the > > old behaviour, I can not test it anyways. > > What do you think, do we need to add this code to NamedGroupd.java > > again? > Sounds like this is ok according to the CSR > https://bugs.openjdk.java.net/browse/JDK-8217907 > Since this file is new with this backport, I prefer keeping it like the original > one for the backport. > We could open a new bug in case anybody wants it back, but I guess that's > not the case. > > There's still some Fips code there: > (!requireFips || namedGroup.isFips)*/ ) { // GL fix isFips > With a comment! > What are you planning to do with it? > > > > There are two follow ups, > > 8224650: Add tests to support X25519 and X448 in TLS > > 8243549: sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java > > failed with Unsupported signature algorithm: DSA > > > > I have downported these too, and will send RFR once this is stable. > > Existing and new test are all passing. > > > > https://bugs.openjdk.java.net/browse/JDK-8171279 > > http://hg.openjdk.java.net/jdk/jdk/rev/946f7f2d321c > Ok. That's an important point. > There may be more to come, but that's all we currently have AFAICS. > > > Best regards, > Martin From goetz.lindenmaier at sap.com Wed Oct 7 08:34:51 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Oct 2020 08:34:51 +0000 Subject: [11u] RFR: 8224650: Add tests to support X25519 and X448 in TLS Message-ID: Hi, I am downporting this for 11.0.10-oracle parity. Also, this is needed to test JDK-8171279. http://cr.openjdk.java.net/~goetz/wr20/8224650-X25519_test-jdk11/01/ The changes to SSLSocketTemplate.java have been downported already: https://bugs.openjdk.java.net/browse/JDK-8249159 8249159: Downport test rework for SSLSocketTemplate from 8224650 In the new test, I had to remove four Cipher suites that are not supported in 11. I just commented them so in case these Cipher suites are downported It is more easy to find that they must be enabled in this test. https://bugs.openjdk.java.net/browse/JDK-8224650 http://hg.openjdk.java.net/jdk/jdk13/rev/ed7851b2d5e4 Best regards, Goetz. From alvdavi at amazon.com Wed Oct 7 08:59:16 2020 From: alvdavi at amazon.com (Alvarez, David) Date: Wed, 7 Oct 2020 08:59:16 +0000 Subject: [11u] Second opinion? RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: Message-ID: Hi Goetz, Not a reviewer, but as you call for opinion, I'll pitch in. Isn't that FIPS option still accessible in jdk11 by passing something like: javac --add-exports java.base/com.sun.net.ssl.internal.ssl=ALL-UNNAMED FipsProviderTest.java I haven't tested the full FIPS functionality, but code like this: import com.sun.net.ssl.internal.ssl.Provider; public class FipsProviderTest { public static void main(String[] args) { com.sun.net.ssl.internal.ssl.Provider p = new Provider( "cryptoProvider"); } } That makes use of that constructor will no longer work. I don't know what is our statement regarding the usage of --add-exports, are we ok breaking solutions that make use of it? If we are, is it only when we have no other option or will be one situation like this one acceptable? Thanks, David On Wed, 2020-10-07 at 07:50 +0000, Lindenmaier, Goetz wrote: > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender > and know the content is safe. > > > > Hi, > > I would like to get a second opinion on how to deal > with the lost FIPS coding in this downport. > Could someone from outside SAP have a look please? > > Thanks, > Goetz. > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Tuesday, October 6, 2020 8:12 PM > > To: Lindenmaier, Goetz ; jdk-updates-dev > > > > Subject: RE: [11u] RFR: 8171279: Support X25519 and X448 in TLS > > > > Hi G?tz, > > > > thanks for backporting this change. I think it's good to put it > > into 11.0.10, > > now, so we have enough testing time. > > Please find comments and questions inline. > > > > > > > file > > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java > > > Non-applying chunk fixes typo in a comment that is not in 11. > > > I copied the comment to 11. > > > > Good. > > > > > > > file > > > src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java > > > Deleting class DHEKAKeyDerivation failed because the code in 11 > > > uses > > > JsseJce.getKeyAgreement() > > > where the patch uses KeyAgreement.getInstance(). > > > > Right. > > > > > > > file > > > src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchang > > > e.java > > > 11 has different imports. > > > The remaining conflicts arise from different usages of > > > KeyFactory, ECUtil > > > > and > > > JsseJce. > > > > Good. > > > > > > > file > > > src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java > > > The conflicts arise from different usages of KeyAgreement and > > > JsseJce. > > > > Ok. > > > > > > > file > > > src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchang > > > e.java > > > Different imports. > > > The remaining conflicts arise from different usages of > > > KeyFactory, ECUtil > > > > and > > > JsseJce. > > > > Ok. > > > > > > > file > > > src/java.base/share/classes/sun/security/ssl/SSLExtension.java > > > Copyright > > > > > > file > > > > src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.j > > ava > > > Copyright > > > > We don't edit Copyright headers for backports. Ok. > > > > > > > file > > > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java > > > imports > > > > Ok. > > > > > > > file > > > > > > > src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtensi > > on.jav > > > a > > > Different imports. > > > > Ok. > > > > > Enums are moved to a file of their own: NamedGroup.java > > > Removing the enums does not apply because in 13 FIPS support was > > > removed. > > > > So you just deleted them manually. Fine. > > > > > Also, a name string was added. > > > > You mean "String name" in the code you removed? > > > > > The supported group types differ, too. > > > > That's expected. Did that cause manual integration? > > > > > In 11, the enums have a row of additional functionality that > > > I now removed, too. E.g., additional constructors, > > > isSupported(), > > > isECAvailable. > > > > That's in the code which is gone. That's fine. > > > > > Some further differences are again usages of ECUtil, JsseJce etc. > > > The original patch has more NamedGroups: "// Secondary NIST > > > curves" > > > > Ok. > > > > > file test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java > > > configureClientSocket() already in 11. We downported this with > > > a previous change. > > > > Ok. I can see this code is already there. > > > > > The NamedGroups enum is moved to a file of it's own. > > > Before this change, the named Groups knew about FIPS in 11. The > > > new > > > > ones > > > don't. > > > https://bugs.openjdk.java.net/browse/JDK-8217835 "Remove the > > > experimental SunJSSE FIPS compliant mode" > > > removed FIPS support in 13 before this change was implemented. > > > > > > As I understand 8217835, the experimental FIPS feature cannot be > > > used in > > > 11, it just remained in the code. So I skipped adapting > > > NamedGroups to the > > > old behaviour, I can not test it anyways. > > > What do you think, do we need to add this code to > > > NamedGroupd.java > > > again? > > > > Sounds like this is ok according to the CSR > > https://bugs.openjdk.java.net/browse/JDK-8217907 > > Since this file is new with this backport, I prefer keeping it like > > the original > > one for the backport. > > We could open a new bug in case anybody wants it back, but I guess > > that's > > not the case. > > > > There's still some Fips code there: > > (!requireFips || namedGroup.isFips)*/ ) { // GL fix isFips > > With a comment! > > What are you planning to do with it? > > > > > > > There are two follow ups, > > > 8224650: Add tests to support X25519 and X448 in TLS > > > 8243549: > > > sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java > > > failed with Unsupported signature algorithm: DSA > > > > > > I have downported these too, and will send RFR once this is > > > stable. > > > Existing and new test are all passing. > > > > > > https://bugs.openjdk.java.net/browse/JDK-8171279 > > > http://hg.openjdk.java.net/jdk/jdk/rev/946f7f2d321c > > > > Ok. That's an important point. > > There may be more to come, but that's all we currently have AFAICS. > > > > > > Best regards, > > Martin > > From martin.doerr at sap.com Wed Oct 7 09:06:45 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 7 Oct 2020 09:06:45 +0000 Subject: [11u] RFR: 8216324: GetClassMethods is confused by the presence of default methods in super interfaces In-Reply-To: References: Message-ID: Hi G?tz, ah, these builds require the older C standard. Your fix is fine. Best regards, Martin > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Mittwoch, 7. Oktober 2020 09:36 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8216324: GetClassMethods is confused by the > presence of default methods in super interfaces > > Hi Martin, > > Thanks for reviewing. > > Unfortunately, the windows and solaris builds boiled up an issue in the test > C-file: > --- > a/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMet > hods.c > +++ > b/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMet > hods.c > @@ -61,7 +61,9 @@ > > if (options != NULL && strcmp(options, "maintain_original_method_order") > == 0) { > printf("Enabled capability: maintain_original_method_order\n"); > - jvmtiCapabilities caps = {}; > + jvmtiCapabilities caps; > + memset(&caps, 0, sizeof(jvmtiCapabilities)); > + > caps.can_maintain_original_method_order = 1; > > jvmtiError err = JNI_ENV_PTR(jvmti)- > >AddCapabilities(JNI_ENV_ARG(jvmti, &caps)); > > New webrev: > http://cr.openjdk.java.net/~goetz/wr20/8216324- > GetClassMethods_confused-jdk11/02/ > > Best regards, > Goetz. > > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Tuesday, October 6, 2020 12:19 PM > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8216324: GetClassMethods is confused by the > > presence of default methods in super interfaces > > > > Hi G?tz, > > > > thanks for doing this work. Backport looks good. > > > > Best regards, > > Martin > > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of Lindenmaier, Goetz > > > Sent: Dienstag, 6. Oktober 2020 10:53 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: [11u] RFR: 8216324: GetClassMethods is confused by the > > > presence of default methods in super interfaces > > > > > > Hi, > > > > > > I am downporting this for 11.0.10-oracle parity. > > > http://cr.openjdk.java.net/~goetz/wr20/8216324- > > > GetClassMethods_confused-jdk11/01/ > > > > > > I had to resolve the test library files. In 11, these are C, in the source > > > they are C++. > > > > > > Please review. > > > https://bugs.openjdk.java.net/browse/JDK-8216324 > > > https://hg.openjdk.java.net/jdk/jdk/rev/c379dc750a02 > > > > > > Best regards, > > > Goetz. From jaroslav.bachorik at datadoghq.com Wed Oct 7 15:58:27 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Wed, 7 Oct 2020 17:58:27 +0200 Subject: [11u] RFR 8252090: JFR: StreamWriterHost::write_unbuffered() stucks in an infinite loop OpenJDK (build 13.0.1+9) Message-ID: Hello, Can I get the following backport reviewed? JIRA: https://bugs.openjdk.java.net/browse/JDK-8252090 Webrev: http://cr.openjdk.java.net/~jbachorik/8252090/00/webrev/ The backport and the original patch are differing in 1 place only: - src/hotspot/share/jfr/recorder/repository/jfrChunkWriter.cpp does not contain write_magic() method and the change needs to be done in JfrChunkWriter::open() instead Ran tier1 and jdk_jfr tests successfully. Thanks, -JB- From goetz.lindenmaier at sap.com Thu Oct 8 10:35:36 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 8 Oct 2020 10:35:36 +0000 Subject: [11u] RFR: 8216324: GetClassMethods is confused by the presence of default methods in super interfaces In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing again. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Wednesday, October 7, 2020 11:07 AM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8216324: GetClassMethods is confused by the > presence of default methods in super interfaces > > Hi G?tz, > > ah, these builds require the older C standard. Your fix is fine. > > Best regards, > Martin > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Mittwoch, 7. Oktober 2020 09:36 > > To: Doerr, Martin ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8216324: GetClassMethods is confused by the > > presence of default methods in super interfaces > > > > Hi Martin, > > > > Thanks for reviewing. > > > > Unfortunately, the windows and solaris builds boiled up an issue in the test > > C-file: > > --- > > a/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMet > > hods.c > > +++ > > b/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMet > > hods.c > > @@ -61,7 +61,9 @@ > > > > if (options != NULL && strcmp(options, > "maintain_original_method_order") > > == 0) { > > printf("Enabled capability: maintain_original_method_order\n"); > > - jvmtiCapabilities caps = {}; > > + jvmtiCapabilities caps; > > + memset(&caps, 0, sizeof(jvmtiCapabilities)); > > + > > caps.can_maintain_original_method_order = 1; > > > > jvmtiError err = JNI_ENV_PTR(jvmti)- > > >AddCapabilities(JNI_ENV_ARG(jvmti, &caps)); > > > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr20/8216324- > > GetClassMethods_confused-jdk11/02/ > > > > Best regards, > > Goetz. > > > > > > > > > -----Original Message----- > > > From: Doerr, Martin > > > Sent: Tuesday, October 6, 2020 12:19 PM > > > To: Lindenmaier, Goetz ; jdk-updates- > > > dev at openjdk.java.net > > > Subject: RE: [11u] RFR: 8216324: GetClassMethods is confused by the > > > presence of default methods in super interfaces > > > > > > Hi G?tz, > > > > > > thanks for doing this work. Backport looks good. > > > > > > Best regards, > > > Martin > > > > > > > > > > -----Original Message----- > > > > From: jdk-updates-dev On > > > > Behalf Of Lindenmaier, Goetz > > > > Sent: Dienstag, 6. Oktober 2020 10:53 > > > > To: jdk-updates-dev at openjdk.java.net > > > > Subject: [11u] RFR: 8216324: GetClassMethods is confused by the > > > > presence of default methods in super interfaces > > > > > > > > Hi, > > > > > > > > I am downporting this for 11.0.10-oracle parity. > > > > http://cr.openjdk.java.net/~goetz/wr20/8216324- > > > > GetClassMethods_confused-jdk11/01/ > > > > > > > > I had to resolve the test library files. In 11, these are C, in the source > > > > they are C++. > > > > > > > > Please review. > > > > https://bugs.openjdk.java.net/browse/JDK-8216324 > > > > https://hg.openjdk.java.net/jdk/jdk/rev/c379dc750a02 > > > > > > > > Best regards, > > > > Goetz. From goetz.lindenmaier at sap.com Thu Oct 8 16:36:58 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 8 Oct 2020 16:36:58 +0000 Subject: [11u] Second opinion? RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: Message-ID: Hi David, > I haven't tested the full FIPS functionality, That is the problem. I don't have appropriate tests, either. > but code like this: > import com.sun.net.ssl.internal.ssl.Provider; > > public class FipsProviderTest { > public static void main(String[] args) { > com.sun.net.ssl.internal.ssl.Provider p = new Provider( > "cryptoProvider"); > } > } > > > That makes use of that constructor will no longer work. Ok, I see how you can reach the FIPS functionality. But the example is obviously too small to touch the code I changed. It compiles fine, with and without the change. And it runs fine if I add SunJSSE as provider, for example. > I don't know > what is our statement regarding the usage of --add-exports, are we ok > breaking solutions that make use of it? If we are, is it only when we > have no other option or will be one situation like this one acceptable? Yes, I would prefer to not change the behavior even for things not explicitly exposed. Best regards, Goetz. > > Thanks, > David > > > On Wed, 2020-10-07 at 07:50 +0000, Lindenmaier, Goetz wrote: > > CAUTION: This email originated from outside of the organization. Do > > not click links or open attachments unless you can confirm the sender > > and know the content is safe. > > > > > > > > Hi, > > > > I would like to get a second opinion on how to deal > > with the lost FIPS coding in this downport. > > Could someone from outside SAP have a look please? > > > > Thanks, > > Goetz. > > > > > > > -----Original Message----- > > > From: Doerr, Martin > > > Sent: Tuesday, October 6, 2020 8:12 PM > > > To: Lindenmaier, Goetz ; jdk-updates-dev > > > > > > Subject: RE: [11u] RFR: 8171279: Support X25519 and X448 in TLS > > > > > > Hi G?tz, > > > > > > thanks for backporting this change. I think it's good to put it > > > into 11.0.10, > > > now, so we have enough testing time. > > > Please find comments and questions inline. > > > > > > > > > > file > > > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java > > > > Non-applying chunk fixes typo in a comment that is not in 11. > > > > I copied the comment to 11. > > > > > > Good. > > > > > > > > > > file > > > > src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java > > > > Deleting class DHEKAKeyDerivation failed because the code in 11 > > > > uses > > > > JsseJce.getKeyAgreement() > > > > where the patch uses KeyAgreement.getInstance(). > > > > > > Right. > > > > > > > > > > file > > > > src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchang > > > > e.java > > > > 11 has different imports. > > > > The remaining conflicts arise from different usages of > > > > KeyFactory, ECUtil > > > > > > and > > > > JsseJce. > > > > > > Good. > > > > > > > > > > file > > > > src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java > > > > The conflicts arise from different usages of KeyAgreement and > > > > JsseJce. > > > > > > Ok. > > > > > > > > > > file > > > > src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchang > > > > e.java > > > > Different imports. > > > > The remaining conflicts arise from different usages of > > > > KeyFactory, ECUtil > > > > > > and > > > > JsseJce. > > > > > > Ok. > > > > > > > > > > file > > > > src/java.base/share/classes/sun/security/ssl/SSLExtension.java > > > > Copyright > > > > > > > > file > > > > > > src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.j > > > ava > > > > Copyright > > > > > > We don't edit Copyright headers for backports. Ok. > > > > > > > > > > file > > > > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java > > > > imports > > > > > > Ok. > > > > > > > > > > file > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtensi > > > on.jav > > > > a > > > > Different imports. > > > > > > Ok. > > > > > > > Enums are moved to a file of their own: NamedGroup.java > > > > Removing the enums does not apply because in 13 FIPS support was > > > > removed. > > > > > > So you just deleted them manually. Fine. > > > > > > > Also, a name string was added. > > > > > > You mean "String name" in the code you removed? > > > > > > > The supported group types differ, too. > > > > > > That's expected. Did that cause manual integration? > > > > > > > In 11, the enums have a row of additional functionality that > > > > I now removed, too. E.g., additional constructors, > > > > isSupported(), > > > > isECAvailable. > > > > > > That's in the code which is gone. That's fine. > > > > > > > Some further differences are again usages of ECUtil, JsseJce etc. > > > > The original patch has more NamedGroups: "// Secondary NIST > > > > curves" > > > > > > Ok. > > > > > > > file test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java > > > > configureClientSocket() already in 11. We downported this with > > > > a previous change. > > > > > > Ok. I can see this code is already there. > > > > > > > The NamedGroups enum is moved to a file of it's own. > > > > Before this change, the named Groups knew about FIPS in 11. The > > > > new > > > > > > ones > > > > don't. > > > > https://bugs.openjdk.java.net/browse/JDK-8217835 "Remove the > > > > experimental SunJSSE FIPS compliant mode" > > > > removed FIPS support in 13 before this change was implemented. > > > > > > > > As I understand 8217835, the experimental FIPS feature cannot be > > > > used in > > > > 11, it just remained in the code. So I skipped adapting > > > > NamedGroups to the > > > > old behaviour, I can not test it anyways. > > > > What do you think, do we need to add this code to > > > > NamedGroupd.java > > > > again? > > > > > > Sounds like this is ok according to the CSR > > > https://bugs.openjdk.java.net/browse/JDK-8217907 > > > Since this file is new with this backport, I prefer keeping it like > > > the original > > > one for the backport. > > > We could open a new bug in case anybody wants it back, but I guess > > > that's > > > not the case. > > > > > > There's still some Fips code there: > > > (!requireFips || namedGroup.isFips)*/ ) { // GL fix isFips > > > With a comment! > > > What are you planning to do with it? > > > > > > > > > > There are two follow ups, > > > > 8224650: Add tests to support X25519 and X448 in TLS > > > > 8243549: > > > > sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java > > > > failed with Unsupported signature algorithm: DSA > > > > > > > > I have downported these too, and will send RFR once this is > > > > stable. > > > > Existing and new test are all passing. > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8171279 > > > > http://hg.openjdk.java.net/jdk/jdk/rev/946f7f2d321c > > > > > > Ok. That's an important point. > > > There may be more to come, but that's all we currently have AFAICS. > > > > > > > > > Best regards, > > > Martin > > > > From rob.mckenna at oracle.com Fri Oct 9 00:46:38 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 9 Oct 2020 01:46:38 +0100 Subject: [11u] Is 11u now frozen for 11.0.9? In-Reply-To: References: <20201005054246.GA551773@stopbrexit> Message-ID: <20201009004638.GA25853@DESKTOP-JNNKIHU.localdomain> Just spotted this. I'm looking into it. -Rob On 05/10/20 06:12, Langer, Christoph wrote: > Hi Andrew, > > correct, with 11.0.9+10, the 11u repo is frozen. You can go ahead with CPU work ?? > > Cheers > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Andrew Hughes > > Sent: Montag, 5. Oktober 2020 07:43 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] Is 11u now frozen for 11.0.9? > > > > I see a jdk-11.0.9+10 tag on 2020-09-30, which matches with what > > should be the last promotion according to the 11u wiki [0], but no > > announcement om the mailing list regarding this. > > > > What is the current state of 11u? > > > > [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > > > Thanks, > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > OpenJDK Package Owner > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From christoph.langer at sap.com Fri Oct 9 04:01:23 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 9 Oct 2020 04:01:23 +0000 Subject: [11u] Is 11u now frozen for 11.0.9? In-Reply-To: <20201009004638.GA25853@DESKTOP-JNNKIHU.localdomain> References: <20201005054246.GA551773@stopbrexit> <20201009004638.GA25853@DESKTOP-JNNKIHU.localdomain> Message-ID: Hi Rob, I don't think there's an action item for you here... It was just the question whether the last public tag for OpenJDK 11.0.9 development had been set and Andrew could start working on the CPU on that base. And I had answered this. Best regards Christoph > -----Original Message----- > From: Rob McKenna > Sent: Freitag, 9. Oktober 2020 02:47 > To: Langer, Christoph > Cc: Andrew Hughes ; jdk-updates- > dev at openjdk.java.net; Lindenmaier, Goetz > Subject: Re: [11u] Is 11u now frozen for 11.0.9? > > Just spotted this. I'm looking into it. > > -Rob > > On 05/10/20 06:12, Langer, Christoph wrote: > > Hi Andrew, > > > > correct, with 11.0.9+10, the 11u repo is frozen. You can go ahead with CPU > work ?? > > > > Cheers > > Christoph > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of Andrew Hughes > > > Sent: Montag, 5. Oktober 2020 07:43 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: [11u] Is 11u now frozen for 11.0.9? > > > > > > I see a jdk-11.0.9+10 tag on 2020-09-30, which matches with what > > > should be the last promotion according to the 11u wiki [0], but no > > > announcement om the mailing list regarding this. > > > > > > What is the current state of 11u? > > > > > > [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > > > > > Thanks, > > > -- > > > Andrew :) > > > > > > Senior Free Java Software Engineer > > > OpenJDK Package Owner > > > Red Hat, Inc. (http://www.redhat.com) > > > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From rob.mckenna at oracle.com Fri Oct 9 13:43:29 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 9 Oct 2020 14:43:29 +0100 Subject: Nothing posted to jdk-updates-changes for 11u since Sep 30 In-Reply-To: References: Message-ID: Seems to work fine for me. -Rob > On 5 Oct 2020, at 07:41, Langer, Christoph wrote: > > ?Hi Paul, > > I'm not registered on jdk-updates-changes, but looking at the web frontend, it seems there is normal traffic: > > https://mail.openjdk.java.net/pipermail/jdk-updates-changes/2020-September/date.html > https://mail.openjdk.java.net/pipermail/jdk-updates-changes/2020-October/date.html > > So, could be a mailing list issue... > > Best regards > Christoph > > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Hohensee, Paul >> Sent: Freitag, 2. Oktober 2020 20:58 >> To: jdk-updates-dev at openjdk.java.net >> Subject: [DMARC FAILURE] Nothing posted to jdk-updates-changes for 11u >> since Sep 30 >> >> Has anyone else noticed that nothing has been posted to jdk-updates- >> changes for 11u since Sep 30? Maybe it?s just me, or maybe just outside >> Oracle like the hotspot-dev problem awhile ago. >> >> Thanks, >> Paul > From nils.eliasson at oracle.com Fri Oct 9 14:34:47 2020 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 9 Oct 2020 16:34:47 +0200 Subject: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11 Message-ID: <549edaa3-7183-2368-c1e4-13f10fd62344@oracle.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8254185 Webrev: http://cr.openjdk.java.net/~neliasso/8254185/webrev.01/ This fix is a replacement for JDK-8244660 that I consider to risky to back port. This issue can't be seen unless JDK-8254185 is applied. That bug causes the sweeper to trigger on every code cache allocation. When JDK-8254185 is applied then no sweeps can be observed at all. The main issue is that the sweeper thread is never woken. And if it isn't woken, it can't check the counters to see if it is time to sweep. This fix include two changes: 1) Notifying waiters on the codecache_lock when a threshold for reclaimed nmethods has been reached. This fix is enough on its own. In JDK 15 I introduced a new lock for the sweeper because a adding a notify in NMethodSweeper::possibly_enable_sweeper conflicted with the compiledMethod_lock in add_osr_method. That lock was added when deoptimization was converted to using handshakes. So in 11 it is still ok to use the codecache_lock. 2) Moving the updates of _total_nof_code_cache_sweeps and _last_sweep inside block that is only run when doing a sweep. This change just makes the counters update as expected. _last_sweep is used to trigger sweeps after a number of safepoints. This is counted by _time_counter. But since updates of _time_counter doesn't wake the sweeper - it still doesn't work. In JDK 15 I removed all of this code since we can't even rely on safepoints happening at all. I don't want to introduce any bugs in JDK 11 by mistake - so I am leaving it as it is. Please review. Best regards, Nils Eliasson From hohensee at amazon.com Fri Oct 9 14:59:30 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 9 Oct 2020 14:59:30 +0000 Subject: Nothing posted to jdk-updates-changes for 11u since Sep 30 Message-ID: Seems to have come back for me also. Sorry for the fuss. Thanks, Paul ?On 10/9/20, 6:44 AM, "Rob McKenna" wrote: Seems to work fine for me. -Rob > On 5 Oct 2020, at 07:41, Langer, Christoph wrote: > > Hi Paul, > > I'm not registered on jdk-updates-changes, but looking at the web frontend, it seems there is normal traffic: > > https://mail.openjdk.java.net/pipermail/jdk-updates-changes/2020-September/date.html > https://mail.openjdk.java.net/pipermail/jdk-updates-changes/2020-October/date.html > > So, could be a mailing list issue... > > Best regards > Christoph > > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Hohensee, Paul >> Sent: Freitag, 2. Oktober 2020 20:58 >> To: jdk-updates-dev at openjdk.java.net >> Subject: [DMARC FAILURE] Nothing posted to jdk-updates-changes for 11u >> since Sep 30 >> >> Has anyone else noticed that nothing has been posted to jdk-updates- >> changes for 11u since Sep 30? Maybe it?s just me, or maybe just outside >> Oracle like the hotspot-dev problem awhile ago. >> >> Thanks, >> Paul > From sgehwolf at redhat.com Fri Oct 9 16:18:02 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 09 Oct 2020 18:18:02 +0200 Subject: [11u] RFR: 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities Message-ID: <6ee2cb0b8081e95781d324876dc0370405cc8171.camel@redhat.com> Hi, Please review this backport for Oracle 11.0.10 parity. The jdk-jdk patch needs to be significantly reworked since JDK 15+ has the cgroups v2 patches. The gist of the change is to only report memory values if swap accounting is disabled on the system (i.e. no swap memory) for metrics which would otherwise report values for memory + swap. Here is the list of changes I've done as compared to the JDK 16 patch: * Drop ProblemList.txt hunks. The test was not problem-listed in OpenJDK 11u. It's not applicable. * Dropped hunk in test/hotspot/jtreg/containers/cgroup/PlainRead.java, which also is not applicable (cgroups v2 and later refactorings related). * Moved changes from?CgroupV1Subsystem.java to?cgroupv1/Metrics.java class. That's where the code lived prior the cgroups v2 addition. * Moved code changes from?CgroupV1MemorySubSystemController.java to MemorySubsystem in?SubSystem.java * test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java adjusted since?JDK-8226575 for JDK 11 was different to JDK 15 (no new methods) * MetricsMemoryTester.java the code is again different in JDK 15+ because of JDK-8231111. But the changes for this bug only move it into a conditional testing whether swap is enabled and only test if it is. * MetricsTesterCgroupV1 => MetricsTester Bug: https://bugs.openjdk.java.net/browse/JDK-8250984 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250984/01/webrev/ Testing: Container tests on a system with swapaccount=0 and on a system with it enabled on Linux x86_64. Tests mentioned in the bug failed before, pass after. Thoughts? Thanks, Severin From goetz.lindenmaier at sap.com Mon Oct 12 06:06:41 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 12 Oct 2020 06:06:41 +0000 Subject: [11u] RFR: 8234147: Avoid looking up standard charsets in core libraries Message-ID: Hi, I am downporting this for parity with 11.0.10-oracle. http://cr.openjdk.java.net/~goetz/wr20/8234147-avoid_charset_lookup-jdk11/01/ The only file with non-trivial resolve was BasicAuthentication.java. The resolves I had to do in detail: file src/java.base/share/classes/com/sun/security/ntlm/NTLM.java Copyright. file src/java.base/share/classes/java/net/InetAddress.java Unclear why chunks were rejected. Context? file src/java.base/share/classes/java/util/Properties.java Context: other includes. file src/java.base/share/classes/java/util/jar/Attributes.java Prerequisite missing: "UTF8" --> UTF_8 file src/java.base/share/classes/java/util/jar/Manifest.java Prerequisite missing: "UTF8" --> UTF_8 file src/java.base/share/classes/java/util/zip/ZipCoder.java Copyright. file src/java.base/share/classes/sun/net/www/protocol/http/BasicAuthentication.java Coding looks different. I replaced occurances of "ISO_8859_1". file src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java Unclear: context? Actually, I don't see why Oracle brought this to 11. https://bugs.openjdk.java.net/browse/JDK-8234147 https://hg.openjdk.java.net/jdk/jdk/rev/5028793d05ff Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Oct 12 06:39:14 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 12 Oct 2020 06:39:14 +0000 Subject: [11u] Second opinion? RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: Message-ID: Hi, I gave it a try: http://cr.openjdk.java.net/~goetz/wr20/8171279-X25519_in_TLS-jdk11/02-incremental/ I think this incremental change restores the lost functionality. It does not break any of the existing tests. But I didn't run any tests for FIPS. On the other side, Matthias found this: https://github.com/elastic/elasticsearch/issues/37250 The larger comment a bit down states that FIPS is unusable in 11. If so, I would prefer to skip the incremental change above. Full webrev: http://cr.openjdk.java.net/~goetz/wr20/8171279-X25519_in_TLS-jdk11/02/ Best regards, Goetz > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Lindenmaier, Goetz > Sent: Thursday, October 8, 2020 6:37 PM > To: 'Alvarez, David' ; Doerr, Martin > ; jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] RE: [11u] Second opinion? RFR: 8171279: Support > X25519 and X448 in TLS > > Hi David, > > > I haven't tested the full FIPS functionality, > That is the problem. I don't have appropriate tests, either. > > > but code like this: > > import com.sun.net.ssl.internal.ssl.Provider; > > > > public class FipsProviderTest { > > public static void main(String[] args) { > > com.sun.net.ssl.internal.ssl.Provider p = new Provider( > > "cryptoProvider"); > > } > > } > > > > > > That makes use of that constructor will no longer work. > > Ok, I see how you can reach the FIPS functionality. > But the example is obviously too small to touch > the code I changed. > It compiles fine, with and without the change. > And it runs fine if I add SunJSSE as provider, for example. > > > I don't know > > what is our statement regarding the usage of --add-exports, are we ok > > breaking solutions that make use of it? If we are, is it only when we > > have no other option or will be one situation like this one acceptable? > Yes, I would prefer to not change the behavior even for > things not explicitly exposed. > > Best regards, > Goetz. > > > > > Thanks, > > David > > > > > > On Wed, 2020-10-07 at 07:50 +0000, Lindenmaier, Goetz wrote: > > > CAUTION: This email originated from outside of the organization. Do > > > not click links or open attachments unless you can confirm the sender > > > and know the content is safe. > > > > > > > > > > > > Hi, > > > > > > I would like to get a second opinion on how to deal > > > with the lost FIPS coding in this downport. > > > Could someone from outside SAP have a look please? > > > > > > Thanks, > > > Goetz. > > > > > > > > > > -----Original Message----- > > > > From: Doerr, Martin > > > > Sent: Tuesday, October 6, 2020 8:12 PM > > > > To: Lindenmaier, Goetz ; jdk-updates- > dev > > > > > > > > Subject: RE: [11u] RFR: 8171279: Support X25519 and X448 in TLS > > > > > > > > Hi G?tz, > > > > > > > > thanks for backporting this change. I think it's good to put it > > > > into 11.0.10, > > > > now, so we have enough testing time. > > > > Please find comments and questions inline. > > > > > > > > > > > > > file > > > > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java > > > > > Non-applying chunk fixes typo in a comment that is not in 11. > > > > > I copied the comment to 11. > > > > > > > > Good. > > > > > > > > > > > > > file > > > > > src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java > > > > > Deleting class DHEKAKeyDerivation failed because the code in 11 > > > > > uses > > > > > JsseJce.getKeyAgreement() > > > > > where the patch uses KeyAgreement.getInstance(). > > > > > > > > Right. > > > > > > > > > > > > > file > > > > > src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchang > > > > > e.java > > > > > 11 has different imports. > > > > > The remaining conflicts arise from different usages of > > > > > KeyFactory, ECUtil > > > > > > > > and > > > > > JsseJce. > > > > > > > > Good. > > > > > > > > > > > > > file > > > > > src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java > > > > > The conflicts arise from different usages of KeyAgreement and > > > > > JsseJce. > > > > > > > > Ok. > > > > > > > > > > > > > file > > > > > src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchang > > > > > e.java > > > > > Different imports. > > > > > The remaining conflicts arise from different usages of > > > > > KeyFactory, ECUtil > > > > > > > > and > > > > > JsseJce. > > > > > > > > Ok. > > > > > > > > > > > > > file > > > > > src/java.base/share/classes/sun/security/ssl/SSLExtension.java > > > > > Copyright > > > > > > > > > > file > > > > > > > > src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.j > > > > ava > > > > > Copyright > > > > > > > > We don't edit Copyright headers for backports. Ok. > > > > > > > > > > > > > file > > > > > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java > > > > > imports > > > > > > > > Ok. > > > > > > > > > > > > > file > > > > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtensi > > > > on.jav > > > > > a > > > > > Different imports. > > > > > > > > Ok. > > > > > > > > > Enums are moved to a file of their own: NamedGroup.java > > > > > Removing the enums does not apply because in 13 FIPS support was > > > > > removed. > > > > > > > > So you just deleted them manually. Fine. > > > > > > > > > Also, a name string was added. > > > > > > > > You mean "String name" in the code you removed? > > > > > > > > > The supported group types differ, too. > > > > > > > > That's expected. Did that cause manual integration? > > > > > > > > > In 11, the enums have a row of additional functionality that > > > > > I now removed, too. E.g., additional constructors, > > > > > isSupported(), > > > > > isECAvailable. > > > > > > > > That's in the code which is gone. That's fine. > > > > > > > > > Some further differences are again usages of ECUtil, JsseJce etc. > > > > > The original patch has more NamedGroups: "// Secondary NIST > > > > > curves" > > > > > > > > Ok. > > > > > > > > > file test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java > > > > > configureClientSocket() already in 11. We downported this with > > > > > a previous change. > > > > > > > > Ok. I can see this code is already there. > > > > > > > > > The NamedGroups enum is moved to a file of it's own. > > > > > Before this change, the named Groups knew about FIPS in 11. The > > > > > new > > > > > > > > ones > > > > > don't. > > > > > https://bugs.openjdk.java.net/browse/JDK-8217835 "Remove the > > > > > experimental SunJSSE FIPS compliant mode" > > > > > removed FIPS support in 13 before this change was implemented. > > > > > > > > > > As I understand 8217835, the experimental FIPS feature cannot be > > > > > used in > > > > > 11, it just remained in the code. So I skipped adapting > > > > > NamedGroups to the > > > > > old behaviour, I can not test it anyways. > > > > > What do you think, do we need to add this code to > > > > > NamedGroupd.java > > > > > again? > > > > > > > > Sounds like this is ok according to the CSR > > > > https://bugs.openjdk.java.net/browse/JDK-8217907 > > > > Since this file is new with this backport, I prefer keeping it like > > > > the original > > > > one for the backport. > > > > We could open a new bug in case anybody wants it back, but I guess > > > > that's > > > > not the case. > > > > > > > > There's still some Fips code there: > > > > (!requireFips || namedGroup.isFips)*/ ) { // GL fix isFips > > > > With a comment! > > > > What are you planning to do with it? > > > > > > > > > > > > > There are two follow ups, > > > > > 8224650: Add tests to support X25519 and X448 in TLS > > > > > 8243549: > > > > > sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java > > > > > failed with Unsupported signature algorithm: DSA > > > > > > > > > > I have downported these too, and will send RFR once this is > > > > > stable. > > > > > Existing and new test are all passing. > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8171279 > > > > > http://hg.openjdk.java.net/jdk/jdk/rev/946f7f2d321c > > > > > > > > Ok. That's an important point. > > > > There may be more to come, but that's all we currently have AFAICS. > > > > > > > > > > > > Best regards, > > > > Martin > > > > > > From rs at jelastic.com Mon Oct 12 08:02:27 2020 From: rs at jelastic.com (Ruslan Synytsky) Date: Mon, 12 Oct 2020 11:02:27 +0300 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> Message-ID: Dear Liang, thank you for the extra efforts on this improvement. Dear Andrew, I assume we need your approval / confirmation. Can you please take a look and let us know your feedback? Regards On Fri, 25 Sep 2020 at 09:42, Liang Mao wrote: > Hi Developers, > > > > I would like to refresh this backport too. As Ruslan's description, this > JEP provides > > a very convenient way to save significant memory for popular applications > like Jenkins. > > Alibaba's JDK11 already had this feature and used it in workloads like big > data > > engines for months. The effect of memory saving is impressive. > > > Alibaba keeps migrating our Java applications to JDK11 and G1. We will > surely maintain > > the quality of the feature as we continues to report/discuss issues of G1 > and > > backport G1 bug fixes. SAP and Microsoft are interested in this feature > during last > > discussion and willing to maintain it as well. The JEP only contains 4 > small to medium > > patches and 6 tiny to small fixes. With communitie's review(Oracle G1 team > agreed to > > help) and experienced JVM developers from several big companies and > testing on > > various workloads and scenarios, I believe the quality is definitely > controllable. > > > I have been managing thousands of Java applications/millions of Java > instances and > > helping them to upgrade JDK and GC including different types of worloads > like online > > services, big data platforms, batch jobs, etc. It's really painful for > owners of Java > > applications to upgrate their JDK version to a larger number, especially > for those big > > applications with a lot of 3rd party packages. Letting JDK11 LTS have > such small > > feature with significant effect would benifit most of users. > > > All changes of the JEP only contains of hunderds lines of code: > > http://cr.openjdk.java.net/~lmao/jep346.11u/all.webrev.00/ > > > Here are the 10 changesets needs backport and 3 of them have conflicts: > > 1) JDK-8071913 > > http://cr.openjdk.java.net/~lmao/jep346.11u/8071913.webrev.00/ > > 2) JDK-6490394 > > 3) JDK-8213898 > > 4) JDK-8212657 > > http://cr.openjdk.java.net/~lmao/jep346.11u/8212657.webrev.00/ > > 5) JDK-8215120 > > 6) JDK-8215149 > > 7) JDK-8215548 > > 8) JDK-8216490 > > 9) JDK-8218880 > > http://cr.openjdk.java.net/~lmao/jep346.11u/8218880.webrev.00/ > > 10) JDK-8212883 > > > Tested with tier1/fastdebug. > > > BTW, I will file an CSR for the new options added if maintainers agree. > > Any questions? > > > Thanks, > > Liang > > > > > -----Original Message----- > > > From: jdk-updates-dev [mailto:jdk-updates-dev-retn at openjdk.java.net] On > > > Behalf Of Ruslan Synytsky > > > Sent: 2020?8?7? 1:00 > > > To: jdk-updates-dev > > > Subject: Re: [11u] Backport JEP 346 : Promptly Return Unused Committed > > > Memory from G1 > > > > > > Hi All, I would like to refresh this topic by sharing a very simple > example that > > > demonstrates why Java looks broken without this improvement. > > > > > > Jenkins is one of the most popular CI/CD tools. Unfortunately it > supports only > > > Java 8 and Java 11 > > > . If you > start a > > > simple standalone Jenkins instance and *just sign in* inside the admin > panel then > > > the JVM will start consuming a significant amount of memory immediately. > In > > > my case I had the following limits: container limit > > > - 8G, heap limit (Xmx) - 6.5G and the memory consumption after the sign > in > > > action got to 3G. By default all Java runtimes lower than Java 12 within > Jelastic > > > are supplied with our Java agent (which is a workaround) that tracks > memory > > > usage and if this agent detects a significant waste it calls full GC. > After this full > > > GC call the memory consumption goes down to 0.5G (check the screenshot) > > > > > > usage/master/images/jenkins-memory-usage-diff.png > > >. > > > If we disable our agent then the memory usage at the idle JVM will stay > at 3G > > > forever which is a waste of resources > > > > > > usage/master/images/jenkins-memory-usage-waste.png > > >. > > > If you put additional load on Jenkins the picture will look even worse. > > > > > > Usually one large host node runs hundreds of containers, and one cloud > cluster > > > may consist of tens, hundreds or thousands of host nodes, so the issue > multiplies. > > > And the case with Jenkins is just one of the examples. > > > I'm pretty sure this inefficient memory usage issue was damaging the > Java brand > > > for many years and a lot of developers believe that Java is too heavy. > Is not it a > > > strong reason to bring the fix to Java 11? > > > > > > Thanks > > > -- > > > Ruslan Synytsky > > > CEO @ Jelastic Multi-Cloud PaaS > -- Ruslan Synytsky CEO @ Jelastic Multi-Cloud PaaS From aph at redhat.com Mon Oct 12 09:35:56 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 Oct 2020 10:35:56 +0100 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> Message-ID: On 12/10/2020 09:02, Ruslan Synytsky wrote: > Dear?Liang, thank you for the extra efforts on this improvement.? > > Dear?Andrew, I assume we need your approval / confirmation. Can you please take a look and let us know your feedback?? OK, I'll have a look and get some input from others. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Mon Oct 12 09:54:08 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 12 Oct 2020 09:54:08 +0000 Subject: [11u] Second opinion? RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: Message-ID: Hi G?tz, thanks for restoring the functionality. Your incremental change looks correct. > The larger comment a bit down states that FIPS is unusable in 11. I guess you would need a Java debugger / JVMTI agent to enable it with SunJSSE which is nothing we have to support ?? Note that FIPS 140 mode can be used by another provider which doesn't need your new code: https://github.com/elastic/elasticsearch/pull/48378 On the other hand, your new version reflects the status of JDK-8217835 correctly, which is not backported. So I'm fine with either version. Best regards, Martin > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 12. Oktober 2020 08:39 > To: Lindenmaier, Goetz ; 'Alvarez, David' > ; Doerr, Martin ; jdk- > updates-dev at openjdk.java.net > Subject: RE: [11u] Second opinion? RFR: 8171279: Support X25519 and X448 in > TLS > > Hi, > > I gave it a try: > http://cr.openjdk.java.net/~goetz/wr20/8171279-X25519_in_TLS-jdk11/02- > incremental/ > I think this incremental change restores the lost functionality. > It does not break any of the existing tests. But I didn't run > any tests for FIPS. > > On the other side, Matthias found this: > https://github.com/elastic/elasticsearch/issues/37250 > The larger comment a bit down states that FIPS is unusable in 11. > If so, I would prefer to skip the incremental change above. > > Full webrev: > http://cr.openjdk.java.net/~goetz/wr20/8171279-X25519_in_TLS-jdk11/02/ > > Best regards, > Goetz > > > > > > -----Original Message----- > > From: jdk-updates-dev On > Behalf > > Of Lindenmaier, Goetz > > Sent: Thursday, October 8, 2020 6:37 PM > > To: 'Alvarez, David' ; Doerr, Martin > > ; jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] RE: [11u] Second opinion? RFR: 8171279: Support > > X25519 and X448 in TLS > > > > Hi David, > > > > > I haven't tested the full FIPS functionality, > > That is the problem. I don't have appropriate tests, either. > > > > > but code like this: > > > import com.sun.net.ssl.internal.ssl.Provider; > > > > > > public class FipsProviderTest { > > > public static void main(String[] args) { > > > com.sun.net.ssl.internal.ssl.Provider p = new Provider( > > > "cryptoProvider"); > > > } > > > } > > > > > > > > > That makes use of that constructor will no longer work. > > > > Ok, I see how you can reach the FIPS functionality. > > But the example is obviously too small to touch > > the code I changed. > > It compiles fine, with and without the change. > > And it runs fine if I add SunJSSE as provider, for example. > > > > > I don't know > > > what is our statement regarding the usage of --add-exports, are we ok > > > breaking solutions that make use of it? If we are, is it only when we > > > have no other option or will be one situation like this one acceptable? > > Yes, I would prefer to not change the behavior even for > > things not explicitly exposed. > > > > Best regards, > > Goetz. > > > > > > > > Thanks, > > > David > > > > > > > > > On Wed, 2020-10-07 at 07:50 +0000, Lindenmaier, Goetz wrote: > > > > CAUTION: This email originated from outside of the organization. Do > > > > not click links or open attachments unless you can confirm the sender > > > > and know the content is safe. > > > > > > > > > > > > > > > > Hi, > > > > > > > > I would like to get a second opinion on how to deal > > > > with the lost FIPS coding in this downport. > > > > Could someone from outside SAP have a look please? > > > > > > > > Thanks, > > > > Goetz. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Doerr, Martin > > > > > Sent: Tuesday, October 6, 2020 8:12 PM > > > > > To: Lindenmaier, Goetz ; jdk-updates- > > dev > > > > > > > > > > Subject: RE: [11u] RFR: 8171279: Support X25519 and X448 in TLS > > > > > > > > > > Hi G?tz, > > > > > > > > > > thanks for backporting this change. I think it's good to put it > > > > > into 11.0.10, > > > > > now, so we have enough testing time. > > > > > Please find comments and questions inline. > > > > > > > > > > > > > > > > file > > > > > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java > > > > > > Non-applying chunk fixes typo in a comment that is not in 11. > > > > > > I copied the comment to 11. > > > > > > > > > > Good. > > > > > > > > > > > > > > > > file > > > > > > src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java > > > > > > Deleting class DHEKAKeyDerivation failed because the code in 11 > > > > > > uses > > > > > > JsseJce.getKeyAgreement() > > > > > > where the patch uses KeyAgreement.getInstance(). > > > > > > > > > > Right. > > > > > > > > > > > > > > > > file > > > > > > > src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchang > > > > > > e.java > > > > > > 11 has different imports. > > > > > > The remaining conflicts arise from different usages of > > > > > > KeyFactory, ECUtil > > > > > > > > > > and > > > > > > JsseJce. > > > > > > > > > > Good. > > > > > > > > > > > > > > > > file > > > > > > > src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java > > > > > > The conflicts arise from different usages of KeyAgreement and > > > > > > JsseJce. > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > file > > > > > > > src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchang > > > > > > e.java > > > > > > Different imports. > > > > > > The remaining conflicts arise from different usages of > > > > > > KeyFactory, ECUtil > > > > > > > > > > and > > > > > > JsseJce. > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > file > > > > > > src/java.base/share/classes/sun/security/ssl/SSLExtension.java > > > > > > Copyright > > > > > > > > > > > > file > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.j > > > > > ava > > > > > > Copyright > > > > > > > > > > We don't edit Copyright headers for backports. Ok. > > > > > > > > > > > > > > > > file > > > > > > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java > > > > > > imports > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > file > > > > > > > > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtensi > > > > > on.jav > > > > > > a > > > > > > Different imports. > > > > > > > > > > Ok. > > > > > > > > > > > Enums are moved to a file of their own: NamedGroup.java > > > > > > Removing the enums does not apply because in 13 FIPS support was > > > > > > removed. > > > > > > > > > > So you just deleted them manually. Fine. > > > > > > > > > > > Also, a name string was added. > > > > > > > > > > You mean "String name" in the code you removed? > > > > > > > > > > > The supported group types differ, too. > > > > > > > > > > That's expected. Did that cause manual integration? > > > > > > > > > > > In 11, the enums have a row of additional functionality that > > > > > > I now removed, too. E.g., additional constructors, > > > > > > isSupported(), > > > > > > isECAvailable. > > > > > > > > > > That's in the code which is gone. That's fine. > > > > > > > > > > > Some further differences are again usages of ECUtil, JsseJce etc. > > > > > > The original patch has more NamedGroups: "// Secondary NIST > > > > > > curves" > > > > > > > > > > Ok. > > > > > > > > > > > file test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java > > > > > > configureClientSocket() already in 11. We downported this with > > > > > > a previous change. > > > > > > > > > > Ok. I can see this code is already there. > > > > > > > > > > > The NamedGroups enum is moved to a file of it's own. > > > > > > Before this change, the named Groups knew about FIPS in 11. The > > > > > > new > > > > > > > > > > ones > > > > > > don't. > > > > > > https://bugs.openjdk.java.net/browse/JDK-8217835 "Remove the > > > > > > experimental SunJSSE FIPS compliant mode" > > > > > > removed FIPS support in 13 before this change was implemented. > > > > > > > > > > > > As I understand 8217835, the experimental FIPS feature cannot be > > > > > > used in > > > > > > 11, it just remained in the code. So I skipped adapting > > > > > > NamedGroups to the > > > > > > old behaviour, I can not test it anyways. > > > > > > What do you think, do we need to add this code to > > > > > > NamedGroupd.java > > > > > > again? > > > > > > > > > > Sounds like this is ok according to the CSR > > > > > https://bugs.openjdk.java.net/browse/JDK-8217907 > > > > > Since this file is new with this backport, I prefer keeping it like > > > > > the original > > > > > one for the backport. > > > > > We could open a new bug in case anybody wants it back, but I guess > > > > > that's > > > > > not the case. > > > > > > > > > > There's still some Fips code there: > > > > > (!requireFips || namedGroup.isFips)*/ ) { // GL fix isFips > > > > > With a comment! > > > > > What are you planning to do with it? > > > > > > > > > > > > > > > > There are two follow ups, > > > > > > 8224650: Add tests to support X25519 and X448 in TLS > > > > > > 8243549: > > > > > > sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java > > > > > > failed with Unsupported signature algorithm: DSA > > > > > > > > > > > > I have downported these too, and will send RFR once this is > > > > > > stable. > > > > > > Existing and new test are all passing. > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8171279 > > > > > > http://hg.openjdk.java.net/jdk/jdk/rev/946f7f2d321c > > > > > > > > > > Ok. That's an important point. > > > > > There may be more to come, but that's all we currently have AFAICS. > > > > > > > > > > > > > > > Best regards, > > > > > Martin > > > > > > > > From sgehwolf at redhat.com Mon Oct 12 10:24:00 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 12 Oct 2020 12:24:00 +0200 Subject: [11u] Second opinion? RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: Message-ID: <16555fcf94e4150aa3de4ebadcc391e530434fcb.camel@redhat.com> Hi G?tz, On Mon, 2020-10-12 at 06:39 +0000, Lindenmaier, Goetz wrote: > Hi, > > I gave it a try: > http://cr.openjdk.java.net/~goetz/wr20/8171279-X25519_in_TLS-jdk11/02-incremental/ > I think this incremental change restores the lost functionality. > It does not break any of the existing tests. But I didn't run > any tests for FIPS. > > On the other side, Matthias found this: > https://github.com/elastic/elasticsearch/issues/37250 > The larger comment a bit down states that FIPS is unusable in 11. > If so, I would prefer to skip the incremental change above. > > Full webrev: > http://cr.openjdk.java.net/~goetz/wr20/8171279-X25519_in_TLS-jdk11/02/ Adding Martin Balao who has done some FIPS work. He mentioned that he'll be looking at this after the 11.0.9 release is done. So if you would be OK with waiting a bit before getting this integrated we'd appreciate it. It's still early in the 11.0.10 cycle. Thoughts? Thanks, Severin > Best regards, > Goetz > > > > > > -----Original Message----- > > From: jdk-updates-dev On Behalf > > Of Lindenmaier, Goetz > > Sent: Thursday, October 8, 2020 6:37 PM > > To: 'Alvarez, David' ; Doerr, Martin > > ; jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] RE: [11u] Second opinion? RFR: 8171279: Support > > X25519 and X448 in TLS > > > > Hi David, > > > > > I haven't tested the full FIPS functionality, > > That is the problem. I don't have appropriate tests, either. > > > > > but code like this: > > > import com.sun.net.ssl.internal.ssl.Provider; > > > > > > public class FipsProviderTest { > > > public static void main(String[] args) { > > > com.sun.net.ssl.internal.ssl.Provider p = new Provider( > > > "cryptoProvider"); > > > } > > > } > > > > > > > > > That makes use of that constructor will no longer work. > > > > Ok, I see how you can reach the FIPS functionality. > > But the example is obviously too small to touch > > the code I changed. > > It compiles fine, with and without the change. > > And it runs fine if I add SunJSSE as provider, for example. > > > > > I don't know > > > what is our statement regarding the usage of --add-exports, are we ok > > > breaking solutions that make use of it? If we are, is it only when we > > > have no other option or will be one situation like this one acceptable? > > Yes, I would prefer to not change the behavior even for > > things not explicitly exposed. > > > > Best regards, > > Goetz. > > > > > Thanks, > > > David > > > > > > > > > On Wed, 2020-10-07 at 07:50 +0000, Lindenmaier, Goetz wrote: > > > > CAUTION: This email originated from outside of the organization. Do > > > > not click links or open attachments unless you can confirm the sender > > > > and know the content is safe. > > > > > > > > > > > > > > > > Hi, > > > > > > > > I would like to get a second opinion on how to deal > > > > with the lost FIPS coding in this downport. > > > > Could someone from outside SAP have a look please? > > > > > > > > Thanks, > > > > Goetz. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Doerr, Martin > > > > > Sent: Tuesday, October 6, 2020 8:12 PM > > > > > To: Lindenmaier, Goetz ; jdk-updates- > > dev > > > > > > > > > > Subject: RE: [11u] RFR: 8171279: Support X25519 and X448 in TLS > > > > > > > > > > Hi G?tz, > > > > > > > > > > thanks for backporting this change. I think it's good to put it > > > > > into 11.0.10, > > > > > now, so we have enough testing time. > > > > > Please find comments and questions inline. > > > > > > > > > > > > > > > > file > > > > > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java > > > > > > Non-applying chunk fixes typo in a comment that is not in 11. > > > > > > I copied the comment to 11. > > > > > > > > > > Good. > > > > > > > > > > > > > > > > file > > > > > > src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java > > > > > > Deleting class DHEKAKeyDerivation failed because the code in 11 > > > > > > uses > > > > > > JsseJce.getKeyAgreement() > > > > > > where the patch uses KeyAgreement.getInstance(). > > > > > > > > > > Right. > > > > > > > > > > > > > > > > file > > > > > > src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchang > > > > > > e.java > > > > > > 11 has different imports. > > > > > > The remaining conflicts arise from different usages of > > > > > > KeyFactory, ECUtil > > > > > > > > > > and > > > > > > JsseJce. > > > > > > > > > > Good. > > > > > > > > > > > > > > > > file > > > > > > src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java > > > > > > The conflicts arise from different usages of KeyAgreement and > > > > > > JsseJce. > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > file > > > > > > src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchang > > > > > > e.java > > > > > > Different imports. > > > > > > The remaining conflicts arise from different usages of > > > > > > KeyFactory, ECUtil > > > > > > > > > > and > > > > > > JsseJce. > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > file > > > > > > src/java.base/share/classes/sun/security/ssl/SSLExtension.java > > > > > > Copyright > > > > > > > > > > > > file > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.j > > > > > ava > > > > > > Copyright > > > > > > > > > > We don't edit Copyright headers for backports. Ok. > > > > > > > > > > > > > > > > file > > > > > > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java > > > > > > imports > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > file > > > > > > > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtensi > > > > > on.jav > > > > > > a > > > > > > Different imports. > > > > > > > > > > Ok. > > > > > > > > > > > Enums are moved to a file of their own: NamedGroup.java > > > > > > Removing the enums does not apply because in 13 FIPS support was > > > > > > removed. > > > > > > > > > > So you just deleted them manually. Fine. > > > > > > > > > > > Also, a name string was added. > > > > > > > > > > You mean "String name" in the code you removed? > > > > > > > > > > > The supported group types differ, too. > > > > > > > > > > That's expected. Did that cause manual integration? > > > > > > > > > > > In 11, the enums have a row of additional functionality that > > > > > > I now removed, too. E.g., additional constructors, > > > > > > isSupported(), > > > > > > isECAvailable. > > > > > > > > > > That's in the code which is gone. That's fine. > > > > > > > > > > > Some further differences are again usages of ECUtil, JsseJce etc. > > > > > > The original patch has more NamedGroups: "// Secondary NIST > > > > > > curves" > > > > > > > > > > Ok. > > > > > > > > > > > file test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java > > > > > > configureClientSocket() already in 11. We downported this with > > > > > > a previous change. > > > > > > > > > > Ok. I can see this code is already there. > > > > > > > > > > > The NamedGroups enum is moved to a file of it's own. > > > > > > Before this change, the named Groups knew about FIPS in 11. The > > > > > > new > > > > > > > > > > ones > > > > > > don't. > > > > > > https://bugs.openjdk.java.net/browse/JDK-8217835 "Remove the > > > > > > experimental SunJSSE FIPS compliant mode" > > > > > > removed FIPS support in 13 before this change was implemented. > > > > > > > > > > > > As I understand 8217835, the experimental FIPS feature cannot be > > > > > > used in > > > > > > 11, it just remained in the code. So I skipped adapting > > > > > > NamedGroups to the > > > > > > old behaviour, I can not test it anyways. > > > > > > What do you think, do we need to add this code to > > > > > > NamedGroupd.java > > > > > > again? > > > > > > > > > > Sounds like this is ok according to the CSR > > > > > https://bugs.openjdk.java.net/browse/JDK-8217907 > > > > > Since this file is new with this backport, I prefer keeping it like > > > > > the original > > > > > one for the backport. > > > > > We could open a new bug in case anybody wants it back, but I guess > > > > > that's > > > > > not the case. > > > > > > > > > > There's still some Fips code there: > > > > > (!requireFips || namedGroup.isFips)*/ ) { // GL fix isFips > > > > > With a comment! > > > > > What are you planning to do with it? > > > > > > > > > > > > > > > > There are two follow ups, > > > > > > 8224650: Add tests to support X25519 and X448 in TLS > > > > > > 8243549: > > > > > > sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java > > > > > > failed with Unsupported signature algorithm: DSA > > > > > > > > > > > > I have downported these too, and will send RFR once this is > > > > > > stable. > > > > > > Existing and new test are all passing. > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8171279 > > > > > > http://hg.openjdk.java.net/jdk/jdk/rev/946f7f2d321c > > > > > > > > > > Ok. That's an important point. > > > > > There may be more to come, but that's all we currently have AFAICS. > > > > > > > > > > > > > > > Best regards, > > > > > Martin From shade at redhat.com Mon Oct 12 11:08:43 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 12 Oct 2020 13:08:43 +0200 Subject: [15u] RFR 8254166: Zero: return-type warning in zeroInterpreter_zero.cpp Message-ID: <81f7e09d-ad49-9415-5e77-38f289972d92@redhat.com> Original fix; https://bugs.openjdk.java.net/browse/JDK-8254166 https://git.openjdk.java.net/jdk/commit/7952c06b cppInterpreter_zero.cpp was renamed to zeroInterpreter_zero.cpp by JDK-8239782. So, 15u patch is: diff -r 7b781c30206d src/hotspot/cpu/zero/cppInterpreter_zero.cpp --- a/src/hotspot/cpu/zero/cppInterpreter_zero.cpp Thu Oct 08 09:33:42 2020 +0000 +++ b/src/hotspot/cpu/zero/cppInterpreter_zero.cpp Mon Oct 12 09:20:58 2020 +0200 @@ -99,7 +99,9 @@ case T_DOUBLE: case T_VOID: return result; - default : ShouldNotReachHere(); + default: + ShouldNotReachHere(); + return result; // silence compiler warnings } } (I am going to use this later for backports to 11u and 8u). Testing: tier{1,2}, Linux x86_64 Zero bootcycle-images -- Thanks, -Aleksey From goetz.lindenmaier at sap.com Mon Oct 12 11:24:25 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 12 Oct 2020 11:24:25 +0000 Subject: [11u] Second opinion? RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: <16555fcf94e4150aa3de4ebadcc391e530434fcb.camel@redhat.com> References: <16555fcf94e4150aa3de4ebadcc391e530434fcb.camel@redhat.com> Message-ID: Hi Severin, Martin, That's fine, there is no hurry! Any input is appreciated. Best regards, Goetz. > -----Original Message----- > From: Severin Gehwolf > Sent: Monday, October 12, 2020 12:24 PM > To: Lindenmaier, Goetz ; 'Alvarez, David' > ; Doerr, Martin ; jdk- > updates-dev at openjdk.java.net > Cc: Martin Balao Alonso > Subject: Re: [11u] Second opinion? RFR: 8171279: Support X25519 and X448 > in TLS > > Hi G?tz, > > On Mon, 2020-10-12 at 06:39 +0000, Lindenmaier, Goetz wrote: > > Hi, > > > > I gave it a try: > > http://cr.openjdk.java.net/~goetz/wr20/8171279-X25519_in_TLS- > jdk11/02-incremental/ > > I think this incremental change restores the lost functionality. > > It does not break any of the existing tests. But I didn't run > > any tests for FIPS. > > > > On the other side, Matthias found this: > > https://github.com/elastic/elasticsearch/issues/37250 > > The larger comment a bit down states that FIPS is unusable in 11. > > If so, I would prefer to skip the incremental change above. > > > > Full webrev: > > http://cr.openjdk.java.net/~goetz/wr20/8171279-X25519_in_TLS- > jdk11/02/ > > Adding Martin Balao who has done some FIPS work. He mentioned that > he'll be looking at this after the 11.0.9 release is done. So if you > would be OK with waiting a bit before getting this integrated we'd > appreciate it. It's still early in the 11.0.10 cycle. Thoughts? > > Thanks, > Severin > > > Best regards, > > Goetz > > > > > > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > Behalf > > > Of Lindenmaier, Goetz > > > Sent: Thursday, October 8, 2020 6:37 PM > > > To: 'Alvarez, David' ; Doerr, Martin > > > ; jdk-updates-dev at openjdk.java.net > > > Subject: [CAUTION] RE: [11u] Second opinion? RFR: 8171279: Support > > > X25519 and X448 in TLS > > > > > > Hi David, > > > > > > > I haven't tested the full FIPS functionality, > > > That is the problem. I don't have appropriate tests, either. > > > > > > > but code like this: > > > > import com.sun.net.ssl.internal.ssl.Provider; > > > > > > > > public class FipsProviderTest { > > > > public static void main(String[] args) { > > > > com.sun.net.ssl.internal.ssl.Provider p = new Provider( > > > > "cryptoProvider"); > > > > } > > > > } > > > > > > > > > > > > That makes use of that constructor will no longer work. > > > > > > Ok, I see how you can reach the FIPS functionality. > > > But the example is obviously too small to touch > > > the code I changed. > > > It compiles fine, with and without the change. > > > And it runs fine if I add SunJSSE as provider, for example. > > > > > > > I don't know > > > > what is our statement regarding the usage of --add-exports, are we ok > > > > breaking solutions that make use of it? If we are, is it only when we > > > > have no other option or will be one situation like this one acceptable? > > > Yes, I would prefer to not change the behavior even for > > > things not explicitly exposed. > > > > > > Best regards, > > > Goetz. > > > > > > > Thanks, > > > > David > > > > > > > > > > > > On Wed, 2020-10-07 at 07:50 +0000, Lindenmaier, Goetz wrote: > > > > > CAUTION: This email originated from outside of the organization. Do > > > > > not click links or open attachments unless you can confirm the sender > > > > > and know the content is safe. > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I would like to get a second opinion on how to deal > > > > > with the lost FIPS coding in this downport. > > > > > Could someone from outside SAP have a look please? > > > > > > > > > > Thanks, > > > > > Goetz. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Doerr, Martin > > > > > > Sent: Tuesday, October 6, 2020 8:12 PM > > > > > > To: Lindenmaier, Goetz ; jdk- > updates- > > > dev > > > > > > > > > > > > Subject: RE: [11u] RFR: 8171279: Support X25519 and X448 in TLS > > > > > > > > > > > > Hi G?tz, > > > > > > > > > > > > thanks for backporting this change. I think it's good to put it > > > > > > into 11.0.10, > > > > > > now, so we have enough testing time. > > > > > > Please find comments and questions inline. > > > > > > > > > > > > > > > > > > > file > > > > > > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java > > > > > > > Non-applying chunk fixes typo in a comment that is not in 11. > > > > > > > I copied the comment to 11. > > > > > > > > > > > > Good. > > > > > > > > > > > > > > > > > > > file > > > > > > > src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java > > > > > > > Deleting class DHEKAKeyDerivation failed because the code in 11 > > > > > > > uses > > > > > > > JsseJce.getKeyAgreement() > > > > > > > where the patch uses KeyAgreement.getInstance(). > > > > > > > > > > > > Right. > > > > > > > > > > > > > > > > > > > file > > > > > > > > src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchang > > > > > > > e.java > > > > > > > 11 has different imports. > > > > > > > The remaining conflicts arise from different usages of > > > > > > > KeyFactory, ECUtil > > > > > > > > > > > > and > > > > > > > JsseJce. > > > > > > > > > > > > Good. > > > > > > > > > > > > > > > > > > > file > > > > > > > > src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java > > > > > > > The conflicts arise from different usages of KeyAgreement and > > > > > > > JsseJce. > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > file > > > > > > > > src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchang > > > > > > > e.java > > > > > > > Different imports. > > > > > > > The remaining conflicts arise from different usages of > > > > > > > KeyFactory, ECUtil > > > > > > > > > > > > and > > > > > > > JsseJce. > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > file > > > > > > > src/java.base/share/classes/sun/security/ssl/SSLExtension.java > > > > > > > Copyright > > > > > > > > > > > > > > file > > > > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.j > > > > > > ava > > > > > > > Copyright > > > > > > > > > > > > We don't edit Copyright headers for backports. Ok. > > > > > > > > > > > > > > > > > > > file > > > > > > > > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java > > > > > > > imports > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > file > > > > > > > > > > > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtensi > > > > > > on.jav > > > > > > > a > > > > > > > Different imports. > > > > > > > > > > > > Ok. > > > > > > > > > > > > > Enums are moved to a file of their own: NamedGroup.java > > > > > > > Removing the enums does not apply because in 13 FIPS support > was > > > > > > > removed. > > > > > > > > > > > > So you just deleted them manually. Fine. > > > > > > > > > > > > > Also, a name string was added. > > > > > > > > > > > > You mean "String name" in the code you removed? > > > > > > > > > > > > > The supported group types differ, too. > > > > > > > > > > > > That's expected. Did that cause manual integration? > > > > > > > > > > > > > In 11, the enums have a row of additional functionality that > > > > > > > I now removed, too. E.g., additional constructors, > > > > > > > isSupported(), > > > > > > > isECAvailable. > > > > > > > > > > > > That's in the code which is gone. That's fine. > > > > > > > > > > > > > Some further differences are again usages of ECUtil, JsseJce etc. > > > > > > > The original patch has more NamedGroups: "// Secondary NIST > > > > > > > curves" > > > > > > > > > > > > Ok. > > > > > > > > > > > > > file test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java > > > > > > > configureClientSocket() already in 11. We downported this with > > > > > > > a previous change. > > > > > > > > > > > > Ok. I can see this code is already there. > > > > > > > > > > > > > The NamedGroups enum is moved to a file of it's own. > > > > > > > Before this change, the named Groups knew about FIPS in 11. The > > > > > > > new > > > > > > > > > > > > ones > > > > > > > don't. > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8217835 "Remove the > > > > > > > experimental SunJSSE FIPS compliant mode" > > > > > > > removed FIPS support in 13 before this change was implemented. > > > > > > > > > > > > > > As I understand 8217835, the experimental FIPS feature cannot be > > > > > > > used in > > > > > > > 11, it just remained in the code. So I skipped adapting > > > > > > > NamedGroups to the > > > > > > > old behaviour, I can not test it anyways. > > > > > > > What do you think, do we need to add this code to > > > > > > > NamedGroupd.java > > > > > > > again? > > > > > > > > > > > > Sounds like this is ok according to the CSR > > > > > > https://bugs.openjdk.java.net/browse/JDK-8217907 > > > > > > Since this file is new with this backport, I prefer keeping it like > > > > > > the original > > > > > > one for the backport. > > > > > > We could open a new bug in case anybody wants it back, but I guess > > > > > > that's > > > > > > not the case. > > > > > > > > > > > > There's still some Fips code there: > > > > > > (!requireFips || namedGroup.isFips)*/ ) { // GL fix isFips > > > > > > With a comment! > > > > > > What are you planning to do with it? > > > > > > > > > > > > > > > > > > > There are two follow ups, > > > > > > > 8224650: Add tests to support X25519 and X448 in TLS > > > > > > > 8243549: > > > > > > > sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java > > > > > > > failed with Unsupported signature algorithm: DSA > > > > > > > > > > > > > > I have downported these too, and will send RFR once this is > > > > > > > stable. > > > > > > > Existing and new test are all passing. > > > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8171279 > > > > > > > http://hg.openjdk.java.net/jdk/jdk/rev/946f7f2d321c > > > > > > > > > > > > Ok. That's an important point. > > > > > > There may be more to come, but that's all we currently have AFAICS. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > Martin From tobias.hartmann at oracle.com Mon Oct 12 12:29:11 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 12 Oct 2020 14:29:11 +0200 Subject: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11 In-Reply-To: <549edaa3-7183-2368-c1e4-13f10fd62344@oracle.com> References: <549edaa3-7183-2368-c1e4-13f10fd62344@oracle.com> Message-ID: <7023cdcd-0fa6-e470-46c4-13d5fe3e230c@oracle.com> Hi Nils, looks good to me. Best regards, Tobias On 09.10.20 16:34, Nils Eliasson wrote: > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8254185 > Webrev: http://cr.openjdk.java.net/~neliasso/8254185/webrev.01/ > > This fix is a replacement for JDK-8244660 that I consider to risky to back port. > > This issue can't be seen unless JDK-8254185 is applied. That bug causes the sweeper to trigger on > every code cache allocation. When JDK-8254185 is applied then no sweeps can be observed at all. > > The main issue is that the sweeper thread is never woken. And if it isn't woken, it can't check the > counters to see if it is time to sweep. > > This fix include two changes: > > 1) Notifying waiters on the codecache_lock when a threshold for reclaimed nmethods has been reached. > This fix is enough on its own. > > In JDK 15 I introduced a new lock for the sweeper because a adding a notify in > NMethodSweeper::possibly_enable_sweeper conflicted with the compiledMethod_lock in add_osr_method. > That lock was added when deoptimization was converted to using handshakes. So in 11 it is still ok > to use the codecache_lock. > > 2) Moving the updates of _total_nof_code_cache_sweeps and _last_sweep inside block that is only run > when doing a sweep. > This change just makes the counters update as expected. _last_sweep is used to trigger sweeps after > a number of safepoints. This is counted by _time_counter. But since updates of _time_counter doesn't > wake the sweeper - it still doesn't work. > > In JDK 15 I removed all of this code since we can't even rely on safepoints happening at all. I > don't want to introduce any bugs in JDK 11 by mistake - so I am leaving it as it is. > > Please review. > > Best regards, > Nils Eliasson > From sgehwolf at redhat.com Mon Oct 12 15:15:43 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 12 Oct 2020 17:15:43 +0200 Subject: [15u] RFR 8254166: Zero: return-type warning in zeroInterpreter_zero.cpp In-Reply-To: <81f7e09d-ad49-9415-5e77-38f289972d92@redhat.com> References: <81f7e09d-ad49-9415-5e77-38f289972d92@redhat.com> Message-ID: On Mon, 2020-10-12 at 13:08 +0200, Aleksey Shipilev wrote: > Original fix; > https://bugs.openjdk.java.net/browse/JDK-8254166 > https://git.openjdk.java.net/jdk/commit/7952c06b > > cppInterpreter_zero.cpp was renamed to zeroInterpreter_zero.cpp by JDK-8239782. > > So, 15u patch is: > > diff -r 7b781c30206d src/hotspot/cpu/zero/cppInterpreter_zero.cpp > --- a/src/hotspot/cpu/zero/cppInterpreter_zero.cpp Thu Oct 08 09:33:42 2020 +0000 > +++ b/src/hotspot/cpu/zero/cppInterpreter_zero.cpp Mon Oct 12 09:20:58 2020 +0200 > @@ -99,7 +99,9 @@ > case T_DOUBLE: > case T_VOID: > return result; > - default : ShouldNotReachHere(); > + default: > + ShouldNotReachHere(); > + return result; // silence compiler warnings > } > } > > (I am going to use this later for backports to 11u and 8u). > > Testing: tier{1,2}, Linux x86_64 Zero bootcycle-images Zero only change. Looks fine to me. Thanks, Severin From shade at redhat.com Mon Oct 12 16:38:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 12 Oct 2020 18:38:06 +0200 Subject: [15u] RFR 8254166: Zero: return-type warning in zeroInterpreter_zero.cpp In-Reply-To: References: <81f7e09d-ad49-9415-5e77-38f289972d92@redhat.com> Message-ID: <2633d73e-4d7d-bfb4-e02a-87b06f5bf45a@redhat.com> On 10/12/20 5:15 PM, Severin Gehwolf wrote: > On Mon, 2020-10-12 at 13:08 +0200, Aleksey Shipilev wrote: >> Original fix; >> https://bugs.openjdk.java.net/browse/JDK-8254166 >> https://git.openjdk.java.net/jdk/commit/7952c06b >> >> cppInterpreter_zero.cpp was renamed to zeroInterpreter_zero.cpp by JDK-8239782. >> >> So, 15u patch is: >> >> diff -r 7b781c30206d src/hotspot/cpu/zero/cppInterpreter_zero.cpp >> --- a/src/hotspot/cpu/zero/cppInterpreter_zero.cpp Thu Oct 08 09:33:42 2020 +0000 >> +++ b/src/hotspot/cpu/zero/cppInterpreter_zero.cpp Mon Oct 12 09:20:58 2020 +0200 >> @@ -99,7 +99,9 @@ >> case T_DOUBLE: >> case T_VOID: >> return result; >> - default : ShouldNotReachHere(); >> + default: >> + ShouldNotReachHere(); >> + return result; // silence compiler warnings >> } >> } >> >> (I am going to use this later for backports to 11u and 8u). >> >> Testing: tier{1,2}, Linux x86_64 Zero bootcycle-images > > Zero only change. Looks fine to me. Thanks, tagged. -- -Aleksey From nils.eliasson at oracle.com Mon Oct 12 18:32:34 2020 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 12 Oct 2020 20:32:34 +0200 Subject: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11 In-Reply-To: <7023cdcd-0fa6-e470-46c4-13d5fe3e230c@oracle.com> References: <549edaa3-7183-2368-c1e4-13f10fd62344@oracle.com> <7023cdcd-0fa6-e470-46c4-13d5fe3e230c@oracle.com> Message-ID: <617c456e-7cfe-d44d-b8b8-243dde7c957a@oracle.com> Thank you Tobias! // Nils On 2020-10-12 14:29, Tobias Hartmann wrote: > Hi Nils, > > looks good to me. > > Best regards, > Tobias > > On 09.10.20 16:34, Nils Eliasson wrote: >> Hi, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8254185 >> Webrev: http://cr.openjdk.java.net/~neliasso/8254185/webrev.01/ >> >> This fix is a replacement for JDK-8244660 that I consider to risky to >> back port. >> >> This issue can't be seen unless JDK-8254185 is applied. That bug >> causes the sweeper to trigger on every code cache allocation. When >> JDK-8254185 is applied then no sweeps can be observed at all. >> >> The main issue is that the sweeper thread is never woken. And if it >> isn't woken, it can't check the counters to see if it is time to sweep. >> >> This fix include two changes: >> >> 1) Notifying waiters on the codecache_lock when a threshold for >> reclaimed nmethods has been reached. This fix is enough on its own. >> >> In JDK 15 I introduced a new lock for the sweeper because a adding a >> notify in NMethodSweeper::possibly_enable_sweeper conflicted with the >> compiledMethod_lock in add_osr_method. That lock was added when >> deoptimization was converted to using handshakes. So in 11 it is >> still ok to use the codecache_lock. >> >> 2) Moving the updates of _total_nof_code_cache_sweeps and _last_sweep >> inside block that is only run when doing a sweep. >> This change just makes the counters update as expected. _last_sweep >> is used to trigger sweeps after a number of safepoints. This is >> counted by _time_counter. But since updates of _time_counter doesn't >> wake the sweeper - it still doesn't work. >> >> In JDK 15 I removed all of this code since we can't even rely on >> safepoints happening at all. I don't want to introduce any bugs in >> JDK 11 by mistake - so I am leaving it as it is. >> >> Please review. >> >> Best regards, >> Nils Eliasson >> From vladimir.kozlov at oracle.com Mon Oct 12 18:36:04 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Oct 2020 11:36:04 -0700 Subject: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11 In-Reply-To: <7023cdcd-0fa6-e470-46c4-13d5fe3e230c@oracle.com> References: <549edaa3-7183-2368-c1e4-13f10fd62344@oracle.com> <7023cdcd-0fa6-e470-46c4-13d5fe3e230c@oracle.com> Message-ID: <20aaa41c-7220-c62a-9e96-ae7cfb7aa2e4@oracle.com> +1 Thanks, Vladimir K On 10/12/20 5:29 AM, Tobias Hartmann wrote: > Hi Nils, > > looks good to me. > > Best regards, > Tobias > > On 09.10.20 16:34, Nils Eliasson wrote: >> Hi, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8254185 >> Webrev: http://cr.openjdk.java.net/~neliasso/8254185/webrev.01/ >> >> This fix is a replacement for JDK-8244660 that I consider to risky to back port. >> >> This issue can't be seen unless JDK-8254185 is applied. That bug causes the sweeper to trigger on every code cache >> allocation. When JDK-8254185 is applied then no sweeps can be observed at all. >> >> The main issue is that the sweeper thread is never woken. And if it isn't woken, it can't check the counters to see if >> it is time to sweep. >> >> This fix include two changes: >> >> 1) Notifying waiters on the codecache_lock when a threshold for reclaimed nmethods has been reached. This fix is >> enough on its own. >> >> In JDK 15 I introduced a new lock for the sweeper because a adding a notify in NMethodSweeper::possibly_enable_sweeper >> conflicted with the compiledMethod_lock in add_osr_method. That lock was added when deoptimization was converted to >> using handshakes. So in 11 it is still ok to use the codecache_lock. >> >> 2) Moving the updates of _total_nof_code_cache_sweeps and _last_sweep inside block that is only run when doing a sweep. >> This change just makes the counters update as expected. _last_sweep is used to trigger sweeps after a number of >> safepoints. This is counted by _time_counter. But since updates of _time_counter doesn't wake the sweeper - it still >> doesn't work. >> >> In JDK 15 I removed all of this code since we can't even rely on safepoints happening at all. I don't want to >> introduce any bugs in JDK 11 by mistake - so I am leaving it as it is. >> >> Please review. >> >> Best regards, >> Nils Eliasson >> From nils.eliasson at oracle.com Mon Oct 12 19:38:57 2020 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 12 Oct 2020 21:38:57 +0200 Subject: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11 In-Reply-To: <20aaa41c-7220-c62a-9e96-ae7cfb7aa2e4@oracle.com> References: <549edaa3-7183-2368-c1e4-13f10fd62344@oracle.com> <7023cdcd-0fa6-e470-46c4-13d5fe3e230c@oracle.com> <20aaa41c-7220-c62a-9e96-ae7cfb7aa2e4@oracle.com> Message-ID: <5676019f-582d-cac2-d1b1-1590506f1853@oracle.com> Thank you Vladimir! // Nils On 2020-10-12 20:36, Vladimir Kozlov wrote: > +1 > > Thanks, > Vladimir K > > On 10/12/20 5:29 AM, Tobias Hartmann wrote: >> Hi Nils, >> >> looks good to me. >> >> Best regards, >> Tobias >> >> On 09.10.20 16:34, Nils Eliasson wrote: >>> Hi, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8254185 >>> Webrev: http://cr.openjdk.java.net/~neliasso/8254185/webrev.01/ >>> >>> This fix is a replacement for JDK-8244660 that I consider to risky >>> to back port. >>> >>> This issue can't be seen unless JDK-8254185 is applied. That bug >>> causes the sweeper to trigger on every code cache allocation. When >>> JDK-8254185 is applied then no sweeps can be observed at all. >>> >>> The main issue is that the sweeper thread is never woken. And if it >>> isn't woken, it can't check the counters to see if it is time to sweep. >>> >>> This fix include two changes: >>> >>> 1) Notifying waiters on the codecache_lock when a threshold for >>> reclaimed nmethods has been reached. This fix is enough on its own. >>> >>> In JDK 15 I introduced a new lock for the sweeper because a adding a >>> notify in NMethodSweeper::possibly_enable_sweeper conflicted with >>> the compiledMethod_lock in add_osr_method. That lock was added when >>> deoptimization was converted to using handshakes. So in 11 it is >>> still ok to use the codecache_lock. >>> >>> 2) Moving the updates of _total_nof_code_cache_sweeps and >>> _last_sweep inside block that is only run when doing a sweep. >>> This change just makes the counters update as expected. _last_sweep >>> is used to trigger sweeps after a number of safepoints. This is >>> counted by _time_counter. But since updates of _time_counter doesn't >>> wake the sweeper - it still doesn't work. >>> >>> In JDK 15 I removed all of this code since we can't even rely on >>> safepoints happening at all. I don't want to introduce any bugs in >>> JDK 11 by mistake - so I am leaving it as it is. >>> >>> Please review. >>> >>> Best regards, >>> Nils Eliasson >>> From kalinshi at tencent.com Tue Oct 13 00:08:43 2020 From: kalinshi at tencent.com (=?utf-8?B?a2FsaW5zaGko5pa95oWnKQ==?=) Date: Tue, 13 Oct 2020 00:08:43 +0000 Subject: =?utf-8?B?5Zue5aSNOiBbMTF1XSBCYWNrcG9ydCBKRVAgMzQ2IDogUHJvbXB0bHkgUmV0?= =?utf-8?B?dXJuIFVudXNlZCBDb21taXR0ZWQgTWVtb3J5IGZyb20gRzEoSW50ZXJuZXQg?= =?utf-8?Q?mail)?= In-Reply-To: References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> Message-ID: <59b83424fb324a79a55fcbfa436454a6@tencent.com> Thanks Liang! It would be great to have this feature in 11u. Regards Hui -----????----- ???: jdk-updates-dev ?? Ruslan Synytsky ????: 2020?10?12? 16:02 ???: Liang Mao ; Andrew Haley ??: jdk-updates-dev ; Lindenmaier, Goetz ; Martijn Verburg ??: Re: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1(Internet mail) Dear Liang, thank you for the extra efforts on this improvement. Dear Andrew, I assume we need your approval / confirmation. Can you please take a look and let us know your feedback? Regards On Fri, 25 Sep 2020 at 09:42, Liang Mao wrote: > Hi Developers, > > > > I would like to refresh this backport too. As Ruslan's description, > this JEP provides > > a very convenient way to save significant memory for popular > applications like Jenkins. > > Alibaba's JDK11 already had this feature and used it in workloads like > big data > > engines for months. The effect of memory saving is impressive. > > > Alibaba keeps migrating our Java applications to JDK11 and G1. We will > surely maintain > > the quality of the feature as we continues to report/discuss issues of > G1 and > > backport G1 bug fixes. SAP and Microsoft are interested in this > feature during last > > discussion and willing to maintain it as well. The JEP only contains 4 > small to medium > > patches and 6 tiny to small fixes. With communitie's review(Oracle G1 > team agreed to > > help) and experienced JVM developers from several big companies and > testing on > > various workloads and scenarios, I believe the quality is definitely > controllable. > > > I have been managing thousands of Java applications/millions of Java > instances and > > helping them to upgrade JDK and GC including different types of > worloads like online > > services, big data platforms, batch jobs, etc. It's really painful for > owners of Java > > applications to upgrate their JDK version to a larger number, > especially for those big > > applications with a lot of 3rd party packages. Letting JDK11 LTS have > such small > > feature with significant effect would benifit most of users. > > > All changes of the JEP only contains of hunderds lines of code: > > http://cr.openjdk.java.net/~lmao/jep346.11u/all.webrev.00/ > > > Here are the 10 changesets needs backport and 3 of them have conflicts: > > 1) JDK-8071913 > > http://cr.openjdk.java.net/~lmao/jep346.11u/8071913.webrev.00/ > > 2) JDK-6490394 > > 3) JDK-8213898 > > 4) JDK-8212657 > > http://cr.openjdk.java.net/~lmao/jep346.11u/8212657.webrev.00/ > > 5) JDK-8215120 > > 6) JDK-8215149 > > 7) JDK-8215548 > > 8) JDK-8216490 > > 9) JDK-8218880 > > http://cr.openjdk.java.net/~lmao/jep346.11u/8218880.webrev.00/ > > 10) JDK-8212883 > > > Tested with tier1/fastdebug. > > > BTW, I will file an CSR for the new options added if maintainers agree. > > Any questions? > > > Thanks, > > Liang > > > > > -----Original Message----- > > > From: jdk-updates-dev [mailto:jdk-updates-dev-retn at openjdk.java.net] > > On > > > Behalf Of Ruslan Synytsky > > > Sent: 2020?8?7? 1:00 > > > To: jdk-updates-dev > > > Subject: Re: [11u] Backport JEP 346 : Promptly Return Unused > > Committed > > > Memory from G1 > > > > > > Hi All, I would like to refresh this topic by sharing a very simple > example that > > > demonstrates why Java looks broken without this improvement. > > > > > > Jenkins is one of the most popular CI/CD tools. Unfortunately it > supports only > > > Java 8 and Java 11 > > > . If > > you > start a > > > simple standalone Jenkins instance and *just sign in* inside the > > admin > panel then > > > the JVM will start consuming a significant amount of memory immediately. > In > > > my case I had the following limits: container limit > > > - 8G, heap limit (Xmx) - 6.5G and the memory consumption after the > > sign > in > > > action got to 3G. By default all Java runtimes lower than Java 12 > > within > Jelastic > > > are supplied with our Java agent (which is a workaround) that tracks > memory > > > usage and if this agent detects a significant waste it calls full GC. > After this full > > > GC call the memory consumption goes down to 0.5G (check the > > screenshot) > > > mages/jenkins-memory-usage-diff.png> > > > usage/master/images/jenkins-memory-usage-diff.png > mages/jenkins-memory-usage-diff.png> > >. > > > If we disable our agent then the memory usage at the idle JVM will > > stay > at 3G > > > forever which is a waste of resources > > > mages/jenkins-memory-usage-waste.png> > > > usage/master/images/jenkins-memory-usage-waste.png > mages/jenkins-memory-usage-waste.png> > >. > > > If you put additional load on Jenkins the picture will look even worse. > > > > > > Usually one large host node runs hundreds of containers, and one > > cloud > cluster > > > may consist of tens, hundreds or thousands of host nodes, so the > > issue > multiplies. > > > And the case with Jenkins is just one of the examples. > > > I'm pretty sure this inefficient memory usage issue was damaging the > Java brand > > > for many years and a lot of developers believe that Java is too heavy. > Is not it a > > > strong reason to bring the fix to Java 11? > > > > > > Thanks > > > -- > > > Ruslan Synytsky > > > CEO @ Jelastic Multi-Cloud PaaS > -- Ruslan Synytsky CEO @ Jelastic Multi-Cloud PaaS From martin.doerr at sap.com Tue Oct 13 09:52:43 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 13 Oct 2020 09:52:43 +0000 Subject: [11u] RFR: 8234147: Avoid looking up standard charsets in core libraries In-Reply-To: References: Message-ID: Hi G?tz, looks good. > Actually, I don't see why Oracle brought this to 11. I don't think this is a must have, but Oracle must have had reasons. Maybe it is related to some specific performance sensitive workloads. Thanks for backporting. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 12. Oktober 2020 08:07 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8234147: Avoid looking up standard charsets > in core libraries > > Hi, > > I am downporting this for parity with 11.0.10-oracle. > http://cr.openjdk.java.net/~goetz/wr20/8234147-avoid_charset_lookup- > jdk11/01/ > > The only file with non-trivial resolve was BasicAuthentication.java. > > The resolves I had to do in detail: > > file src/java.base/share/classes/com/sun/security/ntlm/NTLM.java > Copyright. > > file src/java.base/share/classes/java/net/InetAddress.java > Unclear why chunks were rejected. Context? > > file src/java.base/share/classes/java/util/Properties.java > Context: other includes. > > file src/java.base/share/classes/java/util/jar/Attributes.java > Prerequisite missing: "UTF8" --> UTF_8 > > file src/java.base/share/classes/java/util/jar/Manifest.java > Prerequisite missing: "UTF8" --> UTF_8 > > file src/java.base/share/classes/java/util/zip/ZipCoder.java > Copyright. > > file > src/java.base/share/classes/sun/net/www/protocol/http/BasicAuthenticati > on.java > Coding looks different. I replaced occurances of "ISO_8859_1". > > file > src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java > Unclear: context? > > Actually, I don't see why Oracle brought this to 11. > > https://bugs.openjdk.java.net/browse/JDK-8234147 > https://hg.openjdk.java.net/jdk/jdk/rev/5028793d05ff > > Best regards, > Goetz. From aph at redhat.com Tue Oct 13 12:48:05 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Oct 2020 13:48:05 +0100 Subject: =?UTF-8?B?UmU6IOWbnuWkjTogWzExdV0gQmFja3BvcnQgSkVQIDM0NiA6IFByb21w?= =?UTF-8?Q?tly_Return_Unused_Committed_Memory_from_G1=28Internet_mail=29?= In-Reply-To: <59b83424fb324a79a55fcbfa436454a6@tencent.com> References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> <59b83424fb324a79a55fcbfa436454a6@tencent.com> Message-ID: On 13/10/2020 01:08, kalinshi(??) wrote: > Thanks Liang! > It would be great to have this feature in 11u. I agree, but only if we don't break 11u. If we break only 0.1% of applications it would be catastrophic for the reputation and the future of this project. We have to move very carefully. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue Oct 13 13:18:19 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 13 Oct 2020 13:18:19 +0000 Subject: Last public commit for JDK 15.0.1 Message-ID: Hi Rob, as we're approaching October update release 15.0.1, can you please share the link to the last public commit in http://hg.openjdk.java.net/jdk-updates/jdk15u that was merged into 15.0.1? Thank you in advance! Christoph From joserz at linux.ibm.com Tue Oct 13 13:33:31 2020 From: joserz at linux.ibm.com (joserz at linux.ibm.com) Date: Tue, 13 Oct 2020 10:33:31 -0300 Subject: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use new byte-reverse instructions In-Reply-To: References: <20200909163733.GA422344@pacoca> <20200911012040.GA518622@pacoca> Message-ID: <20201013133331.GA30104@pacoca> Hello Martin!! Ticket is updated: https://bugs.openjdk.java.net/browse/JDK-8248190 Webrev: https://cr.openjdk.java.net/~mhorie/8248190/webrev.02/ Thank you!! On Fri, Sep 11, 2020 at 12:26:09PM +0000, Doerr, Martin wrote: > Hi Jose, > > looks good. Thanks for backporting. > > Best regards, > Martin > > > > -----Original Message----- > > From: joserz at linux.ibm.com > > Sent: Freitag, 11. September 2020 03:21 > > To: Doerr, Martin > > Cc: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > > dev at openjdk.java.net; HORIE at jp.ibm.com > > Subject: Re: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use > > new byte-reverse instructions > > > > Hello Martin, > > > > Here is my new webrev. > > https://cr.openjdk.java.net/~mhorie/8248190/jdk11u/webrev.00/ > > (Thanks again, Michi) > > > > 8<---------------------------------------------------------------------- > > Some evidences in a Power10 emulator: > > $ openjdk/jdk11u-dev/build/jdk/bin/java -Xcomp -XX:CompileThreshold=1 - > > XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions - > > XX:+PrintOptoAssembly -XX:-UseSIGTRAP -XX:+UseByteReverseInstructions > > ReverseBytes | grep 'BRD\|BRH\|BRW\|EXTSH' > > ... > > 054 BRW R17, R18 > > 070 BRD R14, R14 > > 080 BRH R14, R15 > > EXTSH R14, R14 > > 0a0 BRH R17, R15 > > > > $ openjdk/jdk11u-dev/build/jdk/bin/java -XX:+Verbose - > > XX:PowerArchitecturePPC64=10 -version > > dscr value was 0x10 > > Version: ppc64 fsqrt isel lxarxeh cmpb popcntb popcntw fcfids vand lqarx aes > > vpmsumb mfdscr vsx ldbrx stdbrx sha darn brw > > L1_data_cache_line_size=128 > > > > ContendedPaddingWidth 128 > > > > openjdk version "11.0.10-internal" 2021-01-19 > > OpenJDK Runtime Environment (slowdebug build 11.0.10-internal+0- > > adhoc.ziviani.jdk11u-dev) > > OpenJDK 64-Bit Server VM (slowdebug build 11.0.10-internal+0- > > adhoc.ziviani.jdk11u-dev, mixed mode) > > 8<---------------------------------------------------------------------- > > > > Thank you very much! > > > > Jose > > > > On Thu, Sep 10, 2020 at 09:54:04AM +0000, Doerr, Martin wrote: > > > Hi Jose, > > > > > > if manual adaptation/integration is needed we also need to review the > > backport webrev (except trivial differences like in copyright headers). > > > > > > Best regards, > > > Martin > > > > > > > > > > -----Original Message----- > > > > From: jdk-updates-dev On > > > > Behalf Of joserz at linux.ibm.com > > > > Sent: Mittwoch, 9. September 2020 18:38 > > > > To: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > > > > dev at openjdk.java.net > > > > Subject: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use > > new > > > > byte-reverse instructions > > > > > > > > Hello team! > > > > > > > > I'd like to backport the following patchset to 11u. It doesn't apply > > perfectly > > > > due to some positional changes and a copyright update. > > > > Please, let me know if you prefer another webrev addressing this > > backport. > > > > > > > > Webrev: https://cr.openjdk.java.net/~mhorie/8248190/webrev.02/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248190 > > > > > > > > Thank you very much, > > > > > > > > Jose R Ziviani From martin.doerr at sap.com Tue Oct 13 16:17:04 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 13 Oct 2020 16:17:04 +0000 Subject: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use new byte-reverse instructions In-Reply-To: <20201013133331.GA30104@pacoca> References: <20200909163733.GA422344@pacoca> <20200911012040.GA518622@pacoca> <20201013133331.GA30104@pacoca> Message-ID: Hi Jose, pushed to jdk11u-dev. Best regards, Martin > -----Original Message----- > From: joserz at linux.ibm.com > Sent: Dienstag, 13. Oktober 2020 15:34 > To: Doerr, Martin > Cc: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > dev at openjdk.java.net; HORIE at jp.ibm.com > Subject: Re: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use > new byte-reverse instructions > > Hello Martin!! > > Ticket is updated: > https://bugs.openjdk.java.net/browse/JDK-8248190 > Webrev: https://cr.openjdk.java.net/~mhorie/8248190/webrev.02/ > > Thank you!! > > On Fri, Sep 11, 2020 at 12:26:09PM +0000, Doerr, Martin wrote: > > Hi Jose, > > > > looks good. Thanks for backporting. > > > > Best regards, > > Martin > > > > > > > -----Original Message----- > > > From: joserz at linux.ibm.com > > > Sent: Freitag, 11. September 2020 03:21 > > > To: Doerr, Martin > > > Cc: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > > > dev at openjdk.java.net; HORIE at jp.ibm.com > > > Subject: Re: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use > > > new byte-reverse instructions > > > > > > Hello Martin, > > > > > > Here is my new webrev. > > > https://cr.openjdk.java.net/~mhorie/8248190/jdk11u/webrev.00/ > > > (Thanks again, Michi) > > > > > > 8<---------------------------------------------------------------------- > > > Some evidences in a Power10 emulator: > > > $ openjdk/jdk11u-dev/build/jdk/bin/java -Xcomp - > XX:CompileThreshold=1 - > > > XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions - > > > XX:+PrintOptoAssembly -XX:-UseSIGTRAP - > XX:+UseByteReverseInstructions > > > ReverseBytes | grep 'BRD\|BRH\|BRW\|EXTSH' > > > ... > > > 054 BRW R17, R18 > > > 070 BRD R14, R14 > > > 080 BRH R14, R15 > > > EXTSH R14, R14 > > > 0a0 BRH R17, R15 > > > > > > $ openjdk/jdk11u-dev/build/jdk/bin/java -XX:+Verbose - > > > XX:PowerArchitecturePPC64=10 -version > > > dscr value was 0x10 > > > Version: ppc64 fsqrt isel lxarxeh cmpb popcntb popcntw fcfids vand lqarx > aes > > > vpmsumb mfdscr vsx ldbrx stdbrx sha darn brw > > > L1_data_cache_line_size=128 > > > > > > ContendedPaddingWidth 128 > > > > > > openjdk version "11.0.10-internal" 2021-01-19 > > > OpenJDK Runtime Environment (slowdebug build 11.0.10-internal+0- > > > adhoc.ziviani.jdk11u-dev) > > > OpenJDK 64-Bit Server VM (slowdebug build 11.0.10-internal+0- > > > adhoc.ziviani.jdk11u-dev, mixed mode) > > > 8<---------------------------------------------------------------------- > > > > > > Thank you very much! > > > > > > Jose > > > > > > On Thu, Sep 10, 2020 at 09:54:04AM +0000, Doerr, Martin wrote: > > > > Hi Jose, > > > > > > > > if manual adaptation/integration is needed we also need to review the > > > backport webrev (except trivial differences like in copyright headers). > > > > > > > > Best regards, > > > > Martin > > > > > > > > > > > > > -----Original Message----- > > > > > From: jdk-updates-dev > On > > > > > Behalf Of joserz at linux.ibm.com > > > > > Sent: Mittwoch, 9. September 2020 18:38 > > > > > To: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > > > > > dev at openjdk.java.net > > > > > Subject: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use > > > new > > > > > byte-reverse instructions > > > > > > > > > > Hello team! > > > > > > > > > > I'd like to backport the following patchset to 11u. It doesn't apply > > > perfectly > > > > > due to some positional changes and a copyright update. > > > > > Please, let me know if you prefer another webrev addressing this > > > backport. > > > > > > > > > > Webrev: https://cr.openjdk.java.net/~mhorie/8248190/webrev.02/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248190 > > > > > > > > > > Thank you very much, > > > > > > > > > > Jose R Ziviani From vkempik at azul.com Tue Oct 13 20:01:10 2020 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 13 Oct 2020 20:01:10 +0000 Subject: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport changes In-Reply-To: <8E3BF025-A532-499B-9E09-9F92C5911F42@azul.com> References: <3BBDEB11-6FE8-4F93-BCDE-155132DF935A@azul.com> <8E3BF025-A532-499B-9E09-9F92C5911F42@azul.com> Message-ID: Hello Any objections about these patches ? Regards, Vladimir. > 17 ????. 2020 ?., ? 11:24, Vladimir Kempik ???????(?): > > Hello Langer > >> Another thing: Looking at JBS I can see that JDK-8208498 was marked as a blocker for JDK-8209061 and the former hasn't been backported to 11. Is that an issue >> Generally, would it be possible to fix the issue of JDK-8207200 in a way that's less invasive? > > well, I have tried to make 8207200 less invasive by not including 8208498. > > There is a race condition in g1 monitoring which still can be see by some openjdk11 users ( commited < used) and this is the attempt to fix it. > I have verified it helps at least one user. Sadly I don?t have a reproducer. > > Regards, Vladimir > > >> 17 ????. 2020 ?., ? 10:43, Langer, Christoph ???????(?): >> >> Hi, >> >> I've just looked at approving this series of backports (JDK-8209061, JDK-8209062 and JDK-8207200). >> >> While I'm sure that JDK-8207200 fixes an important issue and I also trust your reviews of the backports, I can see that these 3 patches together mean some significant changes in the area of G1 GC. This makes me kind of hesitant to approve the backports right away. I'd like to get some assessment/reassurance of the other JDK11 maintainers (aph, sgehwolf) on whether we should admit them or not? >> >> Also, Aleksey, maybe you can give some technical advice as a gc expert if you think these backports are feasible? >> >> Another thing: Looking at JBS I can see that JDK-8208498 was marked as a blocker for JDK-8209061 and the former hasn't been backported to 11. Is that an issue? >> >> Generally, would it be possible to fix the issue of JDK-8207200 in a way that's less invasive? >> >> Please understand that I'd like to err on the side of caution here... >> >> Thanks & Best regards >> Christoph >> >>> -----Original Message----- >>> From: jdk-updates-dev On >>> Behalf Of John Cuthbertson >>> Sent: Dienstag, 15. September 2020 19:07 >>> To: Vladimir Kempik >>> Cc: jdk-updates-dev at openjdk.java.net >>> Subject: Re: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport changes >>> >>> Hi Vladimir, >>> >>> On Sep 3, 2020, at 5:28 AM, Vladimir Kempik >>> > wrote: >>> >>> Hello >>> >>> Please review these backports of JDK-8209061:Move G1 serviceability >>> functionality to G1MonitoringSupport and JDK-8209062:Clean up >>> G1MonitoringSupport to jdk11u >>> >>> These backports are prerequestes for JDK-8207200 which we can see in the >>> wild with jdk8 and jdk11. >>> >>> JDK-8209061 and JDK-8209062 applies mostly clean, very few places where it >>> wasn?t clean due to surrounding code or code layout. >>> >>> after these two, JDK-8207200 applies cleanly. >>> >>> Testing: tier1. >>> >>> The webrevs: >>> >>> http://cr.openjdk.java.net/~vkempik/8209061/webrev.00/ >>> >>> This looks good to me and matches >>> http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec. >>> >>> http://cr.openjdk.java.net/~vkempik/8209062/webrev.00/ >>> >>> This looks good to me also and matches >>> http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046. >>> >>> >>> All mentioned bugs: >>> https://bugs.openjdk.java.net/browse/JDK-8209062 >>> https://bugs.openjdk.java.net/browse/JDK-8209061 >>> https://bugs.openjdk.java.net/browse/JDK-8207200 >>> >>> Original changesets: >>> 8209061: http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec >>> 8209062: http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046 >>> >>> Thanks, Vladimir >>> >>> Regards, >>> >>> JohnC > From gnu.andrew at redhat.com Wed Oct 14 15:02:34 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 14 Oct 2020 16:02:34 +0100 Subject: [11u] Is 11u now frozen for 11.0.9? In-Reply-To: References: <20201005054246.GA551773@stopbrexit> <20201009004638.GA25853@DESKTOP-JNNKIHU.localdomain> Message-ID: <20201014150234.GA1441580@stopbrexit> On 04:01 Fri 09 Oct , Langer, Christoph wrote: > Hi Rob, > > I don't think there's an action item for you here... > > It was just the question whether the last public tag for OpenJDK 11.0.9 development had been set and Andrew could start working on the CPU on that base. And I had answered this. > > Best regards > Christoph > Yeah, I'm good now, thanks :-) -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Oct 14 17:09:59 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 14 Oct 2020 18:09:59 +0100 Subject: [11u] RFR: JDK-8254177: (tz) Upgrade time-zone data to tzdata2020b Message-ID: <20201014170959.GA1459004@stopbrexit> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177 Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8254177/webrev.01/ This updates OpenJDK 11 to the latest tzdata release, which was released last week. The backport mostly applies cleanly, with the following exceptions: * make/modules/java.base/gendata/GendataTZDB.gmk in 16u => make/gendata/GendataTZDB.gmk * The rule change in test/jdk/java/time/test/java/time/zone/TestZoneRules.java had to be applied manually, as 11u does not contain JDK-8239836, which introduces the OFF_x shorthand for ZoneOffset.ofHours(x) Tests in test/jdk/sun/util/calendar & test/jdk/java/time/test all pass with this update. I intend to include this with the CPU bundle once reviewed. Note that this removes the US/Pacific-New zone, which has been long obsolete and never actually came into effect: https://bugs.openjdk.java.net/browse/JDK-8254679 Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From yan at azul.com Wed Oct 14 17:44:01 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 14 Oct 2020 20:44:01 +0300 Subject: [11u] RFR: JDK-8254177: (tz) Upgrade time-zone data to tzdata2020b In-Reply-To: <20201014170959.GA1459004@stopbrexit> References: <20201014170959.GA1459004@stopbrexit> Message-ID: <6b91ee7a-13b4-430f-e9ae-2fbdae846321@azul.com> But Andrew, even Oracle has it with fixVersion = 11.0.10-oracle which is January. Take pity on us! Only six days before release, and all the builds must be tested and vetted and -- otherwise, as A. Shipilev rightly says, artifacts "may contain horrible bugs that could lead to data corruption, engulfing machines in flames, selling your firstborns at eBay, etc." --yan On 14.10.2020 20:09, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8254177 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8254177/webrev.01/ > > This updates OpenJDK 11 to the latest tzdata release, which was released > last week. The backport mostly applies cleanly, with the following > exceptions: > > * make/modules/java.base/gendata/GendataTZDB.gmk in 16u => > make/gendata/GendataTZDB.gmk > > * The rule change in test/jdk/java/time/test/java/time/zone/TestZoneRules.java > had to be applied manually, as 11u does not contain JDK-8239836, which introduces > the OFF_x shorthand for ZoneOffset.ofHours(x) > > Tests in test/jdk/sun/util/calendar & test/jdk/java/time/test all pass > with this update. > > I intend to include this with the CPU bundle once reviewed. > > Note that this removes the US/Pacific-New zone, which has been long > obsolete and never actually came into effect: > > https://bugs.openjdk.java.net/browse/JDK-8254679 > > Thanks, > From gnu.andrew at redhat.com Thu Oct 15 02:51:23 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 15 Oct 2020 03:51:23 +0100 Subject: [11u] RFR: JDK-8254177: (tz) Upgrade time-zone data to tzdata2020b In-Reply-To: <6b91ee7a-13b4-430f-e9ae-2fbdae846321@azul.com> References: <20201014170959.GA1459004@stopbrexit> <6b91ee7a-13b4-430f-e9ae-2fbdae846321@azul.com> Message-ID: <20201015025123.GB1483134@stopbrexit> On 20:44 Wed 14 Oct , Yuri Nesterenko wrote: > But Andrew, even Oracle has it with fixVersion = 11.0.10-oracle > which is January. Take pity on us! Only six days before release, > and all the builds must be tested and vetted and -- > otherwise, as A. Shipilev rightly says, > > artifacts "may contain horrible bugs that could lead to data corruption, engulfing machines in flames, > selling your firstborns at eBay, etc." > > --yan > Ok, we can include it as a local fix for 8u & 11u instead, and defer to 8u282/11.0.9 upstream, if it's going to cause an issue. I just thought it preferable to include it upstream if possible. Incidentally, note that this tzdata update has gone out to many systems already and so the JDK will be behind the system tzdata for about three months. We use the system tzdata rather than the in-tree version in our packages, so we need this fix to make sure the translations are in sync with that. Any thoughts on the patch itself, so we can get it into 11u-dev? :-) Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From yan at azul.com Thu Oct 15 06:48:04 2020 From: yan at azul.com (Yuri Nesterenko) Date: Thu, 15 Oct 2020 09:48:04 +0300 Subject: [11u] RFR: JDK-8254177: (tz) Upgrade time-zone data to tzdata2020b In-Reply-To: <20201015025123.GB1483134@stopbrexit> References: <20201014170959.GA1459004@stopbrexit> <6b91ee7a-13b4-430f-e9ae-2fbdae846321@azul.com> <20201015025123.GB1483134@stopbrexit> Message-ID: <2f2e52b3-91c6-453d-7ac7-2b8d3646e740@azul.com> On 15.10.2020 05:51, Andrew Hughes wrote: > On 20:44 Wed 14 Oct , Yuri Nesterenko wrote: >> But Andrew, even Oracle has it with fixVersion = 11.0.10-oracle >> which is January. Take pity on us! Only six days before release, >> and all the builds must be tested and vetted and -- >> otherwise, as A. Shipilev rightly says, >> >> artifacts "may contain horrible bugs that could lead to data corruption, engulfing machines in flames, >> selling your firstborns at eBay, etc." >> >> --yan >> > > Ok, we can include it as a local fix for 8u & 11u instead, and defer > to 8u282/11.0.9 upstream, if it's going to cause an issue. I just > thought it preferable to include it upstream if possible. To defer, that would be much better, thank you! > > Incidentally, note that this tzdata update has gone out to many > systems already and so the JDK will be behind the system tzdata > for about three months. We use the system tzdata rather than the > in-tree version in our packages, so we need this fix to make > sure the translations are in sync with that. > > Any thoughts on the patch itself, so we can get it into 11u-dev? :-) As to the fix, it looks OK to me. I don't see a change in backward files related to that stillborn Pacific_new but there's no rush I think. If somebody need it it may be included later, right? Thanks, --yan > > Thanks, > From goetz.lindenmaier at sap.com Thu Oct 15 10:47:13 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 15 Oct 2020 10:47:13 +0000 Subject: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11 In-Reply-To: <549edaa3-7183-2368-c1e4-13f10fd62344@oracle.com> References: <549edaa3-7183-2368-c1e4-13f10fd62344@oracle.com> Message-ID: Hi Nils, Do I understand correctly that after this fix I should also push "8244278: Excessive code cache flushes and sweeps" ? https://bugs.openjdk.java.net/browse/JDK-8244278 Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Nils Eliasson > Sent: Friday, October 9, 2020 4:35 PM > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11 > > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8254185 > Webrev: http://cr.openjdk.java.net/~neliasso/8254185/webrev.01/ > > This fix is a replacement for JDK-8244660 that I consider to risky to > back port. > > This issue can't be seen unless JDK-8254185 is applied. That bug causes > the sweeper to trigger on every code cache allocation. When JDK-8254185 > is applied then no sweeps can be observed at all. > > The main issue is that the sweeper thread is never woken. And if it > isn't woken, it can't check the counters to see if it is time to sweep. > > This fix include two changes: > > 1) Notifying waiters on the codecache_lock when a threshold for > reclaimed nmethods has been reached. This fix is enough on its own. > > In JDK 15 I introduced a new lock for the sweeper because a adding a > notify in NMethodSweeper::possibly_enable_sweeper conflicted with the > compiledMethod_lock in add_osr_method. That lock was added when > deoptimization was converted to using handshakes. So in 11 it is still > ok to use the codecache_lock. > > 2) Moving the updates of _total_nof_code_cache_sweeps and _last_sweep > inside block that is only run when doing a sweep. > This change just makes the counters update as expected. _last_sweep is > used to trigger sweeps after a number of safepoints. This is counted by > _time_counter. But since updates of _time_counter doesn't wake the > sweeper - it still doesn't work. > > In JDK 15 I removed all of this code since we can't even rely on > safepoints happening at all. I don't want to introduce any bugs in JDK > 11 by mistake - so I am leaving it as it is. > > Please review. > > Best regards, > Nils Eliasson From gnu.andrew at redhat.com Thu Oct 15 12:49:25 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 15 Oct 2020 13:49:25 +0100 Subject: [11u] RFR: JDK-8254177: (tz) Upgrade time-zone data to tzdata2020b In-Reply-To: <2f2e52b3-91c6-453d-7ac7-2b8d3646e740@azul.com> References: <20201014170959.GA1459004@stopbrexit> <6b91ee7a-13b4-430f-e9ae-2fbdae846321@azul.com> <20201015025123.GB1483134@stopbrexit> <2f2e52b3-91c6-453d-7ac7-2b8d3646e740@azul.com> Message-ID: <20201015124925.GA1532371@stopbrexit> On 09:48 Thu 15 Oct , Yuri Nesterenko wrote: > > > On 15.10.2020 05:51, Andrew Hughes wrote: > > On 20:44 Wed 14 Oct , Yuri Nesterenko wrote: > >> But Andrew, even Oracle has it with fixVersion = 11.0.10-oracle > >> which is January. Take pity on us! Only six days before release, > >> and all the builds must be tested and vetted and -- > >> otherwise, as A. Shipilev rightly says, > >> > >> artifacts "may contain horrible bugs that could lead to data corruption, engulfing machines in flames, > >> selling your firstborns at eBay, etc." > >> > >> --yan > >> > > > > Ok, we can include it as a local fix for 8u & 11u instead, and defer > > to 8u282/11.0.9 upstream, if it's going to cause an issue. I just > > thought it preferable to include it upstream if possible. > > To defer, that would be much better, thank you! > No problem! > > > > Incidentally, note that this tzdata update has gone out to many > > systems already and so the JDK will be behind the system tzdata > > for about three months. We use the system tzdata rather than the > > in-tree version in our packages, so we need this fix to make > > sure the translations are in sync with that. > > > > Any thoughts on the patch itself, so we can get it into 11u-dev? :-) > As to the fix, it looks OK to me. > I don't see a change in backward files related to that stillborn Pacific_new > but there's no rush I think. If somebody need it it may be included later, right? > Yes, I mentioned this on the original review: https://git.openjdk.java.net/jdk/pull/602 US/Pacific-New was only ever just a link to America/Los_Angeles, rather than an actual definition like those in systemv & jdk11_backward. We could always add it to jdk11_backward if it becomes apparent people depend it, but, in the unlikely event someone is, it's much preferable that they just switch to using America/Los_Angeles directly. This wouldn't be the first time zones have been removed. I've seen it happen in previous updates. The only difference here is the file, which only contained a single zone, is removed as well. > Thanks, > --yan > > > > > > Thanks, > > > Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From filipe.roque at premium-minds.com Thu Oct 15 15:17:40 2020 From: filipe.roque at premium-minds.com (Filipe Roque) Date: Thu, 15 Oct 2020 15:17:40 +0000 Subject: [11u] RFR: 8211450: UndetVar::dup is not copying the kind field to the duplicated instance Message-ID: Hi, I would like to backport this fix to 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8211450 Fix (Original): https://hg.openjdk.java.net/jdk/jdk/rev/52155b28cdb7 I've verified the patch and would be glad if someone could sponsor the backport. The original patch itself doesn't apply cleanly, due to conflict with copyright year in file src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java I have edited the original patch to remove that conflict, which can be found below. For additional context, as my team is trying to move from Java 8 to Java 11, we have encountered the bug https://bugs.openjdk.java.net/browse/JDK-8232766. Although it is marked Unresolved, this bug has been fixed in JDK 12 and all later versions. I have bisected the jdk sources to discovered which changeset fixed the commit and discovered it was the JDK-8211450. Thanks, Filipe Roque # HG changeset patch # User vromero # Date 1541719432 18000 # Node ID 52155b28cdb7fc2a8c8a096c561c68be87fb8cc8 # Parent 4ad404da00887d427e9a3822fa8a7355fdac9832 8211450: UndetVar::dup is not copying the kind field to the duplicated instance Reviewed-by: mcimadamore diff -r 4ad404da0088 -r 52155b28cdb7 src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java Thu Nov 08 23:31:08 2018 +0100 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java Thu Nov 08 18:23:52 2018 -0500 @@ -2020,6 +2020,7 @@ for (IncorporationAction action : incorporationActions) { uv2.incorporationActions.add(action.dup(uv2)); } + uv2.kind = kind; } @Override diff -r 4ad404da0088 -r 52155b28cdb7 test/langtools/tools/javac/T8211450/ThrownTypeVarTest.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/langtools/tools/javac/T8211450/ThrownTypeVarTest.java Thu Nov 08 18:23:52 2018 -0500 @@ -0,0 +1,49 @@ +/* + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8211450 + * @summary UndetVar::dup is not copying the kind field to the duplicated instance + * @compile ThrownTypeVarTest.java + */ + +import java.io.*; + +public class ThrownTypeVarTest { + void repro() throws IOException { + when(f(any())); + } + + interface MyInt {} + + T2 f(MyInt g) throws IOException, E2 { + return null; + } + + static T3 any() { + return null; + } + + static void when(T4 methodCall) {} +} From nils.eliasson at oracle.com Fri Oct 16 08:37:58 2020 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 16 Oct 2020 10:37:58 +0200 Subject: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11 In-Reply-To: References: <549edaa3-7183-2368-c1e4-13f10fd62344@oracle.com> Message-ID: Hi Goetz, Yes. With both fixes the sweeper will work fine again. Best regards, Nils On 2020-10-15 12:47, Lindenmaier, Goetz wrote: > Hi Nils, > > Do I understand correctly that after this fix I should also push > "8244278: Excessive code cache flushes and sweeps" ? > https://bugs.openjdk.java.net/browse/JDK-8244278 > > Best regards, > Goetz. > >> -----Original Message----- >> From: jdk-updates-dev On Behalf >> Of Nils Eliasson >> Sent: Friday, October 9, 2020 4:35 PM >> To: jdk-updates-dev at openjdk.java.net >> Subject: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11 >> >> Hi, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8254185 >> Webrev: http://cr.openjdk.java.net/~neliasso/8254185/webrev.01/ >> >> This fix is a replacement for JDK-8244660 that I consider to risky to >> back port. >> >> This issue can't be seen unless JDK-8254185 is applied. That bug causes >> the sweeper to trigger on every code cache allocation. When JDK-8254185 >> is applied then no sweeps can be observed at all. >> >> The main issue is that the sweeper thread is never woken. And if it >> isn't woken, it can't check the counters to see if it is time to sweep. >> >> This fix include two changes: >> >> 1) Notifying waiters on the codecache_lock when a threshold for >> reclaimed nmethods has been reached. This fix is enough on its own. >> >> In JDK 15 I introduced a new lock for the sweeper because a adding a >> notify in NMethodSweeper::possibly_enable_sweeper conflicted with the >> compiledMethod_lock in add_osr_method. That lock was added when >> deoptimization was converted to using handshakes. So in 11 it is still >> ok to use the codecache_lock. >> >> 2) Moving the updates of _total_nof_code_cache_sweeps and _last_sweep >> inside block that is only run when doing a sweep. >> This change just makes the counters update as expected. _last_sweep is >> used to trigger sweeps after a number of safepoints. This is counted by >> _time_counter. But since updates of _time_counter doesn't wake the >> sweeper - it still doesn't work. >> >> In JDK 15 I removed all of this code since we can't even rely on >> safepoints happening at all. I don't want to introduce any bugs in JDK >> 11 by mistake - so I am leaving it as it is. >> >> Please review. >> >> Best regards, >> Nils Eliasson From goetz.lindenmaier at sap.com Fri Oct 16 09:04:49 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 16 Oct 2020 09:04:49 +0000 Subject: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11 In-Reply-To: References: <549edaa3-7183-2368-c1e4-13f10fd62344@oracle.com> Message-ID: Thanks! Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Nils Eliasson > Sent: Friday, October 16, 2020 10:38 AM > To: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK > 11 > > Hi Goetz, > > Yes. With both fixes the sweeper will work fine again. > > Best regards, > Nils > > On 2020-10-15 12:47, Lindenmaier, Goetz wrote: > > Hi Nils, > > > > Do I understand correctly that after this fix I should also push > > "8244278: Excessive code cache flushes and sweeps" ? > > https://bugs.openjdk.java.net/browse/JDK-8244278 > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: jdk-updates-dev On > Behalf > >> Of Nils Eliasson > >> Sent: Friday, October 9, 2020 4:35 PM > >> To: jdk-updates-dev at openjdk.java.net > >> Subject: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11 > >> > >> Hi, > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8254185 > >> Webrev: http://cr.openjdk.java.net/~neliasso/8254185/webrev.01/ > >> > >> This fix is a replacement for JDK-8244660 that I consider to risky to > >> back port. > >> > >> This issue can't be seen unless JDK-8254185 is applied. That bug causes > >> the sweeper to trigger on every code cache allocation. When JDK- > 8254185 > >> is applied then no sweeps can be observed at all. > >> > >> The main issue is that the sweeper thread is never woken. And if it > >> isn't woken, it can't check the counters to see if it is time to sweep. > >> > >> This fix include two changes: > >> > >> 1) Notifying waiters on the codecache_lock when a threshold for > >> reclaimed nmethods has been reached. This fix is enough on its own. > >> > >> In JDK 15 I introduced a new lock for the sweeper because a adding a > >> notify in NMethodSweeper::possibly_enable_sweeper conflicted with the > >> compiledMethod_lock in add_osr_method. That lock was added when > >> deoptimization was converted to using handshakes. So in 11 it is still > >> ok to use the codecache_lock. > >> > >> 2) Moving the updates of _total_nof_code_cache_sweeps and > _last_sweep > >> inside block that is only run when doing a sweep. > >> This change just makes the counters update as expected. _last_sweep is > >> used to trigger sweeps after a number of safepoints. This is counted by > >> _time_counter. But since updates of _time_counter doesn't wake the > >> sweeper - it still doesn't work. > >> > >> In JDK 15 I removed all of this code since we can't even rely on > >> safepoints happening at all. I don't want to introduce any bugs in JDK > >> 11 by mistake - so I am leaving it as it is. > >> > >> Please review. > >> > >> Best regards, > >> Nils Eliasson From rob.mckenna at oracle.com Fri Oct 16 13:32:36 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 16 Oct 2020 14:32:36 +0100 Subject: [11u] Is 11u now frozen for 11.0.9? In-Reply-To: References: <20201005054246.GA551773@stopbrexit> <20201009004638.GA25853@DESKTOP-JNNKIHU.localdomain> Message-ID: <20201016133236.GC9715@DESKTOP-JNNKIHU.localdomain> Don't ask me how, but I was responding to the wrong mail completely. Sorry for the confusion. (I should have been replying to Paul's email issue) -Rob On 09/10/20 04:01, Langer, Christoph wrote: > Hi Rob, > > I don't think there's an action item for you here... > > It was just the question whether the last public tag for OpenJDK 11.0.9 development had been set and Andrew could start working on the CPU on that base. And I had answered this. > > Best regards > Christoph > > > -----Original Message----- > > From: Rob McKenna > > Sent: Freitag, 9. Oktober 2020 02:47 > > To: Langer, Christoph > > Cc: Andrew Hughes ; jdk-updates- > > dev at openjdk.java.net; Lindenmaier, Goetz > > Subject: Re: [11u] Is 11u now frozen for 11.0.9? > > > > Just spotted this. I'm looking into it. > > > > -Rob > > > > On 05/10/20 06:12, Langer, Christoph wrote: > > > Hi Andrew, > > > > > > correct, with 11.0.9+10, the 11u repo is frozen. You can go ahead with CPU > > work ?? > > > > > > Cheers > > > Christoph > > > > > > > -----Original Message----- > > > > From: jdk-updates-dev On > > > > Behalf Of Andrew Hughes > > > > Sent: Montag, 5. Oktober 2020 07:43 > > > > To: jdk-updates-dev at openjdk.java.net > > > > Subject: [11u] Is 11u now frozen for 11.0.9? > > > > > > > > I see a jdk-11.0.9+10 tag on 2020-09-30, which matches with what > > > > should be the last promotion according to the 11u wiki [0], but no > > > > announcement om the mailing list regarding this. > > > > > > > > What is the current state of 11u? > > > > > > > > [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > > > > > > > Thanks, > > > > -- > > > > Andrew :) > > > > > > > > Senior Free Java Software Engineer > > > > OpenJDK Package Owner > > > > Red Hat, Inc. (https://urldefense.com/v3/__http://www.redhat.com__;!!GqivPVa7Brio!IxjMxAd9vrcVkSMZA7BHoH-xxAM6V8TrAsV_40txjr3CJoK-cd2TZSqoDJs3DSs7$ ) > > > > > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Sat Oct 17 02:12:46 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 17 Oct 2020 03:12:46 +0100 Subject: [11u] RFR: JDK-8254177: (tz) Upgrade time-zone data to tzdata2020b In-Reply-To: <2f2e52b3-91c6-453d-7ac7-2b8d3646e740@azul.com> References: <20201014170959.GA1459004@stopbrexit> <6b91ee7a-13b4-430f-e9ae-2fbdae846321@azul.com> <20201015025123.GB1483134@stopbrexit> <2f2e52b3-91c6-453d-7ac7-2b8d3646e740@azul.com> Message-ID: <20201017021246.GA1922591@stopbrexit> On 09:48 Thu 15 Oct , Yuri Nesterenko wrote: > > > On 15.10.2020 05:51, Andrew Hughes wrote: > > On 20:44 Wed 14 Oct , Yuri Nesterenko wrote: > >> But Andrew, even Oracle has it with fixVersion = 11.0.10-oracle > >> which is January. Take pity on us! Only six days before release, > >> and all the builds must be tested and vetted and -- > >> otherwise, as A. Shipilev rightly says, > >> > >> artifacts "may contain horrible bugs that could lead to data corruption, engulfing machines in flames, > >> selling your firstborns at eBay, etc." > >> > >> --yan > >> > > > > Ok, we can include it as a local fix for 8u & 11u instead, and defer > > to 8u282/11.0.9 upstream, if it's going to cause an issue. I just > > thought it preferable to include it upstream if possible. > > To defer, that would be much better, thank you! > Just an FYI: the bug now shows Oracle including it in 11.0.9.0.2-oracle and 8u271-b32. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From yan at azul.com Sat Oct 17 10:58:24 2020 From: yan at azul.com (Yuri Nesterenko) Date: Sat, 17 Oct 2020 13:58:24 +0300 Subject: [11u] RFR: JDK-8254177: (tz) Upgrade time-zone data to tzdata2020b In-Reply-To: <20201017021246.GA1922591@stopbrexit> References: <20201014170959.GA1459004@stopbrexit> <6b91ee7a-13b4-430f-e9ae-2fbdae846321@azul.com> <20201015025123.GB1483134@stopbrexit> <2f2e52b3-91c6-453d-7ac7-2b8d3646e740@azul.com> <20201017021246.GA1922591@stopbrexit> Message-ID: On 17.10.2020 05:12, Andrew Hughes wrote: > On 09:48 Thu 15 Oct , Yuri Nesterenko wrote: >> >> >> On 15.10.2020 05:51, Andrew Hughes wrote: >>> On 20:44 Wed 14 Oct , Yuri Nesterenko wrote: >>>> But Andrew, even Oracle has it with fixVersion = 11.0.10-oracle >>>> which is January. Take pity on us! Only six days before release, >>>> and all the builds must be tested and vetted and -- >>>> otherwise, as A. Shipilev rightly says, >>>> >>>> artifacts "may contain horrible bugs that could lead to data corruption, engulfing machines in flames, >>>> selling your firstborns at eBay, etc." >>>> >>>> --yan >>>> >>> >>> Ok, we can include it as a local fix for 8u & 11u instead, and defer >>> to 8u282/11.0.9 upstream, if it's going to cause an issue. I just >>> thought it preferable to include it upstream if possible. >> >> To defer, that would be much better, thank you! >> > > Just an FYI: the bug now shows Oracle including it in 11.0.9.0.2-oracle > and 8u271-b32. > That's not inhuman cadence: they are making BPR (in Oracle terms) on top of a regular planned release. Not on Tuesday :-) --yan From goetz.lindenmaier at sap.com Mon Oct 19 11:15:08 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 19 Oct 2020 11:15:08 +0000 Subject: [11u] RFR: 8248745: Add jarsigner and keytool tests for restricted algorithms Message-ID: Hi, I am downporting this for parity with 11.0.9-oracle. It is a new test that didn't make it to 11.0.9, I will push it to 11.0.10. http://cr.openjdk.java.net/~goetz/wr20/8248745-jarsigner_test-jdk11/01/ I had to replace the name SHA256 by SHA-256 to make the test work. https://bugs.openjdk.java.net/browse/JDK-8248745 https://hg.openjdk.java.net/jdk/jdk/rev/7cf5207e2d6a Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Oct 19 14:35:27 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 19 Oct 2020 14:35:27 +0000 Subject: [11u] RFR: 8237499: JFR: Include stack trace in the ThreadStart event Message-ID: HI I am downporting this for 11.0.10-oracle parity. http://cr.openjdk.java.net/~goetz/wr20/8237499-jfr_stacktrace-jdk11/01/ I had to do a really trivial resolve in jfrThreadLocal.cpp:55. https://bugs.openjdk.java.net/browse/JDK-8237499 https://hg.openjdk.java.net/jdk/jdk/rev/6214823ce3d8 Best regards, Goetz. From shade at redhat.com Mon Oct 19 14:58:25 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 19 Oct 2020 16:58:25 +0200 Subject: [11u] RFR 8244142: some hotspot/runtime tests don't check exit code of forked JVM Message-ID: <3f266f1c-6a20-10a7-22cb-4ce4b8d61ae6@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8244142 https://hg.openjdk.java.net/jdk/jdk/rev/d194201e76ef It applies cleanly, except the hunk from test/hotspot/jtreg/runtime/records/RedefineRecord.java, which does not exist in 11u (added for Records). 11u variant therefore is: diff -r 73edf743a93a test/hotspot/jtreg/runtime/Metaspace/MaxMetaspaceSizeTest.java --- a/test/hotspot/jtreg/runtime/Metaspace/MaxMetaspaceSizeTest.java Wed Sep 30 08:58:42 2020 +0200 +++ b/test/hotspot/jtreg/runtime/Metaspace/MaxMetaspaceSizeTest.java Mon Oct 19 16:58:00 2020 +0200 @@ -44,4 +44,5 @@ OutputAnalyzer output = new OutputAnalyzer(pb.start()); output.shouldContain("MaxMetaspaceSize is too small."); + output.shouldNotHaveExitValue(0); } } diff -r 73edf743a93a test/hotspot/jtreg/runtime/getSysPackage/GetPackageXbootclasspath.java --- a/test/hotspot/jtreg/runtime/getSysPackage/GetPackageXbootclasspath.java Wed Sep 30 08:58:42 2020 +0200 +++ b/test/hotspot/jtreg/runtime/getSysPackage/GetPackageXbootclasspath.java Mon Oct 19 16:58:00 2020 +0200 @@ -55,5 +55,6 @@ new OutputAnalyzer(ProcessTools.createJavaProcessBuilder( "-Xbootclasspath/a:" + test_classes, "P.Test") - .start()).shouldContain("Test Passed"); + .start()).shouldContain("Test Passed") + .shouldHaveExitValue(0); } } Testing: affected tests with Linux x86_64 fastdebug -- Thanks, -Aleksey From jaroslav.bachorik at datadoghq.com Mon Oct 19 16:05:46 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 19 Oct 2020 18:05:46 +0200 Subject: [11u] RFR 8252090: JFR: StreamWriterHost::write_unbuffered() stucks in an infinite loop OpenJDK (build 13.0.1+9) In-Reply-To: References: Message-ID: Gentle ping? On Wed, Oct 7, 2020 at 5:58 PM Jaroslav Bachor?k wrote: > > Hello, > > Can I get the following backport reviewed? > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8252090 > Webrev: http://cr.openjdk.java.net/~jbachorik/8252090/00/webrev/ > > The backport and the original patch are differing in 1 place only: > - src/hotspot/share/jfr/recorder/repository/jfrChunkWriter.cpp does > not contain write_magic() method and the change needs to be done in > JfrChunkWriter::open() instead > > Ran tier1 and jdk_jfr tests successfully. > > Thanks, > > -JB- From martin.doerr at sap.com Mon Oct 19 16:08:39 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 19 Oct 2020 16:08:39 +0000 Subject: [11u] RFR: 8237499: JFR: Include stack trace in the ThreadStart event In-Reply-To: References: Message-ID: Hi G?tz, looks good. Thanks, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 19. Oktober 2020 16:35 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8237499: JFR: Include stack trace in the > ThreadStart event > > HI > > I am downporting this for 11.0.10-oracle parity. > http://cr.openjdk.java.net/~goetz/wr20/8237499-jfr_stacktrace-jdk11/01/ > I had to do a really trivial resolve in jfrThreadLocal.cpp:55. > > https://bugs.openjdk.java.net/browse/JDK-8237499 > https://hg.openjdk.java.net/jdk/jdk/rev/6214823ce3d8 > > Best regards, > Goetz. From matthias.baesken at sap.com Tue Oct 20 10:25:50 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 20 Oct 2020 10:25:50 +0000 Subject: [11u] RFR: 8248745: Add jarsigner and keytool tests for restricted algorithms In-Reply-To: References: Message-ID: Hi Goetz, thanks for adding the test . Looks good to me. Best regards, Matthias -----Original Message----- From: Lindenmaier, Goetz Sent: Monday, October 19, 2020 1:15 PM To: jdk-updates-dev at openjdk.java.net Subject: [11u] RFR: 8248745: Add jarsigner and keytool tests for restricted algorithms Hi, I am downporting this for parity with 11.0.9-oracle. It is a new test that didn't make it to 11.0.9, I will push it to 11.0.10. http://cr.openjdk.java.net/~goetz/wr20/8248745-jarsigner_test-jdk11/01/ I had to replace the name SHA256 by SHA-256 to make the test work. https://bugs.openjdk.java.net/browse/JDK-8248745 https://hg.openjdk.java.net/jdk/jdk/rev/7cf5207e2d6a Best regards, Goetz. From goetz.lindenmaier at sap.com Tue Oct 20 13:17:39 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 20 Oct 2020 13:17:39 +0000 Subject: [11u] RFR: 8234147: Avoid looking up standard charsets in core libraries In-Reply-To: References: Message-ID: Thanks Martin! Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Tuesday, October 13, 2020 11:53 AM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8234147: Avoid looking up standard charsets in core > libraries > > Hi G?tz, > > looks good. > > > Actually, I don't see why Oracle brought this to 11. > I don't think this is a must have, but Oracle must have had reasons. Maybe it > is related to some specific performance sensitive workloads. > > Thanks for backporting. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Montag, 12. Oktober 2020 08:07 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8234147: Avoid looking up standard charsets > > in core libraries > > > > Hi, > > > > I am downporting this for parity with 11.0.10-oracle. > > http://cr.openjdk.java.net/~goetz/wr20/8234147-avoid_charset_lookup- > > jdk11/01/ > > > > The only file with non-trivial resolve was BasicAuthentication.java. > > > > The resolves I had to do in detail: > > > > file src/java.base/share/classes/com/sun/security/ntlm/NTLM.java > > Copyright. > > > > file src/java.base/share/classes/java/net/InetAddress.java > > Unclear why chunks were rejected. Context? > > > > file src/java.base/share/classes/java/util/Properties.java > > Context: other includes. > > > > file src/java.base/share/classes/java/util/jar/Attributes.java > > Prerequisite missing: "UTF8" --> UTF_8 > > > > file src/java.base/share/classes/java/util/jar/Manifest.java > > Prerequisite missing: "UTF8" --> UTF_8 > > > > file src/java.base/share/classes/java/util/zip/ZipCoder.java > > Copyright. > > > > file > > > src/java.base/share/classes/sun/net/www/protocol/http/BasicAuthenticati > > on.java > > Coding looks different. I replaced occurances of "ISO_8859_1". > > > > file > > src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java > > Unclear: context? > > > > Actually, I don't see why Oracle brought this to 11. > > > > https://bugs.openjdk.java.net/browse/JDK-8234147 > > https://hg.openjdk.java.net/jdk/jdk/rev/5028793d05ff > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Tue Oct 20 13:19:36 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 20 Oct 2020 13:19:36 +0000 Subject: [11u] RFR: 8237499: JFR: Include stack trace in the ThreadStart event In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Monday, October 19, 2020 6:09 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8237499: JFR: Include stack trace in the ThreadStart > event > > Hi G?tz, > > looks good. > > Thanks, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Montag, 19. Oktober 2020 16:35 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8237499: JFR: Include stack trace in the > > ThreadStart event > > > > HI > > > > I am downporting this for 11.0.10-oracle parity. > > http://cr.openjdk.java.net/~goetz/wr20/8237499-jfr_stacktrace-jdk11/01/ > > I had to do a really trivial resolve in jfrThreadLocal.cpp:55. > > > > https://bugs.openjdk.java.net/browse/JDK-8237499 > > https://hg.openjdk.java.net/jdk/jdk/rev/6214823ce3d8 > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Tue Oct 20 13:29:10 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 20 Oct 2020 13:29:10 +0000 Subject: [11u] RFR: 8248745: Add jarsigner and keytool tests for restricted algorithms In-Reply-To: References: Message-ID: Hi Matthias, Thanks for reviewing! Best regards, Goetz > -----Original Message----- > From: Baesken, Matthias > Sent: Tuesday, October 20, 2020 12:26 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8248745: Add jarsigner and keytool tests for > restricted algorithms > > Hi Goetz, thanks for adding the test . > Looks good to me. > > Best regards, Matthias > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Monday, October 19, 2020 1:15 PM > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8248745: Add jarsigner and keytool tests for restricted > algorithms > > Hi, > > I am downporting this for parity with 11.0.9-oracle. > It is a new test that didn't make it to 11.0.9, I will > push it to 11.0.10. > > http://cr.openjdk.java.net/~goetz/wr20/8248745-jarsigner_test-jdk11/01/ > > I had to replace the name SHA256 by SHA-256 to > make the test work. > > https://bugs.openjdk.java.net/browse/JDK-8248745 > https://hg.openjdk.java.net/jdk/jdk/rev/7cf5207e2d6a > > Best regards, > Goetz. From rs at jelastic.com Tue Oct 20 15:43:21 2020 From: rs at jelastic.com (Ruslan Synytsky) Date: Tue, 20 Oct 2020 18:43:21 +0300 Subject: =?UTF-8?Q?Re=3A_=E5=9B=9E=E5=A4=8D=3A_=5B11u=5D_Backport_JEP_346_=3A_Promptly_Return?= =?UTF-8?Q?_Unused_Committed_Memory_from_G1=28Internet_mail=29?= In-Reply-To: References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> <59b83424fb324a79a55fcbfa436454a6@tencent.com> Message-ID: Hi Andrew, did you have a chance to take a look at this? For sure, we must be very careful to avoid any possible regression. Regards On Tue, 13 Oct 2020 at 15:48, Andrew Haley wrote: > On 13/10/2020 01:08, kalinshi(??) wrote: > > Thanks Liang! > > It would be great to have this feature in 11u. > > I agree, but only if we don't break 11u. If we break only 0.1% of > applications > it would be catastrophic for the reputation and the future of this > project. We have to move very carefully. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > -- Ruslan Synytsky CEO @ Jelastic Multi-Cloud PaaS From aph at redhat.com Tue Oct 20 17:43:59 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 20 Oct 2020 18:43:59 +0100 Subject: =?UTF-8?B?UmU6IOWbnuWkjTogWzExdV0gQmFja3BvcnQgSkVQIDM0NiA6IFByb21w?= =?UTF-8?Q?tly_Return_Unused_Committed_Memory_from_G1=28Internet_mail=29?= In-Reply-To: References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> <59b83424fb324a79a55fcbfa436454a6@tencent.com> Message-ID: <577588c1-79a6-883a-a949-2d3113753471@redhat.com> On 20/10/2020 16:43, Ruslan Synytsky wrote: > Hi Andrew, did you have a chance to take a look at this? > For sure, we must be very careful to avoid any possible regression. Sure, I'm still waiting for a GC expert to get back to me. I'll ping. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Wed Oct 21 05:59:15 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 21 Oct 2020 06:59:15 +0100 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga Message-ID: <20201021055915.GC2428148@stopbrexit> Here are the remaining changes for the jdk11u repository: Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.9/ Changes in jdk-11.0.9+11: - JDK-8233624: Enhance JNI linkage - JDK-8236196: Improve string pooling - JDK-8236862: Enhance support of Proxy class - JDK-8237990: Enhanced LDAP contexts - JDK-8237995: Enhance certificate processing - JDK-8240124: Better VM Interning - JDK-8241114: Better range handling - JDK-8242680: Improved URI Support - JDK-8242685: Better Path Validation - JDK-8242695: Enhanced buffer support - JDK-8243302: Advanced class supports - JDK-8244136: Improved Buffer supports - JDK-8244479: Further constrain certificates - JDK-8244955: Additional Fix for JDK-8240124 - JDK-8245407: Enhance zoning of times - JDK-8245412: Better class definitions - JDK-8245417: Improve certificate chain handling - JDK-8248574: Improve jpeg processing - JDK-8249927: Specify limits of jdk.serialProxyInterfaceLimit - JDK-8253019: Enhanced JPEG decoding Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le, aarch32 & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From christoph.langer at sap.com Wed Oct 21 06:16:32 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 21 Oct 2020 06:16:32 +0000 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: <20201021055915.GC2428148@stopbrexit> References: <20201021055915.GC2428148@stopbrexit> Message-ID: Hi Andrew, I had a quick glance, but obviously no detailed review. Looks good to go from my perspective. Cheers Christoph PS: I think this kind of review is not necessary and does not help the release process. We should really consider dropping it and fully trust the reviews on vuln-dev and your build/test pipeline. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Hughes > Sent: Mittwoch, 21. Oktober 2020 07:59 > To: jdk-updates-dev at openjdk.java.net > Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga > > Here are the remaining changes for the jdk11u repository: > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.9/ > > Changes in jdk-11.0.9+11: > - JDK-8233624: Enhance JNI linkage > - JDK-8236196: Improve string pooling > - JDK-8236862: Enhance support of Proxy class > - JDK-8237990: Enhanced LDAP contexts > - JDK-8237995: Enhance certificate processing > - JDK-8240124: Better VM Interning > - JDK-8241114: Better range handling > - JDK-8242680: Improved URI Support > - JDK-8242685: Better Path Validation > - JDK-8242695: Enhanced buffer support > - JDK-8243302: Advanced class supports > - JDK-8244136: Improved Buffer supports > - JDK-8244479: Further constrain certificates > - JDK-8244955: Additional Fix for JDK-8240124 > - JDK-8245407: Enhance zoning of times > - JDK-8245412: Better class definitions > - JDK-8245417: Improve certificate chain handling > - JDK-8248574: Improve jpeg processing > - JDK-8249927: Specify limits of jdk.serialProxyInterfaceLimit > - JDK-8253019: Enhanced JPEG decoding > > Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, > ppc64le, aarch32 & aarch64. > > Ok to push? > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From yan at azul.com Wed Oct 21 06:33:58 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 21 Oct 2020 09:33:58 +0300 Subject: [13u] RFR: jdk-13.0.5+3/jdk-13.0.5-ga Message-ID: <9052315f-f520-e141-9fed-dbd587d4d8ae@azul.com> Hi all, this is a final set of changes for jdk-13.0.5, please take a look Webrev see in http://cr.openjdk.java.net/~yan/jdk-13.0.5-webrev/webrev.00/ Changes list: JDK-8233624: Enhance JNI linkage JDK-8241114: Better range handling JDK-8236862: Enhance support of Proxy class JDK-8237990: Enhanced LDAP contexts JDK-8244955: Additional Fix for JDK-8240124 JDK-8240124: Better VM Interning JDK-8253019: Enhanced JPEG decoding JDK-8248574: Improve jpeg processing JDK-8245412: Better class definitions JDK-8244136: Improved Buffer supports JDK-8242685: Better Path Validation JDK-8245417: Improve certificate chain handling JDK-8244479: Further constrain certificates JDK-8236196: Improve string pooling JDK-8243302: Advanced class supports JDK-8245407: Enhance zoning of times JDK-8242695: Enhanced buffer support JDK-8237995: Enhance certificate processing JDK-8242680: Improved URI Support The result tagged with jdk-13.0.5+3 and jdk-13.0.5-ga. This state of 13u repository was built and tested on Linux (i686, x86_64), Windows (i686, x86_64), and macOS (x86_64) platforms. OK to push? Thank you! --yan From shade at redhat.com Wed Oct 21 06:40:31 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Oct 2020 08:40:31 +0200 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: <20201021055915.GC2428148@stopbrexit> References: <20201021055915.GC2428148@stopbrexit> Message-ID: <4d61be03-d402-e73c-bf04-f2c87361f692@redhat.com> On 10/21/20 7:59 AM, Andrew Hughes wrote: > Here are the remaining changes for the jdk11u repository: > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.9/ *) What is the changes in: src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.java src/java.base/share/classes/sun/security/util/CurveDB.java src/java.base/share/conf/security/java.security src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/ECDSAUtils.java src/jdk.crypto.ec/share/native/libsunec/impl/ecl-curve.h src/jdk.crypto.ec/share/native/libsunec/impl/ecl.c src/jdk.crypto.ec/share/native/libsunec/impl/oid.c test/jdk/sun/security/ec/TestEC.java test/jdk/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java They are not recorded to belong to any particular changeset. And as far as I can see, there are no symmetric change in 8u CPU. *) As well as in 8u CPU, src/share/native/sun/awt/image/jpeg/jdhuff.c src/share/native/sun/awt/image/jpeg/jdinput.c src/share/native/sun/awt/image/jpeg/jdmarker.c src/share/native/sun/awt/image/jpeg/jpeglib.h ...seem weirdly empty. They are intended to be that way, right? > Ok to push? Well, I am concerned about seemingly unaccounted files above. Please verify what is up with those first? -- Thanks, -Aleksey From christoph.langer at sap.com Wed Oct 21 07:11:23 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 21 Oct 2020 07:11:23 +0000 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: <4d61be03-d402-e73c-bf04-f2c87361f692@redhat.com> References: <20201021055915.GC2428148@stopbrexit> <4d61be03-d402-e73c-bf04-f2c87361f692@redhat.com> Message-ID: Hi, to me it looks as if the webrev was generated on a branch that contains other local changes, e.g. in make/lib/Lib-jdk.crypto.ec.gmk as well. So, those of course mustn't be bushed. I guess the correct patchset is contained in https://cr.openjdk.java.net/~andrew/openjdk11/11.0.9/jdk11.changeset, right? Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Mittwoch, 21. Oktober 2020 08:41 > To: Andrew Hughes ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [RFR] [11u] 11.0.9+11 / 11.0.9-ga > > On 10/21/20 7:59 AM, Andrew Hughes wrote: > > Here are the remaining changes for the jdk11u repository: > > > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.9/ > > *) What is the changes in: > > src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.jav > a > src/java.base/share/classes/sun/security/util/CurveDB.java > src/java.base/share/conf/security/java.security > > src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/securit > y/algorithms/implementations/ECDSAUtils.java > src/jdk.crypto.ec/share/native/libsunec/impl/ecl-curve.h > src/jdk.crypto.ec/share/native/libsunec/impl/ecl.c > src/jdk.crypto.ec/share/native/libsunec/impl/oid.c > test/jdk/sun/security/ec/TestEC.java > test/jdk/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java > > They are not recorded to belong to any particular changeset. And as far as I > can see, there are no > symmetric change in 8u CPU. > > > *) As well as in 8u CPU, > src/share/native/sun/awt/image/jpeg/jdhuff.c > src/share/native/sun/awt/image/jpeg/jdinput.c > src/share/native/sun/awt/image/jpeg/jdmarker.c > src/share/native/sun/awt/image/jpeg/jpeglib.h > > ...seem weirdly empty. They are intended to be that way, right? > > > > Ok to push? > > Well, I am concerned about seemingly unaccounted files above. Please verify > what is up with those first? > > -- > Thanks, > -Aleksey From aph at redhat.com Wed Oct 21 08:26:16 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Oct 2020 09:26:16 +0100 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: References: <20201021055915.GC2428148@stopbrexit> Message-ID: <4b0b94d0-b26b-8f74-6b26-9e9d3876f09b@redhat.com> On 21/10/2020 07:16, Langer, Christoph wrote: > I think this kind of review is not necessary and does not help the release process. We should really consider dropping it and fully trust the reviews on vuln-dev and your build/test pipeline. There are ttwo things going on here: one is the review, which is fairly pefunctory, and one is the announcement and the clear traceable documentatation of what has happened. Maybe we could lose the first, but the documentation is very good to have. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gouessej at orange.fr Wed Oct 21 08:32:27 2020 From: gouessej at orange.fr (gouessej at orange.fr) Date: Wed, 21 Oct 2020 10:32:27 +0200 (CEST) Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: <20201021055915.GC2428148@stopbrexit> References: <20201021055915.GC2428148@stopbrexit> Message-ID: <1478951699.2380.1603269147960.JavaMail.www@wwinf1m14> Sorry, maybe I'm missing something but where is the backport of the fix about the regression in Swing I mentioned several months ago? https://bugs.openjdk.java.net/browse/JDK-8203281 ? ? ? > Message du 21/10/20 08:00 > De : "Andrew Hughes" > A : jdk-updates-dev at openjdk.java.net > Copie ? : > Objet : [RFR] [11u] 11.0.9+11 / 11.0.9-ga > > Here are the remaining changes for the jdk11u repository: > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.9/ > > Changes in jdk-11.0.9+11: > - JDK-8233624: Enhance JNI linkage > - JDK-8236196: Improve string pooling > - JDK-8236862: Enhance support of Proxy class > - JDK-8237990: Enhanced LDAP contexts > - JDK-8237995: Enhance certificate processing > - JDK-8240124: Better VM Interning > - JDK-8241114: Better range handling > - JDK-8242680: Improved URI Support > - JDK-8242685: Better Path Validation > - JDK-8242695: Enhanced buffer support > - JDK-8243302: Advanced class supports > - JDK-8244136: Improved Buffer supports > - JDK-8244479: Further constrain certificates > - JDK-8244955: Additional Fix for JDK-8240124 > - JDK-8245407: Enhance zoning of times > - JDK-8245412: Better class definitions > - JDK-8245417: Improve certificate chain handling > - JDK-8248574: Improve jpeg processing > - JDK-8249927: Specify limits of jdk.serialProxyInterfaceLimit > - JDK-8253019: Enhanced JPEG decoding > > Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, > ppc64le, aarch32 & aarch64. > > Ok to push? > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > From shade at redhat.com Wed Oct 21 08:35:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Oct 2020 10:35:06 +0200 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: <1478951699.2380.1603269147960.JavaMail.www@wwinf1m14> References: <20201021055915.GC2428148@stopbrexit> <1478951699.2380.1603269147960.JavaMail.www@wwinf1m14> Message-ID: On 10/21/20 10:32 AM, gouessej at orange.fr wrote: > Sorry, maybe I'm missing something but where is the backport of the fix about the regression in Swing I mentioned several months ago? > https://bugs.openjdk.java.net/browse/JDK-8203281 This note is about the final push of CPU (security) patches. All previous 11u work is already there, including JDK-8203281 you mention, see how it is in "Fix Version: 11.0.9" in this backport: https://bugs.openjdk.java.net/browse/JDK-8249042 -- Thanks, -Aleksey From gouessej at orange.fr Wed Oct 21 08:38:20 2020 From: gouessej at orange.fr (gouessej at orange.fr) Date: Wed, 21 Oct 2020 10:38:20 +0200 (CEST) Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: References: <20201021055915.GC2428148@stopbrexit> <1478951699.2380.1603269147960.JavaMail.www@wwinf1m14> Message-ID: <1174795107.2518.1603269500663.JavaMail.www@wwinf1m14> Sorry for the misunderstanding. Thanks. ? ? > Message du 21/10/20 10:35 > De : "Aleksey Shipilev" > A : gouessej at orange.fr, "Andrew Hughes" , jdk-updates-dev at openjdk.java.net > Copie ? : > Objet : Re: [RFR] [11u] 11.0.9+11 / 11.0.9-ga > > On 10/21/20 10:32 AM, gouessej at orange.fr wrote: > > Sorry, maybe I'm missing something but where is the backport of the fix about the regression in Swing I mentioned several months ago? > > https://bugs.openjdk.java.net/browse/JDK-8203281 > > This note is about the final push of CPU (security) patches. > > All previous 11u work is already there, including JDK-8203281 you mention, see how it is in "Fix > Version: 11.0.9" in this backport: https://bugs.openjdk.java.net/browse/JDK-8249042 > > -- > Thanks, > -Aleksey > > From sgehwolf at redhat.com Wed Oct 21 08:53:19 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 21 Oct 2020 10:53:19 +0200 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: <1478951699.2380.1603269147960.JavaMail.www@wwinf1m14> References: <20201021055915.GC2428148@stopbrexit> <1478951699.2380.1603269147960.JavaMail.www@wwinf1m14> Message-ID: <3887d05caea2debe644def772d3c4d648862da1c.camel@redhat.com> On Wed, 2020-10-21 at 10:32 +0200, gouessej at orange.fr wrote: > Sorry, maybe I'm missing something but where is the backport of the > fix about the regression in Swing I mentioned several months ago? > > https://bugs.openjdk.java.net/browse/JDK-8203281 This isn't a security fix, so it wouldn't be listed here. What you saw were the 11.0.9+10 -> 11.0.9+11 changes. The 11.0.9 release announcement will have the full changelog. Anyway, JDK-8203281 got fixed in 11.0.9+1[1]. 11.0.9+11 is a later build which has the fix and also the security update. You can test it here with the just released build here: https://adoptopenjdk.net/upstream.html?variant=openjdk11&ga=ga Thanks, Severin [1] https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/tag/jdk-11.0.9%2B1 From sgehwolf at redhat.com Wed Oct 21 09:17:03 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 21 Oct 2020 11:17:03 +0200 Subject: [11u] RFR: 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities In-Reply-To: <6ee2cb0b8081e95781d324876dc0370405cc8171.camel@redhat.com> References: <6ee2cb0b8081e95781d324876dc0370405cc8171.camel@redhat.com> Message-ID: Gentle reminder. Anyone? On Fri, 2020-10-09 at 18:18 +0200, Severin Gehwolf wrote: > Hi, > > Please review this backport for Oracle 11.0.10 parity. The jdk-jdk > patch needs to be significantly reworked since JDK 15+ has the cgroups > v2 patches. The gist of the change is to only report memory values if > swap accounting is disabled on the system (i.e. no swap memory) for > metrics which would otherwise report values for memory + swap. > > Here is the list of changes I've done as compared to the JDK 16 patch: > > * Drop ProblemList.txt hunks. The test was not problem-listed in > OpenJDK 11u. It's not applicable. > * Dropped hunk in test/hotspot/jtreg/containers/cgroup/PlainRead.java, > which also is not applicable (cgroups v2 and later refactorings > related). > * Moved changes from CgroupV1Subsystem.java to cgroupv1/Metrics.java > class. That's where the code lived prior the cgroups v2 addition. > * Moved code changes from CgroupV1MemorySubSystemController.java to > MemorySubsystem in SubSystem.java > * test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java > adjusted since JDK-8226575 for JDK 11 was different to JDK 15 (no > new methods) > * MetricsMemoryTester.java the code is again different in JDK 15+ > because of JDK-8231111. But the changes for this bug only move it > into a conditional testing whether swap is enabled and only test if > it is. > * MetricsTesterCgroupV1 => MetricsTester > > Bug: https://bugs.openjdk.java.net/browse/JDK-8250984 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250984/01/webrev/ > > Testing: Container tests on a system with swapaccount=0 and on a system > with it enabled on Linux x86_64. Tests mentioned in the bug failed > before, pass after. > > Thoughts? > > Thanks, > Severin From shade at redhat.com Wed Oct 21 09:32:11 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Oct 2020 11:32:11 +0200 Subject: [13u] RFR: jdk-13.0.5+3/jdk-13.0.5-ga In-Reply-To: <9052315f-f520-e141-9fed-dbd587d4d8ae@azul.com> References: <9052315f-f520-e141-9fed-dbd587d4d8ae@azul.com> Message-ID: On 10/21/20 8:33 AM, Yuri Nesterenko wrote: > Hi all, > > this is a final set of changes for jdk-13.0.5, please take a look > > Webrev see in http://cr.openjdk.java.net/~yan/jdk-13.0.5-webrev/webrev.00/ These look fine to me. Minor nit: *) As well as in other CPUs: src/share/native/sun/awt/image/jpeg/jdhuff.c src/share/native/sun/awt/image/jpeg/jdinput.c src/share/native/sun/awt/image/jpeg/jdmarker.c src/share/native/sun/awt/image/jpeg/jpeglib.h ...seem weirdly empty. They are intended to be that way, right? > OK to push? Yes, I think so. -- Thanks, -Aleksey From yan at azul.com Wed Oct 21 09:58:25 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 21 Oct 2020 12:58:25 +0300 Subject: [13u] RFR: jdk-13.0.5+3/jdk-13.0.5-ga In-Reply-To: References: <9052315f-f520-e141-9fed-dbd587d4d8ae@azul.com> Message-ID: As to the empty files, that is cumulative to avoid a regression. A work done over a closed loop is zero :-) Thank you! I'm pushing. --yan On 21.10.2020 12:32, Aleksey Shipilev wrote: > On 10/21/20 8:33 AM, Yuri Nesterenko wrote: >> Hi all, >> >> this is a final set of changes for jdk-13.0.5, please take a look >> >> Webrev see in http://cr.openjdk.java.net/~yan/jdk-13.0.5-webrev/webrev.00/ > > These look fine to me. Minor nit: > > *) As well as in other CPUs: > ???? src/share/native/sun/awt/image/jpeg/jdhuff.c > ???? src/share/native/sun/awt/image/jpeg/jdinput.c > ???? src/share/native/sun/awt/image/jpeg/jdmarker.c > ???? src/share/native/sun/awt/image/jpeg/jpeglib.h > > ? ...seem weirdly empty. They are intended to be that way, right? > >> OK to push? > > Yes, I think so. > From shade at redhat.com Wed Oct 21 10:29:34 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Oct 2020 12:29:34 +0200 Subject: [15u] 15.0.1 release? Message-ID: <66a88834-0154-4721-3443-27ff7fee5763@redhat.com> Hi, I see Oracle had released 15.0.1 binaries here: https://jdk.java.net/15/ ...but there are no sources yet here: https://hg.openjdk.java.net/jdk-updates/jdk15u Rob (or other 15u maintainers), could you please push the 15.0.1 to Mercurial repos? -- Thanks, -Aleksey From shade at redhat.com Wed Oct 21 10:43:43 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Oct 2020 12:43:43 +0200 Subject: [11u] RFR: 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities In-Reply-To: References: <6ee2cb0b8081e95781d324876dc0370405cc8171.camel@redhat.com> Message-ID: On 10/21/20 11:17 AM, Severin Gehwolf wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8250984 >> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250984/01/webrev/ Looks fine to me. -- Thanks, -Aleksey From rob.mckenna at oracle.com Wed Oct 21 14:18:45 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 21 Oct 2020 15:18:45 +0100 Subject: [Updates Communication] 15.0.1 security patches pushed Message-ID: <20201021141845.GA31905@DESKTOP-JNNKIHU.localdomain> Apologies for the delay. -Rob From christoph.langer at sap.com Wed Oct 21 14:24:10 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 21 Oct 2020 14:24:10 +0000 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: <20201021055915.GC2428148@stopbrexit> References: <20201021055915.GC2428148@stopbrexit> Message-ID: Hi, when can we expect a push of the release to the Mercurial repository (http://hg.openjdk.java.net/jdk-updates/jdk11u)? Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Hughes > Sent: Mittwoch, 21. Oktober 2020 07:59 > To: jdk-updates-dev at openjdk.java.net > Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga > > Here are the remaining changes for the jdk11u repository: > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.9/ > > Changes in jdk-11.0.9+11: > - JDK-8233624: Enhance JNI linkage > - JDK-8236196: Improve string pooling > - JDK-8236862: Enhance support of Proxy class > - JDK-8237990: Enhanced LDAP contexts > - JDK-8237995: Enhance certificate processing > - JDK-8240124: Better VM Interning > - JDK-8241114: Better range handling > - JDK-8242680: Improved URI Support > - JDK-8242685: Better Path Validation > - JDK-8242695: Enhanced buffer support > - JDK-8243302: Advanced class supports > - JDK-8244136: Improved Buffer supports > - JDK-8244479: Further constrain certificates > - JDK-8244955: Additional Fix for JDK-8240124 > - JDK-8245407: Enhance zoning of times > - JDK-8245412: Better class definitions > - JDK-8245417: Improve certificate chain handling > - JDK-8248574: Improve jpeg processing > - JDK-8249927: Specify limits of jdk.serialProxyInterfaceLimit > - JDK-8253019: Enhanced JPEG decoding > > Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, > ppc64le, aarch32 & aarch64. > > Ok to push? > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From yan at azul.com Wed Oct 21 14:43:48 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 21 Oct 2020 17:43:48 +0300 Subject: OpenJDK 13.0.5 released Message-ID: Let me announce the release of OpenJDK 13.0.5. The release sources are still in the usual place, get them to build from https://hg.openjdk.java.net/jdk-updates/jdk13u Note that this repository most probably will not be updated any more; instead, https://github.com/openjdk/jdk13u will be used for official releases starting from early November. Until then, https://github.com/openjdk/jdk13u is still a read-only git mirror. A list of fixes please see below. Also, a nicely generated list could be found, again, at A. Shipilev's site: https://builds.shipilev.net/backports-monitor/release-notes-13.0.5.txt ============================================ Security fixes: JDK-8233624: Enhance JNI linkage JDK-8241114: Better range handling JDK-8236862: Enhance support of Proxy class JDK-8237990: Enhanced LDAP contexts JDK-8244955: Additional Fix for JDK-8240124 JDK-8240124: Better VM Interning JDK-8253019: Enhanced JPEG decoding JDK-8248574: Improve jpeg processing JDK-8245412: Better class definitions JDK-8244136: Improved Buffer supports JDK-8242685: Better Path Validation JDK-8245417: Improve certificate chain handling JDK-8244479: Further constrain certificates JDK-8236196: Improve string pooling JDK-8243302: Advanced class supports JDK-8245407: Enhance zoning of times JDK-8242695: Enhanced buffer support JDK-8237995: Enhance certificate processing JDK-8242680: Improved URI Support Other fixes: JDK-8241602: jlink does not produce reproducible jimage files JDK-8232864: Classes generated at link time by GenerateJLIClassesPlugin are not reproducible JDK-8231449: HttpClient?s client ssl certificate authentication seems to be broken. JDK-8244818: Java2D Queue Flusher crash while moving application window to external monitor JDK-8252497: Incorrect numeric currency code for ROL JDK-8230094: CCE in createXMLEventWriter(Result) over an arbitrary XMLStreamWriter JDK-8250609: C2 crash in IfNode::fold_compares JDK-8249278: Revert JDK-8226253 which breaks the spec of AccessibleState.SHOWING for JList JDK-8248851: CMS: Missing memory fences between free chunk check and klass read JDK-8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC JDK-8248348: Regression caused by the update to BCEL 6.0 JDK-8248495: [macos] zerovm is broken due to libffi headers location JDK-8243470: [macos] bring back O2 opt level for unsafe.cpp JDK-8238284: [macos] Zero VM build fails due to an obvious typo JDK-8240360: NativeLibraryEvent has wrong library name on Linux JDK-8233787: Break cycle in vm_version* includes JDK-8247873: [arm32] client vm build failure JDK-8234645: ARM32: C1: PatchingStub for field access: not enough bytes JDK-8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint JDK-8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power JDK-8244777: ClassLoaderStats VM Op uses constant hash value A team repository is open at: https://github.com/openjdk/jdk13u-dev Please read https://wiki.openjdk.java.net/display/SKARA about contribution rules. Note, however, that process of contributing of a backport in Skara is still a work in progress. The next release 13.0.6 is due on January 19, 2021 Thanks, --yan From shade at redhat.com Wed Oct 21 15:13:19 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Oct 2020 17:13:19 +0200 Subject: [15u] RFR (S) 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <7ff73194-0ef0-84f4-fbfb-db3245152afc@oracle.com> References: <3dc236a9-2f44-8226-af1d-22fb2187a8fc@redhat.com> <471accdf-9672-0f43-114b-919b09d27e1f@redhat.com> <20a23d12-cd7a-2e8d-f6e0-28e7fb39c798@oracle.com> <7ec5082b-3bcf-2ae8-ef99-7286409d4062@redhat.com> <7ff73194-0ef0-84f4-fbfb-db3245152afc@oracle.com> Message-ID: <19c3b951-38ef-47e3-8ea4-2bbb71de05a7@redhat.com> Hi again, Mostly the question to Rob: On 9/16/20 2:20 PM, Harold Seigel wrote: > Since this fix was backported to JDK15-CPU, it will be in the 15.0.2 > release.? You do not need to do a separate backport to JDK-15u. I am sorry, this is very confusing. I believe JDK 15.0.1 had been just integrated to jdk-updates/jdk15u. There is *no* 8249192 seen in 15.0.2 that (I assume) include the CPU repos: https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8249192 There is still the "Resolved" backport without any reference to the changeset: https://bugs.openjdk.java.net/browse/JDK-8251485 Is there some *other* repository where this CR was backported to? That is, is there the private 15.0.2 CPU repo? Even in this case, can we push the change to open 15.0.2, so we would be able to test it before next CPU hits? -- Thanks, -Aleksey From shade at redhat.com Wed Oct 21 15:13:32 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Oct 2020 17:13:32 +0200 Subject: [15u] RFR (S) 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <7ff73194-0ef0-84f4-fbfb-db3245152afc@oracle.com> References: <3dc236a9-2f44-8226-af1d-22fb2187a8fc@redhat.com> <471accdf-9672-0f43-114b-919b09d27e1f@redhat.com> <20a23d12-cd7a-2e8d-f6e0-28e7fb39c798@oracle.com> <7ec5082b-3bcf-2ae8-ef99-7286409d4062@redhat.com> <7ff73194-0ef0-84f4-fbfb-db3245152afc@oracle.com> Message-ID: Hi again, Mostly the question to Rob: On 9/16/20 2:20 PM, Harold Seigel wrote: > Since this fix was backported to JDK15-CPU, it will be in the 15.0.2 > release.? You do not need to do a separate backport to JDK-15u. I am sorry, this is very confusing. I believe JDK 15.0.1 had been just integrated to jdk-updates/jdk15u. There is *no* 8249192 seen in 15.0.2 that (I assume) include the CPU repos: https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8249192 There is still the "Resolved" backport without any reference to the changeset: https://bugs.openjdk.java.net/browse/JDK-8251485 Is there some *other* repository where this CR was backported to? That is, is there the private 15.0.2 CPU repo? Even in this case, can we push the change to open 15.0.2, so we would be able to test it before next CPU hits? -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Oct 21 16:31:44 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 21 Oct 2020 17:31:44 +0100 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: References: <20201021055915.GC2428148@stopbrexit> <4d61be03-d402-e73c-bf04-f2c87361f692@redhat.com> Message-ID: <20201021163144.GA2458790@stopbrexit> On 07:11 Wed 21 Oct , Langer, Christoph wrote: > Hi, > > to me it looks as if the webrev was generated on a branch that contains other local changes, e.g. in make/lib/Lib-jdk.crypto.ec.gmk as well. So, those of course mustn't be bushed. > > I guess the correct patchset is contained in https://cr.openjdk.java.net/~andrew/openjdk11/11.0.9/jdk11.changeset, right? > > Thanks > Christoph > Ugh, yes, I really wish webrev would do one or the other and not include local changes when there are changes in the outgoing queue. They should be gone now. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Oct 21 16:32:09 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 21 Oct 2020 17:32:09 +0100 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: References: <20201021055915.GC2428148@stopbrexit> Message-ID: <20201021163209.GB2458790@stopbrexit> On 14:24 Wed 21 Oct , Langer, Christoph wrote: > Hi, > > when can we expect a push of the release to the Mercurial repository (http://hg.openjdk.java.net/jdk-updates/jdk11u)? > > Thanks > Christoph > When it's successfully reviewed. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Oct 21 16:36:06 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 21 Oct 2020 17:36:06 +0100 Subject: OpenJDK 11.0.9 Released Message-ID: <20201021163606.GC2458790@stopbrexit> We are pleased to announce the release of OpenJDK 11.0.9. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.9-ga.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.9-ga.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 94b83faa3db395892d0c84d35bbbb194233c291a6bee2d1a43e0a72e49348b18 openjdk-11.0.9-ga.tar.xz 4889dcb9bbece673410ea68a35580dc45818c75e33f91394b06ceca387dd22f4 openjdk-11.0.9-ga.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.9-ga.sha256 New in release OpenJDK 11.0.9 (2020-10-20): =========================================== Live versions of these release notes can be found at: * https://bitly.com/openjdk1109 * https://builds.shipilev.net/backports-monitor/release-notes-11.0.9.txt * New features - JDK-8250784: Shenandoah: A Low-Pause-Time Garbage Collector * Security fixes - JDK-8233624: Enhance JNI linkage - JDK-8236196: Improve string pooling - JDK-8236862, CVE-2020-14779: Enhance support of Proxy class - JDK-8237990, CVE-2020-14781: Enhanced LDAP contexts - JDK-8237995, CVE-2020-14782: Enhance certificate processing - JDK-8240124: Better VM Interning - JDK-8241114, CVE-2020-14792: Better range handling - JDK-8242680, CVE-2020-14796: Improved URI Support - JDK-8242685, CVE-2020-14797: Better Path Validation - JDK-8242695, CVE-2020-14798: Enhanced buffer support - JDK-8243302: Advanced class supports - JDK-8244136, CVE-2020-14803: Improved Buffer supports - JDK-8244479: Further constrain certificates - JDK-8244955: Additional Fix for JDK-8240124 - JDK-8245407: Enhance zoning of times - JDK-8245412: Better class definitions - JDK-8245417: Improve certificate chain handling - JDK-8248574: Improve jpeg processing - JDK-8249927: Specify limits of jdk.serialProxyInterfaceLimit - JDK-8253019: Enhanced JPEG decoding * Other changes - JDK-6532025: GIF reader throws misleading exception with truncated images - JDK-6949753: [TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop - JDK-8022535: [TEST BUG] javax/swing/text/html/parser/Test8017492.java fails - JDK-8062947: Fix exception message to correctly represent LDAP connection failure - JDK-8067354: com/sun/jdi/GetLocalVariables4Test.sh failed - JDK-8134599: TEST_BUG: java/rmi/transport/closeServerSocket/CloseServerSocket.java fails intermittently with Address already in use - JDK-8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect - JDK-8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider - JDK-8172404: Tools should warn if weak algorithms are used before restricting them - JDK-8193367: Annotated type variable bounds crash javac - JDK-8202117: com/sun/jndi/ldap/RemoveNamingListenerTest.java fails intermittently: Connection reset - JDK-8203026: java.rmi.NoSuchObjectException: no such object in table - JDK-8203281: [Windows] JComboBox change in ui when editor.setBorder() is called - JDK-8203382: Rename SystemDictionary::initialize_wk_klass to resolve_wk_klass - JDK-8203393: com/sun/jdi/JdbMethodExitTest.sh and JdbExprTest.sh fail due to timeout - JDK-8203928: [Test] Convert non-JDB scaffolding serviceability shell script tests to java - JDK-8204963: javax.swing.border.TitledBorder has a memory leak - JDK-8204994: SA might fail to attach to process with "Windbg Error: WaitForEvent failed" - JDK-8205534: Remove SymbolTable dependency from serviceability agent - JDK-8206309: Tier1 SA tests fail - JDK-8208281: java/nio/channels/AsynchronousSocketChannel/Basic.java timed out - JDK-8209109: [TEST] rewrite com/sun/jdi shell tests to java version - step1 - JDK-8209332: [TEST] test/jdk/com/sun/jdi/CatchPatternTest.sh is incorrect - JDK-8209342: Problemlist SA tests on Solaris due to Error attaching to process: Can't create thread_db agent! - JDK-8209343: Test javax/swing/border/TestTitledBorderLeak.java should be marked as headful - JDK-8209517: com/sun/jdi/BreakpointWithFullGC.java fails with timeout - JDK-8209604: [TEST] rewrite com/sun/jdi shell tests to java version - step2 - JDK-8209605: com/sun/jdi/BreakpointWithFullGC.java fails with ZGC - JDK-8209608: Problem list com/sun/jdi/BreakpointWithFullGC.java - JDK-8210131: vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code - JDK-8210243: [TEST] rewrite com/sun/jdi shell tests to java version - step3 - JDK-8210527: JShell: NullPointerException in jdk.jshell.Eval.translateExceptionStack - JDK-8210560: [TEST] convert com/sun/jdi redefineClass-related tests - JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds - JDK-8210748: [TESTBUG] lib.jdb.Jdb.waitForPrompt() should clarify which output is the pending reply after a timeout - JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 - JDK-8210977: jdk/jfr/event/oldobject/TestThreadLocalLeak.java fails to find ThreadLocalObject - JDK-8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test - JDK-8211694: JShell: Redeclared variable should be reset - JDK-8212200: assert when shared java.lang.Object is redefined by JVMTI agent - JDK-8212629: [TEST] wrong breakpoint in test/jdk/com/sun/jdi/DeferredStepTest - JDK-8212665: com/sun/jdi/DeferredStepTest.java: jj1 (line 57) - unexpected. lastLine=52, minLine=52, maxLine=55 - JDK-8212807: tools/jar/multiRelease/Basic.java times out - JDK-8213182: Minimal VM build failure after JDK-8212200 (assert when shared java.lang.Object is redefined by JVMTI agent) - JDK-8213214: Set -Djava.io.tmpdir= when running tests - JDK-8213275: ReplaceCriticalClasses.java fails with jdk.internal.vm.PostVMInitHook not found - JDK-8213574: Deadlock in string table expansion when dumping lots of CDS classes - JDK-8213703: LambdaConversionException: Invalid receiver type not a subtype of implementation type interface - JDK-8214074: Ghash optimization using AVX instructions - JDK-8214491: Upgrade to JLine 3.9.0 - JDK-8214797: TestJmapCoreMetaspace.java timed out - JDK-8215243: JShell tests failing intermitently with \"Problem cleaning up the following threads:\" - JDK-8215244: jdk/jshell/ToolBasicTest.java testHistoryReference failed - JDK-8215354: x86_32 build failures after JDK-8214074 (Ghash optimization using AVX instructions) - JDK-8215438: jshell tool: Ctrl-D causes EOF - JDK-8216021: RunTest.gmk might set concurrency level to 1 on Windows - JDK-8216974: HttpConnection not returned to the pool after 204 response - JDK-8218948: SimpleDateFormat :: format - Zone Names are not reflected correctly during run time - JDK-8219712: code_size2 (defined in stub_routines_x86.hpp) is too small on new Skylake CPUs - JDK-8220150: macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs - JDK-8221658: aarch64: add necessary predicate for ubfx patterns - JDK-8221759: Crash when completing \"java.io.File.path\" - JDK-8221918: runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java fails: Shared archive not found - JDK-8222074: Enhance auto vectorization for x86 - JDK-8222079: Don't use memset to initialize fields decode_env constructor in disassembler.cpp - JDK-8222769: [TESTBUG] TestJFRNetworkEvents should not rely on hostname command - JDK-8223688: JShell: crash on the instantiation of raw anonymous class - JDK-8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error - JDK-8223940: Private key not supported by chosen signature algorithm - JDK-8224184: jshell got IOException at exiting with AIX - JDK-8224234: compiler/codegen/TestCharVect2.java fails in test_mulc - JDK-8225037: java.net.JarURLConnection::getJarEntry() throws NullPointerException - JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimization using AVX512 + VAES instructions - JDK-8226536: Catch OOM from deopt that fails rematerializing objects - JDK-8226575: OperatingSystemMXBean should be made container aware - JDK-8226697: Several tests which need the @key headful keyword are missing it. - JDK-8226809: Circular reference in printed stack trace is not correctly indented & ambiguous - JDK-8227059: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timed out - JDK-8227269: Slow class loading when running with JDWP - JDK-8227595: keytool/fakegen/DefaultSignatureAlgorithm.java fails due to "exitValue = 6" - JDK-8228448: Jconsole can't connect to itself - JDK-8228967: Trust/Key store and SSL context utilities for tests - JDK-8229378: jdwp library loader in linker_md.c quietly truncates on buffer overflow - JDK-8229815: Upgrade Jline to 3.12.1 - JDK-8230000: some httpclients testng tests run zero test - JDK-8230002: javax/xml/jaxp/unittest/transform/SecureProcessingTest.java runs zero test - JDK-8230010: Remove jdk8037819/BasicTest1.java - JDK-8230094: CCE in createXMLEventWriter(Result) over an arbitrary XMLStreamWriter - JDK-8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?" - JDK-8230767: FlightRecorderListener returns null recording - JDK-8230870: (zipfs) Add a ZIP FS test that is similar to test/jdk/java/util/zip/EntryCount64k.java - JDK-8231209: [REDO] ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread - JDK-8231586: enlarge encoding space for OopMapValue offsets - JDK-8231953: Wrong assumption in assertion in oop::register_oop - JDK-8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes - JDK-8232083: Minimal VM is broken after JDK-8231586 - JDK-8232161: Align some one-way conversion in MS950 charset with Windows - JDK-8232855: jshell missing word in /help help - JDK-8233027: OopMapSet::all_do does oms.next() twice during iteration - JDK-8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR - JDK-8233386: Initialize NULL fields for unused decorations - JDK-8233452: java.math.BigDecimal.sqrt() with RoundingMode.FLOOR results in incorrect result - JDK-8233686: XML transformer uses excessive amount of memory - JDK-8233741: AES Countermode (AES-CTR) optimization using AVX512 + VAES instructions - JDK-8233829: javac cannot find non-ASCII module name under non-UTF8 environment - JDK-8233958: Memory retention due to HttpsURLConnection finalizer that serves no purpose - JDK-8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() - JDK-8234058: runtime/CompressedOops/CompressedClassPointers.java fails with 'Narrow klass base: 0x0000000000000000' missing from stdout/stderr - JDK-8234149: Several regression tests do not dispose Frame at end - JDK-8234347: "Turkey" meta time zone does not generate composed localized names - JDK-8234385: [TESTBUG] java/awt/EventQueue/6980209/bug6980209.java fails in linux nightly - JDK-8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC - JDK-8234541: C1 emits an empty message when it inlines successfully - JDK-8234687: change javap reporting on unknown attributes - JDK-8236464: SO_LINGER option is ignored by SSLSocket in JDK 11 - JDK-8236548: Localized time zone name inconsistency between English and other locales - JDK-8236617: jtreg test containers/docker/TestMemoryAwareness.java fails after 8226575 - JDK-8237182: Update copyright header for shenandoah and epsilon files - JDK-8237888: security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java fails when checking validity interval - JDK-8237977: Further update javax/net/ssl/compatibility/Compatibility.java - JDK-8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response - JDK-8238284: [macos] Zero VM build fails due to an obvious typo - JDK-8238380: java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10 - JDK-8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10 - JDK-8238388: libj2gss/NativeFunc.o "multiple definition" link errors with GCC10 - JDK-8238448: RSASSA-PSS signature verification fail when using certain odd key sizes - JDK-8238710: LingeredApp doesn't log stdout/stderr if exits with non-zero code - JDK-8239083: C1 assert(known_holder == NULL || (known_holder->is_instance_klass() && (!known_holder->is_interface() || ((ciInstanceKlass*)known_holder)->has_nonstatic_concrete_methods())), "should be non-static concrete method"); - JDK-8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD - JDK-8240169: javadoc fails to link to non-modular api docs - JDK-8240295: hs_err elapsed time in seconds is not accurate enough - JDK-8240360: NativeLibraryEvent has wrong library name on Linux - JDK-8240676: Meet not symmetric failure when running lucene on jdk8 - JDK-8241007: Shenandoah: remove ShenandoahCriticalControlThreadPriority support - JDK-8241065: Shenandoah: remove leftover code after JDK-8231086 - JDK-8241086: Test runtime/NMT/HugeArenaTracking.java is failing on 32bit Windows - JDK-8241130: com.sun.jndi.ldap.EventSupport.removeDeadNotifier: java.lang.NullPointerException - JDK-8241138: http.nonProxyHosts=* causes StringIndexOutOfBoundsException in DefaultProxySelector - JDK-8241319: WB_GetCodeBlob doesn't have ResourceMark - JDK-8241478: vmTestbase/gc/gctests/Steal/steal001/steal001.java fails with OOME - JDK-8241574: Shenandoah: remove ShenandoahAssertToSpaceClosure - JDK-8241750: x86_32 build failure after JDK-8227269 - JDK-8242184: CRL generation error with RSASSA-PSS - JDK-8242283: Can't start JVM when java home path includes non-ASCII character - JDK-8242556: Cannot load RSASSA-PSS public key with non-null params from byte array - JDK-8243029: Rewrite javax/net/ssl/compatibility/Compatibility.java with a flexible interop test framework - JDK-8243138: Enhance BaseLdapServer to support starttls extended request - JDK-8243320: Add SSL root certificates to Oracle Root CA program - JDK-8243321: Add Entrust root CA - G4 to Oracle Root CA program - JDK-8243389: enhance os::pd_print_cpu_info on linux - JDK-8243453: java --describe-module failed with non-ASCII module name under non-UTF8 environment - JDK-8243470: [macos] bring back O2 opt level for unsafe.cpp - JDK-8243489: Thread CPU Load event may contain wrong data for CPU time under certain conditions - JDK-8243925: Toolkit#getScreenInsets() returns wrong value on HiDPI screens (Windows) - JDK-8244087: 2020-04-24 public suffix list update - JDK-8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26 - JDK-8244164: AArch64: jaotc generates incorrect code for compressed OOPs with non-zero heap base - JDK-8244196: adjust output in os_linux - JDK-8244225: stringop-overflow warning on strncpy call from compile_the_world_in - JDK-8244287: JFR: Methods samples have line number 0 - JDK-8244703: "platform encoding not initialized" exceptions with debugger, JNI - JDK-8244719: CTW: C2 compilation fails with "assert(!VerifyHashTableKeys || _hash_lock == 0) failed: remove node from hash table before modifying it" - JDK-8244729: Shenandoah: remove resolve paths from SBSA::generate_shenandoah_lrb - JDK-8244763: Update --release 8 symbol information after JSR 337 MR3 - JDK-8244818: Java2D Queue Flusher crash while moving application window to external monitor - JDK-8245151: jarsigner should not raise duplicate warnings on verification - JDK-8245616: Bump update version for OpenJDK: jdk-11.0.9 - JDK-8245714: "Bad graph detected in build_loop_late" when loads are pinned on loop limit check uncommon branch - JDK-8245801: StressRecompilation triggers assert "redundunt OSR recompilation detected. memory leak in CodeCache!" - JDK-8245832: JDK build make-static-libs should build all JDK libraries - JDK-8245880: Shenandoah: check class unloading flag early in concurrent code root scan - JDK-8245981: Upgrade to jQuery 3.5.1 - JDK-8246027: Minimal fastdebug build broken after JDK-8245801 - JDK-8246094: [macos] Sound Recording and playback is not working - JDK-8246153: TestEliminateArrayCopy fails with -XX:+StressReflectiveCode - JDK-8246193: Possible NPE in ENC-PA-REP search in AS-REQ - JDK-8246196: javax/management/MBeanServer/OldMBeanServerTest fails with AssertionError - JDK-8246203: Segmentation fault in verification due to stack overflow with -XX:+VerifyIterativeGVN - JDK-8246330: Add TLS Tests for Legacy ECDSA curves - JDK-8246453: TestClone crashes with "all collected exceptions must come from the same place" - JDK-8247246: Add explicit ResolvedJavaType.link and expose presence of default methods - JDK-8247350: [aarch64] assert(false) failed: wrong size of mach node - JDK-8247502: PhaseStringOpts crashes while optimising effectively dead code - JDK-8247615: Initialize the bytes left for the heap sampler - JDK-8247824: CTW: C2 (Shenandoah) compilation fails with SEGV in SBC2Support::pin_and_expand - JDK-8247874: Replacement in VersionProps.java.template not working when --with-vendor-bug-url contains '&' - JDK-8247979: aarch64: missing side effect of killing flags for clearArray_reg_reg - JDK-8248214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention - JDK-8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield - JDK-8248348: Regression caused by the update to BCEL 6.0 - JDK-8248385: [testbug][11u] Adapt TestInitiExceptions to jtreg 5.1 - JDK-8248495: [macos] zerovm is broken due to libffi headers location - JDK-8248851: CMS: Missing memory fences between free chunk check and klass read - JDK-8248987: AOT's Linker.java seems to eagerly fail-fast on Windows - JDK-8249159: Downport test rework for SSLSocketTemplate from 8224650 - JDK-8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8 on Japanese Windows. - JDK-8249251: [dark_mode ubuntu 20.04] The selected menu is not highlighted in GTKLookAndFeel - JDK-8249255: Build fails if source code in cygwin home dir - JDK-8249277: TestVerifyIterativeGVN.java is failing with timeout in OpenJDK 11 - JDK-8249278: Revert JDK-8226253 which breaks the spec of AccessibleState.SHOWING for JList - JDK-8249560: Shenandoah: Fix racy GC request handling - JDK-8249801: Shenandoah: Clear soft-refs on requested GC cycle - JDK-8249953: Shenandoah: gc/shenandoah/mxbeans tests should account for corner cases - JDK-8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets - JDK-8250609: C2 crash in IfNode::fold_compares - JDK-8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics - JDK-8250755: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java - JDK-8250787: Provider.put no longer registering aliases in FIPS env - JDK-8250826: jhsdb does not work with coredump which comes from Substrate VM - JDK-8250827: Shenandoah: needs to reset/finish StringTable's dead count before/after parallel walk - JDK-8250844: Make sure {type,obj}ArrayOopDesc accessors check the bounds - JDK-8251117: Cannot check P11Key size in P11Cipher and P11AEADCipher - JDK-8251354: Shenandoah: Fix jdk/jfr/tool/TestPrintJSON.java test failure - JDK-8251451: Shenandoah: Remark ObjectSynchronizer roots with I-U - JDK-8251469: Better cleanup for test/jdk/javax/imageio/SetOutput.java - JDK-8251487: Shenandoah: missing detail timing tracking for final mark cleaning phase - JDK-8252120: compiler/oracle/TestCompileCommand.java misspells "occured" - JDK-8252157: JDK-8231209 11u backport breaks jmm binary compatibility - JDK-8252258: [11u] JDK-8242154 changes the default vendor - JDK-8252804: [test] Fix 'ReleaseDeflater.java' test after downport of 8234011 - JDK-8253134: JMM_VERSION should remain at 0x20020000 (JDK 10) in JDK 11 - JDK-8253283: [11u] Test build/translations/VerifyTranslations.java failing after JDK-8252258 - JDK-8253813: Backout JDK-8244287 from 11u: it causes several crashes Notes on individual issues: =========================== core-libs/java.nio.charsets: JDK-8240196: Modified the MS950 charset Encoder's Conversion Table ================================================================== In this release, some of the one-way byte-to-char mappings have been aligned with the preferred mappings provided by the Unicode Consortium (https://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit950.txt). core-libs/java.util:i18n: JDK-8238914: Localized Time Zone Name Inconsistency Between English and Other Locales ===================================================================================== English time zone names provided by the CLDR locale provider are now correctly synthesized following the CLDR spec, rather than substituted from the COMPAT provider. For example, SHORT style names are no longer synthesized abbreviations of LONG style names, but instead produce GMT offset formats. core-svc/java.lang.management: JDK-8236876: OperatingSystemMXBean Methods Inside a Container Return Container Specific Data ============================================================================================ When executing in a container, or other virtualized operating environment, the following `OperatingSystemMXBean` methods in this release return container specific information, if available. Otherwise, they return host specific data: * getFreePhysicalMemorySize() * getTotalPhysicalMemorySize() * getFreeSwapSpaceSize() * getTotalSwapSpaceSize() * getSystemCpuLoad() security-libs/java.security: JDK-8250756: Added Entrust Root Certification Authority - G4 certificate ======================================================================== The Entrust root certificate has been added to the cacerts truststore: Alias Name: entrustrootcag4 Distinguished Name: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US JDK-8250860: Added 3 SSL Corporation Root CA Certificates ========================================================= The following root certificates have been added to the cacerts truststore for the SSL Corporation: Alias Name: sslrootrsaca Distinguished Name: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US Alias Name: sslrootevrsaca Distinguished Name: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US Alias Name: sslrooteccca Distinguished Name: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US JDK-8236730: Weak Named Curves in TLS, CertPath, and Signed JAR Disabled by Default =================================================================================== Weak named curves are disabled by default by adding them to the following `disabledAlgorithms` security properties: * jdk.tls.disabledAlgorithms * jdk.certpath.disabledAlgorithms * jdk.jar.disabledAlgorithms The disabled curves are as follows: * secp112r1 * secp112r2 * secp128r1 * secp128r2 * secp160k1 * secp160r1 * secp160r2 * secp192k1 * secp192r1 * secp224k1 * secp224r1 * secp256k1 * sect113r1 * sect113r2 * sect131r1 * sect131r2 * sect163k1 * sect163r1 * sect163r2 * sect193r1 * sect193r2 * sect233k1 * sect233r1 * sect239k1 * sect283k1 * sect283r1 * sect409k1 * sect409r1 * sect571k1 * sect571r1 * X9.62 c2tnb191v1 * X9.62 c2tnb191v2, * X9.62 c2tnb191v3 * X9.62 c2tnb239v1 * X9.62 c2tnb239v2 * X9.62 c2tnb239v3 * X9.62 c2tnb359v1 * X9.62 c2tnb431r1 * X9.62 prime192v2 * X9.62 prime192v3 * X9.62 prime239v1 * X9.62 prime239v2 * X9.62 prime239v3 * brainpoolP256r1 * brainpoolP320r1 * brainpoolP384r1 * brainpoolP512r1 The curves that remain enabled are: * secp256r1 * secp384r1 * secp521r1 * X25519 * X448 When large numbers of weak named curves need to be disabled, adding individual named curves to each `disabledAlgorithms` property would be overwhelming. To relieve this, a new security property, `jdk.disabled.namedCurves`, is implemented that can list the named curves common to all of the `disabledAlgorithms` properties. To use the new property in the `disabledAlgorithms` properties, precede the full property name with the keyword `include`. Users can still add individual named curves to `disabledAlgorithms` properties separate from this new property. No other properties can be included in the `disabledAlgorithms` properties. To restore the named curves, remove the `include jdk.disabled.namedCurves` either from specific or from all `disabledAlgorithms` security properties. To restore one or more curves, remove the specific named curve(s) from the `jdk.disabled.namedCurves` property. JDK-8244286: Tools Warn If Weak Algorithms Are Used Before Restricting Them =========================================================================== The `keytool` and `jarsigner` tools have been updated to warn users about weak cryptographic algorithms being used before they are disabled. In this release, the tools issue warnings for the SHA-1 hash algorithm and 1024-bit RSA/DSA keys. security-libs/javax.net.ssl: JDK-8242147: New System Properties to Configure the TLS Signature Schemes ========================================================================= Two new system properties have been added to customize the TLS signature schemes in JDK. `jdk.tls.client.SignatureSchemes` has been added for the TLS client side, and `jdk.tls.server.SignatureSchemes` has been added for the server side. Each system property contains a comma-separated list of supported signature scheme names specifying the signature schemes that could be used for the TLS connections. The names are described in the "Signature Schemes" section of the *Java Security Standard Algorithm Names Specification*. security-libs/javax.security: JDK-8242059: Support for canonicalize in krb5.conf ================================================== The 'canonicalize' flag in the [krb5.conf file][0] is now supported by the JDK Kerberos implementation. When set to *true*, RFC 6806 [1] name canonicalization is requested by clients in TGT requests to KDC services (AS protocol). Otherwise, and by default, it is not requested. The new default behavior is different from previous releases where name canonicalization was always requested by clients in TGT requests to KDC services (provided that support for RFC 6806[1] was not explicitly disabled with the *sun.security.krb5.disableReferrals* system or security properties). [0]: https://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html [1]: https://tools.ietf.org/html/rfc6806 Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Wed Oct 21 16:37:44 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 21 Oct 2020 18:37:44 +0200 Subject: [11u] RFR: 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities In-Reply-To: References: <6ee2cb0b8081e95781d324876dc0370405cc8171.camel@redhat.com> Message-ID: <4cf9c533637dd7c0ca30a67e2f785391371a72fe.camel@redhat.com> On Wed, 2020-10-21 at 12:43 +0200, Aleksey Shipilev wrote: > On 10/21/20 11:17 AM, Severin Gehwolf wrote: > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8250984 > > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250984/01/webrev/ > > Looks fine to me. Thanks for the review! Cheers, Severin From gnu.andrew at redhat.com Wed Oct 21 16:38:32 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 21 Oct 2020 17:38:32 +0100 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: <1478951699.2380.1603269147960.JavaMail.www@wwinf1m14> References: <20201021055915.GC2428148@stopbrexit> <1478951699.2380.1603269147960.JavaMail.www@wwinf1m14> Message-ID: <20201021163832.GD2458790@stopbrexit> On 10:32 Wed 21 Oct , gouessej at orange.fr wrote: > Sorry, maybe I'm missing something but where is the backport of the fix about the regression in Swing I mentioned several months ago? > > https://bugs.openjdk.java.net/browse/JDK-8203281 > This is a review request for the security changes for 11.0.9. What you seem to be looking for are the release notes which are now available here: https://bitly.com/openjdk1109 -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Wed Oct 21 16:48:53 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Oct 2020 18:48:53 +0200 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: <20201021163144.GA2458790@stopbrexit> References: <20201021055915.GC2428148@stopbrexit> <4d61be03-d402-e73c-bf04-f2c87361f692@redhat.com> <20201021163144.GA2458790@stopbrexit> Message-ID: On 10/21/20 6:31 PM, Andrew Hughes wrote: > They should be gone now. They are gone indeed. Looks good! Can push now. -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Oct 21 17:47:35 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 21 Oct 2020 18:47:35 +0100 Subject: [RFR] [11u] 11.0.9+11 / 11.0.9-ga In-Reply-To: References: <20201021055915.GC2428148@stopbrexit> <4d61be03-d402-e73c-bf04-f2c87361f692@redhat.com> <20201021163144.GA2458790@stopbrexit> Message-ID: <20201021174735.GF2463725@stopbrexit> On 18:48 Wed 21 Oct , Aleksey Shipilev wrote: > On 10/21/20 6:31 PM, Andrew Hughes wrote: > > They should be gone now. > > They are gone indeed. Looks good! Can push now. > > -- > Thanks, > -Aleksey > Pushed, thanks! For anyone interested, the tree was still dirty from developing this fix: https://icedtea.classpath.org//hg/icedtea11?cmd=changeset;node=dcab611ca0d6 -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mbalao at redhat.com Wed Oct 21 21:08:36 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 21 Oct 2020 18:08:36 -0300 Subject: [11u] RFR 6722928: Provide a default native GSS-API library on Windows Message-ID: <515701ce-b055-7d3f-f625-8b67d803df35@redhat.com> Hi, I'd like to request a review for the 11u backport of "6722928: Provide a default native GSS-API library on Windows" [1]. Webrev.00 * http://cr.openjdk.java.net/~mbalao/webrevs/6722928/6722928.webrev.11u.00 Conflicts: * src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java * There is one hunk that does not apply cleanly because a line below the one modified is changed by 8209416 [2]. * 8209416 does not apply cleanly (8+ conflicts) and is not fundamental to 6722928 as it's an enhancement related to obtaining values from properties, while 6722928 is about using the native Windows libraries for GSS. * This conflict has been solved by changing the hunk context to match 11u source code; there are no changes on the modified line itself. Testing: * The main line patch does not include a regression test because of its complexity (an Active Directory is needed). I manually tested a few calls through the DLL bridge and observed no errors. Given that this is a pluggable provider, the risk is low. If this proposal is review-approved, I'll go through the CSR process and request a 11u backport. Followup bugs that will be proposed for 11u backporting: * https://bugs.openjdk.java.net/browse/JDK-8225687 Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-6722928 [2] - https://bugs.openjdk.java.net/browse/JDK-8209416 From sandhya.viswanathan at intel.com Wed Oct 21 22:39:45 2020 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Wed, 21 Oct 2020 22:39:45 +0000 Subject: [11u] RFR 8254790: SIGSEGV in string_indexof_char and stringL_indexof_char intrinsics Message-ID: The fix for 8254790 needs to be backported to JDK11u. The fix is one-line change in string_indexof_char intrinsic. The intrinsic is moved to c2_MacroAssembler_x86.cpp since jdk15 and was in macroAssembler_x86.cpp in JDK 11u so I am sending a separate webrev review request. The other stringL_indexof_char intrinsic didn't exist in JDK11u so that fix is omitted in this webrev. JBS: https://bugs.openjdk.java.net/browse/JDK-8254790 Webrev: http://cr.openjdk.java.net/~sviswanathan/8254790/webrev.00/ Best Regards, Sandhya From jhuttana at redhat.com Thu Oct 22 07:06:21 2020 From: jhuttana at redhat.com (Jayashree Huttanagoudar) Date: Thu, 22 Oct 2020 12:36:21 +0530 Subject: OpenJDK 11.0.9 Released In-Reply-To: <20201021163606.GC2458790@stopbrexit> References: <20201021163606.GC2458790@stopbrexit> Message-ID: Hi All, On Wed, Oct 21, 2020 at 10:10 PM Andrew Hughes wrote: > We are pleased to announce the release of OpenJDK 11.0.9. > > The source tarball is available from: > > * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.9-ga.tar.xz > > The tarball is accompanied by a digital signature available at: > > * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.9-ga.tar.xz.sig > > This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): > > PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) > Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F > The binaries to go with this are here: https://adoptopenjdk.net/upstream.html?variant=openjdk11&jvmVariant=hotspot Thanks and Regards, Jaya From shade at redhat.com Thu Oct 22 12:07:45 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Oct 2020 14:07:45 +0200 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> Message-ID: <42e88c3e-763a-644e-a9ad-9299c9f36d5a@redhat.com> On 9/25/20 8:42 AM, Liang Mao wrote: > All changes of the JEP only contains of hunderds lines of code: > http://cr.openjdk.java.net/~lmao/jep346.11u/all.webrev.00/ Andrew asked me to follow up on this from the GC implementation/risk perspective. The first cursory review follows. This issue seems to be missing from the batch: JDK-8238932: Invalid tier1_gc_1 test group definition A philosophical point: the obvious risk for this kind of backport is breaking something. Since G1 is the default garbage collector in 11u, breaking it would break most applications that run with out of the box settings. This can be partially mitigated if we had the kill-switch for the code, and that depends on how code is structured. Per-issue comments: > 1) JDK-8071913: Filter out entries to free/uncommitted regions during iteration > http://cr.openjdk.java.net/~lmao/jep346.11u/8071913.webrev.00/ This looks like a faithful reproduction of original change. This thing concerns me the most: it touches the RSet code without any recourse in case it is broken. > 2) JDK-6490394: G1: Allow heap shrinking / memory unmapping after reclaiming regions during Remark Man Cao reports in the comments there that Google's internal JDK 11 had regressed memory footprint after this change. I cannot see if there was any follow-up on that. > 3) JDK-8213898: CDS dumping of springboot asserts in G1ArchiveAllocator::alloc_new_region This seems to be a simple fix for another regression introduced by JDK-6490394. Looks fine. > 4) JDK-8212657: Implementation of JDK-8204089 Promptly Return Unused Committed Memory from G1 > http://cr.openjdk.java.net/~lmao/jep346.11u/8212657.webrev.00/ This looks like a faithful reproduction of the original change. It seems fairly innocious, and codepaths revert to nops with -XX:G1PeriodicGCInterval=0 and -XX:G1PeriodicGCSystemLoadThreshold=0. update_rs_lengths_prediction() and update_ihop_prediction() are called in the different order now, but that seems fine, as they look independent. As said above, JDK-8238932 is missing as the follow-up. > 5) JDK-8215120: 32-bit build failures after JDK-8212657 (Promptly Return Unused Committed Memory from G1) Simple follow up after JDK-8212657. Looks fine. > 6) JDK-8215149: TestOptionsWithRangesDynamic.java fails after JDK-8215120 ...and another one. Looks fine. > 7) JDK-8215548: G1PeriodicGCSystemLoadThreshold needs to be a double Simple follow up for JDK-8212657. Looks fine. > 8) JDK-8216490: Spammy periodic GC log message contains random time stamp with periodic gc disabled UX fix after JDK-8212657. Looks fine. > 9) JDK-8218880: G1 crashes when issuing a periodic GC while the GCLocker is held > http://cr.openjdk.java.net/~lmao/jep346.11u/8218880.webrev.00/ This looks like a faithful reproduction of the original change. What concerns me, though, is that the bug was found full 3 months after introducing! And it crashed the VM hard, because periodic GC entered collect() from a non-Java thread! I would need some time to breathe out and prove to myself it is safe now. > 10) JDK-8212883: Setting a double manageable flag with jcmd/jinfo crashes the JVM This one can actually be backported ahead of time to 11u, I think. I understand it is needed for JDK-8215548 in this queue, but I don't think that's a blocker for a separate inclusion, and it could be useful for other backports. So, for the current action items: a) JDK-8238932 needs to be added, trivially; b) JDK-6490394 needs to be investigated on footprint impact, possibly involving Man Cao / Google; c) JDK-8218880 deserves more attention/testing, possibly involving others; Thanks, -Aleksey From sgehwolf at redhat.com Thu Oct 22 12:57:54 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 22 Oct 2020 14:57:54 +0200 Subject: [11u] RFR 6722928: Provide a default native GSS-API library on Windows In-Reply-To: <515701ce-b055-7d3f-f625-8b67d803df35@redhat.com> References: <515701ce-b055-7d3f-f625-8b67d803df35@redhat.com> Message-ID: <8cb555f2bf71bcf82a44e667d951be481fa3a75e.camel@redhat.com> Hi Martin, On Wed, 2020-10-21 at 18:08 -0300, Martin Balao wrote: > Hi, > > I'd like to request a review for the 11u backport of "6722928: Provide a > default native GSS-API library on Windows" [1]. > > Webrev.00 > > * http://cr.openjdk.java.net/~mbalao/webrevs/6722928/6722928.webrev.11u.00 > > Conflicts: > > * > src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java > * There is one hunk that does not apply cleanly because a line below > the one modified is changed by 8209416 [2]. > * 8209416 does not apply cleanly (8+ conflicts) and is not > fundamental to 6722928 as it's an enhancement related to obtaining > values from properties, while 6722928 is about using the native Windows > libraries for GSS. > * This conflict has been solved by changing the hunk context to match > 11u source code; there are no changes on the modified line itself. Good call. Backporting JDK-8209416 for the patch to apply cleanly doesn't make sense. The backport looks fine to me. > Testing: > > * The main line patch does not include a regression test because of its > complexity (an Active Directory is needed). I manually tested a few > calls through the DLL bridge and observed no errors. Given that this is > a pluggable provider, the risk is low. > > If this proposal is review-approved, I'll go through the CSR process and > request a 11u backport. Please go ahead and file the 11 CSR request. > Followup bugs that will be proposed for 11u backporting: > > * https://bugs.openjdk.java.net/browse/JDK-8225687 Yes, please. We should get them both integrated to 11 at the same time. Thanks, Severin > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-6722928 > [2] - https://bugs.openjdk.java.net/browse/JDK-8209416 > From hohensee at amazon.com Thu Oct 22 13:28:05 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 22 Oct 2020 13:28:05 +0000 Subject: 11u] RFR 8254790: SIGSEGV in string_indexof_char and stringL_indexof_char intrinsics Message-ID: Looks good. Paul ?On 10/21/20, 3:40 PM, "jdk-updates-dev on behalf of Viswanathan, Sandhya" wrote: The fix for 8254790 needs to be backported to JDK11u. The fix is one-line change in string_indexof_char intrinsic. The intrinsic is moved to c2_MacroAssembler_x86.cpp since jdk15 and was in macroAssembler_x86.cpp in JDK 11u so I am sending a separate webrev review request. The other stringL_indexof_char intrinsic didn't exist in JDK11u so that fix is omitted in this webrev. JBS: https://bugs.openjdk.java.net/browse/JDK-8254790 Webrev: http://cr.openjdk.java.net/~sviswanathan/8254790/webrev.00/ Best Regards, Sandhya From thomas.stuefe at gmail.com Fri Oct 23 05:24:04 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 23 Oct 2020 07:24:04 +0200 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> Message-ID: Hi, I am a bit concerned about this. We are in the process of gently nudging our internal customers up to jdk 11 from jdk 8. We are also internally providing an "11ified" jdk 8, similar to the old hotspot express model. So hotspot 11 gets used alot in our company and in a lot of very different scenarios. Elasticity is welcome, but any destabilization of G1 would be catastrophic. As a counter example, the Shenandoah backport makes me feel less apprehensive since I know that RedHat has a strong commitment to backport releases and that the Shenandoah developers work focused on Shenandoah in the main line (so their resources are not split between different GCs). I'd feel safer if I had a similar commitment from Oracle G1 developers about backing this backport. Do we have that (I may have missed this)? And as Aleksey wrote in his initial review, a killswitch - where "off" is a reliably tested scenario - would be good. Thanks, Thomas On Mon, Oct 12, 2020 at 11:36 AM Andrew Haley wrote: > On 12/10/2020 09:02, Ruslan Synytsky wrote: > > Dear Liang, thank you for the extra efforts on this improvement. > > > > Dear Andrew, I assume we need your approval / confirmation. Can you > please take a look and let us know your feedback? > > OK, I'll have a look and get some input from others. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From maoliang.ml at alibaba-inc.com Fri Oct 23 09:34:51 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Fri, 23 Oct 2020 17:34:51 +0800 Subject: =?UTF-8?B?UmU6IFsxMXVdIEJhY2twb3J0IEpFUCAzNDYgOiBQcm9tcHRseSBSZXR1cm4gVW51c2VkIENv?= =?UTF-8?B?bW1pdHRlZCBNZW1vcnkgZnJvbSBHMQ==?= In-Reply-To: References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> , Message-ID: <02291ba7-fbc7-463b-8dce-586a36999691.maoliang.ml@alibaba-inc.com> Hi Thomas, I agree that we should move forward very carefully to make sure we won't break anything. In another mail I explained my thinkings about the quality concerns. We need full discussion on details and confirm everything goes fine. I guess Oracle G1 team may not give the commitment to back this backport because 11u is already maintained by community now but previously Oracle G1 team agreed to help the review. Thanks, Liang ------------------------------------------------------------------ From:Thomas St?fe Send Time:2020 Oct. 23 (Fri.) 13:24 To:Andrew Haley Cc:rs ; "MAO, Liang" ; jdk-updates-dev ; "Lindenmaier, Goetz" ; Martijn Verburg Subject:Re: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 Hi, I am a bit concerned about this. We are in the process of gently nudging our internal customers up to jdk 11 from jdk 8. We are also internally providing an "11ified" jdk 8, similar to the old hotspot express model. So hotspot 11 gets used alot in our company and in a lot of very different scenarios. Elasticity is welcome, but any destabilization of G1 would be catastrophic. As a counter example, the Shenandoah backport makes me feel less apprehensive since I know that RedHat has a strong commitment to backport releases and that the Shenandoah developers work focused on Shenandoah in the main line (so their resources are not split between different GCs). I'd feel safer if I had a similar commitment from Oracle G1 developers about backing this backport. Do we have that (I may have missed this)? And as Aleksey wrote in his initial review, a killswitch - where "off" is a reliably tested scenario - would be good. Thanks, Thomas On Mon, Oct 12, 2020 at 11:36 AM Andrew Haley wrote: On 12/10/2020 09:02, Ruslan Synytsky wrote: > Dear Liang, thank you for the extra efforts on this improvement. > > Dear Andrew, I assume we need your approval / confirmation. Can you please take a look and let us know your feedback? OK, I'll have a look and get some input from others. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Fri Oct 23 11:14:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 23 Oct 2020 13:14:22 +0200 Subject: [15u] RFR 8255065: Zero: accessor_entry misses the IRIW case Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8255065 https://git.openjdk.java.net/jdk/commit/bd45191f Since cppInterpreter_zero.cpp was renamed to zeroInterpreter_zero.cpp in 16, this patch does not apply cleanly. So I had to apply the same hunk to the old location. 15u patch: diff -r 96851120ae5c src/hotspot/cpu/zero/cppInterpreter_zero.cpp --- a/src/hotspot/cpu/zero/cppInterpreter_zero.cpp Thu Oct 08 08:10:55 2020 +0000 +++ b/src/hotspot/cpu/zero/cppInterpreter_zero.cpp Fri Oct 23 13:10:38 2020 +0200 @@ -555,10 +555,13 @@ stack->overflow_check(1, CHECK_0); stack->alloc(wordSize); break; } if (entry->is_volatile()) { + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { + OrderAccess::fence(); + } switch (entry->flag_state()) { case ctos: SET_LOCALS_INT(object->char_field_acquire(entry->f2_as_index()), 0); break; Testing: Linux x86_64 Zero build -- Thanks, -Aleksey From martin.doerr at sap.com Fri Oct 23 12:16:59 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 23 Oct 2020 12:16:59 +0000 Subject: [15u] RFR 8255065: Zero: accessor_entry misses the IRIW case In-Reply-To: References: Message-ID: Hi Aleksey, looks good. Thanks for fixing it. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Freitag, 23. Oktober 2020 13:14 > To: jdk-updates-dev at openjdk.java.net > Subject: [15u] RFR 8255065: Zero: accessor_entry misses the IRIW case > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8255065 > https://git.openjdk.java.net/jdk/commit/bd45191f > > Since cppInterpreter_zero.cpp was renamed to zeroInterpreter_zero.cpp in > 16, this patch does not > apply cleanly. So I had to apply the same hunk to the old location. > > 15u patch: > > diff -r 96851120ae5c src/hotspot/cpu/zero/cppInterpreter_zero.cpp > --- a/src/hotspot/cpu/zero/cppInterpreter_zero.cpp Thu Oct 08 08:10:55 > 2020 +0000 > +++ b/src/hotspot/cpu/zero/cppInterpreter_zero.cpp Fri Oct 23 13:10:38 > 2020 +0200 > @@ -555,10 +555,13 @@ > stack->overflow_check(1, CHECK_0); > stack->alloc(wordSize); > break; > } > if (entry->is_volatile()) { > + if (support_IRIW_for_not_multiple_copy_atomic_cpu) { > + OrderAccess::fence(); > + } > switch (entry->flag_state()) { > case ctos: > SET_LOCALS_INT(object->char_field_acquire(entry->f2_as_index()), 0); > break; > > Testing: Linux x86_64 Zero build > > -- > Thanks, > -Aleksey From shade at redhat.com Fri Oct 23 14:50:50 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 23 Oct 2020 16:50:50 +0200 Subject: [Updates Communication] 15.0.1 security patches pushed In-Reply-To: <20201021141845.GA31905@DESKTOP-JNNKIHU.localdomain> References: <20201021141845.GA31905@DESKTOP-JNNKIHU.localdomain> Message-ID: On 10/21/20 4:18 PM, Rob McKenna wrote: > Apologies for the delay. Thanks! jdk-15.0.1+9 should also be jdk-15.0.1-ga? -- -Aleksey From christoph.langer at sap.com Fri Oct 23 16:07:54 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 23 Oct 2020 16:07:54 +0000 Subject: [Updates Communication] 15.0.1 security patches pushed In-Reply-To: References: <20201021141845.GA31905@DESKTOP-JNNKIHU.localdomain> Message-ID: Hi, @Rob: Couldn't you add those "-ga" labels for the Oracle maintained OpenJDK update releases in the future? It would greatly help downstream distributors to automatically pick the right tags. And it has been asked several times before ?? Thanks & Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Freitag, 23. Oktober 2020 16:51 > To: Rob McKenna ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [Updates Communication] 15.0.1 security patches pushed > > On 10/21/20 4:18 PM, Rob McKenna wrote: > > Apologies for the delay. > > Thanks! > > jdk-15.0.1+9 should also be jdk-15.0.1-ga? > > -- > -Aleksey From goetz.lindenmaier at sap.com Fri Oct 23 17:30:35 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 23 Oct 2020 17:30:35 +0000 Subject: [11u] RFR: 8249607: C2: assert(!had_error) failed: bad dominance Message-ID: HI I am downporting this for parity with 11.0.10-oracle. http://cr.openjdk.java.net/~goetz/wr20/8249607-bad_dominance-jdk11/01/ I had to do real trivial resolves in loopnode.hpp due to space Differences in the context. https://bugs.openjdk.java.net/browse/JDK-8249607 https://hg.openjdk.java.net/jdk/jdk/rev/05d7a0663063 Best regards, Goetz. From rob.mckenna at oracle.com Fri Oct 23 17:32:41 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 23 Oct 2020 18:32:41 +0100 Subject: [Updates Communication] 15.0.1 security patches pushed In-Reply-To: References: <20201021141845.GA31905@DESKTOP-JNNKIHU.localdomain> Message-ID: <20201023173240.GC31905@DESKTOP-JNNKIHU.localdomain> There was a problem with whatever RE script was responsible for adding them. I'll get them pushed shortly. -Rob On 23/10/20 16:07, Langer, Christoph wrote: > Hi, > > @Rob: Couldn't you add those "-ga" labels for the Oracle maintained OpenJDK update releases in the future? It would greatly help downstream distributors to automatically pick the right tags. And it has been asked several times before ?? > > Thanks & Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Aleksey Shipilev > > Sent: Freitag, 23. Oktober 2020 16:51 > > To: Rob McKenna ; jdk-updates- > > dev at openjdk.java.net > > Subject: Re: [Updates Communication] 15.0.1 security patches pushed > > > > On 10/21/20 4:18 PM, Rob McKenna wrote: > > > Apologies for the delay. > > > > Thanks! > > > > jdk-15.0.1+9 should also be jdk-15.0.1-ga? > > > > -- > > -Aleksey > From christoph.langer at sap.com Fri Oct 23 18:12:22 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 23 Oct 2020 18:12:22 +0000 Subject: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport changes In-Reply-To: References: <3BBDEB11-6FE8-4F93-BCDE-155132DF935A@azul.com> <8E3BF025-A532-499B-9E09-9F92C5911F42@azul.com> Message-ID: Hi Aleksey, I'm wondering whether you could give an assessment about these changes, similar to what you've done regarding the proposed backport of JEP 346? I would hope this one would be less effort... Thanks Christoph > -----Original Message----- > From: Vladimir Kempik > Sent: Dienstag, 13. Oktober 2020 22:01 > To: Langer, Christoph > Cc: John Cuthbertson ; Andrew Haley > ; Severin Gehwolf ; Aleksey > Shipilev ; jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport changes > > Hello > > Any objections about these patches ? > > Regards, Vladimir. > > > 17 ????. 2020 ?., ? 11:24, Vladimir Kempik > ???????(?): > > > > Hello Langer > > > >> Another thing: Looking at JBS I can see that JDK-8208498 was marked as a > blocker for JDK-8209061 and the former hasn't been backported to 11. Is that > an issue > >> Generally, would it be possible to fix the issue of JDK-8207200 in a way > that's less invasive? > > > > well, I have tried to make 8207200 less invasive by not including 8208498. > > > > There is a race condition in g1 monitoring which still can be see by some > openjdk11 users ( commited < used) and this is the attempt to fix it. > > I have verified it helps at least one user. Sadly I don?t have a reproducer. > > > > Regards, Vladimir > > > > > >> 17 ????. 2020 ?., ? 10:43, Langer, Christoph > ???????(?): > >> > >> Hi, > >> > >> I've just looked at approving this series of backports (JDK-8209061, JDK- > 8209062 and JDK-8207200). > >> > >> While I'm sure that JDK-8207200 fixes an important issue and I also trust > your reviews of the backports, I can see that these 3 patches together mean > some significant changes in the area of G1 GC. This makes me kind of > hesitant to approve the backports right away. I'd like to get some > assessment/reassurance of the other JDK11 maintainers (aph, sgehwolf) on > whether we should admit them or not? > >> > >> Also, Aleksey, maybe you can give some technical advice as a gc expert if > you think these backports are feasible? > >> > >> Another thing: Looking at JBS I can see that JDK-8208498 was marked as a > blocker for JDK-8209061 and the former hasn't been backported to 11. Is that > an issue? > >> > >> Generally, would it be possible to fix the issue of JDK-8207200 in a way > that's less invasive? > >> > >> Please understand that I'd like to err on the side of caution here... > >> > >> Thanks & Best regards > >> Christoph > >> > >>> -----Original Message----- > >>> From: jdk-updates-dev On > >>> Behalf Of John Cuthbertson > >>> Sent: Dienstag, 15. September 2020 19:07 > >>> To: Vladimir Kempik > >>> Cc: jdk-updates-dev at openjdk.java.net > >>> Subject: Re: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport > changes > >>> > >>> Hi Vladimir, > >>> > >>> On Sep 3, 2020, at 5:28 AM, Vladimir Kempik > >>> > wrote: > >>> > >>> Hello > >>> > >>> Please review these backports of JDK-8209061:Move G1 serviceability > >>> functionality to G1MonitoringSupport and JDK-8209062:Clean up > >>> G1MonitoringSupport to jdk11u > >>> > >>> These backports are prerequestes for JDK-8207200 which we can see in > the > >>> wild with jdk8 and jdk11. > >>> > >>> JDK-8209061 and JDK-8209062 applies mostly clean, very few places > where it > >>> wasn?t clean due to surrounding code or code layout. > >>> > >>> after these two, JDK-8207200 applies cleanly. > >>> > >>> Testing: tier1. > >>> > >>> The webrevs: > >>> > >>> http://cr.openjdk.java.net/~vkempik/8209061/webrev.00/ > >>> > >>> This looks good to me and matches > >>> http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec. > >>> > >>> http://cr.openjdk.java.net/~vkempik/8209062/webrev.00/ > >>> > >>> This looks good to me also and matches > >>> http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046. > >>> > >>> > >>> All mentioned bugs: > >>> https://bugs.openjdk.java.net/browse/JDK-8209062 > >>> https://bugs.openjdk.java.net/browse/JDK-8209061 > >>> https://bugs.openjdk.java.net/browse/JDK-8207200 > >>> > >>> Original changesets: > >>> 8209061: http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec > >>> 8209062: http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046 > >>> > >>> Thanks, Vladimir > >>> > >>> Regards, > >>> > >>> JohnC > > From hohensee at amazon.com Fri Oct 23 21:29:56 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 23 Oct 2020 21:29:56 +0000 Subject: [11u] RFR: 8249607: C2: assert(!had_error) failed: bad dominance Message-ID: Lgtm, though since you're cleaning up a few spaces, you could also add the blank line after the #endif in loopnode.hpp. :) Thanks, Paul ?On 10/23/20, 10:31 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" wrote: HI I am downporting this for parity with 11.0.10-oracle. http://cr.openjdk.java.net/~goetz/wr20/8249607-bad_dominance-jdk11/01/ I had to do real trivial resolves in loopnode.hpp due to space Differences in the context. https://bugs.openjdk.java.net/browse/JDK-8249607 https://hg.openjdk.java.net/jdk/jdk/rev/05d7a0663063 Best regards, Goetz. From rob.mckenna at oracle.com Sat Oct 24 00:33:46 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Sat, 24 Oct 2020 01:33:46 +0100 Subject: [Updates Communication] 15.0.1 security patches pushed In-Reply-To: <20201023173240.GC31905@DESKTOP-JNNKIHU.localdomain> References: <20201021141845.GA31905@DESKTOP-JNNKIHU.localdomain> <20201023173240.GC31905@DESKTOP-JNNKIHU.localdomain> Message-ID: <20201024003346.GA20076@DESKTOP-JNNKIHU.localdomain> Pushed. -Rob On 23/10/20 18:32, Rob McKenna wrote: > There was a problem with whatever RE script was responsible for adding > them. I'll get them pushed shortly. > > -Rob > > On 23/10/20 16:07, Langer, Christoph wrote: > > Hi, > > > > @Rob: Couldn't you add those "-ga" labels for the Oracle maintained OpenJDK update releases in the future? It would greatly help downstream distributors to automatically pick the right tags. And it has been asked several times before ?? > > > > Thanks & Best regards > > Christoph > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of Aleksey Shipilev > > > Sent: Freitag, 23. Oktober 2020 16:51 > > > To: Rob McKenna ; jdk-updates- > > > dev at openjdk.java.net > > > Subject: Re: [Updates Communication] 15.0.1 security patches pushed > > > > > > On 10/21/20 4:18 PM, Rob McKenna wrote: > > > > Apologies for the delay. > > > > > > Thanks! > > > > > > jdk-15.0.1+9 should also be jdk-15.0.1-ga? > > > > > > -- > > > -Aleksey > > From maoliang.ml at alibaba-inc.com Mon Oct 26 02:19:22 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Mon, 26 Oct 2020 10:19:22 +0800 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: <42e88c3e-763a-644e-a9ad-9299c9f36d5a@redhat.com> References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> <42e88c3e-763a-644e-a9ad-9299c9f36d5a@redhat.com> Message-ID: <001901d6ab3e$6cc96bb0$465c4310$@alibaba-inc.com> Hi Aleksey, Thanks very much for your careful initial review! > So, for the current action items: > a) JDK-8238932 needs to be added, trivially; Yes. It should be added although trival. > b) JDK-6490394 needs to be investigated on footprint impact, possibly > involving Man Cao / Google; JDK-6490394 might increase the memory footprint because introducing the heap resize in remark phase. But we also need this to shrink the heap for saving memory. The heap sizing heuristics in 11u has some original issues that it would unnecessarily expand heap size with a fixed input. Thomas made a lot of efforts on this later: https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-June/030090.html Even with a fixed IR running for specjbb2015 (as -Dspecjbb.controller.preset.ir=4000), the heap will expand continuously. So I think that's why JEP346 is valuable in 11u because not only memory footprint issue in Java is a common sense but there're also some uncessary memory expansion in G1. For the potential issue of increasing footprint by default, can we make a very simple fix that we only do resize in remark with (G1PeriodicGCInterval != 0): +if (G1PeriodicGCInterval != 0) { _g1h->resize_heap_if_necessary(); +} So the additional sizing only happen with a specified G1PeriodicGCInterval. > c) JDK-8218880 deserves more attention/testing, possibly involving others; > It seems the only real severe issue brought by the JEP. But periodic triggering GC with GC locks on is not a common scenario. So it is acceptable that it took 3 months to find the bug. And the fix is straight forward that just don't trigger GC when GC locks on. After half and one year, there're no other bugs from the feature. It looks stable for quite a long time (3 releases). Thanks, Liang > -----Original Message----- > From: Aleksey Shipilev [mailto:shade at redhat.com] > Sent: 2020?10?22? 20:08 > To: Liang Mao ; jdk-updates-dev dev at openjdk.java.net>; Lindenmaier, Goetz ; > Martijn Verburg ; Ruslan Synytsky > > Subject: Re: [11u] Backport JEP 346 : Promptly Return Unused Committed > Memory from G1 > > On 9/25/20 8:42 AM, Liang Mao wrote: > > All changes of the JEP only contains of hunderds lines of code: > > http://cr.openjdk.java.net/~lmao/jep346.11u/all.webrev.00/ > > Andrew asked me to follow up on this from the GC implementation/risk > perspective. > > The first cursory review follows. > > This issue seems to be missing from the batch: > JDK-8238932: Invalid tier1_gc_1 test group definition > > A philosophical point: the obvious risk for this kind of backport is breaking > something. Since G1 is the default garbage collector in 11u, breaking it would > break most applications that run with out of the box settings. This can be > partially mitigated if we had the kill-switch for the code, and that depends on > how code is structured. > > Per-issue comments: > > > 1) JDK-8071913: Filter out entries to free/uncommitted regions during > > iteration > > http://cr.openjdk.java.net/~lmao/jep346.11u/8071913.webrev.00/ > > This looks like a faithful reproduction of original change. This thing concerns me > the most: it touches the RSet code without any recourse in case it is broken. > > > 2) JDK-6490394: G1: Allow heap shrinking / memory unmapping after > > reclaiming regions during Remark > > Man Cao reports in the comments there that Google's internal JDK 11 had > regressed memory footprint after this change. I cannot see if there was any > follow-up on that. > > > 3) JDK-8213898: CDS dumping of springboot asserts in > > G1ArchiveAllocator::alloc_new_region > > This seems to be a simple fix for another regression introduced by JDK-6490394. > Looks fine. > > > 4) JDK-8212657: Implementation of JDK-8204089 Promptly Return Unused > > Committed Memory from G1 > > http://cr.openjdk.java.net/~lmao/jep346.11u/8212657.webrev.00/ > > This looks like a faithful reproduction of the original change. It seems fairly > innocious, and codepaths revert to nops with -XX:G1PeriodicGCInterval=0 and - > XX:G1PeriodicGCSystemLoadThreshold=0. > > update_rs_lengths_prediction() and update_ihop_prediction() are called in the > different order now, but that seems fine, as they look independent. > > As said above, JDK-8238932 is missing as the follow-up. > > > 5) JDK-8215120: 32-bit build failures after JDK-8212657 (Promptly > > Return Unused Committed Memory from G1) > > Simple follow up after JDK-8212657. Looks fine. > > > 6) JDK-8215149: TestOptionsWithRangesDynamic.java fails after > > JDK-8215120 > > ...and another one. Looks fine. > > > 7) JDK-8215548: G1PeriodicGCSystemLoadThreshold needs to be a double > > Simple follow up for JDK-8212657. Looks fine. > > > 8) JDK-8216490: Spammy periodic GC log message contains random time > > stamp with periodic gc disabled > > UX fix after JDK-8212657. Looks fine. > > > 9) JDK-8218880: G1 crashes when issuing a periodic GC while the > > GCLocker is held > > http://cr.openjdk.java.net/~lmao/jep346.11u/8218880.webrev.00/ > > This looks like a faithful reproduction of the original change. > > What concerns me, though, is that the bug was found full 3 months after > introducing! And it crashed the VM hard, because periodic GC entered collect() > from a non-Java thread! I would need some time to breathe out and prove to > myself it is safe now. > > > 10) JDK-8212883: Setting a double manageable flag with jcmd/jinfo > > crashes the JVM > > This one can actually be backported ahead of time to 11u, I think. I understand it > is needed for > JDK-8215548 in this queue, but I don't think that's a blocker for a separate > inclusion, and it could be useful for other backports. > > So, for the current action items: > a) JDK-8238932 needs to be added, trivially; > b) JDK-6490394 needs to be investigated on footprint impact, possibly > involving Man Cao / Google; > c) JDK-8218880 deserves more attention/testing, possibly involving others; > > Thanks, > -Aleksey From phh at openjdk.java.net Mon Oct 26 18:56:42 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Mon, 26 Oct 2020 18:56:42 GMT Subject: [jdk13u-dev] RFR: 8255269: Unsigned overflow in g1Policy.cpp Message-ID: <9v_h7CZv5ar0SxIVC5XMU4tiDrQggQKauf_IuN_1OnI=.1984df18-cfd9-4e10-849c-46e9d41c9e39@github.com> Filed on behalf of William Kemper, kemperw at amazon.com. Please review this jdk13 patch. Th plan is to also backport to 11.0.10 and openjdk8u282. See JBS issue Description for details. ------------- Commit messages: - 8255259: Unsigned overflow in g1Policy.cpp Changes: https://git.openjdk.java.net/jdk13u-dev/pull/4/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=4&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255269 Stats: 7 lines in 1 file changed: 2 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/4.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/4/head:pull/4 PR: https://git.openjdk.java.net/jdk13u-dev/pull/4 From hohensee at amazon.com Mon Oct 26 21:14:38 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 26 Oct 2020 21:14:38 +0000 Subject: [jdk13u-dev] RFR: 8255269: Unsigned overflow in g1Policy.cpp Message-ID: <625011FF-90F1-4A28-9954-F45F745C3485@amazon.com> +hotspot-gc-dev. /cc doesn't seem to work yet for jdk13u-dev. Thanks, Paul ?On 10/26/20, 11:57 AM, "jdk-updates-dev on behalf of Paul Hohensee" wrote: Filed on behalf of William Kemper, kemperw at amazon.com. Please review this jdk13 patch. Th plan is to also backport to 11.0.10 and openjdk8u282. See JBS issue Description for details. ------------- Commit messages: - 8255259: Unsigned overflow in g1Policy.cpp Changes: https://git.openjdk.java.net/jdk13u-dev/pull/4/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=4&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255269 Stats: 7 lines in 1 file changed: 2 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/4.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/4/head:pull/4 PR: https://git.openjdk.java.net/jdk13u-dev/pull/4 From vkempik at openjdk.java.net Tue Oct 27 08:29:27 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 27 Oct 2020 08:29:27 GMT Subject: [jdk13u-dev] RFR: 8232616: JVMCI_lock fails to get initialized when cds is disabled Message-ID: Please review this backport of 8232616 to jdk13u, fix didn't apply cleanly, minimal mods were needed. ------------- Commit messages: - 8232616: JVMCI_lock fails to get initialized when cds is disabled Changes: https://git.openjdk.java.net/jdk13u-dev/pull/5/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=5&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232616 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/5/head:pull/5 PR: https://git.openjdk.java.net/jdk13u-dev/pull/5 From yan at openjdk.java.net Tue Oct 27 08:52:17 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 27 Oct 2020 08:52:17 GMT Subject: [jdk13u-dev] RFR: 8232616: JVMCI_lock fails to get initialized when cds is disabled In-Reply-To: References: Message-ID: <6D3tGcg5zFl77Miig8Og21vXZIV9kg3FSN0cWMUW7JY=.2a277ddb-d78e-43d6-8233-7a110159c2b8@github.com> On Tue, 27 Oct 2020 08:23:52 GMT, Vladimir Kempik wrote: > Please review this backport of 8232616 to jdk13u, fix didn't apply cleanly, minimal mods were needed. so it is slightly different context here, OK... ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/5 From vkempik at openjdk.java.net Tue Oct 27 09:06:19 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 27 Oct 2020 09:06:19 GMT Subject: [jdk13u-dev] Integrated: 8232616: JVMCI_lock fails to get initialized when cds is disabled In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 08:23:52 GMT, Vladimir Kempik wrote: > Please review this backport of 8232616 to jdk13u, fix didn't apply cleanly, minimal mods were needed. This pull request has now been integrated. Changeset: 8ea6f9ed Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/8ea6f9ed Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod 8232616: JVMCI_lock fails to get initialized when cds is disabled Reviewed-by: yan ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/5 From yan at openjdk.java.net Tue Oct 27 13:48:25 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 27 Oct 2020 13:48:25 GMT Subject: [jdk13u-dev] RFR: 8255269: Unsigned overflow in g1Policy.cpp In-Reply-To: <9v_h7CZv5ar0SxIVC5XMU4tiDrQggQKauf_IuN_1OnI=.1984df18-cfd9-4e10-849c-46e9d41c9e39@github.com> References: <9v_h7CZv5ar0SxIVC5XMU4tiDrQggQKauf_IuN_1OnI=.1984df18-cfd9-4e10-849c-46e9d41c9e39@github.com> Message-ID: On Mon, 26 Oct 2020 18:51:58 GMT, Paul Hohensee wrote: > Filed on behalf of William Kemper, kemperw at amazon.com. > > Please review this jdk13 patch. The plan is to also backport to 11.0.10 and openjdk8u282. > See JBS issue Description for details. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/4 From phh at openjdk.java.net Tue Oct 27 15:17:26 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Tue, 27 Oct 2020 15:17:26 GMT Subject: [jdk13u-dev] Integrated: 8255269: Unsigned overflow in g1Policy.cpp In-Reply-To: <9v_h7CZv5ar0SxIVC5XMU4tiDrQggQKauf_IuN_1OnI=.1984df18-cfd9-4e10-849c-46e9d41c9e39@github.com> References: <9v_h7CZv5ar0SxIVC5XMU4tiDrQggQKauf_IuN_1OnI=.1984df18-cfd9-4e10-849c-46e9d41c9e39@github.com> Message-ID: On Mon, 26 Oct 2020 18:51:58 GMT, Paul Hohensee wrote: > Filed on behalf of William Kemper, kemperw at amazon.com. > > Please review this jdk13 patch. The plan is to also backport to 11.0.10 and openjdk8u282. > See JBS issue Description for details. This pull request has now been integrated. Changeset: 7e95c0a5 Author: Paul Hohensee URL: https://git.openjdk.java.net/jdk13u-dev/commit/7e95c0a5 Stats: 7 lines in 1 file changed: 2 ins; 2 del; 3 mod 8255269: Unsigned overflow in g1Policy.cpp Co-authored-by: William Kemper Reviewed-by: yan ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/4 From phh at openjdk.java.net Tue Oct 27 16:55:22 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Tue, 27 Oct 2020 16:55:22 GMT Subject: [jdk13u-dev] RFR: 8255468: JDK-8255269 incorrectly replaced average copy time Message-ID: Please review this fix to the patch for JDK-8255269. Part of the average copy time calculation was left out. This line from the patch double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy); should be double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy) + average_time_ms(G1GCPhaseTimes::OptObjCopy); Thanks, Paul ------------- Commit messages: - 8255468: JDK-8255269 incorrectly replaced average copy time Changes: https://git.openjdk.java.net/jdk13u-dev/pull/6/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=6&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255468 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/6.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/6/head:pull/6 PR: https://git.openjdk.java.net/jdk13u-dev/pull/6 From johnc at azul.com Tue Oct 27 17:52:29 2020 From: johnc at azul.com (John Cuthbertson) Date: Tue, 27 Oct 2020 17:52:29 +0000 Subject: [jdk13u-dev] RFR: 8255468: JDK-8255269 incorrectly replaced average copy time In-Reply-To: References: Message-ID: <92176794-2F81-46E3-8A48-E16D00EDA66E@azul.com> Hi Paul, Looks good to me. I got to the original review this morning and was going to say something until I saw your followup. JohnC > On Oct 27, 2020, at 9:55 AM, Paul Hohensee wrote: > > Please review this fix to the patch for JDK-8255269. Part of the average copy time calculation was left out. This line from the patch > > double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy); > > should be > > double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy) + average_time_ms(G1GCPhaseTimes::OptObjCopy); > > Thanks, > Paul > > ------------- > > Commit messages: > - 8255468: JDK-8255269 incorrectly replaced average copy time > > Changes: https://git.openjdk.java.net/jdk13u-dev/pull/6/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=6&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8255468 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jdk13u-dev/pull/6.diff > Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/6/head:pull/6 > > PR: https://git.openjdk.java.net/jdk13u-dev/pull/6 From hohensee at amazon.com Tue Oct 27 18:04:26 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Oct 2020 18:04:26 +0000 Subject: [jdk13u-dev] RFR: 8255468: JDK-8255269 incorrectly replaced average copy time Message-ID: <754E7DEF-C570-45AC-9F07-B595E8A1A29D@amazon.com> Thanks, John. I've tagged the issue. Paul ?On 10/27/20, 10:53 AM, "jdk-updates-dev on behalf of John Cuthbertson" wrote: Hi Paul, Looks good to me. I got to the original review this morning and was going to say something until I saw your followup. JohnC > On Oct 27, 2020, at 9:55 AM, Paul Hohensee wrote: > > Please review this fix to the patch for JDK-8255269. Part of the average copy time calculation was left out. This line from the patch > > double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy); > > should be > > double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy) + average_time_ms(G1GCPhaseTimes::OptObjCopy); > > Thanks, > Paul > > ------------- > > Commit messages: > - 8255468: JDK-8255269 incorrectly replaced average copy time > > Changes: https://git.openjdk.java.net/jdk13u-dev/pull/6/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=6&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8255468 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jdk13u-dev/pull/6.diff > Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/6/head:pull/6 > > PR: https://git.openjdk.java.net/jdk13u-dev/pull/6 From yan at openjdk.java.net Wed Oct 28 06:37:22 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 28 Oct 2020 06:37:22 GMT Subject: [jdk13u-dev] RFR: 8255468: JDK-8255269 incorrectly replaced average copy time In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 16:50:29 GMT, Paul Hohensee wrote: > Please review this fix to the patch for JDK-8255269. Part of the average copy time calculation was left out. This line from the patch > > double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy); > > should be > > double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy) + average_time_ms(G1GCPhaseTimes::OptObjCopy); > > Thanks, > Paul Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/6 From sgehwolf at redhat.com Wed Oct 28 09:12:29 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 28 Oct 2020 10:12:29 +0100 Subject: [11u] RFR 8244142: some hotspot/runtime tests don't check exit code of forked JVM In-Reply-To: <3f266f1c-6a20-10a7-22cb-4ce4b8d61ae6@redhat.com> References: <3f266f1c-6a20-10a7-22cb-4ce4b8d61ae6@redhat.com> Message-ID: <2324f55f5396ce9974201e7fd88e019447f781b3.camel@redhat.com> On Mon, 2020-10-19 at 16:58 +0200, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8244142 > https://hg.openjdk.java.net/jdk/jdk/rev/d194201e76ef > > It applies cleanly, except the hunk from test/hotspot/jtreg/runtime/records/RedefineRecord.java, > which does not exist in 11u (added for Records). > > 11u variant therefore is: > > diff -r 73edf743a93a test/hotspot/jtreg/runtime/Metaspace/MaxMetaspaceSizeTest.java > --- a/test/hotspot/jtreg/runtime/Metaspace/MaxMetaspaceSizeTest.java Wed Sep 30 08:58:42 2020 +0200 > +++ b/test/hotspot/jtreg/runtime/Metaspace/MaxMetaspaceSizeTest.java Mon Oct 19 16:58:00 2020 +0200 > @@ -44,4 +44,5 @@ > OutputAnalyzer output = new OutputAnalyzer(pb.start()); > output.shouldContain("MaxMetaspaceSize is too small."); > + output.shouldNotHaveExitValue(0); > } > } > diff -r 73edf743a93a test/hotspot/jtreg/runtime/getSysPackage/GetPackageXbootclasspath.java > --- a/test/hotspot/jtreg/runtime/getSysPackage/GetPackageXbootclasspath.java Wed Sep 30 08:58:42 > 2020 +0200 > +++ b/test/hotspot/jtreg/runtime/getSysPackage/GetPackageXbootclasspath.java Mon Oct 19 16:58:00 > 2020 +0200 > @@ -55,5 +55,6 @@ > new OutputAnalyzer(ProcessTools.createJavaProcessBuilder( > "-Xbootclasspath/a:" + test_classes, "P.Test") > - .start()).shouldContain("Test Passed"); > + .start()).shouldContain("Test Passed") > + .shouldHaveExitValue(0); > } > } This looks fine to me. Thanks, Severin From shade at redhat.com Wed Oct 28 09:29:51 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 28 Oct 2020 10:29:51 +0100 Subject: [11u] RFR 8244142: some hotspot/runtime tests don't check exit code of forked JVM In-Reply-To: <2324f55f5396ce9974201e7fd88e019447f781b3.camel@redhat.com> References: <3f266f1c-6a20-10a7-22cb-4ce4b8d61ae6@redhat.com> <2324f55f5396ce9974201e7fd88e019447f781b3.camel@redhat.com> Message-ID: <59f35e59-421c-b306-5a8c-638f0ae392f3@redhat.com> On 10/28/20 10:12 AM, Severin Gehwolf wrote: > This looks fine to me. Thanks. I see the approval in the bug. Pushed! -- Thanks, -Aleksey From sgehwolf at redhat.com Wed Oct 28 10:21:44 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 28 Oct 2020 11:21:44 +0100 Subject: [11u] RFR 8252090: JFR: StreamWriterHost::write_unbuffered() stucks in an infinite loop OpenJDK (build 13.0.1+9) In-Reply-To: References: Message-ID: <7e5a6e8f96125cfd610cb6ffabde6adad664a916.camel@redhat.com> Hi, On Mon, 2020-10-19 at 18:05 +0200, Jaroslav Bachor?k wrote: > Gentle ping? > > On Wed, Oct 7, 2020 at 5:58 PM Jaroslav Bachor?k > wrote: > > Hello, > > > > Can I get the following backport reviewed? > > > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8252090 > > Webrev: http://cr.openjdk.java.net/~jbachorik/8252090/00/webrev/ > > > > The backport and the original patch are differing in 1 place only: > > - src/hotspot/share/jfr/recorder/repository/jfrChunkWriter.cpp does > > not contain write_magic() method and the change needs to be done in > > JfrChunkWriter::open() instead It also differs a bit in jfrStorageUtils.inline.hpp where EpochDispatchOp::process() isn't present in 11u. OK. The patch seems OK to me. Thanks, Severin > > Ran tier1 and jdk_jfr tests successfully. > > > > Thanks, > > > > -JB- From phh at openjdk.java.net Wed Oct 28 16:37:46 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Wed, 28 Oct 2020 16:37:46 GMT Subject: [jdk13u-dev] RFR: 8255468: JDK-8255269 incorrectly replaced average copy time In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 06:34:18 GMT, Yuri Nesterenko wrote: >> Please review this fix to the patch for JDK-8255269. Part of the average copy time calculation was left out. This line from the patch >> >> double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy); >> >> should be >> >> double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy) + average_time_ms(G1GCPhaseTimes::OptObjCopy); >> >> Thanks, >> Paul > > Marked as reviewed by yan (Reviewer). Thanks, Yuri. ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/6 From phh at openjdk.java.net Wed Oct 28 16:37:47 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Wed, 28 Oct 2020 16:37:47 GMT Subject: [jdk13u-dev] Integrated: 8255468: JDK-8255269 incorrectly replaced average copy time In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 16:50:29 GMT, Paul Hohensee wrote: > Please review this fix to the patch for JDK-8255269. Part of the average copy time calculation was left out. This line from the patch > > double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy); > > should be > > double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy) + average_time_ms(G1GCPhaseTimes::OptObjCopy); > > Thanks, > Paul This pull request has now been integrated. Changeset: dbc73fd6 Author: Paul Hohensee URL: https://git.openjdk.java.net/jdk13u-dev/commit/dbc73fd6 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8255468: JDK-8255269 incorrectly replaced average copy time Reviewed-by: yan ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/6 From maoliang.ml at alibaba-inc.com Thu Oct 29 06:46:59 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Thu, 29 Oct 2020 14:46:59 +0800 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: <001901d6ab3e$6cc96bb0$465c4310$@alibaba-inc.com> References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> <42e88c3e-763a-644e-a9ad-9299c9f36d5a@redhat.com> <001901d6ab3e$6cc96bb0$465c4310$@alibaba-inc.com> Message-ID: <004c01d6adbf$4cf91780$e6eb4680$@alibaba-inc.com> Hi All, For the potential memory footprint issue from JDK-6490394,I made more tests. Fixed IR test on specjbb2015 shows that memory footprint will climb more aggressively than original 11u. That could be an issue but it also exists in JDK12 to JDK15 for 4 releases. (I use following options to test: -Dspecjbb.controller.type=PRESET -Dspecjbb.controller.preset.ir=4000 -Dspecjbb.controller.preset.duration=1000000 -XX:ParallelGCThreads=8 -XX:+UseG1GC -Xmx10g -Xms1g -jar specjbb2015.jar -m COMPOSITE) As I suggested in previous mail that we can do resizing in remark only with (G1PeriodicGCInterval != 0) : http://cr.openjdk.java.net/~lmao/jep346.11u/all.webrev.01/ The diff with all.webrev.00 only contains: < + if (G1PeriodicGCInterval != 0) { < + _g1h->resize_heap_if_necessary(); < + } --- > + _g1h->resize_heap_if_necessary(); The tier1 is clean with fastdebug and the above specjbb2015 test won't have memory footprint issues anymore. So looks like most of impacts will be excluded from default G1. Could someone please take a look? Thanks, Liang > -----Original Message----- > From: Liang Mao [mailto:maoliang.ml at alibaba-inc.com] > Sent: 2020?10?26? 10:19 > To: 'Aleksey Shipilev' ; 'jdk-updates-dev' dev at openjdk.java.net>; 'Lindenmaier, Goetz' ; > 'Martijn Verburg' ; 'Ruslan Synytsky' > > Subject: RE: [11u] Backport JEP 346 : Promptly Return Unused Committed > Memory from G1 > > Hi Aleksey, > > Thanks very much for your careful initial review! > > > So, for the current action items: > > a) JDK-8238932 needs to be added, trivially; > Yes. It should be added although trival. > > > > b) JDK-6490394 needs to be investigated on footprint impact, > > possibly involving Man Cao / Google; > > JDK-6490394 might increase the memory footprint because introducing the > heap resize in remark phase. But we also need this to shrink the heap for saving > memory. The heap sizing heuristics in 11u has some original issues that it would > unnecessarily expand heap size with a fixed input. Thomas made a lot of efforts > on this later: > https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020- > June/030090.html > Even with a fixed IR running for specjbb2015 (as - > Dspecjbb.controller.preset.ir=4000), > the heap will expand continuously. > > So I think that's why JEP346 is valuable in 11u because not only memory > footprint issue in Java is a common sense but there're also some uncessary > memory expansion in G1. > > For the potential issue of increasing footprint by default, can we make a very > simple fix that we only do resize in remark with (G1PeriodicGCInterval != 0): > > +if (G1PeriodicGCInterval != 0) { > _g1h->resize_heap_if_necessary(); > +} > > So the additional sizing only happen with a specified G1PeriodicGCInterval. > > > c) JDK-8218880 deserves more attention/testing, possibly involving > > others; > > > > It seems the only real severe issue brought by the JEP. But periodic triggering GC > with GC locks on is not a common scenario. So it is acceptable that it took 3 > months to find the bug. And the fix is straight forward that just don't trigger GC > when GC locks on. After half and one year, there're no other bugs from the > feature. It looks stable for quite a long time (3 releases). > > Thanks, > Liang > > > -----Original Message----- > > From: Aleksey Shipilev [mailto:shade at redhat.com] > > Sent: 2020?10?22? 20:08 > > To: Liang Mao ; jdk-updates-dev > > ; Lindenmaier, Goetz > > ; Martijn Verburg > > ; Ruslan Synytsky > > Subject: Re: [11u] Backport JEP 346 : Promptly Return Unused Committed > > Memory from G1 > > > > On 9/25/20 8:42 AM, Liang Mao wrote: > > > All changes of the JEP only contains of hunderds lines of code: > > > http://cr.openjdk.java.net/~lmao/jep346.11u/all.webrev.00/ > > > > Andrew asked me to follow up on this from the GC implementation/risk > > perspective. > > > > The first cursory review follows. > > > > This issue seems to be missing from the batch: > > JDK-8238932: Invalid tier1_gc_1 test group definition > > > > A philosophical point: the obvious risk for this kind of backport is > > breaking something. Since G1 is the default garbage collector in 11u, > > breaking it would break most applications that run with out of the box > > settings. This can be partially mitigated if we had the kill-switch > > for the code, and that depends on how code is structured. > > > > Per-issue comments: > > > > > 1) JDK-8071913: Filter out entries to free/uncommitted regions > > > during iteration > > > http://cr.openjdk.java.net/~lmao/jep346.11u/8071913.webrev.00/ > > > > This looks like a faithful reproduction of original change. This thing > > concerns me the most: it touches the RSet code without any recourse in case it > is broken. > > > > > 2) JDK-6490394: G1: Allow heap shrinking / memory unmapping after > > > reclaiming regions during Remark > > > > Man Cao reports in the comments there that Google's internal JDK 11 > > had regressed memory footprint after this change. I cannot see if > > there was any follow-up on that. > > > > > 3) JDK-8213898: CDS dumping of springboot asserts in > > > G1ArchiveAllocator::alloc_new_region > > > > This seems to be a simple fix for another regression introduced by JDK- > 6490394. > > Looks fine. > > > > > 4) JDK-8212657: Implementation of JDK-8204089 Promptly Return Unused > > > Committed Memory from G1 > > > http://cr.openjdk.java.net/~lmao/jep346.11u/8212657.webrev.00/ > > > > This looks like a faithful reproduction of the original change. It > > seems fairly innocious, and codepaths revert to nops with > > -XX:G1PeriodicGCInterval=0 and - XX:G1PeriodicGCSystemLoadThreshold=0. > > > > update_rs_lengths_prediction() and update_ihop_prediction() are called > > in the different order now, but that seems fine, as they look independent. > > > > As said above, JDK-8238932 is missing as the follow-up. > > > > > 5) JDK-8215120: 32-bit build failures after JDK-8212657 (Promptly > > > Return Unused Committed Memory from G1) > > > > Simple follow up after JDK-8212657. Looks fine. > > > > > 6) JDK-8215149: TestOptionsWithRangesDynamic.java fails after > > > JDK-8215120 > > > > ...and another one. Looks fine. > > > > > 7) JDK-8215548: G1PeriodicGCSystemLoadThreshold needs to be a double > > > > Simple follow up for JDK-8212657. Looks fine. > > > > > 8) JDK-8216490: Spammy periodic GC log message contains random time > > > stamp with periodic gc disabled > > > > UX fix after JDK-8212657. Looks fine. > > > > > 9) JDK-8218880: G1 crashes when issuing a periodic GC while the > > > GCLocker is held > > > http://cr.openjdk.java.net/~lmao/jep346.11u/8218880.webrev.00/ > > > > This looks like a faithful reproduction of the original change. > > > > What concerns me, though, is that the bug was found full 3 months > > after introducing! And it crashed the VM hard, because periodic GC > > entered collect() from a non-Java thread! I would need some time to > > breathe out and prove to myself it is safe now. > > > > > 10) JDK-8212883: Setting a double manageable flag with jcmd/jinfo > > > crashes the JVM > > > > This one can actually be backported ahead of time to 11u, I think. I > > understand it is needed for > > JDK-8215548 in this queue, but I don't think that's a blocker for a > > separate inclusion, and it could be useful for other backports. > > > > So, for the current action items: > > a) JDK-8238932 needs to be added, trivially; > > b) JDK-6490394 needs to be investigated on footprint impact, > > possibly involving Man Cao / Google; > > c) JDK-8218880 deserves more attention/testing, possibly involving > > others; > > > > Thanks, > > -Aleksey From martin.doerr at sap.com Thu Oct 29 10:22:45 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 29 Oct 2020 10:22:45 +0000 Subject: 11.0.9 misses JDK-8250861 Message-ID: Hi, we have observed a crash with SIGSEGV in the C2 code on SPARC (but it's not in platform specific code) in 11.0.9. This code was introduced with http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/ed3959f95671 Fix is already available: https://bugs.openjdk.java.net/browse/JDK-8250861 I've requested backport for 11.0.10 so I'm planning to push it to jdk11u-dev. Does anybody need it in jdk11u? Best regards, Martin From sgehwolf at redhat.com Thu Oct 29 10:45:15 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 29 Oct 2020 11:45:15 +0100 Subject: 11.0.9 misses JDK-8250861 In-Reply-To: References: Message-ID: Hi Martin, Thanks for the heads-up. On Thu, 2020-10-29 at 10:22 +0000, Doerr, Martin wrote: > Hi, > > we have observed a crash with SIGSEGV in the C2 code on SPARC (but > it's not in platform specific code) in 11.0.9. This code was > introduced with > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/ed3959f95671 > > Fix is already available: > https://bugs.openjdk.java.net/browse/JDK-8250861 > > I've requested backport for 11.0.10 so I'm planning to push it to > jdk11u-dev. Does anybody need it in jdk11u? Approved for 11.0.10. I'll let others chime in on whether or not this warrants a respin for 11.0.9. Thanks, Severin From aph at redhat.com Thu Oct 29 11:09:36 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 29 Oct 2020 11:09:36 +0000 Subject: 11.0.9 misses JDK-8250861 In-Reply-To: References: Message-ID: Hi, On 29/10/2020 10:45, Severin Gehwolf wrote: > > On Thu, 2020-10-29 at 10:22 +0000, Doerr, Martin wrote: >> Hi, >> >> we have observed a crash with SIGSEGV in the C2 code on SPARC (but >> it's not in platform specific code) in 11.0.9. This code was >> introduced with >> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/ed3959f95671 >> >> Fix is already available: >> https://bugs.openjdk.java.net/browse/JDK-8250861 >> >> I've requested backport for 11.0.10 so I'm planning to push it to >> jdk11u-dev. Does anybody need it in jdk11u? > > Approved for 11.0.10. > > I'll let others chime in on whether or not this warrants a respin for > 11.0.9. I would have thought so. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Thu Oct 29 11:31:10 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 29 Oct 2020 11:31:10 +0000 Subject: 11.0.9 misses JDK-8250861 In-Reply-To: References: Message-ID: Hi, So should we release a 11.0.9.0.1 version? I could post a RFR for the version change. I think we should also bump the release date, then. But to which date? Maybe Monday, 2.11.? Actually, we have detected another problem introduced in 11.0.8, Christoph has the details. It increases memory footprint severely and came up in our productive systems. Unfortunately, no fix exists yet in OpenJDK, we are working on it. But it might be another candidate for a 11.0.9.0.1. Best regards, Goetz. -----Original Message----- From: jdk-updates-dev On Behalf Of Andrew Haley Sent: Donnerstag, 29. Oktober 2020 12:10 To: jdk-updates-dev at openjdk.java.net Subject: Re: 11.0.9 misses JDK-8250861 Hi, On 29/10/2020 10:45, Severin Gehwolf wrote: > > On Thu, 2020-10-29 at 10:22 +0000, Doerr, Martin wrote: >> Hi, >> >> we have observed a crash with SIGSEGV in the C2 code on SPARC (but >> it's not in platform specific code) in 11.0.9. This code was >> introduced with >> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/ed3959f95671 >> >> Fix is already available: >> https://bugs.openjdk.java.net/browse/JDK-8250861 >> >> I've requested backport for 11.0.10 so I'm planning to push it to >> jdk11u-dev. Does anybody need it in jdk11u? > > Approved for 11.0.10. > > I'll let others chime in on whether or not this warrants a respin for > 11.0.9. I would have thought so. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Oct 29 11:47:11 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 29 Oct 2020 11:47:11 +0000 Subject: 11.0.9 misses JDK-8250861 In-Reply-To: References: Message-ID: <5a2f0339-9c4a-ba96-3184-6e1954c19adf@redhat.com> On 29/10/2020 11:31, Lindenmaier, Goetz wrote: > Actually, we have detected another problem introduced > in 11.0.8, Christoph has the details. > It increases memory footprint severely and came up > in our productive systems. Unfortunately, no fix > exists yet in OpenJDK, we are working on it. > But it might be another candidate for a 11.0.9.0.1. Any guess at an ETA? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Thu Oct 29 12:46:49 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 29 Oct 2020 13:46:49 +0100 Subject: 11.0.9 misses JDK-8250861 In-Reply-To: References: Message-ID: <60e83046d0289cc878703784869896773664eefd.camel@redhat.com> On Thu, 2020-10-29 at 11:09 +0000, Andrew Haley wrote: > Hi, > > On 29/10/2020 10:45, Severin Gehwolf wrote: > > On Thu, 2020-10-29 at 10:22 +0000, Doerr, Martin wrote: > > > Hi, > > > > > > we have observed a crash with SIGSEGV in the C2 code on SPARC (but > > > it's not in platform specific code) in 11.0.9. This code was > > > introduced with > > > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/ed3959f95671 > > > > > > Fix is already available: > > > https://bugs.openjdk.java.net/browse/JDK-8250861 > > > > > > I've requested backport for 11.0.10 so I'm planning to push it to > > > jdk11u-dev. Does anybody need it in jdk11u? > > > > Approved for 11.0.10. > > > > I'll let others chime in on whether or not this warrants a respin for > > 11.0.9. > > I would have thought so. :) Sorry, that came out wrong. What I wanted to say was: Let's hear what others have to say about this with respect to a potential respin. Thanks, Severin From christoph.langer at sap.com Thu Oct 29 14:39:51 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 29 Oct 2020 14:39:51 +0000 Subject: 11.0.9 misses JDK-8250861 In-Reply-To: <5a2f0339-9c4a-ba96-3184-6e1954c19adf@redhat.com> References: <5a2f0339-9c4a-ba96-3184-6e1954c19adf@redhat.com> Message-ID: Hi, I'm about to create the bug for head jdk and RFR now... let's see how it's received from the security-dev experts, checkpoint e.g. tomorrow EOB. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Haley > Sent: Donnerstag, 29. Oktober 2020 12:47 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: 11.0.9 misses JDK-8250861 > > On 29/10/2020 11:31, Lindenmaier, Goetz wrote: > > Actually, we have detected another problem introduced > > in 11.0.8, Christoph has the details. > > It increases memory footprint severely and came up > > in our productive systems. Unfortunately, no fix > > exists yet in OpenJDK, we are working on it. > > But it might be another candidate for a 11.0.9.0.1. > > Any guess at an ETA? > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Thu Oct 29 15:39:21 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 29 Oct 2020 15:39:21 +0000 Subject: 11.0.9 misses JDK-8250861 In-Reply-To: References: <5a2f0339-9c4a-ba96-3184-6e1954c19adf@redhat.com> Message-ID: Hi again, I've just created: https://bugs.openjdk.java.net/browse/JDK-8255603 https://github.com/openjdk/jdk/pull/937 However, I can also see, that this potential regression is already part of 11.0.5 and hence, I don't think it should go into an 11.0.9 respin, whether or not it is merged into head soon. Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 29. Oktober 2020 15:40 > To: Andrew Haley ; Lindenmaier, Goetz > ; jdk-updates-dev at openjdk.java.net > Subject: RE: 11.0.9 misses JDK-8250861 > > Hi, > > I'm about to create the bug for head jdk and RFR now... let's see how it's > received from the security-dev experts, checkpoint e.g. tomorrow EOB. > > Cheers > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Andrew Haley > > Sent: Donnerstag, 29. Oktober 2020 12:47 > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: Re: 11.0.9 misses JDK-8250861 > > > > On 29/10/2020 11:31, Lindenmaier, Goetz wrote: > > > Actually, we have detected another problem introduced > > > in 11.0.8, Christoph has the details. > > > It increases memory footprint severely and came up > > > in our productive systems. Unfortunately, no fix > > > exists yet in OpenJDK, we are working on it. > > > But it might be another candidate for a 11.0.9.0.1. > > > > Any guess at an ETA? > > > > -- > > Andrew Haley (he/him) > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > https://keybase.io/andrewhaley > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gil at azul.com Thu Oct 29 17:12:06 2020 From: gil at azul.com (Gil Tene) Date: Thu, 29 Oct 2020 17:12:06 +0000 Subject: 11.0.9 misses JDK-8250861 In-Reply-To: References: Message-ID: <3E0927E4-63A9-4DD0-AF1C-8F4CD11A540A@azul.com> > On Oct 29, 2020, at 1:31 AM, Lindenmaier, Goetz wrote: > > Hi, > > So should we release a 11.0.9.0.1 version? Without opining in any way on whether or not a respin of 11.0.9 is needed or not, I'd like to chime in on the version number for such a respin *if* one is done. We have not done any of those in the 11+ version range this far (we did e.g. 8u265 as an urgent update after 8u262, but the versioning convention there is different). According to JEP322 [1], the first four elements in the version are assigned meaning: $FEATURE.$INTERIM.$UPDATE.$PATCH And "...The fifth and later elements of version numbers are reserved for use by downstream consumers of the JDK code base." As such, I think the 11u (and later updates projects) should not use the fifth element, and that the right version for an 11.0.9 "patch" (if one is done) would be 11.0.9.1 [1] https://openjdk.java.net/jeps/322 > I could post a RFR for the version change. > I think we should also bump the release date, then. > But to which date? Maybe Monday, 2.11.? > > Actually, we have detected another problem introduced > in 11.0.8, Christoph has the details. > It increases memory footprint severely and came up > in our productive systems. Unfortunately, no fix > exists yet in OpenJDK, we are working on it. > But it might be another candidate for a 11.0.9.0.1. > > Best regards, > Goetz. > > > > > -----Original Message----- > From: jdk-updates-dev On Behalf Of Andrew Haley > Sent: Donnerstag, 29. Oktober 2020 12:10 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: 11.0.9 misses JDK-8250861 > > Hi, > > On 29/10/2020 10:45, Severin Gehwolf wrote: >> >> On Thu, 2020-10-29 at 10:22 +0000, Doerr, Martin wrote: >>> Hi, >>> >>> we have observed a crash with SIGSEGV in the C2 code on SPARC (but >>> it's not in platform specific code) in 11.0.9. This code was >>> introduced with >>> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/ed3959f95671 >>> >>> Fix is already available: >>> https://bugs.openjdk.java.net/browse/JDK-8250861 >>> >>> I've requested backport for 11.0.10 so I'm planning to push it to >>> jdk11u-dev. Does anybody need it in jdk11u? >> >> Approved for 11.0.10. >> >> I'll let others chime in on whether or not this warrants a respin for >> 11.0.9. > > I would have thought so. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From goetz.lindenmaier at sap.com Fri Oct 30 10:15:21 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 30 Oct 2020 10:15:21 +0000 Subject: [11u] RFR: 8249607: C2: assert(!had_error) failed: bad dominance In-Reply-To: References: Message-ID: Hi Paul, Thanks for reviewing. I added the blank line. Best regards, Goetz. > -----Original Message----- > From: Hohensee, Paul > Sent: Friday, October 23, 2020 11:30 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8249607: C2: assert(!had_error) failed: bad > dominance > > Lgtm, though since you're cleaning up a few spaces, you could also add the > blank line after the #endif in loopnode.hpp. :) > > Thanks, > Paul > > ?On 10/23/20, 10:31 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" > goetz.lindenmaier at sap.com> wrote: > > HI > > I am downporting this for parity with 11.0.10-oracle. > > http://cr.openjdk.java.net/~goetz/wr20/8249607-bad_dominance- > jdk11/01/ > > I had to do real trivial resolves in loopnode.hpp due to space > Differences in the context. > > https://bugs.openjdk.java.net/browse/JDK-8249607 > https://hg.openjdk.java.net/jdk/jdk/rev/05d7a0663063 > > Best regards, > Goetz. From christoph.langer at sap.com Fri Oct 30 10:23:40 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 30 Oct 2020 10:23:40 +0000 Subject: [11u] Respin of JDK 11.0.9 with JDK-8250861 and JDK-8255603 -> 11.0.9.1 Message-ID: Hi, I hereby propose a re-spin of OpenJDK 11 update release 11.0.9 with the following two fixes to be added: JDK-8250861: Crash in MinINode::Ideal(PhaseGVN*, bool) [0] JDK-8255603: Memory/Performance regression after JDK-8210985 [1] The first one is a potential crash which comes as a regression to one of the October CPU patches. The second one fixes a memory regression that was introduced with 11.0.5 already but has just been analyzed and fixed within the last few days. The version number of the update would be 11.0.9.1, as Gil correctly pointed out [2] I will wait for feedback/objections until Tuesday 03/11/20 EOB. In case nobody vetoes, Goetz and me will go ahead on Wednesday 04/11/20 and push these patches into the jdk11u repository, along with the required version bumps and tags. Thanks and best regards, Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8250861 [1] https://bugs.openjdk.java.net/browse/JDK-8255603 [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-October/004055.html From sgehwolf at redhat.com Fri Oct 30 16:08:32 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 30 Oct 2020 17:08:32 +0100 Subject: [11u] Respin of JDK 11.0.9 with JDK-8250861 and JDK-8255603 -> 11.0.9.1 In-Reply-To: References: Message-ID: <4ff2839dcb37c16694c85cf943961498446db38c.camel@redhat.com> Hi, On Fri, 2020-10-30 at 10:23 +0000, Langer, Christoph wrote: > Hi, > > I hereby propose a re-spin of OpenJDK 11 update release 11.0.9 with the following two fixes to be added: > > JDK-8250861: Crash in MinINode::Ideal(PhaseGVN*, bool) [0] > JDK-8255603: Memory/Performance regression after JDK-8210985 [1] > > The first one is a potential crash which comes as a regression to one of the October CPU patches. The second one fixes a memory regression that was introduced with 11.0.5 already but has just been analyzed and fixed within the last few days. > > The version number of the update would be 11.0.9.1, as Gil correctly pointed out [2] > > I will wait for feedback/objections until Tuesday 03/11/20 EOB. In case nobody vetoes, Goetz and me will go ahead on Wednesday 04/11/20 and push these patches into the jdk11u repository, along with the required version bumps and tags. Here are my thoughts: JDK-8250861 is a regression introduced in 11.0.9 and a serious crasher bug in c2. If consensus is to fix it with an async update to 11.0.9, then we should do the same for 8u272 (and possibly JDK 13). It looks like for JDK 15 it'll end up in 15.0.2. Just some more data points :) As to JDK-8255603, my preference would be to defer to 11.0.10. While the fix seems benign, it appears nobody noticed this until very recently. 11.0.5 got out in October 2019. There is a known work-around. At least it seems strange to rush this fix now, where it's been out in the wild for about a year. Thanks, Severin > > [0] https://bugs.openjdk.java.net/browse/JDK-8250861 > [1] https://bugs.openjdk.java.net/browse/JDK-8255603 > [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-October/004055.html >