From linzang at tencent.com Wed Apr 1 04:57:56 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Wed, 1 Apr 2020 04:57:56 +0000 Subject: RFR 8241285(s): [jdk8u] fail to build hotspot with gcc-8.4.0 with or without COMPILER_WARNINGS_FATAL(Internet mail) In-Reply-To: <1784D304-9914-4BC5-9E56-8FEC0607D170@tencent.com> References: <0FBDE19A-C44F-4460-9CDF-33C380EE406E@tencent.com> <9198BFA1-673B-4B28-83AC-A07EE44772BD@amazon.com> <1784D304-9914-4BC5-9E56-8FEC0607D170@tencent.com> Message-ID: Dear All, May I ask your help to review this small change? And may I ask help of pushing it if a go decision is made. Thanks. BRs, Lin ?On 2020/3/30, 10:41 AM, "linzang(??)" wrote: Thanks Paul! Dear All, may I get more review about this patch? Or may I get help for tesitng it on platfrom other than bsd and Linux? Thanks! BRs, Lin On 2020/3/25, 9:29 PM, "Hohensee, Paul" wrote: It would be great if someone could build on the other platforms. Otherwise, lgtm. Paul On 3/24/20, 11:22 PM, "linzang(??)" 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 Paul, Thanks for your comments, I hava upload a new patch http://cr.openjdk.java.net/~lzang/8241285/webrev03 >> Has it been tested on all affected platforms? No, I only test on macos and linux, since they are the only platforms I could find. BRs, Lin On 2020/3/25, 12:19 AM, "Hohensee, Paul" wrote: In make/solaris/makefiles/gcc.make, the WARNINGS_ARE_ERRORS line should be indented 2 spaces. For aix, the COMPILER_WARNINGS_FATAL check looks like it should go in xlc.make. Code would be the same as in make/linux/makefiles/gcc.make. Has it been tested on all affected platforms? Paul On 3/24/20, 7:12 AM, "linzang(??)" wrote: Dear Paul and Andrew? May I ask your help to review this new patch?and help to push it if it is ok. Thanks! BRs, Lin > ? 2020?3?21????1:00?linzang(??) ??? > > Dear Paul and Andrew, > > A new patch has been uploaded to http://cr.openjdk.java.net/~lzang/8241285/webrev02 > Would you like to help review it? Thanks. > > > > BRs, > Lin > > > On 2020/3/20, 11:47 PM, "Hohensee, Paul" wrote: >> >> Lgtm. I see that Andrew has approved 8241285 as an 8u-only patch (extended to all unixen). >> >> Paul >> >> On 3/19/20, 8:31 PM, "linzang(??)" wrote: >> >> Dear Paul, >> Thanks for your suggestion, it seems https://bugs.openjdk.java.net/browse/JDK-8144695 was introduced to fix this issue on jdk9, by changing "WARNINGS_AS_ERROR=" to " WARNINGS_AS_ERROR?=". >> But it is based on "--disable-warnings-as-errors" flag, and this flag set a global WARNINGS_AS_ERROR flag, which jdk8 doesn't have it, so simply backport the patch can't solve the problem. >> I have made some change based on it . and I will mark my fix as backport. >> And I have updated the patch based on the fix of https://bugs.openjdk.java.net/browse/JDK-8144695. >> Webrev: http://cr.openjdk.java.net/~lzang/8241285/webrev01/ >> Would you like to help review? Thanks. >> >> >> BRs, >> Lin >> >>>> On 2020/3/20, 2:11 AM, "Hohensee, Paul" wrote: >>> >>> Is there an existing JBS issue you can backport to get the same effect? >>> >>> Thanks, >>> Paul >>> >>>> On 3/19/20, 7:00 AM, "jdk8u-dev on behalf of linzang(??)" wrote: >>> >>> Dear All, >>> Would you like to help review this tiny fix of build hotspot with gcc-8.4.0? >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241285 >>> Webrev: http://cr.openjdk.java.net/~lzang/8241285/webrev/ >>> >>> The fix makes gcc consider COMPILER_WARNINGS_FATAL flag, when it set to false, the warnings from gcc will not be treated as error. >>> >>> BRs, >>> Lin > > > > > > > > > From aph at redhat.com Wed Apr 1 10:22:23 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 1 Apr 2020 11:22:23 +0100 Subject: [8u] RFR: 8237951: CTW: C2 compilation fails with "malformed control flow" In-Reply-To: <871rp8ek1x.fsf@redhat.com> References: <871rp8ek1x.fsf@redhat.com> Message-ID: <51b56814-c654-beaf-f4d3-0e952ff337fa@redhat.com> On 3/31/20 2:22 PM, Roland Westrelin wrote: > The patch from the fix applies cleanly but it relies on > Node::find_out_with() that's missing from 8. The backport below cherry > picks that method from 8066312 (Add new Node* Node::find_out(int opc) > method). > > http://cr.openjdk.java.net/~roland/8237951.8u/webrev.00/ OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Apr 1 10:55:30 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 1 Apr 2020 11:55:30 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat Message-ID: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> http://cr.openjdk.java.net/~aph/8076475-8u/ Original bug: https://bugs.openjdk.java.net/browse/JDK-8076475 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4cf3113c8f42 In a couple of places the original patch didn't apply because the code being patched was not there yet. Other places required some minor adjustments. OK, I'll be honest, I'm not completely convinced that this is really a suitable patch to be backported to stable 8u. Maybe as a maintainer I'll reject it. But I've done it now, so I'd be grateful for a review. -- 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 zgu at redhat.com Wed Apr 1 12:18:34 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 1 Apr 2020 08:18:34 -0400 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> Message-ID: <99779015-670e-fd72-1018-a484f6d2435f@redhat.com> Backport looks good to me. -Zhengyu On 4/1/20 6:55 AM, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8076475-8u/ > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8076475 > Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4cf3113c8f42 > > In a couple of places the original patch didn't apply because the code > being patched was not there yet. Other places required some minor > adjustments. > > OK, I'll be honest, I'm not completely convinced that this is really a > suitable patch to be backported to stable 8u. Maybe as a maintainer > I'll reject it. But I've done it now, so I'd be grateful for a review. > From snazarkin at azul.com Wed Apr 1 14:30:27 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Wed, 1 Apr 2020 14:30:27 +0000 Subject: [8u] RFR: Backport of 8067796 (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null In-Reply-To: References: <11F4B16A-212E-4805-AF6A-46B8760278EB@azul.com> <586f5546-4614-565a-dc5f-8c62aff09782@redhat.com> <2b42427a-6485-4c36-fbb2-ff7f4eedf08b@redhat.com> <23C95150-015E-417C-AEF9-5E3E389896DA@azul.com> Message-ID: I?ve tracked down patchset required for clean backport. Beside 8037866 [2] only 8014066 [1] is required. I?m a bit worrying about 8014066, the changeset may affect existent applications behavior. With 8014066 all subsequent patches applied cleanly except 8067796: - for non-windows OSes waitFor method is at UNIXProcess.java (not ProcessImpl.java) - windows version of ProcessImpl.java is placed at different path - Basic.java: bug list is different If 8014066 is accepted for backport I?ll create separate RFRs. In this case patch sequence should be [4] -> [5] -> [6] [1] https://bugs.openjdk.java.net/browse/JDK-8014066 [2] https://bugs.openjdk.java.net/browse/JDK-8037866 [3] https://bugs.openjdk.java.net/browse/JDK-8067796 [4] http://cr.openjdk.java.net/~snazarki/webrev/8014066/ [5] http://cr.openjdk.java.net/~snazarki/webrev/8037866/ [6] http://cr.openjdk.java.net/~snazarki/webrev/8067796/ Sergey Nazarkin > On Mar 27, 2020, at 10:26, Andrew Hughes wrote: > > > > On 26/03/2020 17:39, Sergey Nazarkin wrote: >> Yes, fixes are jdk8 specific and caused by refactoring introduced at http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/cb15bc14c26a. >> >> >> Sergey Nazarkin >> >> > > Ah right, I see the problem; Fun becomes an interface after JDK-8037866, > allowing the lambdas in the test case to implement it. > > I think the right course here is to backport JDK-8037866. It's a test > only change and no doubt other test backports will end up hitting this > problem in the future. Your original webrev should then still be valid. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > From hohensee at amazon.com Wed Apr 1 15:11:43 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 1 Apr 2020 15:11:43 +0000 Subject: RFR 8241285(s): [jdk8u] fail to build hotspot with gcc-8.4.0 with or without COMPILER_WARNINGS_FATAL(Internet mail) Message-ID: <89117E11-B7F2-4B46-8BD0-B3C9AC918E62@amazon.com> I believe you need only one review for a backport, so you can now tag the issue with jdk8-fix-request and a 'Fix Request (8u)' comment. Thanks, Paul ?On 3/31/20, 9:58 PM, "linzang(??)" wrote: Dear All, May I ask your help to review this small change? And may I ask help of pushing it if a go decision is made. Thanks. BRs, Lin On 2020/3/30, 10:41 AM, "linzang(??)" wrote: Thanks Paul! Dear All, may I get more review about this patch? Or may I get help for tesitng it on platfrom other than bsd and Linux? Thanks! BRs, Lin On 2020/3/25, 9:29 PM, "Hohensee, Paul" wrote: It would be great if someone could build on the other platforms. Otherwise, lgtm. Paul On 3/24/20, 11:22 PM, "linzang(??)" 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 Paul, Thanks for your comments, I hava upload a new patch http://cr.openjdk.java.net/~lzang/8241285/webrev03 >> Has it been tested on all affected platforms? No, I only test on macos and linux, since they are the only platforms I could find. BRs, Lin On 2020/3/25, 12:19 AM, "Hohensee, Paul" wrote: In make/solaris/makefiles/gcc.make, the WARNINGS_ARE_ERRORS line should be indented 2 spaces. For aix, the COMPILER_WARNINGS_FATAL check looks like it should go in xlc.make. Code would be the same as in make/linux/makefiles/gcc.make. Has it been tested on all affected platforms? Paul On 3/24/20, 7:12 AM, "linzang(??)" wrote: Dear Paul and Andrew? May I ask your help to review this new patch?and help to push it if it is ok. Thanks! BRs, Lin > ? 2020?3?21????1:00?linzang(??) ??? > > Dear Paul and Andrew, > > A new patch has been uploaded to http://cr.openjdk.java.net/~lzang/8241285/webrev02 > Would you like to help review it? Thanks. > > > > BRs, > Lin > > > On 2020/3/20, 11:47 PM, "Hohensee, Paul" wrote: >> >> Lgtm. I see that Andrew has approved 8241285 as an 8u-only patch (extended to all unixen). >> >> Paul >> >> On 3/19/20, 8:31 PM, "linzang(??)" wrote: >> >> Dear Paul, >> Thanks for your suggestion, it seems https://bugs.openjdk.java.net/browse/JDK-8144695 was introduced to fix this issue on jdk9, by changing "WARNINGS_AS_ERROR=" to " WARNINGS_AS_ERROR?=". >> But it is based on "--disable-warnings-as-errors" flag, and this flag set a global WARNINGS_AS_ERROR flag, which jdk8 doesn't have it, so simply backport the patch can't solve the problem. >> I have made some change based on it . and I will mark my fix as backport. >> And I have updated the patch based on the fix of https://bugs.openjdk.java.net/browse/JDK-8144695. >> Webrev: http://cr.openjdk.java.net/~lzang/8241285/webrev01/ >> Would you like to help review? Thanks. >> >> >> BRs, >> Lin >> >>>> On 2020/3/20, 2:11 AM, "Hohensee, Paul" wrote: >>> >>> Is there an existing JBS issue you can backport to get the same effect? >>> >>> Thanks, >>> Paul >>> >>>> On 3/19/20, 7:00 AM, "jdk8u-dev on behalf of linzang(??)" wrote: >>> >>> Dear All, >>> Would you like to help review this tiny fix of build hotspot with gcc-8.4.0? >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241285 >>> Webrev: http://cr.openjdk.java.net/~lzang/8241285/webrev/ >>> >>> The fix makes gcc consider COMPILER_WARNINGS_FATAL flag, when it set to false, the warnings from gcc will not be treated as error. >>> >>> BRs, >>> Lin > > > > > > > > > From aph at redhat.com Wed Apr 1 15:14:17 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 1 Apr 2020 16:14:17 +0100 Subject: [8u] RFR: Backport of 8067796 (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null In-Reply-To: References: <11F4B16A-212E-4805-AF6A-46B8760278EB@azul.com> <586f5546-4614-565a-dc5f-8c62aff09782@redhat.com> <2b42427a-6485-4c36-fbb2-ff7f4eedf08b@redhat.com> <23C95150-015E-417C-AEF9-5E3E389896DA@azul.com> Message-ID: <87c7205e-5b55-f95c-0800-72c4e0aa408c@redhat.com> On 4/1/20 3:30 PM, Sergey Nazarkin wrote: > I?ve tracked down patchset required for clean backport. Beside 8037866 [2] only 8014066 [1] is required. I?m a bit worrying about 8014066, the changeset may affect existent applications behavior. > > With 8014066 all subsequent patches applied cleanly except 8067796: > - for non-windows OSes waitFor method is at UNIXProcess.java (not ProcessImpl.java) > - windows version of ProcessImpl.java is placed at different path > - Basic.java: bug list is different > > If 8014066 is accepted for backport I?ll create separate RFRs. In this case patch sequence should be [4] -> [5] -> [6] > > [1] https://bugs.openjdk.java.net/browse/JDK-8014066 > [2] https://bugs.openjdk.java.net/browse/JDK-8037866 > [3] https://bugs.openjdk.java.net/browse/JDK-8067796 > > [4] http://cr.openjdk.java.net/~snazarki/webrev/8014066/ > [5] http://cr.openjdk.java.net/~snazarki/webrev/8037866/ > [6] http://cr.openjdk.java.net/~snazarki/webrev/8067796/ You're right. This is too much for the initial patch, which is low risk and changes only a few lines. It'd be OK if you find a way to do it without changing ArrayList#removeRange. It wouldn't be a disaster if you rewrote the test case to not require JDK-8037866. -- 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 Wed Apr 1 15:43:46 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 1 Apr 2020 16:43:46 +0100 Subject: [8u] 8039082: [TEST_BUG] Test java/awt/dnd/BadSerializationTest/BadSerializationTest.java fails In-Reply-To: References: Message-ID: On 3/25/20 4:27 PM, Zhengyu Gu wrote: > 1) The test is not in 8u's ProblemList.txt > > 2) Replaced binary files. Generated those files for 8u, they are version > specific. > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8039082 > Original patch: http://hg.openjdk.java.net/jdk/client/rev/4b2c1e154664 > > 8u patch: http://cr.openjdk.java.net/~zgu/JDK-8039082_8u/webrev.00/ OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Wed Apr 1 15:45:50 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 1 Apr 2020 11:45:50 -0400 Subject: [8u] 8039082: [TEST_BUG] Test java/awt/dnd/BadSerializationTest/BadSerializationTest.java fails In-Reply-To: References: Message-ID: <0a73dbdf-6eca-920f-686e-8b823c4a2c9d@redhat.com> Thanks, Andrew. -Zhengyu On 4/1/20 11:43 AM, Andrew Haley wrote: > On 3/25/20 4:27 PM, Zhengyu Gu wrote: >> 1) The test is not in 8u's ProblemList.txt >> >> 2) Replaced binary files. Generated those files for 8u, they are version >> specific. >> >> >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8039082 >> Original patch: http://hg.openjdk.java.net/jdk/client/rev/4b2c1e154664 >> >> 8u patch: http://cr.openjdk.java.net/~zgu/JDK-8039082_8u/webrev.00/ > > OK, thanks. > From gnu.andrew at redhat.com Wed Apr 1 17:54:28 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 1 Apr 2020 18:54:28 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> Message-ID: <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> On 01/04/2020 11:55, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8076475-8u/ > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8076475 > Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4cf3113c8f42 > > In a couple of places the original patch didn't apply because the code > being patched was not there yet. Other places required some minor > adjustments. Looking at the places where this differs from the OpenJDK 9 version: * src/share/vm/compiler/compilerOracle.cpp - This hunk is missing because JDK-8059847 (double support for command-line arguments) is absent. I backported this myself as a pre-requisite for this patch [0], as it seemed trivial enough and avoids someone missing the strncat change if JDK-8059847 is later backported, but it's certainly optional. * src/share/vm/runtime/arguments.cpp - The two missing hunks here were handled by a security fix, JDK-815968, in the Oct 2016 CPU. If we're going to introduce os::strdup_check_oom (see below), we might want to consider whether to change the first case (if pos != NULL) to match the JDK-8076475 version. * src/share/vm/utilities/ostream.cpp The missing hunk was added by JDK-8196882: "VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already Defined Compilation Error" * src/share/vm/runtime/os.{c,h}pp If we're going to add strdup_check_oom, I think this should be done by backporting JDK-6424123 [1] so it's used consistently throughout the codebase rather than just the two call sites in this patch. As I've already backported this, I'm happy to submit this against current 8u-dev and then you can rebase against this. > > OK, I'll be honest, I'm not completely convinced that this is really a > suitable patch to be backported to stable 8u. Maybe as a maintainer > I'll reject it. But I've done it now, so I'd be grateful for a review. > I tend towards including this. The fact that part of it was already picked up by a security fix suggests it's a useful hardening of this code and it's been around since 2015, so is pretty well tested. Similarly, JDK-6224123 dates back to 2014. [0] http://icedtea.classpath.org//hg/icedtea8-forest/hotspot?cmd=changeset;node=f8beb13aec9f [1] http://icedtea.classpath.org//hg/icedtea8-forest/hotspot?cmd=changeset;node=cfb34db6589e Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Apr 1 18:09:46 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 1 Apr 2020 19:09:46 +0100 Subject: RFR 8241285(s): [jdk8u] fail to build hotspot with gcc-8.4.0 with or without COMPILER_WARNINGS_FATAL(Internet mail) In-Reply-To: <0FBDE19A-C44F-4460-9CDF-33C380EE406E@tencent.com> References: <0FBDE19A-C44F-4460-9CDF-33C380EE406E@tencent.com> Message-ID: On 25/03/2020 06:21, linzang(??) wrote: > Hi Paul, > Thanks for your comments, I hava upload a new patch http://cr.openjdk.java.net/~lzang/8241285/webrev03 > > >> Has it been tested on all affected platforms? > No, I only test on macos and linux, since they are the only platforms I could find. > > BRs, > Lin > A few comments: * make/aix/makefiles/xlc.make - This doesn't seem to do anything as WARNINGS_ARE_ERRORS is never used. I suspect EXTRA_WARNINGS should be replaced by WARNINGS_ARE_ERRORS, but it would be good to have some feedback from AIX people. - There seems to be a blank line being added for no reason. * make/solaris/makefiles/adlc.make - Bogus whitespace change to "We need libCstd.so for adlc" line - -errwarn gets replaced by -xwe. I think it would be better to revert this unless there is a good reason to change it. * make/solaris/makefiles/sparcWorks.make - Missing indenting. Should be ok with those issues fixed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alexey at azul.com Wed Apr 1 20:35:30 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 1 Apr 2020 20:35:30 +0000 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <7165F681-60B6-438E-8967-3BE2FC850472@azul.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <92098404-8A1F-4CF7-BD83-41AF69CEB362@azul.com> <57211559-08ad-b26a-9596-7a3308c1d52f@redhat.com> <7165F681-60B6-438E-8967-3BE2FC850472@azul.com> Message-ID: Hello All, I?ve noticed, that the following bugs are targeted for JDK11.07 release only. They are not included in JDK11.06-GA : - 8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 [1] - 8225766: Curve in certificate should not affect signature scheme when using TLSv1.3 [2] I excluded these bug fixes from the TLSv1.3 for JDK8 implementation. The webrev is updated : http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v3/ Also, there is a diff between JDK11.06-GA and TLSv1.3 for JDK8 implementation (sun.security.ssl package only). It shows how JDK11 TLSv1.3 implementation was changed to be applied to JDK8 MR3 : http://cr.openjdk.java.net/~abakhtin/tls1.3_vs_jdk11/webrev.v0/ [1] - https://bugs.openjdk.java.net/browse/JDK-8236039 [2] - https://bugs.openjdk.java.net/browse/JDK-8225766 Regards Alexey On 27 Mar 2020, at 17:54, Alexey Bakhtin > wrote: Hello Andrew, Volker This patch of TLSv1.3 backport for JDK8u is based on the TLSv1.3 implementation for JDK11.06 and OpenJSSE provider implementation version v1.1.2 OpenJSSE is an open source pluggable security provider for TLSv1.3 protocol in JDK8u. OpenJSSE provider version 1.1.0 was released in July 2019 and based on the JDK11.04 TLSv1.3 implementation. Subsequent versions of the OpenJSSE provider were created by backporting TLS related fixes from JDK11.05 and JDK11.06. The history of these backports is available at https://github.com/openjsse/openjsse/commits/master The latest version of OpenJSSE v1.1.2 contains almost all TLS related bug fixes available in JDK11.06 This patch was created by merging TLS related source code from JDK11.06 to JDK8u MR3. Then I used OpenJSSE version 1.1.2 code base to implement backport from JDK11 to JDK8. Also, I verified that new TLSv1.3 code for JDK8 is semantically identical to OpenJSSE version 1.1.2. After that I removed DTLS support from the new TLSv1.3 implementation and added back TLS_KRB5 support removed by JDK-8196584. Separate patch for TLS_KRB5 support is available at: http://cr.openjdk.java.net/~abakhtin/rfc2712/webrev.v0/ As soon as I did not backport TLSv1.3 implementation patch by patch, the bug list I provided is not fully accurate. It is just list of TLSv1.3 related bugs from Initial implementation till JDK11.06 GA. As Andrew mentioned, some of the bugs already backported to JDK8. It is: - 8208350: Disable all DES cipher suites - 8211883: Disable anon and NULL cipher suites - 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883 - 8210985: Update the default SSL session cache size to 20480 - 8218863: Better endpoint checks - 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange - 8227758: More valid PKIX processing - 8218873: Improve JSSE endpoint checking - 8228825: Enhance ECDSA operations - 8218580: endpoint identification algorithm should be case-insensitive Some of these bugs should be re-backported in the new implementation - e.g. 8218873, 8228825, 8218580 The rest of these bugs should be verified after new implementation is applied. Thank you Alexey From gnu.andrew at redhat.com Thu Apr 2 03:46:54 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 2 Apr 2020 04:46:54 +0100 Subject: [8u] RFR: 8229888: (zipfs) Updating an existing zip file does not preserve original permissions In-Reply-To: <09d61305-07c1-d493-60af-7e96e0bfc7b3@redhat.com> References: <09d61305-07c1-d493-60af-7e96e0bfc7b3@redhat.com> Message-ID: <7366bd30-b282-656a-1c2e-0cc336f815ef@redhat.com> On 26/03/2020 23:15, Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8229888 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229888 > > Original review thread: > http://mail.openjdk.java.net/pipermail/nio-dev/2019-December/006894.html > > 11u changeset: > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/57fd597352b8 > > 8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8229888/webrev.00/ > > 8u patch is very close to 11u one: ZipFileSystem part is the same, test > is changed to replace API not available in 8u, changes to policy file > are not included. > It would be helpful if you could explain why such changes had to be made, rather than leaving the reviewer to guess. The test changes are fairly clear, though the replacement for Set.of, createSet, returns a modifiable set, whereas of returns an unmodifiable set. This doesn't really matter for a test case, but may in JDK code. It could also potentially be simplified to just: private static Set createSet(Object... entries) { Set set = new LinkedHashSet<>(Arrays.asList(entries)); return Collections.unmodifiableSet(set); } I'm not sure why the policy file change is unnecessary. I would guess it's because the zipfs code is only demo code in 8u, but it would be good to have more reassurance. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Apr 2 04:09:03 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 2 Apr 2020 05:09:03 +0100 Subject: [8u] RFR: 4949105: Access Bridge lacks html tags parsing In-Reply-To: <12e2cbed-4d26-768c-93ff-0dbccc2d567e@redhat.com> References: <12e2cbed-4d26-768c-93ff-0dbccc2d567e@redhat.com> Message-ID: <97b66d4d-0b27-3cc0-11a8-db30cd71caa4@redhat.com> On 27/03/2020 20:54, Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-4949105 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-4949105 > > Original review thread: > http://mail.openjdk.java.net/pipermail/swing-dev/2019-September/009793.html > > 11u changeset: > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/628d3e224aaa > > 8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/4949105/webrev.00/ > > 8u specific changes: paths, copyright year, String.strip() replaced with > trim(). > > On the strip() change: while trim() and strip() are not equivalent > (details: https://bugs.openjdk.java.net/browse/JDK-8200378 ), trim() may > be appropriate here for 8u. > Well, what you don't mention is that strip() is not an option for 8u, as it doesn't exist :) One could implement an appropriate isWhitespace()-based trimming routine instead, but I suspect there are enough uses of trim() already in the 8u codebase to make this out of scope for this backport and too risky for a stable codebase. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Apr 2 04:46:36 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 2 Apr 2020 05:46:36 +0100 Subject: RFR: [8u] JDK-6424123: "JVM crashes on failed 'strdup' call" Message-ID: <0d7f3ec4-300d-0747-0580-8d6231e41329@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-6424123 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/6424123/webrev.01 This patch cleans up some cases where strings aren't freed and also introduces strdup_check_oom to more elegantly handle cases where strdup fails. That function is later used by JDK-8076475 [0]. The differences in the backport are mainly due to later changes that have already been backported to 8u: * src/cpu/ppc/vm/vm_version_ppc.cpp - Context changes due to later updates to the supported feature set * src/cpu/sparc/vm/vm_version_sparc.cpp - Same as for vm_version_ppc.cpp * src/cpu/x86/vm/vm_version_x86.cpp - Same again * src/os/aix/vm/porting_aix.cpp - Header context is different as 8u doesn't import allocation.hpp * src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp - Changes dropped as code was completely refactored by JDK-8134119 and now uses os::malloc & os::free already * src/share/vm/classfile/classLoader.cpp - Context of signature of LazyClassPathEntry::LazyClassPathEntry was different, due to introduction of throw_exception. Changes to setup_bootstrap_search_path were dropped as JDK-8056971 changed sys_class_path to be used read only and not duplicated. * src/share/vm/classfile/classLoader.hpp - Change to LazyClassPathEntry::_path (char* -> const char*) in JDK-8056971 had to be reverted so it could be passed to os::free. Some context differences due to changes in class methods (addition of open_entry). * src/share/vm/compiler/compilerOracle.cpp - strdup is already present, thanks to JDK-8055286, so is replaced with strdup_check_oom. Destructor and removal of strdup in call to add_option_string are also already present, thank to that change. * src/share/vm/runtime/arguments.cpp - Some context differences due to process_java_launcher_argument having a special case for "gamma" from JDK-7022037. This was removed by JDK-8027113 in OpenJDK 9. Ok for 8u? [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011514.html Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From thomas.stuefe at gmail.com Thu Apr 2 07:25:27 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 2 Apr 2020 09:25:27 +0200 Subject: RFR: [8u] JDK-6424123: "JVM crashes on failed 'strdup' call" In-Reply-To: <0d7f3ec4-300d-0747-0580-8d6231e41329@redhat.com> References: <0d7f3ec4-300d-0747-0580-8d6231e41329@redhat.com> Message-ID: Hi Andrew, some small issues (not a 8u reviewer though): ---- os_aix.cpp: size_t data_page_size = SIZE_4K; { - void* p = ::malloc(SIZE_16M); + void* p = os::malloc(SIZE_16M, mtInternal); guarantee(p != NULL, "malloc failed"); data_page_size = os::Aix::query_pagesize(p); - ::free(p); + os::free(p); } This seems wrong. We should explicitly use raw malloc here. We do so in head. I see that we rolled this part back with 8075505 which was a larger change revamping AIX memory handling. I would leave this part out. ---- #ifdef SPARC - _masm->_verify_oop(r->as_Register(), strdup(st.as_string()), __FILE__, __LINE__); + _masm->_verify_oop(r->as_Register(), os::strdup(st.as_string(), mtCompiler), __FILE__, __LINE__); #else This seems to be a memory leak, but it has been one before that change. --- classLoader.cpp @@ -536,11 +540,11 @@ } default: { if (!skipCurrentJar && cur_entry != NULL) { - char* new_name = strdup(package_name); + char* new_name = os::strdup_check_oom(package_name); boot_class_path_packages.append(new_name); } } } } I believe this leaks too, and did so before. --- share/vm/compiler/compilerOracle.cpp @@ -217,11 +218,11 @@ Symbol* method_name, Mode method_mode, Symbol* signature, const char* opt, const T value, MethodMatcher* next) : MethodMatcher(class_name, class_mode, method_name, method_mode, signature, next), _type(get_type_for()), _value(copy_value(value)) { - _option = strdup(opt); + _option = os::strdup_check_oom(opt); } ~TypedMethodOptionMatcher() { free((void*)_option); } Unmatched free. free must be os::free. --- Cheers, Thomas On Thu, Apr 2, 2020 at 6:47 AM Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-6424123 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/6424123/webrev.01 > > This patch cleans up some cases where strings aren't freed and also > introduces strdup_check_oom to more elegantly handle cases where strdup > fails. That function is later used by JDK-8076475 [0]. > > The differences in the backport are mainly due to later changes that > have already been backported to 8u: > > * src/cpu/ppc/vm/vm_version_ppc.cpp > - Context changes due to later updates to the supported feature set > > * src/cpu/sparc/vm/vm_version_sparc.cpp > - Same as for vm_version_ppc.cpp > > * src/cpu/x86/vm/vm_version_x86.cpp > - Same again > > * src/os/aix/vm/porting_aix.cpp > - Header context is different as 8u doesn't import allocation.hpp > > * src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp > - Changes dropped as code was completely refactored by JDK-8134119 and > now uses os::malloc & os::free already > > * src/share/vm/classfile/classLoader.cpp > - Context of signature of LazyClassPathEntry::LazyClassPathEntry was > different, due to introduction of throw_exception. Changes to > setup_bootstrap_search_path were dropped as JDK-8056971 changed > sys_class_path to be used read only and not duplicated. > > * src/share/vm/classfile/classLoader.hpp > - Change to LazyClassPathEntry::_path (char* -> const char*) in > JDK-8056971 had to be reverted so it could be passed to os::free. Some > context differences due to changes in class methods (addition of > open_entry). > > * src/share/vm/compiler/compilerOracle.cpp > - strdup is already present, thanks to JDK-8055286, so is replaced > with strdup_check_oom. Destructor and removal of strdup in call to > add_option_string are also already present, thank to that change. > > * src/share/vm/runtime/arguments.cpp > - Some context differences due to process_java_launcher_argument > having a special case for "gamma" from JDK-7022037. This was removed by > JDK-8027113 in OpenJDK 9. > > Ok for 8u? > > [0] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011514.html > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > From aph at redhat.com Thu Apr 2 08:36:54 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 2 Apr 2020 09:36:54 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> Message-ID: <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> On 4/1/20 6:54 PM, Andrew Hughes wrote: > * src/share/vm/runtime/os.{c,h}pp > If we're going to add strdup_check_oom, I think this should be done by > backporting JDK-6424123 [1] so it's used consistently throughout the > codebase rather than just the two call sites in this patch. I strongly disagree that we should import such a patch into JDK 8 for this reason. It's a judgement call, of course. We have two desiderata here: those of consistently backporting patches and minimizing changes. As JDK 8 matures, minimizing change has become more and more important, and it's perfectly OK to snip small fragments of patches such as this in order to minimize change. Of course I'm aware of the other side of the argument, but I don't think it's as important. -- 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 linzang at tencent.com Thu Apr 2 08:49:52 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Thu, 2 Apr 2020 08:49:52 +0000 Subject: RFR 8241285(s): [jdk8u] fail to build hotspot with gcc-8.4.0 with or without COMPILER_WARNINGS_FATAL(Internet mail) In-Reply-To: References: <0FBDE19A-C44F-4460-9CDF-33C380EE406E@tencent.com> Message-ID: <0A79238A-3C56-4797-8A0A-9AFB25F0AD67@tencent.com> Dear Andrew, Thanks for your comments, I have uploaded a new patch at http://cr.openjdk.java.net/~lzang/8241285/webrev04/. Would you like to help review it again? BRs, Lin ?On 2020/4/2, 2:10 AM, "Andrew Hughes" wrote: On 25/03/2020 06:21, linzang(??) wrote: > Hi Paul, > Thanks for your comments, I hava upload a new patch http://cr.openjdk.java.net/~lzang/8241285/webrev03 > > >> Has it been tested on all affected platforms? > No, I only test on macos and linux, since they are the only platforms I could find. > > BRs, > Lin > A few comments: * make/aix/makefiles/xlc.make - This doesn't seem to do anything as WARNINGS_ARE_ERRORS is never used. I suspect EXTRA_WARNINGS should be replaced by WARNINGS_ARE_ERRORS, but it would be good to have some feedback from AIX people. - There seems to be a blank line being added for no reason. * make/solaris/makefiles/adlc.make - Bogus whitespace change to "We need libCstd.so for adlc" line - -errwarn gets replaced by -xwe. I think it would be better to revert this unless there is a good reason to change it. * make/solaris/makefiles/sparcWorks.make - Missing indenting. Should be ok with those issues fixed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From andrew_m_leonard at uk.ibm.com Thu Apr 2 13:09:53 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 2 Apr 2020 13:09:53 +0000 Subject: jdk8u252 MacOS Notarization ? Message-ID: Hi, I've been trying to track down the current position for Mac Notarized hardened runtime support in the upcoming jdk8u252 release, can someone point me to the thread/bug/discussion please? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From volker.simonis at gmail.com Thu Apr 2 14:11:51 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 2 Apr 2020 16:11:51 +0200 Subject: [8u-252] [urgent] 8241823: SignedObject throws NullPointerException for null keys with an initialized Signature object In-Reply-To: <8b2eccfc-05e6-b1c9-a75d-acb5cff5a313@redhat.com> References: <8b2eccfc-05e6-b1c9-a75d-acb5cff5a313@redhat.com> Message-ID: Andrew Hughes, Severin, could please have a quick look at this? I still think it makes sense to bring it into 8u252 and the faster we push it, the more time we'll give others to test it (although I don't expect this change to make any problems - on the contrary, it will save others from investigating TCK failures :) Thank you and best regards, Volker On Tue, Mar 31, 2020 at 11:05 AM Andrew Haley wrote: > > On 3/31/20 9:43 AM, Volker Simonis wrote: > > I know we're late for 8u252 but I'd still like to bring this trivial > > fix into 8u252 because we think it fixes a serious regression which > > will impact many users: > > > > https://bugs.openjdk.java.net/browse/JDK-8241823 > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8241823 > > That looks reasonable. OK by me, as long as Andrew Hughes doesn't > object because of time pressure. > > -- > 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 thomas.stuefe at gmail.com Thu Apr 2 14:45:43 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 2 Apr 2020 16:45:43 +0200 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> Message-ID: Hi Andrew x 2, I had another look at these changes after all these years, and they still look fine to me. They do fix a couple of potential errors where strings may be left unterminated on truncation. However I agree with AH that the possibility of this happening is remote, so its your call. Cheers, thomas On Thu, Apr 2, 2020 at 10:39 AM Andrew Haley wrote: > On 4/1/20 6:54 PM, Andrew Hughes wrote: > > * src/share/vm/runtime/os.{c,h}pp > > If we're going to add strdup_check_oom, I think this should be done by > > backporting JDK-6424123 [1] so it's used consistently throughout the > > codebase rather than just the two call sites in this patch. > > I strongly disagree that we should import such a patch into JDK 8 for > this reason. > > It's a judgement call, of course. We have two desiderata here: those > of consistently backporting patches and minimizing changes. As JDK 8 > matures, minimizing change has become more and more important, and it's > perfectly OK to snip small fragments of patches such as this in order > to minimize change. > > Of course I'm aware of the other side of the argument, but I don't > think it's as important. > > -- > 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 Fri Apr 3 03:44:10 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 3 Apr 2020 04:44:10 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> Message-ID: <19d143d5-7284-1f64-d2a0-3eb30dd2220c@redhat.com> On 02/04/2020 09:36, Andrew Haley wrote: > On 4/1/20 6:54 PM, Andrew Hughes wrote: >> * src/share/vm/runtime/os.{c,h}pp >> If we're going to add strdup_check_oom, I think this should be done by >> backporting JDK-6424123 [1] so it's used consistently throughout the >> codebase rather than just the two call sites in this patch. > > I strongly disagree that we should import such a patch into JDK 8 for > this reason. > > It's a judgement call, of course. We have two desiderata here: those > of consistently backporting patches and minimizing changes. As JDK 8 > matures, minimizing change has become more and more important, and it's > perfectly OK to snip small fragments of patches such as this in order > to minimize change. > > Of course I'm aware of the other side of the argument, but I don't > think it's as important. > And I strongly disagree with turning 8u into a unmaintainable mass of partial chunks of code from various changesets. In this case, it would lead to a strdup failure being handled differently, depending on where in the code it occurred. The alternative would be to use os::strdup directly and avoid introducing this function. This was how JDK-8155968 already handled this issue. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Apr 3 03:58:26 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 3 Apr 2020 04:58:26 +0100 Subject: RFR: [8u] JDK-6424123: "JVM crashes on failed 'strdup' call" In-Reply-To: References: <0d7f3ec4-300d-0747-0580-8d6231e41329@redhat.com> Message-ID: On 02/04/2020 08:25, Thomas St?fe wrote: > Hi Andrew, > > some small issues (not a 8u reviewer though): > > ---- > > os_aix.cpp:? > ? ?size_t data_page_size = SIZE_4K; > ? ?{ > - ? ?void* p = ::malloc(SIZE_16M); > + ? ?void* p = os::malloc(SIZE_16M, mtInternal); > ? ? ?guarantee(p != NULL, "malloc failed"); > ? ? ?data_page_size = os::Aix::query_pagesize(p); > - ? ?::free(p); > + ? ?os::free(p); > ? ?} > > This seems wrong. We should explicitly use raw malloc here. > > We do so in head. I see that we rolled this part back with 8075505 which > was a larger?change revamping AIX memory handling. I would leave this > part out. > Ok, dropped. > ---- > > ?#ifdef SPARC > - ? ? ? ? ?_masm->_verify_oop(r->as_Register(), strdup(st.as_string()), > __FILE__, __LINE__); > + ? ? ? ? ?_masm->_verify_oop(r->as_Register(), > os::strdup(st.as_string(), mtCompiler), __FILE__, __LINE__); > ?#else > > This seems to be a memory leak, but it has been one before that change. > > --- > > classLoader.cpp > > @@ -536,11 +540,11 @@ > ? ? ? ? ?} > ? > ? ? ? ? ?default: > ? ? ? ? ?{ > ? ? ? ? ? ?if (!skipCurrentJar && cur_entry != NULL) { > - ? ? ? ? ? ?char* new_name = strdup(package_name); > + ? ? ? ? ? ?char* new_name = os::strdup_check_oom(package_name); > ? ? ? ? ? ? ?boot_class_path_packages.append(new_name); > ? ? ? ? ? ?} > ? ? ? ? ?} > ? ? ? ?} > ? ? ?} > > I believe this leaks too, and did so before. > Right. This is a backport. I didn't write any of these changes, or alter them, so if they're wrong, they were wrong in the original patch too. In the first case, the line is in verification code for non-product builds, so I suspect we don't care greatly. In the second, boot_class_path_packages is a GrowableArray, so it looks like new_name will be freed when clear_and_dellocate is called by its destructor. > --- > > share/vm/compiler/compilerOracle.cpp > > @@ -217,11 +218,11 @@ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? Symbol* method_name, Mode method_mode, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? Symbol* signature, const char* opt, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? const T value, ?MethodMatcher* next) : > ? ? ?MethodMatcher(class_name, class_mode, method_name, method_mode, > signature, next), > ? ? ? ? ? ? ? ? ? ?_type(get_type_for()), _value(copy_value(value)) { > - ? ?_option = strdup(opt); > + ? ?_option = os::strdup_check_oom(opt); > ? ?} > ? > ? ?~TypedMethodOptionMatcher() { > ? ? ?free((void*)_option); > ? ?} > > Unmatched free. free must be os::free. This was missed, because the line was already there rather than being added by this patch. Fixed. New webrev: https://cr.openjdk.java.net/~andrew/openjdk8/6424123/webrev.02 > > --- > > Cheers, Thomas > Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Apr 3 04:05:47 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 3 Apr 2020 05:05:47 +0100 Subject: [8u-252] [urgent] 8241823: SignedObject throws NullPointerException for null keys with an initialized Signature object In-Reply-To: References: <8b2eccfc-05e6-b1c9-a75d-acb5cff5a313@redhat.com> Message-ID: On 02/04/2020 15:11, Volker Simonis wrote: > Andrew Hughes, Severin, > > could please have a quick look at this? I still think it makes sense > to bring it into 8u252 and the faster we push it, the more time we'll > give others to test it (although I don't expect this change to make > any problems - on the contrary, it will save others from investigating > TCK failures :) > > Thank you and best regards, > Volker > > On Tue, Mar 31, 2020 at 11:05 AM Andrew Haley wrote: >> >> On 3/31/20 9:43 AM, Volker Simonis wrote: >>> I know we're late for 8u252 but I'd still like to bring this trivial >>> fix into 8u252 because we think it fixes a serious regression which >>> will impact many users: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8241823 >>> http://cr.openjdk.java.net/~simonis/webrevs/2020/8241823 >> >> That looks reasonable. OK by me, as long as Andrew Hughes doesn't >> object because of time pressure. >> >> -- >> 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 >> > It's not just late, we're now frozen for release [0], so there are no more public changes to 8u252. I can include this with the CPU patchset. For cases like this in future, it would be better to raise it via the vulnerability group so it isn't missed. It's lucky I just spotted this before starting the CPU builds. If you want public testing prior to release of 8u252, I suggest pushing to 8u-dev (i.e. 8u262). As this is not a public bug, take this as my jdk8u-fix-yes for that commit. While I think fixing the regression is the right thing to do, I do worry that this may create a compatibility difference between OpenJDK 8u and the Oracle fork. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011476.html Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From volker.simonis at gmail.com Fri Apr 3 07:37:08 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 3 Apr 2020 09:37:08 +0200 Subject: [8u-252] [urgent] 8241823: SignedObject throws NullPointerException for null keys with an initialized Signature object In-Reply-To: References: <8b2eccfc-05e6-b1c9-a75d-acb5cff5a313@redhat.com> Message-ID: Andrew Hughes schrieb am Fr., 3. Apr. 2020, 06:06: > > On 02/04/2020 15:11, Volker Simonis wrote: > > Andrew Hughes, Severin, > > > > could please have a quick look at this? I still think it makes sense > > to bring it into 8u252 and the faster we push it, the more time we'll > > give others to test it (although I don't expect this change to make > > any problems - on the contrary, it will save others from investigating > > TCK failures :) > > > > Thank you and best regards, > > Volker > > > > On Tue, Mar 31, 2020 at 11:05 AM Andrew Haley wrote: > >> > >> On 3/31/20 9:43 AM, Volker Simonis wrote: > >>> I know we're late for 8u252 but I'd still like to bring this trivial > >>> fix into 8u252 because we think it fixes a serious regression which > >>> will impact many users: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8241823 > >>> http://cr.openjdk.java.net/~simonis/webrevs/2020/8241823 > >> > >> That looks reasonable. OK by me, as long as Andrew Hughes doesn't > >> object because of time pressure. > >> > >> -- > >> 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 > >> > > > > It's not just late, we're now frozen for release [0], so there are no > more public changes to 8u252. > > I can include this with the CPU patchset. I think that's a good idea and I'm fine with that. Could you please include it into an updated patchset and send that to the VG list. I think that will give the change enough exposure. > For cases like this in future, > it would be better to raise it via the vulnerability group so it isn't > missed. It's lucky I just spotted this before starting the CPU builds. Sure, will do so. > If you want public testing prior to release of 8u252, I suggest pushing > to 8u-dev (i.e. 8u262). As this is not a public bug, take this as my > jdk8u-fix-yes for that commit. Thanks, but I'm not sure. If you'll include it into the 8u252 CPU patchset, I think that would be enough. I don't particularly like it if we have multiple instances of the same change in the repository. > While I think fixing the regression is the right thing to do, I do worry > that this may create a compatibility difference between OpenJDK 8u and > the Oracle fork. Unfortunately, we can't say it either way, because it is a closed bug. So the Oracle fork may have the fix already or not. But because it is clearly a regression, I'd rather prefer to prevent breaking running systems than having 100% compatibility with Oracle JDK. > [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011476.html > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > From aph at redhat.com Fri Apr 3 09:18:45 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 3 Apr 2020 10:18:45 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: <19d143d5-7284-1f64-d2a0-3eb30dd2220c@redhat.com> References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> <19d143d5-7284-1f64-d2a0-3eb30dd2220c@redhat.com> Message-ID: <5eaf28fd-3bf5-fbc1-2288-a2c623719cd5@redhat.com> On 4/3/20 4:44 AM, Andrew Hughes wrote: > > On 02/04/2020 09:36, Andrew Haley wrote: >> On 4/1/20 6:54 PM, Andrew Hughes wrote: >>> * src/share/vm/runtime/os.{c,h}pp >>> If we're going to add strdup_check_oom, I think this should be done by >>> backporting JDK-6424123 [1] so it's used consistently throughout the >>> codebase rather than just the two call sites in this patch. >> >> I strongly disagree that we should import such a patch into JDK 8 for >> this reason. >> >> It's a judgement call, of course. We have two desiderata here: those >> of consistently backporting patches and minimizing changes. As JDK 8 >> matures, minimizing change has become more and more important, and it's >> perfectly OK to snip small fragments of patches such as this in order >> to minimize change. >> >> Of course I'm aware of the other side of the argument, but I don't >> think it's as important. > > And I strongly disagree with turning 8u into a unmaintainable mass of > partial chunks of code from various changesets. I have no intention of doing that, but pulling in large and otherwise unnecessary changesets for single functions should not be done in a release of a mature product. Here is my reasoning. The need for stability and the minimization of churn increases over time. People use JDK 8 because they want that stability, and every patch carries some risk. So, ecause it is now a mature piece of software, patches should be minimal where they reasonably can. The practice of, by default, pulling in dependencies from later releases is too risky: they might well be broken in ways that the old version wasn't, and they may depend on other changes in the recent code base. Now, that doesn't mean that such dependent changesets must *never* be pulled in, especially when they are needed by several backports. But if dependency changesets substantially multiply the size of a change, as they do in this case, this should not be done. I am aware that this does not ease the life of the maintainers, but that isn't the goal. Stability is. We need to discuss this issue some more, with a view to producing some updated guidelines. > In this case, it would lead to a strdup failure being handled > differently, depending on where in the code it occurred. > The alternative would be to use os::strdup directly and avoid > introducing this function. This was how JDK-8155968 already handled > this issue. That sounds like an excellent idea. I'll prepare a new patch. -- 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 dalibor.topic at oracle.com Fri Apr 3 10:19:41 2020 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 3 Apr 2020 12:19:41 +0200 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <7165F681-60B6-438E-8967-3BE2FC850472@azul.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <92098404-8A1F-4CF7-BD83-41AF69CEB362@azul.com> <57211559-08ad-b26a-9596-7a3308c1d52f@redhat.com> <7165F681-60B6-438E-8967-3BE2FC850472@azul.com> Message-ID: Hi Alexey, On 27.03.2020 15:54, Alexey Bakhtin wrote: > OpenJSSE is an open source pluggable security provider for TLSv1.3 protocol in JDK8u. > OpenJSSE provider version 1.1.0 was released in July 2019 and based on the JDK11.04 TLSv1.3 implementation. Subsequent versions of the OpenJSSE provider were created by backporting TLS related fixes from JDK11.05 and JDK11.06. The history of these backports is available at https://github.com/openjsse/openjsse/commits/master as usual before accepting a contribution including code created outside of OpenJDK, we need to go through the repo to ensure that the authors have an OCA on file. Looking at the list of commits, I see commits from yourself and Gil Tene at Azul as well as from Pavel Petroshenko. Pavel's GitHub account [0] associates him with a different company, for which no OCA is in place yet. [1] Could you elaborate a bit on the origin story of Pavel's commits, please? cheers, dalibor topic [0] https://github.com/ppetrosh [1] https://www.oracle.com/technetwork/community/oca-486395.html -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From aph at redhat.com Fri Apr 3 13:40:06 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 3 Apr 2020 14:40:06 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: <5eaf28fd-3bf5-fbc1-2288-a2c623719cd5@redhat.com> References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> <19d143d5-7284-1f64-d2a0-3eb30dd2220c@redhat.com> <5eaf28fd-3bf5-fbc1-2288-a2c623719cd5@redhat.com> Message-ID: <895d4073-853e-2109-e55f-aea3f11919ff@redhat.com> On 4/3/20 10:18 AM, Andrew Haley wrote: >> In this case, it would lead to a strdup failure being handled >> differently, depending on where in the code it occurred. >> The alternative would be to use os::strdup directly and avoid >> introducing this function. This was how JDK-8155968 already handled >> this issue. > That sounds like an excellent idea. I'll prepare a new patch. http://cr.openjdk.java.net/~aph/8076475-1/ OK? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From akashche at redhat.com Sat Apr 4 11:28:42 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Sat, 4 Apr 2020 12:28:42 +0100 Subject: [8u] RFR: 8229888: (zipfs) Updating an existing zip file does not preserve original permissions In-Reply-To: <7366bd30-b282-656a-1c2e-0cc336f815ef@redhat.com> References: <09d61305-07c1-d493-60af-7e96e0bfc7b3@redhat.com> <7366bd30-b282-656a-1c2e-0cc336f815ef@redhat.com> Message-ID: On 04/02/2020 04:46 AM, Andrew Hughes wrote: > On 26/03/2020 23:15, Alex Kashchenko wrote: >> Hi, >> >> Please review the backport of JDK-8229888 to 8u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229888 >> >> Original review thread: >> http://mail.openjdk.java.net/pipermail/nio-dev/2019-December/006894.html >> >> 11u changeset: >> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/57fd597352b8 >> >> 8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8229888/webrev.00/ >> >> 8u patch is very close to 11u one: ZipFileSystem part is the same, test >> is changed to replace API not available in 8u, changes to policy file >> are not included. >> > > It would be helpful if you could explain why such changes had to be > made, rather than leaving the reviewer to guess. > > The test changes are fairly clear, though the replacement for Set.of, > createSet, returns a modifiable set, whereas of returns an unmodifiable > set. This doesn't really matter for a test case, but may in JDK code. > > It could also potentially be simplified to just: > > private static Set createSet(Object... entries) { > Set set = new LinkedHashSet<>(Arrays.asList(entries)); > return Collections.unmodifiableSet(set); > } Thanks for the review! I simplified this part of test removing createSet() helper: https://cr.openjdk.java.net/~akasko/jdk8u/8229888/webrev.01/ > > I'm not sure why the policy file change is unnecessary. I would guess > it's because the zipfs code is only demo code in 8u, but it would be > good to have more reassurance. AFAIU these changes to policy file are only necessary for jdk9+ with JPMS, some details on this policy change in jdk11: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002644.html https://mail.openjdk.java.net/pipermail/nio-dev/2019-March/005978.html -- -Alex From snazarkin at azul.com Sun Apr 5 19:44:12 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Sun, 5 Apr 2020 19:44:12 +0000 Subject: [8u] RFR: Backport of 8067796 (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null In-Reply-To: <87c7205e-5b55-f95c-0800-72c4e0aa408c@redhat.com> References: <11F4B16A-212E-4805-AF6A-46B8760278EB@azul.com> <586f5546-4614-565a-dc5f-8c62aff09782@redhat.com> <2b42427a-6485-4c36-fbb2-ff7f4eedf08b@redhat.com> <23C95150-015E-417C-AEF9-5E3E389896DA@azul.com> <87c7205e-5b55-f95c-0800-72c4e0aa408c@redhat.com> Message-ID: Thanks, Andrew. In simpler case 8037866(Replace the Fun class in tests with lambdas) only misses a part of MOAT.java that was introduced by 8014066(ArrayList#removeRange): $cat test/java/util/Collection/MOAT.java.rej --- MOAT.java +++ MOAT.java @@ -728,8 +722,8 @@ l.listIterator(0); l.listIterator(l.size()); THROWS(IndexOutOfBoundsException.class, - new Fun(){void f(){l.listIterator(-1);}}, - new Fun(){void f(){l.listIterator(l.size() + 1);}}); + () -> l.listIterator(-1), + () -> l.listIterator(l.size() + 1)); if (l instanceof AbstractList) { try { Final patchset would be 1) http://cr.openjdk.java.net/~snazarki/webrev/8037866/ 2) http://cr.openjdk.java.net/~snazarki/webrev/8067796/ Sergey Nazarkin > On Apr 1, 2020, at 18:14, Andrew Haley wrote: > > On 4/1/20 3:30 PM, Sergey Nazarkin wrote: >> I?ve tracked down patchset required for clean backport. Beside 8037866 [2] only 8014066 [1] is required. I?m a bit worrying about 8014066, the changeset may affect existent applications behavior. >> >> With 8014066 all subsequent patches applied cleanly except 8067796: >> - for non-windows OSes waitFor method is at UNIXProcess.java (not ProcessImpl.java) >> - windows version of ProcessImpl.java is placed at different path >> - Basic.java: bug list is different >> >> If 8014066 is accepted for backport I?ll create separate RFRs. In this case patch sequence should be [4] -> [5] -> [6] >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8014066 >> [2] https://bugs.openjdk.java.net/browse/JDK-8037866 >> [3] https://bugs.openjdk.java.net/browse/JDK-8067796 >> >> [4] http://cr.openjdk.java.net/~snazarki/webrev/8014066/ >> [5] http://cr.openjdk.java.net/~snazarki/webrev/8037866/ >> [6] http://cr.openjdk.java.net/~snazarki/webrev/8067796/ > > You're right. This is too much for the initial patch, which is low > risk and changes only a few lines. It'd be OK if you find a way to do > it without changing ArrayList#removeRange. It wouldn't be a disaster > if you rewrote the test case to not require JDK-8037866. > > -- > 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 alexey at azul.com Mon Apr 6 08:06:49 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 6 Apr 2020 08:06:49 +0000 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <92098404-8A1F-4CF7-BD83-41AF69CEB362@azul.com> <57211559-08ad-b26a-9596-7a3308c1d52f@redhat.com> <7165F681-60B6-438E-8967-3BE2FC850472@azul.com> Message-ID: <56B4DBE2-7A0B-4583-A076-C1C5F9AD29A1@azul.com> Hello Dalibor, Pavel Petroshenko is working in Azul since March 2019. Commits to OpenJSSE project were done by Pavel as part of his work on Azul. Regards Alexey > On 3 Apr 2020, at 13:19, Dalibor Topic wrote: > > Hi Alexey, > > On 27.03.2020 15:54, Alexey Bakhtin wrote: >> OpenJSSE is an open source pluggable security provider for TLSv1.3 protocol in JDK8u. >> OpenJSSE provider version 1.1.0 was released in July 2019 and based on the JDK11.04 TLSv1.3 implementation. Subsequent versions of the OpenJSSE provider were created by backporting TLS related fixes from JDK11.05 and JDK11.06. The history of these backports is available at https://github.com/openjsse/openjsse/commits/master > > as usual before accepting a contribution including code created outside of OpenJDK, we need to go through the repo to ensure that the authors have an OCA on file. > > Looking at the list of commits, I see commits from yourself and Gil Tene at Azul as well as from Pavel Petroshenko. Pavel's GitHub account [0] associates him with a different company, for which no OCA is in place yet. [1] > > Could you elaborate a bit on the origin story of Pavel's commits, please? > > cheers, > dalibor topic > > [0] https://github.com/ppetrosh > [1] https://www.oracle.com/technetwork/community/oca-486395.html > > -- > Dalibor Topic > Consulting Product Manager > Phone: +494089091214 , Mobile: +491737185961 > , Video: dalibor.topic at oracle.com > > > Oracle Global Services Germany GmbH > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRB 246209 > Gesch?ftsf?hrer: Ralf Herrmann From thomas.stuefe at gmail.com Mon Apr 6 08:47:16 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 6 Apr 2020 10:47:16 +0200 Subject: RFR: [8u] JDK-6424123: "JVM crashes on failed 'strdup' call" In-Reply-To: References: <0d7f3ec4-300d-0747-0580-8d6231e41329@redhat.com> Message-ID: Hi Andrew, okay, looks good. ..Thomas On Fri, Apr 3, 2020 at 5:58 AM Andrew Hughes wrote: > On 02/04/2020 08:25, Thomas St?fe wrote: > > Hi Andrew, > > > > some small issues (not a 8u reviewer though): > > > > ---- > > > > os_aix.cpp: > > size_t data_page_size = SIZE_4K; > > { > > - void* p = ::malloc(SIZE_16M); > > + void* p = os::malloc(SIZE_16M, mtInternal); > > guarantee(p != NULL, "malloc failed"); > > data_page_size = os::Aix::query_pagesize(p); > > - ::free(p); > > + os::free(p); > > } > > > > This seems wrong. We should explicitly use raw malloc here. > > > > We do so in head. I see that we rolled this part back with 8075505 which > > was a larger change revamping AIX memory handling. I would leave this > > part out. > > > > Ok, dropped. > > > ---- > > > > #ifdef SPARC > > - _masm->_verify_oop(r->as_Register(), strdup(st.as_string()), > > __FILE__, __LINE__); > > + _masm->_verify_oop(r->as_Register(), > > os::strdup(st.as_string(), mtCompiler), __FILE__, __LINE__); > > #else > > > > This seems to be a memory leak, but it has been one before that change. > > > > --- > > > > classLoader.cpp > > > > @@ -536,11 +540,11 @@ > > } > > > > default: > > { > > if (!skipCurrentJar && cur_entry != NULL) { > > - char* new_name = strdup(package_name); > > + char* new_name = os::strdup_check_oom(package_name); > > boot_class_path_packages.append(new_name); > > } > > } > > } > > } > > > > I believe this leaks too, and did so before. > > > > Right. This is a backport. I didn't write any of these changes, or alter > them, so if they're wrong, they were wrong in the original patch too. > > In the first case, the line is in verification code for non-product > builds, so I suspect we don't care greatly. In the second, > boot_class_path_packages is a GrowableArray, so it looks like new_name > will be freed when clear_and_dellocate is called by its destructor. > > > --- > > > > share/vm/compiler/compilerOracle.cpp > > > > @@ -217,11 +218,11 @@ > > Symbol* method_name, Mode method_mode, > > Symbol* signature, const char* opt, > > const T value, MethodMatcher* next) : > > MethodMatcher(class_name, class_mode, method_name, method_mode, > > signature, next), > > _type(get_type_for()), > _value(copy_value(value)) { > > - _option = strdup(opt); > > + _option = os::strdup_check_oom(opt); > > } > > > > ~TypedMethodOptionMatcher() { > > free((void*)_option); > > } > > > > Unmatched free. free must be os::free. > > This was missed, because the line was already there rather than being > added by this patch. Fixed. > > New webrev: https://cr.openjdk.java.net/~andrew/openjdk8/6424123/webrev.02 > > > > > --- > > > > Cheers, Thomas > > > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > From xxinliu at amazon.com Mon Apr 6 10:43:30 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Mon, 6 Apr 2020 10:43:30 +0000 Subject: RFR: [8u] JDK-8191393: Random crashes during cfree+0x1c Message-ID: Hi, Reviewers, May I request review this bugfix? Bug: https://bugs.openjdk.java.net/browse/JDK-8191393 Webrev: https://cr.openjdk.java.net/~xliu/8191393/webrev/ I believe that root cause is the race condition between ConcurrentMarkThread and the VMThread. We can?t directly backport from upstream because upstream is based on unified logging framework. further, TIP doesn?t have reentry problem while jdk8u has. Instead, this patch uses a mutex to protect FILE* fileStream::_file and a Boolean flag to avoid reentry. Of course, a mutex is not free. Therefore, I didn't use it if users don't emit log to file. Test: I ran the stress test over 24 hours and no problem is identified. I passed tier1 test of jtreg. Thanks, --lx From dalibor.topic at oracle.com Mon Apr 6 12:19:28 2020 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 6 Apr 2020 14:19:28 +0200 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <56B4DBE2-7A0B-4583-A076-C1C5F9AD29A1@azul.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <92098404-8A1F-4CF7-BD83-41AF69CEB362@azul.com> <57211559-08ad-b26a-9596-7a3308c1d52f@redhat.com> <7165F681-60B6-438E-8967-3BE2FC850472@azul.com> <56B4DBE2-7A0B-4583-A076-C1C5F9AD29A1@azul.com> Message-ID: Hi Alexey, thank you very much for checking that and confirming that all the commits in OpenJSSE come from (at the time) Azul employees. cheers, dalibor topic On 06.04.2020 10:06, Alexey Bakhtin wrote: > Hello Dalibor, > > Pavel Petroshenko is working in Azul since March 2019. > Commits to OpenJSSE project were done by Pavel as part of his work on Azul. > > Regards > Alexey > >> On 3 Apr 2020, at 13:19, Dalibor Topic wrote: >> >> Hi Alexey, >> >> On 27.03.2020 15:54, Alexey Bakhtin wrote: >>> OpenJSSE is an open source pluggable security provider for TLSv1.3 protocol in JDK8u. >>> OpenJSSE provider version 1.1.0 was released in July 2019 and based on the JDK11.04 TLSv1.3 implementation. Subsequent versions of the OpenJSSE provider were created by backporting TLS related fixes from JDK11.05 and JDK11.06. The history of these backports is available at https://github.com/openjsse/openjsse/commits/master >> >> as usual before accepting a contribution including code created outside of OpenJDK, we need to go through the repo to ensure that the authors have an OCA on file. >> >> Looking at the list of commits, I see commits from yourself and Gil Tene at Azul as well as from Pavel Petroshenko. Pavel's GitHub account [0] associates him with a different company, for which no OCA is in place yet. [1] >> >> Could you elaborate a bit on the origin story of Pavel's commits, please? >> >> cheers, >> dalibor topic >> >> [0] https://github.com/ppetrosh >> [1] https://www.oracle.com/technetwork/community/oca-486395.html >> >> -- >> Dalibor Topic >> Consulting Product Manager >> Phone: +494089091214 , Mobile: +491737185961 >> , Video: dalibor.topic at oracle.com >> >> >> Oracle Global Services Germany GmbH >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRB 246209 >> Gesch?ftsf?hrer: Ralf Herrmann > -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From sgehwolf at redhat.com Mon Apr 6 12:39:28 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 06 Apr 2020 14:39:28 +0200 Subject: jdk8u252 MacOS Notarization ? In-Reply-To: References: Message-ID: Hi Andrew, On Thu, 2020-04-02 at 13:09 +0000, Andrew Leonard wrote: > Hi, > I've been trying to track down the current position for Mac Notarized > hardened runtime support in the upcoming jdk8u252 release, can someone > point me to the thread/bug/discussion please? AFAIUI, jdk8u252 won't support Notarized Builds for Mac OSX. Your best bet about it's status is to get in touch with Simon Tooke (cc) who has been working on some of the patches to move to a newer toolchain (a pre-req for getting this done, AFAIK). Thanks, Severin From linzang at tencent.com Tue Apr 7 05:19:40 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Tue, 7 Apr 2020 05:19:40 +0000 Subject: RFR 8241285(s): [jdk8u] fail to build hotspot with gcc-8.4.0 with or without COMPILER_WARNINGS_FATAL(Internet mail) In-Reply-To: <0A79238A-3C56-4797-8A0A-9AFB25F0AD67@tencent.com> References: <0FBDE19A-C44F-4460-9CDF-33C380EE406E@tencent.com> <0A79238A-3C56-4797-8A0A-9AFB25F0AD67@tencent.com> Message-ID: <0AE35AA4-B3A3-422F-9843-394042D51A10@tencent.com> Hi Andrew? Do you think http://cr.openjdk.java.net/~lzang/8241285/webrev04/ is ready for push? P.S. it is hard for me to find AIX environment to test, if it is a problem, may I ask your help? Thanks! BRs, Lin ?On 2020/4/2, 4:49 PM, "linzang(??)" wrote: Dear Andrew, Thanks for your comments, I have uploaded a new patch at http://cr.openjdk.java.net/~lzang/8241285/webrev04/. Would you like to help review it again? BRs, Lin On 2020/4/2, 2:10 AM, "Andrew Hughes" wrote: On 25/03/2020 06:21, linzang(??) wrote: > Hi Paul, > Thanks for your comments, I hava upload a new patch http://cr.openjdk.java.net/~lzang/8241285/webrev03 > > >> Has it been tested on all affected platforms? > No, I only test on macos and linux, since they are the only platforms I could find. > > BRs, > Lin > A few comments: * make/aix/makefiles/xlc.make - This doesn't seem to do anything as WARNINGS_ARE_ERRORS is never used. I suspect EXTRA_WARNINGS should be replaced by WARNINGS_ARE_ERRORS, but it would be good to have some feedback from AIX people. - There seems to be a blank line being added for no reason. * make/solaris/makefiles/adlc.make - Bogus whitespace change to "We need libCstd.so for adlc" line - -errwarn gets replaced by -xwe. I think it would be better to revert this unless there is a good reason to change it. * make/solaris/makefiles/sparcWorks.make - Missing indenting. Should be ok with those issues fixed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From adinn at redhat.com Tue Apr 7 09:21:38 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 7 Apr 2020 10:21:38 +0100 Subject: RFR: [8u] JDK-8191393: Random crashes during cfree+0x1c In-Reply-To: References: Message-ID: <5305b65e-6e50-9df9-2d77-8c5c5d04a79c@redhat.com> On 06/04/2020 11:43, Liu, Xin wrote: > Hi, Reviewers, > > May I request review this bugfix? > Bug: https://bugs.openjdk.java.net/browse/JDK-8191393 > Webrev: https://cr.openjdk.java.net/~xliu/8191393/webrev/ > > I believe that root cause is the race condition between ConcurrentMarkThread and the VMThread. > We can?t directly backport from upstream because upstream is based on unified logging framework. further, TIP doesn?t have reentry problem while jdk8u has. > Instead, this patch uses a mutex to protect FILE* fileStream::_file and a Boolean flag to avoid reentry. > > Of course, a mutex is not free. Therefore, I didn't use it if users don't emit log to file. > > Test: > I ran the stress test over 24 hours and no problem is identified. > I passed tier1 test of jtreg. That looks good to me. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From snazarkin at azul.com Tue Apr 7 09:43:29 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Tue, 7 Apr 2020 09:43:29 +0000 Subject: RFR: [8u] JDK-8191393: Random crashes during cfree+0x1c In-Reply-To: References: Message-ID: Hi! I?m a bit confused but is gcLogFileStream a singleton object? Shouldn?t new Mutex be destroyed at gcLogFileStream destructor? /Sergey > On Apr 6, 2020, at 13:43, Liu, Xin wrote: > > Hi, Reviewers, > > May I request review this bugfix? > Bug: https://bugs.openjdk.java.net/browse/JDK-8191393 > Webrev: https://cr.openjdk.java.net/~xliu/8191393/webrev/ > > I believe that root cause is the race condition between ConcurrentMarkThread and the VMThread. > We can?t directly backport from upstream because upstream is based on unified logging framework. further, TIP doesn?t have reentry problem while jdk8u has. > Instead, this patch uses a mutex to protect FILE* fileStream::_file and a Boolean flag to avoid reentry. > > Of course, a mutex is not free. Therefore, I didn't use it if users don't emit log to file. > > Test: > I ran the stress test over 24 hours and no problem is identified. > I passed tier1 test of jtreg. > > Thanks, > --lx > > > From adinn at redhat.com Tue Apr 7 11:23:22 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 7 Apr 2020 12:23:22 +0100 Subject: RFR: [8u] JDK-8191393: Random crashes during cfree+0x1c In-Reply-To: References: Message-ID: On 07/04/2020 10:43, Sergey Nazarkin wrote: > Hi! > > I?m a bit confused but is gcLogFileStream a singleton object? > Shouldn?t new Mutex be destroyed at gcLogFileStream destructor? Yes, it's a singleton created by ostream_init_log under Threads::create_vm. You are probably right that for form's sake the mutex should be destroyed. In practice I don't think it matters. regards, Andrew Dinn ----------- From hohensee at amazon.com Tue Apr 7 15:20:13 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 7 Apr 2020 15:20:13 +0000 Subject: [8u] JDK-8191393: Random crashes during cfree+0x1c In-Reply-To: References: Message-ID: <02584D31-2CE0-4FD2-A9FA-9AC1BB44507B@amazon.com> Hi, Xin. Could you explain the nature of the race condition between concurrent mark threads and the vm thread? And why _gclog_reentry is needed (i.e., how the vm thread can call write() from rotate_gc_log())? The comment on rotate_log() in ostream.cpp (you can see most of it in the webrev) is: // rotate_log must be called from VMThread at safepoint. In case need change parameters // for gc log rotation from thread other than VMThread, a sub type of VM_Operation // should be created and be submitted to VMThread's operation queue. DO NOT call this // function directly. Currently, it is safe to rotate log at safepoint through VMThread. // That is, no mutator threads and concurrent GC threads run parallel with VMThread to // write to gc log file at safepoint. If in future, changes made for mutator threads or // concurrent GC threads to run parallel with VMThread at safepoint, write and rotate_log // must be synchronized. I'd take a look at the CMS (and G1) concurrent mark code to discover why it's running during a safepoint. That might be where the problem should be fixed, rather than in the logging code. Assuming the fix should be in the logging code: In vmThread.*: The names of simple getters are conventionally the same as the field name. In this case, I'd use _reentry_gclog as the field name rather than _reentry_gclog_writing. In ostream.*: I don't understand the comment in gcLogFileStream::write() that says // can't use Thread::current() because thread is NULL before initialization It'd be good for the comment to explain how it can happen that a GC log entry can be written before Thread::current() is valid. In rotate_log(), you can hoist the assignment to thread out of the assert and use it instead of vmthread in the locked region. In rotate_log(), it looks like you added rotate_gc_log_impl() because part of the race is in should_rotate(). But, you don't need to add rotate_gc_log_impl(), you can just put the new code into the existing rotate_log(). Thanks, Paul ?On 4/6/20, 3:47 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Reviewers, May I request review this bugfix? Bug: https://bugs.openjdk.java.net/browse/JDK-8191393 Webrev: https://cr.openjdk.java.net/~xliu/8191393/webrev/ I believe that root cause is the race condition between ConcurrentMarkThread and the VMThread. We can?t directly backport from upstream because upstream is based on unified logging framework. further, TIP doesn?t have reentry problem while jdk8u has. Instead, this patch uses a mutex to protect FILE* fileStream::_file and a Boolean flag to avoid reentry. Of course, a mutex is not free. Therefore, I didn't use it if users don't emit log to file. Test: I ran the stress test over 24 hours and no problem is identified. I passed tier1 test of jtreg. Thanks, --lx From xxinliu at amazon.com Wed Apr 8 04:25:16 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 8 Apr 2020 04:25:16 +0000 Subject: [8u] JDK-8191393: Random crashes during cfree+0x1c In-Reply-To: <02584D31-2CE0-4FD2-A9FA-9AC1BB44507B@amazon.com> References: <02584D31-2CE0-4FD2-A9FA-9AC1BB44507B@amazon.com> Message-ID: Hi, Paul, Andrew and Sergey, I found there're a multiple bug reports, starting from 8u65. https://bugs.openjdk.java.net/browse/JDK-8223603?jql=component%20%3D%20hotspot%20AND%20labels%20%3D%20webbug%20AND%20text%20~%20%22cfree%2B0x1c%22 Except one ParallelGC, I found a common pattern of them is +UseG1GC and -XX:+UseGCLogFileRotation Here is my analysis of the race condition between ConcurrentMarkThread and VMThread. Please correct me if I am wrong. In SafepointSynchronize::begin, VMThread does synchronize with SuspendibleThreadSet. https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/f37c2dd33031/src/share/vm/runtime/safepoint.cpp#l183 Here's an abstract concept called SuspendibleThreadSet(STS). Only threads who voluntarily join the set honor a safepoint synchronization. ConcurrentMarkThread::run() in the main body of ConcurrentMarkThread of G1. I found it only partially takes part in this set. It joins SuspendibleThreadSet time to time. You can search a construct called "SuspendibleThreadSetJoiner" as indicator. Many gclog sites fall outside of that construct. IMHO, It means that it runs out of sync with VMThread. We certainly could put ConcurrentMarkThread into STS completely. I don't think it's good idea because it will cause Marking phrases stops time to time(bad#1). Each time it yields, it might be scheduled to another processor with cold cache and affinity (bad#2). On the other side, I don't think logging is a performance-critical task. Developers who pursue extreme performance can opt out gclog. It would be nice to have a mutex to make gclog "more serial". Actually, with it, we can guarantee there's no interleaved messages in a line. It actually improve readability as a side effect. The reason I need to add a flag called "_gclog_reentry" because there's a corner case. When VMThread is doing gclog rotation, it calls "write" from "rotate_log". It writes gclog header to new file. The mutex of hotspot doesn't support reentry. That flag is for reentry avoidance. I took all your suggestions except one. I found there're multiple exits in gcLogFileStream::rotate_log_impl. It's easier to manage _gclog_reentry in a parent function. Further, it leaves a function without a mutex. It may be useful if someone can truly stop the world. I also take Andrew Dinn and Sergey's advice. Thank you. It might be a problem if we run memory leak analysis , so I delete it in the dtor. Here is the new revision of webrev. Could you take a look at it? https://cr.openjdk.java.net/~xliu/8191393/01/webrev/ Because this problem only happens when gc rotation is enable. I don't use mutex protection if gc rotation is off in the new revision. I.e. It shouldn't have any overhead for normal case. I passed hotspot-tier1 and have run several hours for the correctness check. Thanks, --lx ?On 4/7/20, 8:20 AM, "Hohensee, Paul" wrote: Hi, Xin. Could you explain the nature of the race condition between concurrent mark threads and the vm thread? And why _gclog_reentry is needed (i.e., how the vm thread can call write() from rotate_gc_log())? The comment on rotate_log() in ostream.cpp (you can see most of it in the webrev) is: // rotate_log must be called from VMThread at safepoint. In case need change parameters // for gc log rotation from thread other than VMThread, a sub type of VM_Operation // should be created and be submitted to VMThread's operation queue. DO NOT call this // function directly. Currently, it is safe to rotate log at safepoint through VMThread. // That is, no mutator threads and concurrent GC threads run parallel with VMThread to // write to gc log file at safepoint. If in future, changes made for mutator threads or // concurrent GC threads to run parallel with VMThread at safepoint, write and rotate_log // must be synchronized. I'd take a look at the CMS (and G1) concurrent mark code to discover why it's running during a safepoint. That might be where the problem should be fixed, rather than in the logging code. Assuming the fix should be in the logging code: In vmThread.*: The names of simple getters are conventionally the same as the field name. In this case, I'd use _reentry_gclog as the field name rather than _reentry_gclog_writing. In ostream.*: I don't understand the comment in gcLogFileStream::write() that says // can't use Thread::current() because thread is NULL before initialization It'd be good for the comment to explain how it can happen that a GC log entry can be written before Thread::current() is valid. In rotate_log(), you can hoist the assignment to thread out of the assert and use it instead of vmthread in the locked region. In rotate_log(), it looks like you added rotate_gc_log_impl() because part of the race is in should_rotate(). But, you don't need to add rotate_gc_log_impl(), you can just put the new code into the existing rotate_log(). Thanks, Paul On 4/6/20, 3:47 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Reviewers, May I request review this bugfix? Bug: https://bugs.openjdk.java.net/browse/JDK-8191393 Webrev: https://cr.openjdk.java.net/~xliu/8191393/webrev/ I believe that root cause is the race condition between ConcurrentMarkThread and the VMThread. We can?t directly backport from upstream because upstream is based on unified logging framework. further, TIP doesn?t have reentry problem while jdk8u has. Instead, this patch uses a mutex to protect FILE* fileStream::_file and a Boolean flag to avoid reentry. Of course, a mutex is not free. Therefore, I didn't use it if users don't emit log to file. Test: I ran the stress test over 24 hours and no problem is identified. I passed tier1 test of jtreg. Thanks, --lx From hohensee at amazon.com Wed Apr 8 15:50:53 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 8 Apr 2020 15:50:53 +0000 Subject: [8u] JDK-8191393: Random crashes during cfree+0x1c In-Reply-To: References: <02584D31-2CE0-4FD2-A9FA-9AC1BB44507B@amazon.com> Message-ID: Looks good now, except one more small issue. I forgot to say before that, given that rotate_log and write are now synchronized, the rotate_log method comment is inaccurate. It could be changed to eliminate the reference to 8191393 and read something like // rotate_log must be called from the VMThread at a safepoint. In case of need to do // gc log rotation from a thread other than the VMThread, a subtype of VM_Operation // should be created and be submitted to the VMThread's operation queue. DO NOT call this // function directly. It is safe to rotate the log at a safepoint via the VMThread because // no mutator threads run concurrently with the VMThread, and GC threads that run // concurrently with the VMThread are synchronized in write and rotate_log via _file_lock. // rotate_log can write log entries, so write does a recursive lock check on _file_lock. Thanks, Paul ?On 4/7/20, 9:25 PM, "Liu, Xin" wrote: Hi, Paul, Andrew and Sergey, I found there're a multiple bug reports, starting from 8u65. https://bugs.openjdk.java.net/browse/JDK-8223603?jql=component%20%3D%20hotspot%20AND%20labels%20%3D%20webbug%20AND%20text%20~%20%22cfree%2B0x1c%22 Except one ParallelGC, I found a common pattern of them is +UseG1GC and -XX:+UseGCLogFileRotation Here is my analysis of the race condition between ConcurrentMarkThread and VMThread. Please correct me if I am wrong. In SafepointSynchronize::begin, VMThread does synchronize with SuspendibleThreadSet. https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/f37c2dd33031/src/share/vm/runtime/safepoint.cpp#l183 Here's an abstract concept called SuspendibleThreadSet(STS). Only threads who voluntarily join the set honor a safepoint synchronization. ConcurrentMarkThread::run() in the main body of ConcurrentMarkThread of G1. I found it only partially takes part in this set. It joins SuspendibleThreadSet time to time. You can search a construct called "SuspendibleThreadSetJoiner" as indicator. Many gclog sites fall outside of that construct. IMHO, It means that it runs out of sync with VMThread. We certainly could put ConcurrentMarkThread into STS completely. I don't think it's good idea because it will cause Marking phrases stops time to time(bad#1). Each time it yields, it might be scheduled to another processor with cold cache and affinity (bad#2). On the other side, I don't think logging is a performance-critical task. Developers who pursue extreme performance can opt out gclog. It would be nice to have a mutex to make gclog "more serial". Actually, with it, we can guarantee there's no interleaved messages in a line. It actually improve readability as a side effect. The reason I need to add a flag called "_gclog_reentry" because there's a corner case. When VMThread is doing gclog rotation, it calls "write" from "rotate_log". It writes gclog header to new file. The mutex of hotspot doesn't support reentry. That flag is for reentry avoidance. I took all your suggestions except one. I found there're multiple exits in gcLogFileStream::rotate_log_impl. It's easier to manage _gclog_reentry in a parent function. Further, it leaves a function without a mutex. It may be useful if someone can truly stop the world. I also take Andrew Dinn and Sergey's advice. Thank you. It might be a problem if we run memory leak analysis , so I delete it in the dtor. Here is the new revision of webrev. Could you take a look at it? https://cr.openjdk.java.net/~xliu/8191393/01/webrev/ Because this problem only happens when gc rotation is enable. I don't use mutex protection if gc rotation is off in the new revision. I.e. It shouldn't have any overhead for normal case. I passed hotspot-tier1 and have run several hours for the correctness check. Thanks, --lx On 4/7/20, 8:20 AM, "Hohensee, Paul" wrote: Hi, Xin. Could you explain the nature of the race condition between concurrent mark threads and the vm thread? And why _gclog_reentry is needed (i.e., how the vm thread can call write() from rotate_gc_log())? The comment on rotate_log() in ostream.cpp (you can see most of it in the webrev) is: // rotate_log must be called from VMThread at safepoint. In case need change parameters // for gc log rotation from thread other than VMThread, a sub type of VM_Operation // should be created and be submitted to VMThread's operation queue. DO NOT call this // function directly. Currently, it is safe to rotate log at safepoint through VMThread. // That is, no mutator threads and concurrent GC threads run parallel with VMThread to // write to gc log file at safepoint. If in future, changes made for mutator threads or // concurrent GC threads to run parallel with VMThread at safepoint, write and rotate_log // must be synchronized. I'd take a look at the CMS (and G1) concurrent mark code to discover why it's running during a safepoint. That might be where the problem should be fixed, rather than in the logging code. Assuming the fix should be in the logging code: In vmThread.*: The names of simple getters are conventionally the same as the field name. In this case, I'd use _reentry_gclog as the field name rather than _reentry_gclog_writing. In ostream.*: I don't understand the comment in gcLogFileStream::write() that says // can't use Thread::current() because thread is NULL before initialization It'd be good for the comment to explain how it can happen that a GC log entry can be written before Thread::current() is valid. In rotate_log(), you can hoist the assignment to thread out of the assert and use it instead of vmthread in the locked region. In rotate_log(), it looks like you added rotate_gc_log_impl() because part of the race is in should_rotate(). But, you don't need to add rotate_gc_log_impl(), you can just put the new code into the existing rotate_log(). Thanks, Paul On 4/6/20, 3:47 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Reviewers, May I request review this bugfix? Bug: https://bugs.openjdk.java.net/browse/JDK-8191393 Webrev: https://cr.openjdk.java.net/~xliu/8191393/webrev/ I believe that root cause is the race condition between ConcurrentMarkThread and the VMThread. We can?t directly backport from upstream because upstream is based on unified logging framework. further, TIP doesn?t have reentry problem while jdk8u has. Instead, this patch uses a mutex to protect FILE* fileStream::_file and a Boolean flag to avoid reentry. Of course, a mutex is not free. Therefore, I didn't use it if users don't emit log to file. Test: I ran the stress test over 24 hours and no problem is identified. I passed tier1 test of jtreg. Thanks, --lx From adinn at redhat.com Wed Apr 8 16:13:12 2020 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 8 Apr 2020 17:13:12 +0100 Subject: [8u] JDK-8191393: Random crashes during cfree+0x1c In-Reply-To: References: <02584D31-2CE0-4FD2-A9FA-9AC1BB44507B@amazon.com> Message-ID: <5f3cab25-77d6-9e0f-5abe-e91e90a2f0b2@redhat.com> On 08/04/2020 16:50, Hohensee, Paul wrote: > Looks good now, except one more small issue. > > I forgot to say before that, given that rotate_log and write are now synchronized, the rotate_log method comment is inaccurate. It could be changed to eliminate the reference to 8191393 and read something like > > // rotate_log must be called from the VMThread at a safepoint. In case of need to do > // gc log rotation from a thread other than the VMThread, a subtype of VM_Operation > // should be created and be submitted to the VMThread's operation queue. DO NOT call this > // function directly. It is safe to rotate the log at a safepoint via the VMThread because > // no mutator threads run concurrently with the VMThread, and GC threads that run > // concurrently with the VMThread are synchronized in write and rotate_log via _file_lock. > // rotate_log can write log entries, so write does a recursive lock check on _file_lock. Yes, that's very clear. Still ok for me assuming the above change. No need for another webrev. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From xxinliu at amazon.com Wed Apr 8 19:35:53 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 8 Apr 2020 19:35:53 +0000 Subject: [8u] JDK-8191393: Random crashes during cfree+0x1c In-Reply-To: <5f3cab25-77d6-9e0f-5abe-e91e90a2f0b2@redhat.com> References: <02584D31-2CE0-4FD2-A9FA-9AC1BB44507B@amazon.com> <5f3cab25-77d6-9e0f-5abe-e91e90a2f0b2@redhat.com> Message-ID: <7A707A0D-EEC6-4669-86B6-A6CAB6D6E2A2@amazon.com> Hi, Reviewers, Thanks for reviewing. Here is the modified webrev: https://cr.openjdk.java.net/~xliu/8191393/02/webrev/ @Paul, Could you sponsor this webrev? I add the label "jdk8u-fix-request" to JDK-8191393. Thanks, --lx https://bugs.openjdk.java.net/browse/?On 4/8/20, 9:13 AM, "Andrew Dinn" 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. On 08/04/2020 16:50, Hohensee, Paul wrote: > Looks good now, except one more small issue. > > I forgot to say before that, given that rotate_log and write are now synchronized, the rotate_log method comment is inaccurate. It could be changed to eliminate the reference to 8191393 and read something like > > // rotate_log must be called from the VMThread at a safepoint. In case of need to do > // gc log rotation from a thread other than the VMThread, a subtype of VM_Operation > // should be created and be submitted to the VMThread's operation queue. DO NOT call this > // function directly. It is safe to rotate the log at a safepoint via the VMThread because > // no mutator threads run concurrently with the VMThread, and GC threads that run > // concurrently with the VMThread are synchronized in write and rotate_log via _file_lock. > // rotate_log can write log entries, so write does a recursive lock check on _file_lock. Yes, that's very clear. Still ok for me assuming the above change. No need for another webrev. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From hohensee at amazon.com Wed Apr 8 20:56:50 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 8 Apr 2020 20:56:50 +0000 Subject: [8u] JDK-8191393: Random crashes during cfree+0x1c In-Reply-To: <7A707A0D-EEC6-4669-86B6-A6CAB6D6E2A2@amazon.com> References: <02584D31-2CE0-4FD2-A9FA-9AC1BB44507B@amazon.com> <5f3cab25-77d6-9e0f-5abe-e91e90a2f0b2@redhat.com> <7A707A0D-EEC6-4669-86B6-A6CAB6D6E2A2@amazon.com> Message-ID: <4E2279FF-41DF-470F-81B0-B55312436D99@amazon.com> Np sponsoring your patch. I've also added a Fix Request comment to the JBS issue. Paul ?On 4/8/20, 12:36 PM, "Liu, Xin" wrote: Hi, Reviewers, Thanks for reviewing. Here is the modified webrev: https://cr.openjdk.java.net/~xliu/8191393/02/webrev/ @Paul, Could you sponsor this webrev? I add the label "jdk8u-fix-request" to JDK-8191393. Thanks, --lx https://bugs.openjdk.java.net/browse/On 4/8/20, 9:13 AM, "Andrew Dinn" 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. On 08/04/2020 16:50, Hohensee, Paul wrote: > Looks good now, except one more small issue. > > I forgot to say before that, given that rotate_log and write are now synchronized, the rotate_log method comment is inaccurate. It could be changed to eliminate the reference to 8191393 and read something like > > // rotate_log must be called from the VMThread at a safepoint. In case of need to do > // gc log rotation from a thread other than the VMThread, a subtype of VM_Operation > // should be created and be submitted to the VMThread's operation queue. DO NOT call this > // function directly. It is safe to rotate the log at a safepoint via the VMThread because > // no mutator threads run concurrently with the VMThread, and GC threads that run > // concurrently with the VMThread are synchronized in write and rotate_log via _file_lock. > // rotate_log can write log entries, so write does a recursive lock check on _file_lock. Yes, that's very clear. Still ok for me assuming the above change. No need for another webrev. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From snazarkin at azul.com Fri Apr 10 12:45:44 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Fri, 10 Apr 2020 12:45:44 +0000 Subject: [8u] RFR: Backport of 8067796 (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null In-Reply-To: References: <11F4B16A-212E-4805-AF6A-46B8760278EB@azul.com> <586f5546-4614-565a-dc5f-8c62aff09782@redhat.com> <2b42427a-6485-4c36-fbb2-ff7f4eedf08b@redhat.com> <23C95150-015E-417C-AEF9-5E3E389896DA@azul.com> <87c7205e-5b55-f95c-0800-72c4e0aa408c@redhat.com> Message-ID: <4DD100BC-23CD-49AD-B5E0-3146403D1376@azul.com> Could anyone help review this patch? Thanks. /Sergey > On Apr 5, 2020, at 22:44, Sergey Nazarkin wrote: > > Thanks, Andrew. In simpler case 8037866(Replace the Fun class in tests with lambdas) only misses a part of MOAT.java that was introduced by 8014066(ArrayList#removeRange): > > $cat test/java/util/Collection/MOAT.java.rej > --- MOAT.java > +++ MOAT.java > @@ -728,8 +722,8 @@ > l.listIterator(0); > l.listIterator(l.size()); > THROWS(IndexOutOfBoundsException.class, > - new Fun(){void f(){l.listIterator(-1);}}, > - new Fun(){void f(){l.listIterator(l.size() + 1);}}); > + () -> l.listIterator(-1), > + () -> l.listIterator(l.size() + 1)); > > if (l instanceof AbstractList) { > try { > > Final patchset would be > > 1) http://cr.openjdk.java.net/~snazarki/webrev/8037866/ > 2) http://cr.openjdk.java.net/~snazarki/webrev/8067796/ > > > > Sergey Nazarkin > > > > >> On Apr 1, 2020, at 18:14, Andrew Haley wrote: >> >> On 4/1/20 3:30 PM, Sergey Nazarkin wrote: >>> I?ve tracked down patchset required for clean backport. Beside 8037866 [2] only 8014066 [1] is required. I?m a bit worrying about 8014066, the changeset may affect existent applications behavior. >>> >>> With 8014066 all subsequent patches applied cleanly except 8067796: >>> - for non-windows OSes waitFor method is at UNIXProcess.java (not ProcessImpl.java) >>> - windows version of ProcessImpl.java is placed at different path >>> - Basic.java: bug list is different >>> >>> If 8014066 is accepted for backport I?ll create separate RFRs. In this case patch sequence should be [4] -> [5] -> [6] >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8014066 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8037866 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8067796 >>> >>> [4] http://cr.openjdk.java.net/~snazarki/webrev/8014066/ >>> [5] http://cr.openjdk.java.net/~snazarki/webrev/8037866/ >>> [6] http://cr.openjdk.java.net/~snazarki/webrev/8067796/ >> >> You're right. This is too much for the initial patch, which is low >> risk and changes only a few lines. It'd be OK if you find a way to do >> it without changing ArrayList#removeRange. It wouldn't be a disaster >> if you rewrote the test case to not require JDK-8037866. >> >> -- >> Andrew Haley (he/him) >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> https://keybase.io/andrewhaley >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From aph at redhat.com Tue Apr 14 09:43:50 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Apr 2020 10:43:50 +0100 Subject: [8u] RFR: Backport of 8067796 (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null In-Reply-To: <4DD100BC-23CD-49AD-B5E0-3146403D1376@azul.com> References: <11F4B16A-212E-4805-AF6A-46B8760278EB@azul.com> <586f5546-4614-565a-dc5f-8c62aff09782@redhat.com> <2b42427a-6485-4c36-fbb2-ff7f4eedf08b@redhat.com> <23C95150-015E-417C-AEF9-5E3E389896DA@azul.com> <87c7205e-5b55-f95c-0800-72c4e0aa408c@redhat.com> <4DD100BC-23CD-49AD-B5E0-3146403D1376@azul.com> Message-ID: <14a61b44-5002-2abb-0e62-3e5b6cd1614b@redhat.com> On 4/10/20 1:45 PM, Sergey Nazarkin wrote: > Could anyone help review this patch? > > Thanks. > > /Sergey > >> On Apr 5, 2020, at 22:44, Sergey Nazarkin wrote: >> >> Thanks, Andrew. In simpler case 8037866(Replace the Fun class in tests with lambdas) only misses a part of MOAT.java that was introduced by 8014066(ArrayList#removeRange): >> >> $cat test/java/util/Collection/MOAT.java.rej >> --- MOAT.java >> +++ MOAT.java >> @@ -728,8 +722,8 @@ >> l.listIterator(0); >> l.listIterator(l.size()); >> THROWS(IndexOutOfBoundsException.class, >> - new Fun(){void f(){l.listIterator(-1);}}, >> - new Fun(){void f(){l.listIterator(l.size() + 1);}}); >> + () -> l.listIterator(-1), >> + () -> l.listIterator(l.size() + 1)); >> >> if (l instanceof AbstractList) { >> try { >> >> Final patchset would be >> >> 1) http://cr.openjdk.java.net/~snazarki/webrev/8037866/ >> 2) http://cr.openjdk.java.net/~snazarki/webrev/8067796/ Yes, let's go with that. It seems like a crazy amount of code to import for such a small patch, but it's all test code and the changes are trivial. The most important thing is that the actual change to runtime code is minimal. -- 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 Tue Apr 14 19:08:19 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 Apr 2020 20:08:19 +0100 Subject: [RFR] [8u] 8u252-b09 Message-ID: <26e52f65-659e-bcc9-8108-838a2a0395cf@redhat.com> Here are the jdk8u252-b09 changes (the security patches) for the jdk8u repository: Webrevs: https://cr.openjdk.java.net/~andrew/openjdk8/8u252/ Changes in jdk8u252-b09: - S8204152: SignedObject throws NullPointerException for null keys with an initialized Signature object - S8219597: (bf) Heap buffer state changes could provoke unexpected exceptions - S8223898: Forward references to Nashorn - S8223904: Improve Nashorn matching - S8224541: Better mapping of serial ENUMs - S8224549: Less Blocking Array Queues - S8225603: Enhancement for big integers - S8227542: Manifest improved jar headers - S8231415: Better signatures in XML - S8233250: Better X11 rendering - S8233410: Better Build Scripting - S8234027: Better JCEKS key support - S8234408: Improve TLS session handling - S8234825: Better Headings for HTTP Servers - S8234841: Enhance buffering of byte buffers - S8235274: Enhance typing of methods - S8236201: Better Scanner conversions - S8238960: linux-i586 builds are inconsistent as the newly build jdk is not able to reserve enough space for object heap Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Tue Apr 14 19:14:27 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 21:14:27 +0200 Subject: [RFR] [8u] 8u252-b09 In-Reply-To: <26e52f65-659e-bcc9-8108-838a2a0395cf@redhat.com> References: <26e52f65-659e-bcc9-8108-838a2a0395cf@redhat.com> Message-ID: On 4/14/20 9:08 PM, Andrew John Hughes wrote: > Here are the jdk8u252-b09 changes (the security patches) for the jdk8u > repository: > > Webrevs: https://cr.openjdk.java.net/~andrew/openjdk8/8u252/ corba: hotspot: jaxp: jaxws: langtools: Looks trivially good. jdk: Looks good. nashorn: Looks good. root: Looks good. > Ok to push? Yes, I think so. -- Thanks, -Aleksey From bourges.laurent at gmail.com Tue Apr 14 19:20:31 2020 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 14 Apr 2020 21:20:31 +0200 Subject: RFR: 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering Message-ID: Please review this 10th patch to backport the Marlin renderer from jdk9. JBS: https://bugs.openjdk.java.net/browse/JDK-8148886 patch: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/m10.8148886.patch webrev: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/webrev-8148886.0/ unshuffled patch: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/unshuffled/8-m10.8148886.patch Changes: - RendererContext.java: fixed few chunks due to missing changes (Cleaner API can not be used in jdk8) - fixed Version: to 0.7.3.2 Complete diff between unshuffled & proposed patch: --- /home/bourgesl/libs/graphics-rasterizer/wr/marlin-8.10/unshuffled/8-m10.8148886.patch +++ /home/bourgesl/libs/graphics-rasterizer/wr/marlin-8.10/m10.8148886.patch @@ -772,10 +772,10 @@ - * @see MarlinRenderingEngine#REF_TYPE - */ - final Object reference; - // Smallest object used as Cleaner's parent reference - final Object cleanerObj = new Object(); // dirty flag indicating an exception occured during pipeline in pathTo() -@@ -101,7 +98,7 @@ + boolean dirty = false; + // dynamic array caches kept using weak reference (low memory footprint) +@@ -99,7 +96,7 @@ /** * Constructor * @@ -784,7 +784,7 @@ */ RendererContext(final String name) { if (logCreateContext) { -@@ -124,20 +121,6 @@ +@@ -122,20 +119,6 @@ stroker = new Stroker(this); dasher = new Dasher(this); @@ -819,7 +819,7 @@ public final class Version { -- private static final String version = "marlin-0.7.3-Unsafe-OpenJDK"; +- private static final String version = "marlin-0.7.2-Unsafe-OpenJDK"; + private static final String version = "marlin-0.7.3.2-Unsafe-OpenJDK"; public static String getVersion() { Cheers, Laurent From shade at redhat.com Wed Apr 15 05:25:11 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Apr 2020 07:25:11 +0200 Subject: [8u] RFR (XS) 8242788: Non-PCH build is broken after JDK-8191393 Message-ID: <6cd66af5-df35-4dd7-b318-962403d0de7e@redhat.com> 8u-specific bug: https://bugs.openjdk.java.net/browse/JDK-8242788 Simple fix: diff -r 6c179587bf5b src/share/vm/utilities/ostream.cpp --- a/src/share/vm/utilities/ostream.cpp Thu Apr 09 20:58:56 2020 +0000 +++ b/src/share/vm/utilities/ostream.cpp Wed Apr 15 07:24:34 2020 +0200 @@ -30,4 +30,5 @@ #include "runtime/mutexLocker.hpp" #include "runtime/os.hpp" +#include "runtime/vmThread.hpp" #include "utilities/defaultStream.hpp" #include "utilities/ostream.hpp" Testing: Linux x86_64 {release,fastdebug,slowdebug} non-PCH build -- Thanks, -Aleksey From aph at redhat.com Wed Apr 15 08:51:23 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Apr 2020 09:51:23 +0100 Subject: [8u] RFR (XS) 8242788: Non-PCH build is broken after JDK-8191393 In-Reply-To: <6cd66af5-df35-4dd7-b318-962403d0de7e@redhat.com> References: <6cd66af5-df35-4dd7-b318-962403d0de7e@redhat.com> Message-ID: <98429640-e68e-cc21-1876-d2102738889f@redhat.com> On 4/15/20 6:25 AM, Aleksey Shipilev wrote: > 8u-specific bug: > https://bugs.openjdk.java.net/browse/JDK-8242788 > > Simple fix: > > diff -r 6c179587bf5b src/share/vm/utilities/ostream.cpp > --- a/src/share/vm/utilities/ostream.cpp Thu Apr 09 20:58:56 2020 +0000 > +++ b/src/share/vm/utilities/ostream.cpp Wed Apr 15 07:24:34 2020 +0200 > @@ -30,4 +30,5 @@ > #include "runtime/mutexLocker.hpp" > #include "runtime/os.hpp" > +#include "runtime/vmThread.hpp" > #include "utilities/defaultStream.hpp" > #include "utilities/ostream.hpp" > > Testing: Linux x86_64 {release,fastdebug,slowdebug} non-PCH build > OK, thanks. This one again... -- 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 snazarkin at azul.com Wed Apr 15 09:17:52 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Wed, 15 Apr 2020 09:17:52 +0000 Subject: [8u] RFR: Backport of 8067796 (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null In-Reply-To: <14a61b44-5002-2abb-0e62-3e5b6cd1614b@redhat.com> References: <11F4B16A-212E-4805-AF6A-46B8760278EB@azul.com> <586f5546-4614-565a-dc5f-8c62aff09782@redhat.com> <2b42427a-6485-4c36-fbb2-ff7f4eedf08b@redhat.com> <23C95150-015E-417C-AEF9-5E3E389896DA@azul.com> <87c7205e-5b55-f95c-0800-72c4e0aa408c@redhat.com> <4DD100BC-23CD-49AD-B5E0-3146403D1376@azul.com> <14a61b44-5002-2abb-0e62-3e5b6cd1614b@redhat.com> Message-ID: <9371CBB4-6290-418A-9ACF-0F8A5EFDCEC8@azul.com> Thanks, Andrew. [1] and [2] marked with jdk8u-fix-request [1] https://bugs.openjdk.java.net/browse/JDK-8037866 [2] https://bugs.openjdk.java.net/browse/JDK-8067796 Sergey Nazarkin > On Apr 14, 2020, at 12:43, Andrew Haley wrote: > > On 4/10/20 1:45 PM, Sergey Nazarkin wrote: >> Could anyone help review this patch? >> >> Thanks. >> >> /Sergey >> >>> On Apr 5, 2020, at 22:44, Sergey Nazarkin wrote: >>> >>> Thanks, Andrew. In simpler case 8037866(Replace the Fun class in tests with lambdas) only misses a part of MOAT.java that was introduced by 8014066(ArrayList#removeRange): >>> >>> $cat test/java/util/Collection/MOAT.java.rej >>> --- MOAT.java >>> +++ MOAT.java >>> @@ -728,8 +722,8 @@ >>> l.listIterator(0); >>> l.listIterator(l.size()); >>> THROWS(IndexOutOfBoundsException.class, >>> - new Fun(){void f(){l.listIterator(-1);}}, >>> - new Fun(){void f(){l.listIterator(l.size() + 1);}}); >>> + () -> l.listIterator(-1), >>> + () -> l.listIterator(l.size() + 1)); >>> >>> if (l instanceof AbstractList) { >>> try { >>> >>> Final patchset would be >>> >>> 1) http://cr.openjdk.java.net/~snazarki/webrev/8037866/ >>> 2) http://cr.openjdk.java.net/~snazarki/webrev/8067796/ > Yes, let's go with that. It seems like a crazy amount of code to import for > such a small patch, but it's all test code and the changes are trivial. > The most important thing is that the actual change to runtime code is > minimal. > > -- > 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 Wed Apr 15 09:18:36 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Apr 2020 11:18:36 +0200 Subject: [8u] RFR (XS) 8242788: Non-PCH build is broken after JDK-8191393 In-Reply-To: <98429640-e68e-cc21-1876-d2102738889f@redhat.com> References: <6cd66af5-df35-4dd7-b318-962403d0de7e@redhat.com> <98429640-e68e-cc21-1876-d2102738889f@redhat.com> Message-ID: <1e0cb44c-d524-a713-b8ac-2e03ad402869@redhat.com> On 4/15/20 10:51 AM, Andrew Haley wrote: > On 4/15/20 6:25 AM, Aleksey Shipilev wrote: >> 8u-specific bug: >> https://bugs.openjdk.java.net/browse/JDK-8242788 >> >> Simple fix: >> >> diff -r 6c179587bf5b src/share/vm/utilities/ostream.cpp >> --- a/src/share/vm/utilities/ostream.cpp Thu Apr 09 20:58:56 2020 +0000 >> +++ b/src/share/vm/utilities/ostream.cpp Wed Apr 15 07:24:34 2020 +0200 >> @@ -30,4 +30,5 @@ >> #include "runtime/mutexLocker.hpp" >> #include "runtime/os.hpp" >> +#include "runtime/vmThread.hpp" >> #include "utilities/defaultStream.hpp" >> #include "utilities/ostream.hpp" >> >> Testing: Linux x86_64 {release,fastdebug,slowdebug} non-PCH build >> > > OK, thanks. This one again... Thanks, added tags. -- -Aleksey From gnu.andrew at redhat.com Wed Apr 15 13:22:29 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 15 Apr 2020 14:22:29 +0100 Subject: OpenJDK 8u252 Released Message-ID: <489b2a4f-a0d7-7cab-ce05-6db6792ae18d@redhat.com> We are pleased to announce the release of OpenJDK 8u252. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u252-ga.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u252-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: bce0eadd22e0b00a4a38590866e3edde69f4e7e4c9bbd7f94fe2ca820c39cf71 openjdk8u252-ga.tar.xz 442b9facebf7108dbb1616e617e96cf7b74f806b8a8b10e4a0b60231453dc617 openjdk8u252-ga.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u252-ga.sha256 Key: JDK-X - https://bugs.openjdk.java.net/browse/JDK-X CVE-XXXX-YYYY: https://cve.mitre.org/cgi-bin/cvename.cgi?name=XXXX-YYYY New in release OpenJDK 8u252 (2020-04-14): =========================================== Live versions of these release notes can be found at: * https://bitly.com/oj8u252 * https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u252.txt * Security fixes - JDK-8223898, CVE-2020-2754: Forward references to Nashorn - JDK-8223904, CVE-2020-2755: Improve Nashorn matching - JDK-8224541, CVE-2020-2756: Better mapping of serial ENUMs - JDK-8224549, CVE-2020-2757: Less Blocking Array Queues - JDK-8225603: Enhancement for big integers - JDK-8227542: Manifest improved jar headers - JDK-8231415, CVE-2020-2773: Better signatures in XML - JDK-8233250: Better X11 rendering - JDK-8233410: Better Build Scripting - JDK-8234027: Better JCEKS key support - JDK-8234408, CVE-2020-2781: Improve TLS session handling - JDK-8234825, CVE-2020-2800: Better Headings for HTTP Servers - JDK-8234841, CVE-2020-2803: Enhance buffering of byte buffers - JDK-8235274, CVE-2020-2805: Enhance typing of methods - JDK-8236201, CVE-2020-2830: Better Scanner conversions - JDK-8238960: linux-i586 builds are inconsistent as the newly build jdk is not able to reserve enough space for object heap * Other changes - JDK-8005819: Support cross-realm MSSFU - JDK-8022263: use same Clang warnings on BSD as on Linux - JDK-8038631: Create wrapper for awt.Robot with additional functionality - JDK-8047212: runtime/ParallelClassLoading/bootstrap/random/inner-complex assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is invalid - JDK-8055283: Expand ResourceHashtable with C_HEAP allocation, removal and some unit tests - JDK-8068184: Fix for JDK-8032832 caused a deadlock - JDK-8079693: Add support for ECDSA P-384 and P-521 curves to XML Signature - JDK-8132130: some docs cleanup - JDK-8135318: CMS wrong max_eden_size for check_gc_overhead_limit - JDK-8144445: Maximum size checking in Marlin ArrayCache utility methods is not optimal - JDK-8144446: Automate the Marlin crash test - JDK-8144526: Remove Marlin logging use of deleted internal API - JDK-8144630: Use PrivilegedAction to create Thread in Marlin RendererStats - JDK-8144654: Improve Marlin logging - JDK-8144718: Pisces / Marlin Strokers may generate invalid curves with huge coordinates and round joins - JDK-8166976: TestCipherPBECons has wrong @run line - JDK-8167409: Invalid value passed to critical JNI function - JDK-8181872: C1: possible overflow when strength reducing integer multiply by constant - JDK-8187078: -XX:+VerifyOops finds numerous problems when running JPRT - JDK-8191227: issues with unsafe handle resolution - JDK-8197441: Signature#initSign/initVerify for an invalid private/public key fails with ClassCastException for SunPKCS11 provider - JDK-8204152: SignedObject throws NullPointerException for null keys with an initialized Signature object - JDK-8215756: Memory leaks in the AWT on macOS - JDK-8216472: (se) Stack overflow during selection operation leads to crash (win) - JDK-8219244: NMT: Change ThreadSafepointState's allocation type from mtInternal to mtThread - JDK-8219597: (bf) Heap buffer state changes could provoke unexpected exceptions - JDK-8225128: Add exception for expiring DocuSign root to VerifyCACerts test - JDK-8225130: Add exception for expiring Comodo roots to VerifyCACerts test - JDK-8229022: BufferedReader performance can be improved by using StringBuilder - JDK-8229345: Memory leak due to vtable stubs not being shared on SPARC - JDK-8229872: (fs) Increase buffer size used with getmntent - JDK-8230235: Rendering HTML with empty img attribute and documentBaseKey cause Exception - JDK-8231430: C2: Memory stomp in max_array_length() for T_ILLEGAL type - JDK-8235744: PIT: test/jdk/javax/swing/text/html/TestJLabelWithHTMLText.java times out in linux-x64 - JDK-8235904: Infinite loop when rendering huge lines - JDK-8236179: C1 register allocation error with T_ADDRESS - JDK-8237368: Problem with NullPointerException in RMI TCPEndpoint.read - JDK-8240521: Revert backport of 8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call - JDK-8241296: Segfault in JNIHandleBlock::oops_do() - JDK-8241307: Marlin renderer should not be the default in 8u252 Notes on individual issues: =========================== hotspot/svc: JDK-8174881: Binary format for HPROF updated ============================================ When dumping the heap in binary format, HPROF format 1.0.2 is always used now. Previously, format 1.0.1 was used for heaps smaller than 2GB. HPROF format 1.0.2 is also used by jhsdb jmap for the serviceability agent. security-libs/java.security: JDK-8229518: Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature ==================================================================================== The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the `java.security.spec` and `javax.crypto.spec` packages for supporting additional RSASSA-PSS parameters. security-libs/javax.crypto: JDK-8205471: RSASSA-PSS Signature Support Added to SunMSCAPI ============================================================ The RSASSA-PSS signature algorithm support has been added to the SunMSCAPI provider. security-libs/javax.security: JDK-8227564: Allow SASL Mechanisms to Be Restricted =================================================== A security property named `jdk.sasl.disabledMechanisms` has been added that can be used to disable SASL mechanisms. Any disabled mechanism will be ignored if it is specified in the `mechanisms` argument of `Sasl.createSaslClient` or the `mechanism` argument of `Sasl.createSaslServer`. The default value for this security property is empty, which means that no mechanisms are disabled out-of-the-box. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Wed Apr 15 13:36:09 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 15 Apr 2020 15:36:09 +0200 Subject: OpenJDK 8u252 Released In-Reply-To: <489b2a4f-a0d7-7cab-ce05-6db6792ae18d@redhat.com> References: <489b2a4f-a0d7-7cab-ce05-6db6792ae18d@redhat.com> Message-ID: On Wed, 2020-04-15 at 14:22 +0100, Andrew John Hughes wrote: > We are pleased to announce the release of OpenJDK 8u252. The Upstream Project Build to go with this is here: https://adoptopenjdk.net/upstream.html?variant=openjdk8&ga=ga Thanks, Severin From aoqi at loongson.cn Wed Apr 15 18:43:18 2020 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 16 Apr 2020 02:43:18 +0800 Subject: [8u] RFR (T): 8242883: Incomplete backport of JDK-8078268: backport test part Message-ID: Hi all, This is a 8u-specific bug. JDK-8078268 was backported to jdk8u, but the backport is incomplete. An empty test were backported to jdk8u. JBS: https://bugs.openjdk.java.net/browse/JDK-8242883 webrev: http://cr.openjdk.java.net/~aoqi/8242883/webrev.00/ before fix: $ jtreg -dir:/home/aoqi/work/jdk8u-dev/jdk/test javax/swing/text/html/parser/Parser/8078268/bug8078268.java Error: Not a test or directory containing tests: javax/swing/text/html/parser/Parser/8078268/bug8078268.java after fix: $ jtreg -dir:/home/aoqi/work/jdk8u-dev/jdk/test javax/swing/text/html/parser/Parser/8078268/bug8078268.java Test results: passed: 1 Thanks, Ao Qi From hohensee at amazon.com Thu Apr 16 12:54:27 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 16 Apr 2020 12:54:27 +0000 Subject: [8u] RFR (T): 8242883: Incomplete backport of JDK-8078268: backport test part Message-ID: Lgtm. Paul ?On 4/15/20, 11:49 AM, "jdk8u-dev on behalf of Ao Qi" wrote: Hi all, This is a 8u-specific bug. JDK-8078268 was backported to jdk8u, but the backport is incomplete. An empty test were backported to jdk8u. JBS: https://bugs.openjdk.java.net/browse/JDK-8242883 webrev: http://cr.openjdk.java.net/~aoqi/8242883/webrev.00/ before fix: $ jtreg -dir:/home/aoqi/work/jdk8u-dev/jdk/test javax/swing/text/html/parser/Parser/8078268/bug8078268.java Error: Not a test or directory containing tests: javax/swing/text/html/parser/Parser/8078268/bug8078268.java after fix: $ jtreg -dir:/home/aoqi/work/jdk8u-dev/jdk/test javax/swing/text/html/parser/Parser/8078268/bug8078268.java Test results: passed: 1 Thanks, Ao Qi From aoqi at loongson.cn Thu Apr 16 17:35:59 2020 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 17 Apr 2020 01:35:59 +0800 Subject: [8u] RFR (T): 8242883: Incomplete backport of JDK-8078268: backport test part In-Reply-To: References: Message-ID: Thank you, Paul. Added the label jdk8u-fix-request. Cheers, Ao Qi On Thu, Apr 16, 2020 at 8:54 PM Hohensee, Paul wrote: > > Lgtm. > > Paul > > ?On 4/15/20, 11:49 AM, "jdk8u-dev on behalf of Ao Qi" wrote: > > Hi all, > > This is a 8u-specific bug. JDK-8078268 was backported to jdk8u, but > the backport is incomplete. An empty test were backported to jdk8u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242883 > webrev: http://cr.openjdk.java.net/~aoqi/8242883/webrev.00/ > > before fix: > $ jtreg -dir:/home/aoqi/work/jdk8u-dev/jdk/test > javax/swing/text/html/parser/Parser/8078268/bug8078268.java > Error: Not a test or directory containing tests: > javax/swing/text/html/parser/Parser/8078268/bug8078268.java > > after fix: > $ jtreg -dir:/home/aoqi/work/jdk8u-dev/jdk/test > javax/swing/text/html/parser/Parser/8078268/bug8078268.java > Test results: passed: 1 > > Thanks, > Ao Qi > > From ebaron at redhat.com Thu Apr 16 23:54:05 2020 From: ebaron at redhat.com (Elliott Baron) Date: Thu, 16 Apr 2020 19:54:05 -0400 Subject: [8u] RFR Backport 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 Message-ID: Hi, I'd like to request a review to backport 8177334 to 8u. Original fix: https://bugs.openjdk.java.net/browse/JDK-8177334 http://hg.openjdk.java.net/jdk/jdk/rev/3810c9a2efa1 The JDK 11 fix did not apply cleanly. Below, I have detailed the modifications I made in order to backport this fix to 8u. There are some major changes that I believe may require some discussion, and many minor changes outlined after those. The changes within each section are listed roughly in order of the patch. Thank you to Martin Balao for his assistance in tracking down the dependencies for this fix. I should point out that there are some known bugfixes that fix problems introduced by this update. These should probably go into the same 8u update as this fix. They are: - 8217878: ENVELOPING XML signature no longer works - 8218629: XML Digital Signature throws NAMESPACE_ERR exception on OpenJDK 11, works 8/9/10 (I believe this is the same fix as above) - 8236645: JDK 8u231 introduces a regression with incompatible handling of XML messages 8u webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8177334/webrev.00/ Testing: x86_64 build, jdk_tier1, jdk_security tests Major changes --------------- javax/xml/crypto/dsig/DigestMethod: - New string constants referencing new algorithms have been removed, in order to not introduce new public API. I'm not sure if this would technically be a breakage. javax/xml/crypto/dsig/SignatureMethod: - New string constants have been removed, as in DigestMethod mentioned above. org/jcp/xml/dsig/internal/dom/DOMSignatureMethod: - There is no "8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes" in 8u. This was a messy backport and it appears to add a new feature. To limit the amount of modifications done to this class, I opted to backport the "getSignature" method only from 8042967. - The class hierarchies of various nested DOMSignatureMethods have been changed to exclude abstract classes that were introduced by 8042967. - I'm a bit on the fence about these modifications, perhaps it would be better to backport 8042967 after all. test/javax/xml/crypto/dsig/GenerationTests: - jtreg tag differs because of newer tests already in 8u, lack of modules, and argument added by "8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux". - Test cases using missing SHA-3 algorithm have been removed, since there is no support for it in 8u. This would require a backport of "8000415: Add support for SHA-3" and possibly others. - Constants in javax/xml/crypto/dsig/{Digest,Signature}Method that were not backported are substituted with their String values. - List.of, which doesn't exist in JDK 8, has been replaced with a static initializer. - For code added by "8206911: javax/xml/crypto/dsig/GenerationTests.java fails in 8u-dev", rename call from "test_create_detached_signature" to "test_create_detached_signature0". This reflects the method name change introduced by this fix. - Some context also required changes due to 8206911. Minor changes --------------- THIRD_PARTY_README: Bump version of Apache Santuario corresponding to changes in share/legal/santuario.md from original fix. com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm: - Context slightly different due to "6850612: Deprecate Class.newInstance since it violates the checked exception language contract" not backported to 8u. com/sun/org/apache/xml/internal/security/encryption/AbstractSerializer: - Context differs due to lack of "8055723: Replace concat String to append in StringBuilder parameters" in 8u. I chose not to backport this since it relies on "8041679: Replace uses of StringBuffer with StringBuilder within core library classes", which is another fairly large patch. - End result is unaffected since this file is deleted. com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod: - Context differs due to lack of "8067377: My hobby: caning, then then canning, the the can-can" in 8u. I didn't backport this since it's a large doc fix and is easily worked around. - End result is unaffected since this file is deleted. com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty: - Context differs due to existing backport of "8133802: replace some tags (obsolete in html5) in security-libs docs" being slightly different. - End result is unaffected since this file is deleted. com/sun/org/apache/xml/internal/security/encryption/ReferenceList: - Same differences/reasoning as EncryptionProperty above. com/sun/org/apache/xml/internal/security/keys/KeyUtils: - Comment to be patched differs slightly due to absent "8067377: My hobby: caning, then then canning, the the can-can". End result matches original fix. com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver: - A few differences in context due "6850612: Deprecate Class.newInstance since it violates the checked exception language contract" not present in 8u. com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverSpi: - Same difference/reasoning as in KeyResolver above. com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHere: - One hunk removed that rearranges imports, because the import was added by "8181150: Fix lint warnings in JAXP repo: rawtypes and unchecked". I did not backport this to 8u since it's a large patch and is trivial to work around in this backport. com/sun/org/apache/xml/internal/security/transforms/params/InclusiveNamespaces: - One line of context differs due to missing "8055723: Replace concat String to append in StringBuilder parameters". See AbstractSerializer above. com/sun/org/apache/xml/internal/security/utils/JavaUtils: - Hunk moving "checkRegisterPermission" not required since it's already located where it would be moved to in 8u. com/sun/org/apache/xml/internal/security/utils/XalanXPathAPI: - One change editing a log message has been removed, since the code that introduced the log message is not in 8u. That changeset is "8087283: Add support for the XML Signature here() function to the JDK XPath implementation". It didn't seem worthwhile to backport for the sake of this fix. com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver: - Context differs in one hunk due to "6850612: Deprecate Class.newInstance since it violates the checked exception language contract" absent backported in 8u. - Resulting code is the same, minus a @SuppressWarnings annotation. org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer: - Context differs due to "8046949: Generify the javax.xml.crypto API" not backported to 8u. Some minor changes unneeded since they revert changes from 8046949. org/jcp/xml/dsig/internal/dom/ApacheTransform: - Removed change that reverts the removal of a "@SuppressWarnings" annotation by "8046949: Generify the javax.xml.crypto API", since this change was never backported in the first place. org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod: - Two lines of context changed due to no 8u backport of "8041679: Replace uses of StringBuffer with StringBuilder within core library classes" and "8046949: Generify the javax.xml.crypto API". org/jcp/xml/dsig/internal/dom/DOMKeyInfo: - Changes that revert changes made by "8046949: Generify the javax.xml.crypto API" have been removed since 8046949 is not in 8u. org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory: - The majority of changes here revert "8046949: Generify the javax.xml.crypto API". Since this wasn't backported they aren't applicable. Most of what remains is adding "@Override" annotations. org/jcp/xml/dsig/internal/dom/DOMManifest: - This required similar modifications to DOMKeyInfoFactory above. org/jcp/xml/dsig/internal/dom/DOMPGPData: - Changes reverting those introduced by "8046949: Generify the javax.xml.crypto API" have been removed, similar to DOMKeyInfoFactory above. - Different context for getKeyId and getKeyPacket methods due to "8032733: Fix cast lint warnings in client libraries" not being backported to 8u. This is a fairly large patch and was previously ruled out for a backport to 8u. org/jcp/xml/dsig/internal/dom/DOMReference: - Modifications required here were done for the same reasons as DOMPGPData above. org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod, org/jcp/xml/dsig/internal/dom/DOMSignatureProperties, org/jcp/xml/dsig/internal/dom/DOMSignatureProperty, org/jcp/xml/dsig/internal/dom/DOMSignedInfo, org/jcp/xml/dsig/internal/dom/DOMUtils, org/jcp/xml/dsig/internal/dom/DOMX509Data, org/jcp/xml/dsig/internal/dom/DOMXMLObject, org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory, org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform, org/jcp/xml/dsig/internal/dom/DOMXPathTransform: - These also remove inapplicable reversions for changes that would have been done by "8046949: Generify the javax.xml.crypto API". org/jcp/xml/dsig/internal/dom/DOMXMLSignature: - Removed portions that don't apply due to lack of "8046949: Generify the javax.xml.crypto API". - A line of context needed to be changed because of "8032733: Fix cast lint warnings in client libraries" not backported. org/jcp/xml/dsig/internal/dom/Utils: - Context surrounding changes is slightly different due to lack of "8046949: Generify the javax.xml.crypto API" in 8u. com/sun/org/apache/xml/internal/security/algorithms/package.html com/sun/org/apache/xml/internal/security/keys/content/keyvalues/package.html com/sun/org/apache/xml/internal/security/keys/content/package.html com/sun/org/apache/xml/internal/security/keys/content/x509/package.html com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/package.html com/sun/org/apache/xml/internal/security/keys/keyresolver/package.html com/sun/org/apache/xml/internal/security/keys/storage/implementations/package.html com/sun/org/apache/xml/internal/security/keys/storage/package.html: - Missing newline at end of file introduced by "8134984: Text files should end in exactly one newline". Did not backport since these files are all deleted. Thanks, Elliott From mbalao at redhat.com Fri Apr 17 05:31:29 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 17 Apr 2020 02:31:29 -0300 Subject: [8u] RFR: 8143925 : enhancing CounterMode.crypt() for AESCrypt.implEncryptBlock() + 8146581 : Minor corrections to the patch submitted for earlier bug id - 8143925 In-Reply-To: References: <95d7dae6-215e-3fdf-276b-b1e516fbb2b1@azul.com> <7c144a7b-c3bc-c4f0-fc32-d689abc0ba3d@redhat.com> <2bfe2b4d-4af5-699d-6c42-996efde361c8@azul.com> <78f41b91-d4bf-1bb8-068e-2e46b5fd6476@azul.com> <44E34230-5C62-435A-B0AA-644D27EF14A0@amazon.com> Message-ID: <7d30ffcf-cbe7-b6d2-25b1-1d33a6cc6ba3@redhat.com> Hey all, Seems like we have a reviewed candidate patch but, as far as I know, there isn't an official approval for the review. I'm not a reviewer so leave it to you @Andrew/@Paul. Thanks, Martin.- From mbalao at redhat.com Fri Apr 17 06:25:45 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 17 Apr 2020 03:25:45 -0300 Subject: [8u] RFR: 8028431: NullPointerException in DerValue.equals(DerValue) Message-ID: <1766321e-b85d-7a62-ddf7-4c0f08926e05@redhat.com> Hi, Can I have a review for the 8u backport of 8028431 [1]? We need this for parity with Oracle's JDK. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8028431/8028431.webrev.jdk8u.jdk.00/ Applies cleanly except for the copyright date of DerValue.java (which has a changeset from a more recent year). It's a trivial changeset, with minimal risk. Testing: * No regressions in sun/security/util (Test results: passed: 22). Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8028431 From sgehwolf at redhat.com Fri Apr 17 08:26:27 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 Apr 2020 10:26:27 +0200 Subject: [8u] RFR: 8028431: NullPointerException in DerValue.equals(DerValue) In-Reply-To: <1766321e-b85d-7a62-ddf7-4c0f08926e05@redhat.com> References: <1766321e-b85d-7a62-ddf7-4c0f08926e05@redhat.com> Message-ID: Hi Martin, On Fri, 2020-04-17 at 03:25 -0300, Martin Balao wrote: > Hi, > > Can I have a review for the 8u backport of 8028431 [1]? > > We need this for parity with Oracle's JDK. > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8028431/8028431.webrev.jdk8u.jdk.00/ > > Applies cleanly except for the copyright date of DerValue.java (which > has a changeset from a more recent year). Right. Copyright in DerValue.java is 2017 already and the original changeset would change it to 2013. OK. Reviewed. Thanks, Severin > It's a trivial changeset, with minimal risk. > > Testing: > > * No regressions in sun/security/util (Test results: passed: 22). > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8028431 > From bourges.laurent at gmail.com Fri Apr 17 11:10:18 2020 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 17 Apr 2020 13:10:18 +0200 Subject: RFR: 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: Message-ID: Could someone review this 8u RFR ? PS: next 5 patches will be harder to prepare & review. Thanks, Laurent Le mar. 14 avr. 2020 ? 21:20, Laurent Bourg?s a ?crit : > Please review this 10th patch to backport the Marlin renderer from jdk9. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8148886 > patch: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/m10.8148886.patch > webrev: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/webrev-8148886.0/ > unshuffled patch: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/unshuffled/8-m10.8148886.patch > > Changes: > - RendererContext.java: fixed few chunks due to missing changes (Cleaner > API can not be used in jdk8) > - fixed Version: to 0.7.3.2 > > Complete diff between unshuffled & proposed patch: > > --- > /home/bourgesl/libs/graphics-rasterizer/wr/marlin-8.10/unshuffled/8-m10.8148886.patch > +++ > /home/bourgesl/libs/graphics-rasterizer/wr/marlin-8.10/m10.8148886.patch > @@ -772,10 +772,10 @@ > - * @see MarlinRenderingEngine#REF_TYPE > - */ > - final Object reference; > - // Smallest object used as Cleaner's parent reference > - final Object cleanerObj = new Object(); > // dirty flag indicating an exception occured during pipeline in > pathTo() > -@@ -101,7 +98,7 @@ > + boolean dirty = false; > + // dynamic array caches kept using weak reference (low memory > footprint) > +@@ -99,7 +96,7 @@ > /** > * Constructor > * > @@ -784,7 +784,7 @@ > */ > RendererContext(final String name) { > if (logCreateContext) { > -@@ -124,20 +121,6 @@ > +@@ -122,20 +119,6 @@ > > stroker = new Stroker(this); > dasher = new Dasher(this); > @@ -819,7 +819,7 @@ > > public final class Version { > > -- private static final String version = "marlin-0.7.3-Unsafe-OpenJDK"; > +- private static final String version = "marlin-0.7.2-Unsafe-OpenJDK"; > + private static final String version = > "marlin-0.7.3.2-Unsafe-OpenJDK"; > > public static String getVersion() { > > Cheers, > Laurent > From dcherepanov at azul.com Fri Apr 17 12:53:16 2020 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Fri, 17 Apr 2020 15:53:16 +0300 Subject: [8u] RFR 8235687: Contents/MacOS/libjli.dylib cannot be a symlink Message-ID: <84d2d72d-5a32-aca9-dfde-17f04c586713@azul.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8235687 original review: https://mail.openjdk.java.net/pipermail/build-dev/2019-December/026452.html patch for 11u: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/1859de77ee6c webrev for 8u: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8235687/webrev.v0/ The patch doesn?t apply cleanly due to the lack of SetupCopyFiles which was added with the transition to the modular system 8054834. The patch directly calls the cp utility, this is consistent with how the images are copied a few lines above. The second part of the patch (phony target with recipes modifying files) also does not apply as is. This is an optional refactoring, and for simplicity, this part has been omitted. This fix also requires a follow-up fix (8238225), a review request for which will be sent separately. Thanks, Dmitry From dcherepanov at azul.com Fri Apr 17 12:57:46 2020 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Fri, 17 Apr 2020 15:57:46 +0300 Subject: [8u] RFR 8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary Message-ID: <5e7890f6-2a8c-b551-58b0-02c67df0b544@azul.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8238225 original review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064561.html patch for 11u: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/128739be82b6 webrev for 8u: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8238225/webrev.v0/ 1) src/macosx/bin/java_md_macosx.c This part applies cleanly but needs refinement. The logic has been expanded to cover 8u-specifics: if the libjli.dylib library was loaded from MacOS bundle (i.e. realPathToSelf ends with ?/MacOS/libjli.dylib?), then check if it?s a JDK bundle (private JRE is in ../Home/jre) and then check if it?s a JRE bundle (public JRE is in ../Home) 2) testing part Given that support for building native part of jtpeg tests is currently missing in 8u (8072842), new shell script was created and used for testing.? The java part of the test also includes additional changes relative to 11u version (http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8238225/JliLaunchTest.java.diff.v0). The test fails without a fix and passes from the fixes (for JRE/JDK bundles) Thanks, Dmitry From mbalao at redhat.com Fri Apr 17 16:54:37 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 17 Apr 2020 13:54:37 -0300 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> Message-ID: Hi Alexey, On 3/6/20 7:19 AM, Alexey Bakhtin wrote: > 8148188: Enhance the security libraries to record events of interest I'm a bit concerned about partially backporting this one. 8148188 goes across libraries out of the 'sun.security.ssl' namespace. We would need to either include that on your patch or take it out of your patch and apply it separately (there will be a dependency on your patch in the latter). I'm open to listen to your thoughts and see how can I help. Thanks, Martin.- From alexey at azul.com Fri Apr 17 19:29:06 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 17 Apr 2020 19:29:06 +0000 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> Message-ID: <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> Hello Martin, This bug was added to the list by mistake. Sorry. 8148188 is not included in the patch. You can check it - there are no recordEvent method in the sun.security.ssl.Finished class : http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v3/src/share/classes/sun/security/ssl/Finished.java.html As you mention, 8148188 should be backported separately. Regards Alexey > On 17 Apr 2020, at 19:54, Martin Balao wrote: > > Hi Alexey, > > On 3/6/20 7:19 AM, Alexey Bakhtin wrote: >> 8148188: Enhance the security libraries to record events of interest > > I'm a bit concerned about partially backporting this one. 8148188 goes > across libraries out of the 'sun.security.ssl' namespace. We would need > to either include that on your patch or take it out of your patch and > apply it separately (there will be a dependency on your patch in the > latter). I'm open to listen to your thoughts and see how can I help. > > Thanks, > Martin.- From mbalao at redhat.com Fri Apr 17 23:25:41 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 17 Apr 2020 20:25:41 -0300 Subject: [8u] RFR 7147060: com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode Message-ID: <93cba9ac-7f0b-4b80-367c-4862b0dc574b@redhat.com> Hi, I'd like to request a review for the 8u backport of 7147060 [1]. This backport will bring parity with Oracle's JDK. Risk is minimal as only a test is affected. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/7147060/7147060.webrev.jdk8u.jdk.00/ Main line patch did not apply cleanly because the list of tests in ProblemList.txt has some differences. These differences are not related to this backport and is not worth having them as dependencies. In addition, the change to ProblemList.txt is to remove the test from there. Testing: * The modified test (com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java) passes. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-7147060 From christoph.langer at sap.com Sun Apr 19 06:20:55 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 19 Apr 2020 06:20:55 +0000 Subject: Result: New JDK 8 Updates Committer: Thomas Stuefe Message-ID: Voting for Thomas Stuefe[0] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus [1], this is sufficient to approve the nomination. Thanks, Christoph [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011461.html [1] http://openjdk.java.net/bylaws#three-vote-consensus From sgehwolf at redhat.com Mon Apr 20 09:16:25 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 20 Apr 2020 11:16:25 +0200 Subject: [8u] RFR 7147060: com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode In-Reply-To: <93cba9ac-7f0b-4b80-367c-4862b0dc574b@redhat.com> References: <93cba9ac-7f0b-4b80-367c-4862b0dc574b@redhat.com> Message-ID: Hi Martin, On Fri, 2020-04-17 at 20:25 -0300, Martin Balao wrote: > Hi, > > I'd like to request a review for the 8u backport of 7147060 [1]. > > This backport will bring parity with Oracle's JDK. > > Risk is minimal as only a test is affected. > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/7147060/7147060.webrev.jdk8u.jdk.00/ > > Main line patch did not apply cleanly because the list of tests in > ProblemList.txt has some differences. These differences are not related > to this backport and is not worth having them as dependencies. In > addition, the change to ProblemList.txt is to remove the test from there. > > Testing: > > * The modified test > (com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java) > passes. This looks fine to me. Thanks, Severin > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-7147060 > From jaroslav.bachorik at datadoghq.com Mon Apr 20 14:02:38 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 20 Apr 2020 16:02:38 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing Message-ID: Please review the following backport JIRA. : https://bugs.openjdk.java.net/browse/JDK-8233197 Webrev. : http://cr.openjdk.java.net/~jbachorik/8233197/ The backport patch applied rather cleanly, not considering several offset adjustments. The only part that required an additional change was modifying the place where java lang classes initialization happens in thread.cpp - those classes need to be initialized before 'Jfr::on_create_vm_2()' is called. In order to achieve this I just moved around the whole codeblock related to java lang classes initialization. All tests from jdk_jfr are passing after this patch has been applied. Thanks! -JB- From mbalao at redhat.com Mon Apr 20 20:24:31 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 20 Apr 2020 17:24:31 -0300 Subject: [8u] RFR 8151834: Test SmallPrimeExponentP.java times out intermittently Message-ID: <7201b370-802b-986f-599e-c97dd101313c@redhat.com> Hi, I'd like to request a review for the 8u backport of 8151834 [1]. This backport would bring parity with Oracle's JDK. Risk is minimal as only a test is affected. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8151834/8151834.webrev.jdk8u.jdk.00/ Main line patch does not apply cleanly because: * test/sun/security/mscapi/SmallPrimeExponentP.java * 3rd hook * 8u does not have "@key intermittent" line added by 8151835 [2] [3] * backporting 8151835 is not necessary because "@key intermittent" will be removed by 8151834 (it was added to make clear that the test was intermittently failing, and that's what's being fixed) * "@modules java.base/sun.security.x509" and "java.base/sun.security.tools.keytool" lines were not available in 8u because the test was not modules-aware. It won't be modules-aware anyways but these lines (which will be added by 8151834) are harmless. Testing: * test/sun/security/mscapi/SmallPrimeExponentP.java * Passed (tested on Windows) Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8151834 [2] - https://bugs.openjdk.java.net/browse/JDK-8151835 [3] - http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/927f20de2cc1 From mbalao at redhat.com Tue Apr 21 00:22:37 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 20 Apr 2020 21:22:37 -0300 Subject: [8u] RFR 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() Message-ID: <4920603f-9099-cc2a-1524-fa8a16c7733b@redhat.com> Hi, I'd like to request a review for the 8u backport of 8028591 [1]. This backport is needed for parity with Oracle's JDK. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8028591/8028591.webrev.jdk8u.jdk.00/ Main line patch does not apply cleanly for the following reasons: * src/share/classes/sun/security/util/DerInputStream.java * 8u has several patches after 8028591 already applied: 8059485, 8168714 and 8175251. * Copyright date hook does not apply. Current file copyright date is 2017, newer than 2014 present in the hook. * "if (buffer.read() != DerValue.tag_BitString)" part applied manually (surrounding of the if-true statement with curly brackets) * "int length = getDefiniteLength(buffer);" part applied manually * "length--;" applied manually * "if (validBits < 0) {" part alraedy applied in 8u * "if ((length != 0) && (buffer.read(repn) != length))" part already applied in 8u * After these changes, I verified that "DerInputStream::getUnalignedBitString" looks identical in JDK-8 and JDK-11. * src/share/classes/sun/security/util/ObjectIdentifier.java * 8u has 8168705 already applied * Manually set 'encoding' array length to 'in.getDefiniteLength()'. JDK-8 and JDK-11 look the same. Testing: * java/security/cert/X509Certificate/X509BadCertificate.java * Passed * No regressions found in java/security/cert (50 passed) Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8028591 From sgehwolf at redhat.com Tue Apr 21 10:06:19 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 21 Apr 2020 12:06:19 +0200 Subject: [8u] RFR: 8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE In-Reply-To: References: <9FDC0DA0-10A8-4603-97BF-AB85F4954389@amazon.com> <5b6eb7c0facc02856ef72ca8d941f95ae2c4c041.camel@redhat.com> Message-ID: Hi Andrew, On Tue, 2020-02-18 at 12:25 +0000, Andrew Hughes wrote: > > On 29/11/2019 16:42, Severin Gehwolf wrote: > > On Fri, 2019-11-29 at 16:09 +0000, Hohensee, Paul wrote: > > > Looks good. > > > > Thanks for the review, Paul! > > > > > Separately, how difficult would it be to backport the SA test infra? Should we consider doing it? > > > > I haven't looked at it in detail, but it may be something we should > > consider doing. I doubt it's difficult, but it'll be a chunk of work. > > > > It basically amounts to looking at > > test/hotspot/jtreg/serviceability/sa/ and checking what functionality > > exists in 8u then porting it over. Not sure how much of the other test > > support libraries would need to get backported too. > > > > Thanks, > > Severin > > > > > Thanks, > > > Paul > > > > > Could we not include the tests but ProblemList them for now? I'm very > wary of just dropping tests on the floor, because it means someone else > needs to find and restore them under a separate bug later. You probably > need to knock the 'jtreg' out of the path so it fits into the current > OpenJDK 8u setup. In JDK 8u there is only one ProblemList.txt (in jdk repo). So there is no easy way to problem list a test out of the box. I could remove the @test annotation so that it doesn't run. Is such an approach going to help anybody, though? It'll just not run and would need another bug to get enabled anyway. Of course I can do that if you insist (like in [1]), but it opens up the door for it to bit-rot. Personally, it's either biting the bullet and backporting the entire SA testing infra (and this test). Or not having this test at all. For reference (and adhoc testing), there would be the JDK 11 test to fall back on. I'm strongly for the latter in this case. > JDK-8081037: "serviceability/sa/ tests time out on Windows" (introduces > LingeredApp.java) and JDK-8190198: "SA: Framework for writing 'jhsdb > clhsdb' commands tests and testcases for some of the commands" seem to > be the key issues here, but there are probably others. Right. Do we really need to bring in two more bugs for this small fix in SA code, though? There is a balance to strike. It's hard enough to get fixes in. Even without backporting 2 other dependencies for tests. Getting 8u test code into a state where 11u is will require some significant amount of work across the board :-/ Thanks, Severin [1] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196969/jdk8/02/webrev/ From aph at redhat.com Tue Apr 21 15:06:18 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Apr 2020 16:06:18 +0100 Subject: CFV: New OpenJDK 8u Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes On 3/6/20 8:14 AM, Andrew Hughes wrote: > I hereby nominate Martin Balao [0] for the role of OpenJDK 8u Reviewer. > > Martin has contributed a significant body of patches to OpenJDK [1] [2] > [3]. He is also doing a lot of work behind the scenes in the > vulnerability group for our security updates, which sadly can't be > evidenced publicly. The keen-eyed amongst you may have noticed that I've > already listed him as reviewer on some security patches, so it would be > good to make this status official. > > Votes are due by 21h00 UTC on the 20th of March, 2020. > > Only current OpenJDK 8u Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [5]. > > [0] https://openjdk.java.net/census#mbalao > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [2] > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [3] > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [4] http://openjdk.java.net/census#jdk8u > [5] http://openjdk.java.net/bylaws#three-vote-consensus > -- 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 Apr 21 15:10:29 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 21 Apr 2020 15:10:29 +0000 Subject: RFD: What do we do about programs which set sys_paths to null? In-Reply-To: References: Message-ID: Hi Andrew, what's your status on this? Can we expect you to bring this fix in for 11.0.8 and 8u262? For 11u, we haven't backed out JDK-8231584 yet. So I'd like to either see your fix going in or to have a decision about a backout. Maybe in 11u we can also live with the backport of the upstream patch... I'm not sure. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Haley > Sent: Dienstag, 17. M?rz 2020 17:50 > To: jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: RFD: What do we do about programs which set sys_paths to null? > > [ People who know all this stuff already, please feel free to skip > this introduction. ] > > This is a request for discussion about support for some programs that > do something illegal, not at all supported. I'd like to make this work > as intended by users, even though it's unsupported. Which seems odd, > but I still think we should do it. > > There is a long-established hack (going back about 20 years) which > allows Java programs to set the property "java.library.path" > dynamically. You might need to do this if you're a Java program which > extracts a shared library from a jarfile, puts it in a tmpdir > somewhere, then loads that library. > > People discovered that even though you can set "java.library.path" in > a program, it doesn't work as intended because the property is only > read once at boot time, and it is then cached in the static field > ClassLoader.usr_paths. So, people discovered that if they set > "java.library.path" then set set ClassLoader.sys_paths to null, then > called ClassLoader.loadLibrary, it works. Something like this: > > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField( "sys_paths" ); > userPaths.setAccessible( true ); > userPaths.set( null, null ); > > See the answer here, for example: > https://community.oracle.com/thread/1551225?start=15&tstart=0 > > This worked because ClassLoader.loadLibrary() did this: > > if (sys_paths == null) { > usr_paths = initializePath("java.library.path"); > sys_paths = initializePath("sun.boot.library.path"); > } > > The paths got re-initialized. > > The back-ported fix for "8231584: Deadlock with > ClassLoader.findLibrary and System.loadLibrary call", broke this > hack. The code that lazily re-initializes usr_paths and sys_paths has > gone. However, there was another important change: > ClassLoader.loadLibrary0(), which calls ClassLoader.loadLibrary, is no > longer synchronized, so there may now be concurrent accesses to > ClassLoader.loadLibrary(). > > [ The proposed fix. ] > > I'd like to add this patch to 8u and 11u: > > --- a/src/java.base/share/classes/java/lang/ClassLoader.java Mon Feb 03 > 09:39:39 2020 +0100 > +++ b/src/java.base/share/classes/java/lang/ClassLoader.java Tue Mar 17 > 16:24:10 2020 +0000 > @@ -2562,7 +2562,7 @@ > > // The paths searched for libraries > private static String usr_paths[]; > - private static String sys_paths[]; > + private static volatile String sys_paths[]; > > private static String[] initializePath(String propName) { > String ldPath = System.getProperty(propName, ""); > @@ -2620,6 +2620,10 @@ > boolean isAbsolute) { > ClassLoader loader = > (fromClass == null) ? null : fromClass.getClassLoader(); > + if (sys_paths == null) { > + usr_paths = initializePath("java.library.path"); > + sys_paths = initializePath("sun.boot.library.path"); > + } > assert sys_paths != null : "should be initialized at this point"; > assert usr_paths != null : "should be initialized at this point"; > > This patch does nothing unless sys_paths has been set to null. There > is some slight slowdown because a non-volatile read of sys_paths is > now volatile, but it's IMO insignificant and in any case it's less > than the overhead of the synchronized loadLibrary0(). > > I do not believe that this introduces a race when the user sets > sys_paths to null because > > setProperty("java.library.path") happens before (write volatile sys_paths) > (Program order) > (write volatile sys_paths) synchronizes with (read volatile sys_paths) > (read volatile sys_paths) happens before getProperty("java.lbrary.path") > (Program order) > > If the user sets sys_paths to null before setting "java.library.path" > there is indeed a race and their program might not work, but there > always was a race anyway. > > I think we should do this for 8u and 11u. My justification is that even > though this is an ugly hack, it satisfies a real need and we don't want > to break users' programs in an update. > > What do you think? > > -- > 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 abrygin at azul.com Tue Apr 21 15:17:56 2020 From: abrygin at azul.com (Andrew Brygin) Date: Tue, 21 Apr 2020 18:17:56 +0300 Subject: CFV: New OpenJDK 8u Reviewer: Martin Balao In-Reply-To: References: Message-ID: <5b5f1840-ad32-a9d5-a5fd-c739af930425@azul.com> Vote: yes On 06/03/2020 11:14, Andrew Hughes wrote: > I hereby nominate Martin Balao [0] for the role of OpenJDK 8u Reviewer. > > Martin has contributed a significant body of patches to OpenJDK [1] [2] > [3]. He is also doing a lot of work behind the scenes in the > vulnerability group for our security updates, which sadly can't be > evidenced publicly. The keen-eyed amongst you may have noticed that I've > already listed him as reviewer on some security patches, so it would be > good to make this status official. > > Votes are due by 21h00 UTC on the 20th of March, 2020. > > Only current OpenJDK 8u Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [5]. > > [0] https://openjdk.java.net/census#mbalao > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [2] > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [3] > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [4] http://openjdk.java.net/census#jdk8u > [5] http://openjdk.java.net/bylaws#three-vote-consensus > From aph at redhat.com Tue Apr 21 15:19:55 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Apr 2020 16:19:55 +0100 Subject: RFD: What do we do about programs which set sys_paths to null? In-Reply-To: References: Message-ID: <34fd134b-52ad-a494-3de8-ef9dfdb53644@redhat.com> On 4/21/20 4:10 PM, Langer, Christoph wrote: > what's your status on this? Can we expect you to bring this fix in > for 11.0.8 and 8u262? > > For 11u, we haven't backed out JDK-8231584 yet. So I'd like to > either see your fix going in or to have a decision about a > backout. Maybe in 11u we can also live with the backport of the > upstream patch... I'm not sure. Jeez, I dunno. Every option I can think of is horrible. If I had to guess, I'd say that what we have now is the least bad. 8u continues to work, and the people making the jump to 11 will perhaps find the workarounds they need. But some of the workarounds people use instead of setting sys_paths to null are even worse. Like this one: final Field fieldUsrPaths = ClassLoader.class.getDeclaredField("usr_paths"); fieldUsrPaths.setAccessible(true); fieldUsrPaths.set(System.class.getClassLoader(), usr_paths); This will work in 8u. Maybe we should add a test case to 8u to that we check that both this and the sys_paths-to-null hack keep working. I think that we'd better keep 11 as it is, in the hope that people transitioning to 8 will also transition to fixing the code. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Tue Apr 21 15:40:18 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 21 Apr 2020 17:40:18 +0200 Subject: RFD: What do we do about programs which set sys_paths to null? In-Reply-To: <34fd134b-52ad-a494-3de8-ef9dfdb53644@redhat.com> References: <34fd134b-52ad-a494-3de8-ef9dfdb53644@redhat.com> Message-ID: <47c40da707b7869e449460a52195ace2f95af3dd.camel@redhat.com> On Tue, 2020-04-21 at 16:19 +0100, Andrew Haley wrote: > I think that we'd better keep 11 as it is, in the hope that people > transitioning to 8 will also transition to fixing the code. s/8/11/ +1 Thanks, Severin From aph at redhat.com Tue Apr 21 16:05:10 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Apr 2020 17:05:10 +0100 Subject: RFD: What do we do about programs which set sys_paths to null? In-Reply-To: <47c40da707b7869e449460a52195ace2f95af3dd.camel@redhat.com> References: <34fd134b-52ad-a494-3de8-ef9dfdb53644@redhat.com> <47c40da707b7869e449460a52195ace2f95af3dd.camel@redhat.com> Message-ID: On 4/21/20 4:40 PM, Severin Gehwolf wrote: > On Tue, 2020-04-21 at 16:19 +0100, Andrew Haley wrote: >> I think that we'd better keep 11 as it is, in the hope that people >> transitioning to 8 will also transition to fixing the code. > > s/8/11/ Ah, yes, transitioning to 11. Thx. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mbalao at redhat.com Tue Apr 21 19:49:12 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 21 Apr 2020 16:49:12 -0300 Subject: [8u] RFR 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one Message-ID: <813dd8da-18ed-cdc1-c82a-185f3395890e@redhat.com> Hi, I'd like to request a review for the 8u backport of 8241888 [1]. For further information on why it's desirable to have this in JDK-8, have a look at the 8u-CSR [2] (already approved). Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.jdk8u.jdk.00/ Main line patch does not apply cleanly because we need to propagate java.security change across all java.security-os files. There is nothing OS-specific in 8241888 so this change applies to all of them. Testing: * Tests in sun/security/validator passed. * Executed my own internal test to make sure that both the Security property and the replacement of the System property work fine * Note: no new tests have been proposed as part of the main line patch because it's a trivial change and SecurityProperties functionality (basis for this patch) is already covered by tests. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8241888 [2] - https://bugs.openjdk.java.net/browse/JDK-8243285 From linzang at tencent.com Wed Apr 22 00:24:59 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Wed, 22 Apr 2020 00:24:59 +0000 Subject: RFR 8241285(s): [jdk8u] fail to build hotspot with gcc-8.4.0 with or without COMPILER_WARNINGS_FATAL(Internet mail) In-Reply-To: <0AE35AA4-B3A3-422F-9843-394042D51A10@tencent.com> References: <0FBDE19A-C44F-4460-9CDF-33C380EE406E@tencent.com> <0A79238A-3C56-4797-8A0A-9AFB25F0AD67@tencent.com> <0AE35AA4-B3A3-422F-9843-394042D51A10@tencent.com> Message-ID: Dear All, May I say this patch is ready for push? And may I ask your help to push if it is OK. Thanks. BRs, Lin ?On 2020/4/7, 1:19 PM, "linzang(??)" wrote: Hi Andrew? Do you think http://cr.openjdk.java.net/~lzang/8241285/webrev04/ is ready for push? P.S. it is hard for me to find AIX environment to test, if it is a problem, may I ask your help? Thanks! BRs, Lin On 2020/4/2, 4:49 PM, "linzang(??)" wrote: Dear Andrew, Thanks for your comments, I have uploaded a new patch at http://cr.openjdk.java.net/~lzang/8241285/webrev04/. Would you like to help review it again? BRs, Lin On 2020/4/2, 2:10 AM, "Andrew Hughes" wrote: On 25/03/2020 06:21, linzang(??) wrote: > Hi Paul, > Thanks for your comments, I hava upload a new patch http://cr.openjdk.java.net/~lzang/8241285/webrev03 > > >> Has it been tested on all affected platforms? > No, I only test on macos and linux, since they are the only platforms I could find. > > BRs, > Lin > A few comments: * make/aix/makefiles/xlc.make - This doesn't seem to do anything as WARNINGS_ARE_ERRORS is never used. I suspect EXTRA_WARNINGS should be replaced by WARNINGS_ARE_ERRORS, but it would be good to have some feedback from AIX people. - There seems to be a blank line being added for no reason. * make/solaris/makefiles/adlc.make - Bogus whitespace change to "We need libCstd.so for adlc" line - -errwarn gets replaced by -xwe. I think it would be better to revert this unless there is a good reason to change it. * make/solaris/makefiles/sparcWorks.make - Missing indenting. Should be ok with those issues fixed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alexander.scherbatiy at bell-sw.com Wed Apr 22 05:18:42 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Wed, 22 Apr 2020 08:18:42 +0300 Subject: RFR: 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: Message-ID: The fix looks good to me. Thanks, Alexander. On 17.04.2020 14:10, Laurent Bourg?s wrote: > Could someone review this 8u RFR ? > > PS: next 5 patches will be harder to prepare & review. > > Thanks, > Laurent > > Le mar. 14 avr. 2020 ? 21:20, Laurent Bourg?s > > a ?crit?: > > Please review this 10th patch to backport the Marlin renderer from > jdk9. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8148886 > patch: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/m10.8148886.patch > webrev: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/webrev-8148886.0/ > unshuffled patch: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/unshuffled/8-m10.8148886.patch > > Changes: > - RendererContext.java: fixed few chunks due to missing changes > (Cleaner API can not be used in jdk8) > - fixed Version: to 0.7.3.2 > > Complete diff between unshuffled & proposed patch: > > --- > /home/bourgesl/libs/graphics-rasterizer/wr/marlin-8.10/unshuffled/8-m10.8148886.patch > +++ > /home/bourgesl/libs/graphics-rasterizer/wr/marlin-8.10/m10.8148886.patch > @@ -772,10 +772,10 @@ > ?- ? ? * @see MarlinRenderingEngine#REF_TYPE > ?- ? ? */ > ?- ? ?final Object reference; > - ? ? // Smallest object used as Cleaner's parent reference > - ? ? final Object cleanerObj = new Object(); > ? ? ? // dirty flag indicating an exception occured during > pipeline in pathTo() > -@@ -101,7 +98,7 @@ > + ? ? boolean dirty = false; > + ? ? // dynamic array caches kept using weak reference (low > memory footprint) > +@@ -99,7 +96,7 @@ > ? ? ? /** > ? ? ? ?* Constructor > ? ? ? ?* > @@ -784,7 +784,7 @@ > ? ? ? ?*/ > ? ? ? RendererContext(final String name) { > ? ? ? ? ? if (logCreateContext) { > -@@ -124,20 +121,6 @@ > +@@ -122,20 +119,6 @@ > > ? ? ? ? ? stroker = new Stroker(this); > ? ? ? ? ? dasher = new Dasher(this); > @@ -819,7 +819,7 @@ > > ? public final class Version { > > -- ? ?private static final String version = > "marlin-0.7.3-Unsafe-OpenJDK"; > +- ? ?private static final String version = > "marlin-0.7.2-Unsafe-OpenJDK"; > ?+ ? ?private static final String version = > "marlin-0.7.3.2-Unsafe-OpenJDK"; > > ? ? ? public static String getVersion() { > > Cheers, > Laurent > From aph at redhat.com Wed Apr 22 09:09:42 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Apr 2020 10:09:42 +0100 Subject: [8u] RFR 8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary In-Reply-To: <5e7890f6-2a8c-b551-58b0-02c67df0b544@azul.com> References: <5e7890f6-2a8c-b551-58b0-02c67df0b544@azul.com> Message-ID: On 4/17/20 1:57 PM, Dmitry Cherepanov wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8238225 > original review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064561.html > patch for 11u: > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/128739be82b6 > > webrev for 8u: > http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8238225/webrev.v0/ > > 1) src/macosx/bin/java_md_macosx.c > > This part applies cleanly but needs refinement. The logic has been > expanded to cover 8u-specifics: if the libjli.dylib library was loaded > from MacOS bundle (i.e. realPathToSelf ends with ?/MacOS/libjli.dylib?), > then check if it?s a JDK bundle (private JRE is in ../Home/jre) and then > check if it?s a JRE bundle (public JRE is in ../Home) OK. I don't think we have an active reviewer here with MacOS experience, but it looks reasonable. > 2) testing part > > Given that support for building native part of jtpeg tests is currently > missing in 8u (8072842), new shell script was created and used for > testing.? The java part of the test also includes additional changes > relative to 11u version > (http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8238225/JliLaunchTest.java.diff.v0). > The test fails without a fix and passes from the fixes (for JRE/JDK bundles) OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Apr 22 09:09:47 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Apr 2020 10:09:47 +0100 Subject: [8u] RFR 8235687: Contents/MacOS/libjli.dylib cannot be a symlink In-Reply-To: <84d2d72d-5a32-aca9-dfde-17f04c586713@azul.com> References: <84d2d72d-5a32-aca9-dfde-17f04c586713@azul.com> Message-ID: On 4/17/20 1:53 PM, Dmitry Cherepanov wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8235687 > original review: > https://mail.openjdk.java.net/pipermail/build-dev/2019-December/026452.html > patch for 11u: > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/1859de77ee6c > > webrev for 8u: > http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8235687/webrev.v0/ > The patch doesn?t apply cleanly due to the lack of SetupCopyFiles which > was added with the transition to the modular system 8054834. The patch > directly calls the cp utility, this is consistent with how the images > are copied a few lines above. The second part of the patch (phony target > with recipes modifying files) also does not apply as is. This is an > optional refactoring, and for simplicity, this part has been omitted. Sounds right. > This fix also requires a follow-up fix (8238225), a review request for > which will be sent separately. OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Wed Apr 22 20:45:10 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 22 Apr 2020 20:45:10 +0000 Subject: [8u] RFR: 8143925 : enhancing CounterMode.crypt() for AESCrypt.implEncryptBlock() + 8146581 : Minor corrections to the patch submitted for earlier bug id - 8143925 Message-ID: <0372C512-63CD-4D1D-9C3F-237682477402@amazon.com> I've lost the webrev reference, would you repost please? Thanks, Paul ?On 4/16/20, 10:32 PM, "Martin Balao" wrote: Hey all, Seems like we have a reviewed candidate patch but, as far as I know, there isn't an official approval for the review. I'm not a reviewer so leave it to you @Andrew/@Paul. Thanks, Martin.- From hohensee at amazon.com Wed Apr 22 20:57:26 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 22 Apr 2020 20:57:26 +0000 Subject: RFR 8241285(s): [jdk8u] fail to build hotspot with gcc-8.4.0 with or without COMPILER_WARNINGS_FATAL(Internet mail) Message-ID: <3C208FF1-2615-42F8-8552-06CA860AA2DD@amazon.com> Lgtm. It looks like this is a backport of JDK-8144695, so you need to tag it with jdk8u-fix-request and add a Fix Request (8u) comment. I can push your patch after the issue is tagged with jdk8u-fix-yes. Your original issue was JDK-8241285, but that looks like you wanted to file it against 8u. I'd say that one should be closed, if Andrew agrees. Thanks, Paul ?On 4/21/20, 5:26 PM, "linzang(??)" wrote: Dear All, May I say this patch is ready for push? And may I ask your help to push if it is OK. Thanks. BRs, Lin On 2020/4/7, 1:19 PM, "linzang(??)" wrote: Hi Andrew? Do you think http://cr.openjdk.java.net/~lzang/8241285/webrev04/ is ready for push? P.S. it is hard for me to find AIX environment to test, if it is a problem, may I ask your help? Thanks! BRs, Lin On 2020/4/2, 4:49 PM, "linzang(??)" wrote: Dear Andrew, Thanks for your comments, I have uploaded a new patch at http://cr.openjdk.java.net/~lzang/8241285/webrev04/. Would you like to help review it again? BRs, Lin On 2020/4/2, 2:10 AM, "Andrew Hughes" wrote: On 25/03/2020 06:21, linzang(??) wrote: > Hi Paul, > Thanks for your comments, I hava upload a new patch http://cr.openjdk.java.net/~lzang/8241285/webrev03 > > >> Has it been tested on all affected platforms? > No, I only test on macos and linux, since they are the only platforms I could find. > > BRs, > Lin > A few comments: * make/aix/makefiles/xlc.make - This doesn't seem to do anything as WARNINGS_ARE_ERRORS is never used. I suspect EXTRA_WARNINGS should be replaced by WARNINGS_ARE_ERRORS, but it would be good to have some feedback from AIX people. - There seems to be a blank line being added for no reason. * make/solaris/makefiles/adlc.make - Bogus whitespace change to "We need libCstd.so for adlc" line - -errwarn gets replaced by -xwe. I think it would be better to revert this unless there is a good reason to change it. * make/solaris/makefiles/sparcWorks.make - Missing indenting. Should be ok with those issues fixed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mbalao at redhat.com Wed Apr 22 21:44:37 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 22 Apr 2020 18:44:37 -0300 Subject: [8u] RFR: 8143925 : enhancing CounterMode.crypt() for AESCrypt.implEncryptBlock() + 8146581 : Minor corrections to the patch submitted for earlier bug id - 8143925 In-Reply-To: <0372C512-63CD-4D1D-9C3F-237682477402@amazon.com> References: <0372C512-63CD-4D1D-9C3F-237682477402@amazon.com> Message-ID: <25513b16-adc5-3a5c-aca7-3db3a03e9a2a@redhat.com> Hi Paul, On 4/22/20 5:45 PM, Hohensee, Paul wrote: > I've lost the webrev reference, would you repost please? > If I'm right, the latest webrev is: * http://cr.openjdk.java.net/~akozlov/8143925/hotspot.01/ * http://cr.openjdk.java.net/~akozlov/8143925/jdk.00/ @Anton can you please confirm? Thanks, Martin.- From linzang at tencent.com Thu Apr 23 02:59:35 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Thu, 23 Apr 2020 02:59:35 +0000 Subject: RFR 8241285(s): [jdk8u] fail to build hotspot with gcc-8.4.0 with or without COMPILER_WARNINGS_FATAL(Internet mail) In-Reply-To: <3C208FF1-2615-42F8-8552-06CA860AA2DD@amazon.com> References: <3C208FF1-2615-42F8-8552-06CA860AA2DD@amazon.com> Message-ID: <6F54111B-957F-4605-B170-7AF26D8B298B@tencent.com> Hi Paul, Andrew, Thanks for your help . I have updated JDK-8144695 and closed my original issue JDK-8241285. BRs, Lin ?On 2020/4/23, 4:57 AM, "Hohensee, Paul" wrote: Lgtm. It looks like this is a backport of JDK-8144695, so you need to tag it with jdk8u-fix-request and add a Fix Request (8u) comment. I can push your patch after the issue is tagged with jdk8u-fix-yes. Your original issue was JDK-8241285, but that looks like you wanted to file it against 8u. I'd say that one should be closed, if Andrew agrees. Thanks, Paul On 4/21/20, 5:26 PM, "linzang(??)" wrote: Dear All, May I say this patch is ready for push? And may I ask your help to push if it is OK. Thanks. BRs, Lin On 2020/4/7, 1:19 PM, "linzang(??)" wrote: Hi Andrew? Do you think http://cr.openjdk.java.net/~lzang/8241285/webrev04/ is ready for push? P.S. it is hard for me to find AIX environment to test, if it is a problem, may I ask your help? Thanks! BRs, Lin On 2020/4/2, 4:49 PM, "linzang(??)" wrote: Dear Andrew, Thanks for your comments, I have uploaded a new patch at http://cr.openjdk.java.net/~lzang/8241285/webrev04/. Would you like to help review it again? BRs, Lin On 2020/4/2, 2:10 AM, "Andrew Hughes" wrote: On 25/03/2020 06:21, linzang(??) wrote: > Hi Paul, > Thanks for your comments, I hava upload a new patch http://cr.openjdk.java.net/~lzang/8241285/webrev03 > > >> Has it been tested on all affected platforms? > No, I only test on macos and linux, since they are the only platforms I could find. > > BRs, > Lin > A few comments: * make/aix/makefiles/xlc.make - This doesn't seem to do anything as WARNINGS_ARE_ERRORS is never used. I suspect EXTRA_WARNINGS should be replaced by WARNINGS_ARE_ERRORS, but it would be good to have some feedback from AIX people. - There seems to be a blank line being added for no reason. * make/solaris/makefiles/adlc.make - Bogus whitespace change to "We need libCstd.so for adlc" line - -errwarn gets replaced by -xwe. I think it would be better to revert this unless there is a good reason to change it. * make/solaris/makefiles/sparcWorks.make - Missing indenting. Should be ok with those issues fixed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From akozlov at azul.com Thu Apr 23 04:28:48 2020 From: akozlov at azul.com (Anton Kozlov) Date: Thu, 23 Apr 2020 07:28:48 +0300 Subject: [8u] RFR: 8143925 : enhancing CounterMode.crypt() for AESCrypt.implEncryptBlock() + 8146581 : Minor corrections to the patch submitted for earlier bug id - 8143925 In-Reply-To: <25513b16-adc5-3a5c-aca7-3db3a03e9a2a@redhat.com> References: <0372C512-63CD-4D1D-9C3F-237682477402@amazon.com> <25513b16-adc5-3a5c-aca7-3db3a03e9a2a@redhat.com> Message-ID: <80ad8b0b-8aea-533d-7dbb-f7f052e75396@azul.com> Hi All, On 23.04.2020 00:44, Martin Balao wrote: > On 4/22/20 5:45 PM, Hohensee, Paul wrote: >> I've lost the webrev reference, would you repost please? >> > > If I'm right, the latest webrev is: > > * http://cr.openjdk.java.net/~akozlov/8143925/hotspot.01/ > * http://cr.openjdk.java.net/~akozlov/8143925/jdk.00/ > > @Anton can you please confirm? > That's correct, proposed in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-January/010988.html I'm sorry it slipped out of my attention, discussion threads are https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010843.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-January/010958.html Thanks, Anton From linzang at tencent.com Thu Apr 23 05:52:06 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Thu, 23 Apr 2020 05:52:06 +0000 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Message-ID: <87677EE3-CA02-4C29-B261-C13B25BB630B@tencent.com> Dear All, May I ask your help to review the tiny patch about backport of 8241638? Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Patch: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev01/ BRs, Lin From hohensee at amazon.com Thu Apr 23 16:50:51 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 23 Apr 2020 16:50:51 +0000 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Message-ID: This looks like a clean backport, except for eliminating some whitespace in java.c. The whitespace elimination might not show up if webrev is ignoring whitespace changes. Anyway, being a clean backport, there's no need for an on-list review, you can just say it's clean in the Fix Request comment, along with an estimate of how risky the backport is. Looks straightforward and low risk to me. Thanks, Paul ?On 4/22/20, 10:56 PM, "jdk8u-dev on behalf of linzang(??)" wrote: Dear All, May I ask your help to review the tiny patch about backport of 8241638? Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Patch: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev01/ BRs, Lin From xxinliu at amazon.com Thu Apr 23 23:19:43 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 23 Apr 2020 23:19:43 +0000 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: <87677EE3-CA02-4C29-B261-C13B25BB630B@tencent.com> References: <87677EE3-CA02-4C29-B261-C13B25BB630B@tencent.com> Message-ID: <6AD583C2-249E-49C5-B6F9-3FB6F9F2D00D@amazon.com> Hi, Zang, I am now a reviewer. I just offer helps to eyeball trivial issues. The patch is almost a clean backport. As long as you declare the patch can apply to jdk8u cleanly, I think you can skip the formal review. 1. the only difference from original patch is java_md_macosx.m->java_md_macosx.c. I think it's the same file in different names. 2. I think you should place a whitespace in the copyrights section of java_md_solinux.h. "* Copyright (c) 2013,[ ]2020 Oracle and/or its affiliates. All rights reserved." Thanks, --lx ?On 4/22/20, 10:56 PM, "jdk8u-dev on behalf of linzang(??)" 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. Dear All, May I ask your help to review the tiny patch about backport of 8241638? Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Patch: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev01/ BRs, Lin From xxinliu at amazon.com Thu Apr 23 23:32:22 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 23 Apr 2020 23:32:22 +0000 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: <6AD583C2-249E-49C5-B6F9-3FB6F9F2D00D@amazon.com> References: <87677EE3-CA02-4C29-B261-C13B25BB630B@tencent.com> <6AD583C2-249E-49C5-B6F9-3FB6F9F2D00D@amazon.com> Message-ID: Oh, no! sorry I sent misinformation here. I am *NOT* a reviewer. I just offer helps to eyeball trivial issues. --lx ?On 4/23/20, 4:23 PM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Zang, I am now a reviewer. I just offer helps to eyeball trivial issues. The patch is almost a clean backport. As long as you declare the patch can apply to jdk8u cleanly, I think you can skip the formal review. 1. the only difference from original patch is java_md_macosx.m->java_md_macosx.c. I think it's the same file in different names. 2. I think you should place a whitespace in the copyrights section of java_md_solinux.h. "* Copyright (c) 2013,[ ]2020 Oracle and/or its affiliates. All rights reserved." Thanks, --lx On 4/22/20, 10:56 PM, "jdk8u-dev on behalf of linzang(??)" 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. Dear All, May I ask your help to review the tiny patch about backport of 8241638? Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Patch: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev01/ BRs, Lin From linzang at tencent.com Fri Apr 24 02:32:45 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Fri, 24 Apr 2020 02:32:45 +0000 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: References: <87677EE3-CA02-4C29-B261-C13B25BB630B@tencent.com> <6AD583C2-249E-49C5-B6F9-3FB6F9F2D00D@amazon.com> Message-ID: <4E5115AB-BB66-4289-A54E-5C52AFD636A0@tencent.com> Hi Paul and Xin, Thanks for your guidance, I have uploaded a webrev02 that fixing the copyrights issue Xin pointed out. And updated the comments at https://bugs.openjdk.java.net/browse/JDK-8241638. BRs, Lin ?On 2020/4/24, 7:32 AM, "Liu, Xin" wrote: Oh, no! sorry I sent misinformation here. I am *NOT* a reviewer. I just offer helps to eyeball trivial issues. --lx On 4/23/20, 4:23 PM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Zang, I am now a reviewer. I just offer helps to eyeball trivial issues. The patch is almost a clean backport. As long as you declare the patch can apply to jdk8u cleanly, I think you can skip the formal review. 1. the only difference from original patch is java_md_macosx.m->java_md_macosx.c. I think it's the same file in different names. 2. I think you should place a whitespace in the copyrights section of java_md_solinux.h. "* Copyright (c) 2013,[ ]2020 Oracle and/or its affiliates. All rights reserved." Thanks, --lx On 4/22/20, 10:56 PM, "jdk8u-dev on behalf of linzang(??)" 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. Dear All, May I ask your help to review the tiny patch about backport of 8241638? Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Patch: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev01/ BRs, Lin From xxinliu at amazon.com Fri Apr 24 08:35:58 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Fri, 24 Apr 2020 08:35:58 +0000 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <4E5115AB-BB66-4289-A54E-5C52AFD636A0@tencent.com> References: <87677EE3-CA02-4C29-B261-C13B25BB630B@tencent.com> <6AD583C2-249E-49C5-B6F9-3FB6F9F2D00D@amazon.com> <4E5115AB-BB66-4289-A54E-5C52AFD636A0@tencent.com> Message-ID: <5A2250E7-7CCC-4A46-A9F0-847F5D00F62B@amazon.com> LGTM. Thanks. ?On 4/23/20, 7:33 PM, "linzang(??)" 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 Paul and Xin, Thanks for your guidance, I have uploaded a webrev02 that fixing the copyrights issue Xin pointed out. And updated the comments at https://bugs.openjdk.java.net/browse/JDK-8241638. BRs, Lin On 2020/4/24, 7:32 AM, "Liu, Xin" wrote: Oh, no! sorry I sent misinformation here. I am *NOT* a reviewer. I just offer helps to eyeball trivial issues. --lx On 4/23/20, 4:23 PM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Zang, I am now a reviewer. I just offer helps to eyeball trivial issues. The patch is almost a clean backport. As long as you declare the patch can apply to jdk8u cleanly, I think you can skip the formal review. 1. the only difference from original patch is java_md_macosx.m->java_md_macosx.c. I think it's the same file in different names. 2. I think you should place a whitespace in the copyrights section of java_md_solinux.h. "* Copyright (c) 2013,[ ]2020 Oracle and/or its affiliates. All rights reserved." Thanks, --lx On 4/22/20, 10:56 PM, "jdk8u-dev on behalf of linzang(??)" 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. Dear All, May I ask your help to review the tiny patch about backport of 8241638? Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Patch: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev01/ BRs, Lin From jaroslav.bachorik at datadoghq.com Fri Apr 24 09:53:10 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 24 Apr 2020 11:53:10 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: Gentle ping? On Mon, Apr 20, 2020 at 4:02 PM Jaroslav Bachor?k < jaroslav.bachorik at datadoghq.com> wrote: > Please review the following backport > > JIRA. : https://bugs.openjdk.java.net/browse/JDK-8233197 > Webrev. : http://cr.openjdk.java.net/~jbachorik/8233197/ > > The backport patch applied rather cleanly, not considering several offset > adjustments. > The only part that required an additional change was modifying the place > where java lang classes initialization happens in thread.cpp - those > classes need to be initialized before 'Jfr::on_create_vm_2()' is called. In > order to achieve this I just moved around the whole codeblock related to > java lang classes initialization. > > All tests from jdk_jfr are passing after this patch has been applied. > > Thanks! > > -JB- > From jaroslav.bachorik at datadoghq.com Fri Apr 24 10:17:01 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 24 Apr 2020 12:17:01 +0200 Subject: Fwd: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: Resending again in plain text to make the filters pass. ---------- Forwarded message --------- From: Jaroslav Bachor?k Date: Mon, Apr 20, 2020 at 4:02 PM Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing To: jdk8u-dev Please review the following backport JIRA. : https://bugs.openjdk.java.net/browse/JDK-8233197 Webrev. : http://cr.openjdk.java.net/~jbachorik/8233197/ The backport patch applied rather cleanly, not considering several offset adjustments. The only part that required an additional change was modifying the place where java lang classes initialization happens in thread.cpp - those classes need to be initialized before 'Jfr::on_create_vm_2()' is called. In order to achieve this I just moved around the whole codeblock related to java lang classes initialization. All tests from jdk_jfr are passing after this patch has been applied. Thanks! -JB- From hohensee at amazon.com Fri Apr 24 12:51:35 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 24 Apr 2020 12:51:35 +0000 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) Message-ID: <50DB97FE-1E39-4B84-B302-AD832843E871@amazon.com> Thanks for noticing the copyright issue, Xin. Lgtm too. Paul ?On 4/24/20, 1:36 AM, "Liu, Xin" wrote: LGTM. Thanks. On 4/23/20, 7:33 PM, "linzang(??)" wrote: Hi Paul and Xin, Thanks for your guidance, I have uploaded a webrev02 that fixing the copyrights issue Xin pointed out. And updated the comments at https://bugs.openjdk.java.net/browse/JDK-8241638. BRs, Lin On 2020/4/24, 7:32 AM, "Liu, Xin" wrote: Oh, no! sorry I sent misinformation here. I am *NOT* a reviewer. I just offer helps to eyeball trivial issues. --lx On 4/23/20, 4:23 PM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Zang, I am now a reviewer. I just offer helps to eyeball trivial issues. The patch is almost a clean backport. As long as you declare the patch can apply to jdk8u cleanly, I think you can skip the formal review. 1. the only difference from original patch is java_md_macosx.m->java_md_macosx.c. I think it's the same file in different names. 2. I think you should place a whitespace in the copyrights section of java_md_solinux.h. "* Copyright (c) 2013,[ ]2020 Oracle and/or its affiliates. All rights reserved." Thanks, --lx On 4/22/20, 10:56 PM, "jdk8u-dev on behalf of linzang(??)" 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. Dear All, May I ask your help to review the tiny patch about backport of 8241638? Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Patch: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev01/ BRs, Lin From aoqi at loongson.cn Sun Apr 26 02:17:42 2020 From: aoqi at loongson.cn (Ao Qi) Date: Sun, 26 Apr 2020 10:17:42 +0800 Subject: [8u] RFR: 8243474: [TESTBUG] removed three tests of 0 bytes Message-ID: Hi all, This is a 8u-specific bug. jdk/test/lib/testlibrary/jdk/testlibrary/IOUtils.java, test/jdk/java/awt/FontClass/GlyphRotationTest.java and test/jdk/java/awt/font/Rotate/RotatedFontMetricsTest.java were 0 bytes and added into jdk8u by JDK-8237175, JDK-8225334 and JDK-8235559 respectively. The corresponding three tests were already backported properly. I think we should remove these empty files. JBS: https://bugs.openjdk.java.net/browse/JDK-8243474 webrev: http://cr.openjdk.java.net/~aoqi/8243474/webrev.00/ (Should I file three bugs or one?) Thanks, Ao Qi From denghui.ddh at alibaba-inc.com Sun Apr 26 13:50:38 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Sun, 26 Apr 2020 21:50:38 +0800 Subject: =?UTF-8?B?Wzh1XSBSRlIgODIyNTc5NzogW2JhY2twb3J0XSBPbGRPYmplY3RTYW1wbGUgZXZlbnQgY3Jl?= =?UTF-8?B?YXRlcyB1bmV4cGVjdGVkIGFtb3VudCBvZiBjaGVja3BvaW50IGRhdGE=?= Message-ID: <64ccf973-bb1f-420d-bea2-9254e0375602.denghui.ddh@alibaba-inc.com> Hi team, Please review the following backport. Original Bug: https://bugs.openjdk.java.net/browse/JDK-8225797 Original patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2a13c6785ad2 Webrev: http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/ Some code has been commented out because those facilities(e.g. Module and Package) is not supported in 8u, so the original patch can not apply cleanly. Matter of fact, the backport is mostly manual. I put all reject files in http://cr.openjdk.java.net/~ddong/8225797/rej/ All tests from jdk_jfr are passing after this patch has been applied. Cheers, Denghui Dong From sergei.tsypanov at yandex.ru Mon Apr 27 06:37:26 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Mon, 27 Apr 2020 08:37:26 +0200 Subject: [PATCH] bakcporting of some trivial enhancements done for later JDKs Message-ID: <717541587967894@mail.yandex.ru> Hello, during recent years I've contributed some very simple patches into JDK which I guess can be back-ported into JDK8u https://bugs.openjdk.java.net/browse/JDK-8196207 Inefficient ArrayList.subList().toArray() https://bugs.openjdk.java.net/browse/JDK-8199800 Optimize Boolean.parseBoolean(String) https://bugs.openjdk.java.net/browse/JDK-8240094 Optimize empty substring handling https://bugs.openjdk.java.net/browse/JDK-8241649 Optimize Character.toString Could this changes be encorporated into JDK8u? If yes then I will prepare separate patches for each ticket. Regards, Sergey Tsypanov From aoqi at loongson.cn Mon Apr 27 10:50:30 2020 From: aoqi at loongson.cn (Ao Qi) Date: Mon, 27 Apr 2020 18:50:30 +0800 Subject: [8u] RFR (T): 8242883: Incomplete backport of JDK-8078268: backport test part In-Reply-To: References: Message-ID: Hi, Could someone help to sponsor this patch? Thanks, Ao Qi On Fri, Apr 17, 2020 at 1:35 AM Ao Qi wrote: > > Thank you, Paul. Added the label jdk8u-fix-request. > > Cheers, > Ao Qi > > On Thu, Apr 16, 2020 at 8:54 PM Hohensee, Paul wrote: > > > > Lgtm. > > > > Paul > > > > ?On 4/15/20, 11:49 AM, "jdk8u-dev on behalf of Ao Qi" wrote: > > > > Hi all, > > > > This is a 8u-specific bug. JDK-8078268 was backported to jdk8u, but > > the backport is incomplete. An empty test were backported to jdk8u. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242883 > > webrev: http://cr.openjdk.java.net/~aoqi/8242883/webrev.00/ > > > > before fix: > > $ jtreg -dir:/home/aoqi/work/jdk8u-dev/jdk/test > > javax/swing/text/html/parser/Parser/8078268/bug8078268.java > > Error: Not a test or directory containing tests: > > javax/swing/text/html/parser/Parser/8078268/bug8078268.java > > > > after fix: > > $ jtreg -dir:/home/aoqi/work/jdk8u-dev/jdk/test > > javax/swing/text/html/parser/Parser/8078268/bug8078268.java > > Test results: passed: 1 > > > > Thanks, > > Ao Qi > > > > From aph at redhat.com Mon Apr 27 11:32:01 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Apr 2020 12:32:01 +0100 Subject: [PATCH] bakcporting of some trivial enhancements done for later JDKs In-Reply-To: <717541587967894@mail.yandex.ru> References: <717541587967894@mail.yandex.ru> Message-ID: <19971b60-1fad-af57-3a34-e262cb164b43@redhat.com> On 4/27/20 7:37 AM, ?????? ??????? wrote: > https://bugs.openjdk.java.net/browse/JDK-8196207 Inefficient ArrayList.subList().toArray() > https://bugs.openjdk.java.net/browse/JDK-8199800 Optimize Boolean.parseBoolean(String) > https://bugs.openjdk.java.net/browse/JDK-8240094 Optimize empty substring handling > https://bugs.openjdk.java.net/browse/JDK-8241649 Optimize Character.toString > > Could this changes be encorporated into JDK8u? I'm thinking not. While these are useful enhancements, JDK 8u is a long- term maintenance release and we need to concentrate on stability. Thanks anyway, -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Mon Apr 27 11:35:33 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 27 Apr 2020 13:35:33 +0200 Subject: [PATCH] bakcporting of some trivial enhancements done for later JDKs In-Reply-To: <717541587967894@mail.yandex.ru> References: <717541587967894@mail.yandex.ru> Message-ID: Hi Sergey, On Mon, 2020-04-27 at 08:37 +0200, ?????? ??????? wrote: > Hello, > > during recent years I've contributed some very simple patches into > JDK which I guess can be back-ported into JDK8u Perhaps. We are somewhat wary about performance enhancements. Is there a really good justification to get them into a maintenance release? They're not without risk. > https://bugs.openjdk.java.net/browse/JDK-8196207 Inefficient ArrayList.subList().toArray() > https://bugs.openjdk.java.net/browse/JDK-8199800 Optimize Boolean.parseBoolean(String) I see these two are in 11. > https://bugs.openjdk.java.net/browse/JDK-8240094 Optimize empty substring handling > https://bugs.openjdk.java.net/browse/JDK-8241649 Optimize Character.toString > > Could this changes be encorporated into JDK8u? If yes then I will prepare separate patches for each ticket. Have these been proposed for JDK 11u updates? If not, we should start with that. Thanks, Severin From sgehwolf at redhat.com Mon Apr 27 11:44:06 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 27 Apr 2020 13:44:06 +0200 Subject: [8u] RFR: 8243474: [TESTBUG] removed three tests of 0 bytes In-Reply-To: References: Message-ID: Hi, On Sun, 2020-04-26 at 10:17 +0800, Ao Qi wrote: > Hi all, > > This is a 8u-specific bug. > jdk/test/lib/testlibrary/jdk/testlibrary/IOUtils.java, > test/jdk/java/awt/FontClass/GlyphRotationTest.java and > test/jdk/java/awt/font/Rotate/RotatedFontMetricsTest.java were 0 bytes > and added into jdk8u by JDK-8237175, JDK-8225334 and JDK-8235559 > respectively. The corresponding three tests were already backported > properly. I think we should remove these empty files. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8243474 > webrev: http://cr.openjdk.java.net/~aoqi/8243474/webrev.00/ Looks reasonable. OK. > (Should I file three bugs or one?) One bug report is fine. Thanks, Severin From yan at azul.com Mon Apr 27 12:16:35 2020 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 27 Apr 2020 15:16:35 +0300 Subject: [8u] RFR (S) 8046274: Removing dependency on jakarta-regexp In-Reply-To: <01a43b4b-c5a1-dc6e-5d17-d0f5fcd2a0ec@redhat.com> References: <01a43b4b-c5a1-dc6e-5d17-d0f5fcd2a0ec@redhat.com> Message-ID: Looks good to me. --yan On 27.03.2020 14:23, Aleksey Shipilev wrote: > Original change: > https://bugs.openjdk.java.net/browse/JDK-8046274 > https://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/bfc9ec1a816b > > Patch does not apply cleanly to 8u, because paths are different. I have removed > src/com/sun/org/apache/regexp/ by hand. Reapplied THIRD_PARTY_README by hand. InstructionFinder.java > change applies after reshuffling. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8046274/webrev.8u.01/ > > Testing: java/xml tests, tier1 > From gnu.andrew at redhat.com Mon Apr 27 15:17:18 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 27 Apr 2020 16:17:18 +0100 Subject: [8u] RFR (T): 8242883: Incomplete backport of JDK-8078268: backport test part In-Reply-To: References: Message-ID: <24b23310-2c88-30ef-2fc3-e0ca297aba0c@redhat.com> On 27/04/2020 11:50, Ao Qi wrote: > Hi, > > Could someone help to sponsor this patch? > > Thanks, > Ao Qi > Sure. I'll push this for you. Thanks for catching this. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From felix.yang at huawei.com Tue Apr 28 08:42:11 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 28 Apr 2020 08:42:11 +0000 Subject: Help push 8u-backport of 8240576 Message-ID: Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8240576 8u-backport webrev: http://cr.openjdk.java.net/~fyang/8240576-8u-backport/ It has already been labeled jdk8u-fix-yes. Patch still applies to 8u-dev repo and jtreg tested. Could someone help push it please? Thanks, Felix From denghui.ddh at alibaba-inc.com Tue Apr 28 09:43:07 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 28 Apr 2020 17:43:07 +0800 Subject: =?UTF-8?B?UmU6IEhlbHAgcHVzaCA4dS1iYWNrcG9ydCBvZiA4MjQwNTc2?= In-Reply-To: References: Message-ID: Pushed. Denghui Dong ------------------------------------------------------------------ From:Yangfei (Felix) Send Time:2020?4?28?(???) 16:46 To:jdk8u-dev at openjdk.java.net Subject:Help push 8u-backport of 8240576 Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8240576 8u-backport webrev: http://cr.openjdk.java.net/~fyang/8240576-8u-backport/ It has already been labeled jdk8u-fix-yes. Patch still applies to 8u-dev repo and jtreg tested. Could someone help push it please? Thanks, Felix From felix.yang at huawei.com Tue Apr 28 10:51:02 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 28 Apr 2020 10:51:02 +0000 Subject: Help push 8u-backport of 8240576 In-Reply-To: References: Message-ID: Hi, Thanks for doing that. ? Felix From: Denghui Dong [mailto:denghui.ddh at alibaba-inc.com] Sent: Tuesday, April 28, 2020 5:43 PM To: jdk8u-dev at openjdk.java.net; Yangfei (Felix) Subject: Re: Help push 8u-backport of 8240576 Pushed. Denghui Dong Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8240576 8u-backport webrev: http://cr.openjdk.java.net/~fyang/8240576-8u-backport/ It has already been labeled jdk8u-fix-yes. Patch still applies to 8u-dev repo and jtreg tested. Could someone help push it please? Thanks, Felix From linzang at tencent.com Tue Apr 28 15:24:18 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Tue, 28 Apr 2020 15:24:18 +0000 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <50DB97FE-1E39-4B84-B302-AD832843E871@amazon.com> References: <50DB97FE-1E39-4B84-B302-AD832843E871@amazon.com> Message-ID: <66D21DA6-0F63-4F10-9548-D07820924AE5@tencent.com> Dear Paul and Xin, Thanks for your review, sorry that I forgot to mention this is actually a backport combined two issues, 8241638, and 8243539. It is better to make two separate patches to make it clear, I will do it ASAP. And then ask your help to review. Issues: https://bugs.openjdk.java.net/browse/JDK-8241638 https://bugs.openjdk.java.net/browse/JDK-8243539 Thanks! BRs, Lin ?On 2020/4/24, 8:52 PM, "Hohensee, Paul" wrote: Thanks for noticing the copyright issue, Xin. Lgtm too. Paul On 4/24/20, 1:36 AM, "Liu, Xin" wrote: LGTM. Thanks. On 4/23/20, 7:33 PM, "linzang(??)" wrote: Hi Paul and Xin, Thanks for your guidance, I have uploaded a webrev02 that fixing the copyrights issue Xin pointed out. And updated the comments at https://bugs.openjdk.java.net/browse/JDK-8241638. BRs, Lin On 2020/4/24, 7:32 AM, "Liu, Xin" wrote: Oh, no! sorry I sent misinformation here. I am *NOT* a reviewer. I just offer helps to eyeball trivial issues. --lx On 4/23/20, 4:23 PM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Zang, I am now a reviewer. I just offer helps to eyeball trivial issues. The patch is almost a clean backport. As long as you declare the patch can apply to jdk8u cleanly, I think you can skip the formal review. 1. the only difference from original patch is java_md_macosx.m->java_md_macosx.c. I think it's the same file in different names. 2. I think you should place a whitespace in the copyrights section of java_md_solinux.h. "* Copyright (c) 2013,[ ]2020 Oracle and/or its affiliates. All rights reserved." Thanks, --lx On 4/22/20, 10:56 PM, "jdk8u-dev on behalf of linzang(??)" 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. Dear All, May I ask your help to review the tiny patch about backport of 8241638? Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Patch: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev01/ BRs, Lin From linzang at tencent.com Tue Apr 28 16:14:02 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Tue, 28 Apr 2020 16:14:02 +0000 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <66D21DA6-0F63-4F10-9548-D07820924AE5@tencent.com> References: <50DB97FE-1E39-4B84-B302-AD832843E871@amazon.com> <66D21DA6-0F63-4F10-9548-D07820924AE5@tencent.com> Message-ID: <4EA5C01E-D93E-4B9D-85CA-8CAF8AE9438D@tencent.com> Hi Paul and Xin, Here are the latest patches: Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Webrev: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev03/ Issue: https://bugs.openjdk.java.net/browse/JDK-8243539 Webrev: http://cr.openjdk.java.net/~lzang/8243539/webrev8u/ Thanks! BRs, Lin ?On 2020/4/28, 11:24 PM, "linzang(??)" wrote: Dear Paul and Xin, Thanks for your review, sorry that I forgot to mention this is actually a backport combined two issues, 8241638, and 8243539. It is better to make two separate patches to make it clear, I will do it ASAP. And then ask your help to review. Issues: https://bugs.openjdk.java.net/browse/JDK-8241638 https://bugs.openjdk.java.net/browse/JDK-8243539 Thanks! BRs, Lin On 2020/4/24, 8:52 PM, "Hohensee, Paul" wrote: Thanks for noticing the copyright issue, Xin. Lgtm too. Paul On 4/24/20, 1:36 AM, "Liu, Xin" wrote: LGTM. Thanks. On 4/23/20, 7:33 PM, "linzang(??)" wrote: Hi Paul and Xin, Thanks for your guidance, I have uploaded a webrev02 that fixing the copyrights issue Xin pointed out. And updated the comments at https://bugs.openjdk.java.net/browse/JDK-8241638. BRs, Lin On 2020/4/24, 7:32 AM, "Liu, Xin" wrote: Oh, no! sorry I sent misinformation here. I am *NOT* a reviewer. I just offer helps to eyeball trivial issues. --lx On 4/23/20, 4:23 PM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Zang, I am now a reviewer. I just offer helps to eyeball trivial issues. The patch is almost a clean backport. As long as you declare the patch can apply to jdk8u cleanly, I think you can skip the formal review. 1. the only difference from original patch is java_md_macosx.m->java_md_macosx.c. I think it's the same file in different names. 2. I think you should place a whitespace in the copyrights section of java_md_solinux.h. "* Copyright (c) 2013,[ ]2020 Oracle and/or its affiliates. All rights reserved." Thanks, --lx On 4/22/20, 10:56 PM, "jdk8u-dev on behalf of linzang(??)" 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. Dear All, May I ask your help to review the tiny patch about backport of 8241638? Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Patch: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev01/ BRs, Lin From hohensee at amazon.com Tue Apr 28 17:07:02 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 28 Apr 2020 17:07:02 +0000 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) Message-ID: <9A05DCC9-8AA9-43AF-91D6-1744D1793D0D@amazon.com> Looks good. Paul ?On 4/28/20, 9:14 AM, "linzang(??)" wrote: Hi Paul and Xin, Here are the latest patches: Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Webrev: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev03/ Issue: https://bugs.openjdk.java.net/browse/JDK-8243539 Webrev: http://cr.openjdk.java.net/~lzang/8243539/webrev8u/ Thanks! BRs, Lin On 2020/4/28, 11:24 PM, "linzang(??)" wrote: Dear Paul and Xin, Thanks for your review, sorry that I forgot to mention this is actually a backport combined two issues, 8241638, and 8243539. It is better to make two separate patches to make it clear, I will do it ASAP. And then ask your help to review. Issues: https://bugs.openjdk.java.net/browse/JDK-8241638 https://bugs.openjdk.java.net/browse/JDK-8243539 Thanks! BRs, Lin On 2020/4/24, 8:52 PM, "Hohensee, Paul" wrote: Thanks for noticing the copyright issue, Xin. Lgtm too. Paul On 4/24/20, 1:36 AM, "Liu, Xin" wrote: LGTM. Thanks. On 4/23/20, 7:33 PM, "linzang(??)" wrote: Hi Paul and Xin, Thanks for your guidance, I have uploaded a webrev02 that fixing the copyrights issue Xin pointed out. And updated the comments at https://bugs.openjdk.java.net/browse/JDK-8241638. BRs, Lin On 2020/4/24, 7:32 AM, "Liu, Xin" wrote: Oh, no! sorry I sent misinformation here. I am *NOT* a reviewer. I just offer helps to eyeball trivial issues. --lx On 4/23/20, 4:23 PM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Zang, I am now a reviewer. I just offer helps to eyeball trivial issues. The patch is almost a clean backport. As long as you declare the patch can apply to jdk8u cleanly, I think you can skip the formal review. 1. the only difference from original patch is java_md_macosx.m->java_md_macosx.c. I think it's the same file in different names. 2. I think you should place a whitespace in the copyrights section of java_md_solinux.h. "* Copyright (c) 2013,[ ]2020 Oracle and/or its affiliates. All rights reserved." Thanks, --lx On 4/22/20, 10:56 PM, "jdk8u-dev on behalf of linzang(??)" 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. Dear All, May I ask your help to review the tiny patch about backport of 8241638? Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Patch: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev01/ BRs, Lin From sergei.tsypanov at yandex.ru Wed Apr 29 06:39:57 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Wed, 29 Apr 2020 08:39:57 +0200 Subject: [PATCH] bakcporting of some trivial enhancements done for later JDKs In-Reply-To: References: <717541587967894@mail.yandex.ru> Message-ID: <79731588142239@mail.yandex.ru> Hello, is there a mailing list where I can forward this message to, in order to backport patches to JDK11? Regards, Sergey Tsypanov 27.04.2020, 13:35, "Severin Gehwolf" : > Hi Sergey, > > On Mon, 2020-04-27 at 08:37 +0200, ?????? ??????? wrote: >> ?Hello, >> >> ?during recent years I've contributed some very simple patches into >> ?JDK which I guess can be back-ported into JDK8u > > Perhaps. We are somewhat wary about performance enhancements. Is there > a really good justification to get them into a maintenance release? > They're not without risk. > >> ?https://bugs.openjdk.java.net/browse/JDK-8196207 Inefficient ArrayList.subList().toArray() >> ?https://bugs.openjdk.java.net/browse/JDK-8199800 Optimize Boolean.parseBoolean(String) > > I see these two are in 11. > >> ?https://bugs.openjdk.java.net/browse/JDK-8240094 Optimize empty substring handling >> ?https://bugs.openjdk.java.net/browse/JDK-8241649 Optimize Character.toString >> >> ?Could this changes be encorporated into JDK8u? If yes then I will prepare separate patches for each ticket. > > Have these been proposed for JDK 11u updates? If not, we should start > with that. > > Thanks, > Severin From jaroslav.bachorik at datadoghq.com Wed Apr 29 10:46:39 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Wed, 29 Apr 2020 12:46:39 +0200 Subject: [8u] RFR 8225797: [backport] OldObjectSample event creates unexpected amount of checkpoint data In-Reply-To: <64ccf973-bb1f-420d-bea2-9254e0375602.denghui.ddh@alibaba-inc.com> References: <64ccf973-bb1f-420d-bea2-9254e0375602.denghui.ddh@alibaba-inc.com> Message-ID: Hi Denghui, I have validated that the backport contains the changes from the original changeset and that the conflicts were resolved correctly. I have only two minor comments: 1. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp.sdiff.html L113 and L116 - perhaps the commented out asserts can be removed completely? 2. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.cpp.sdiff.html L158 - `module_lock` - > `package_lock`? Cheers, -JB- On Sun, Apr 26, 2020 at 3:52 PM Denghui Dong wrote: > > Hi team, > Please review the following backport. > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8225797 > Original patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2a13c6785ad2 > Webrev: http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/ > > Some code has been commented out because those facilities(e.g. Module and Package) is not supported in 8u, > so the original patch can not apply cleanly. Matter of fact, the backport is mostly manual. > I put all reject files in http://cr.openjdk.java.net/~ddong/8225797/rej/ > > All tests from jdk_jfr are passing after this patch has been applied. > > Cheers, > Denghui Dong From gnu.andrew at redhat.com Wed Apr 29 14:42:23 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 29 Apr 2020 15:42:23 +0100 Subject: Result: New OpenJDK 8 Updates Reviewer: Andrew Dinn Message-ID: <5b39f24a-a3d8-522c-39c4-589bc8525055@redhat.com> Voting for Andrew Dinn [0] is now closed. Yes: 9 Veto: 0 Abstain: 0 Invalid: 0 Turnout: 9% (9/100) According to the Bylaws definition of Three-Vote Consensus [1], this is sufficient to approve the nomination. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011319.html [1] http://openjdk.java.net/bylaws#three-vote-consensus -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Apr 29 14:52:17 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 29 Apr 2020 15:52:17 +0100 Subject: Result: New OpenJDK 8 Updates Reviewer: Martin Balao Message-ID: Voting for Martin Balao [0] is now closed. Yes: 9 Veto: 0 Abstain: 0 Invalid: 3* Turnout: 9% (9/100) According to the Bylaws definition of Three-Vote Consensus [1], this is sufficient to approve the nomination. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011321.html [1] http://openjdk.java.net/bylaws#three-vote-consensus [*] The votes from Andrew Haley & Andrew Brygin were received after the deadline of 2020-03-20. The vote from Andrew Dinn was invalid as he wasn't an 8u reviewer at the time of voting. But thanks for your participation :-) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Apr 29 14:56:49 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 29 Apr 2020 15:56:49 +0100 Subject: Result: New OpenJDK 8 Updates Committer: Elliott Baron Message-ID: Voting for Elliott Baron [0] is now closed. Yes: 9 Veto: 0 Abstain: 0 Turnout: 4% (9/225) According to the Bylaws definition of Lazy Consensus [1], this is sufficient to approve the nomination. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011317.html [1] https://openjdk.java.net/bylaws#lazy-consensus -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Apr 29 15:09:32 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 29 Apr 2020 16:09:32 +0100 Subject: Result: New OpenJDK 8 Updates Committer: Yangfei (Felix) Message-ID: <74bb519f-95b2-fd7a-4483-68b681c0d7a3@redhat.com> Voting for Yangfei (Felix/fyang) [0] is now closed. Yes: 8 Veto: 0 Abstain: 0 Turnout: 3.6% (8/225) According to the Bylaws definition of Lazy Consensus [1], this is sufficient to approve the nomination. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011318.html [1] https://openjdk.java.net/bylaws#lazy-consensus -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Apr 30 02:00:17 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 30 Apr 2020 03:00:17 +0100 Subject: RFR: [8u] JDK-8035949: Remove unused macro USE_SELECT and clean up Unix version of net_util_md.{c,h} Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8035949 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8035949/webrev.01/ This is the first of two backports to cleanup unused #include directives and dead code in the networking stack. The initial motivation was to resolve build breakage due to the upcoming release of glibc 2.32, which removes the long deprecated sys/sysctl.h [0]. Rather than just fixing that with an 8u-specific patch, backporting these two fixes will bring the code closer to that in 9+ (both were completed during OpenJDK 9 development, so are well tested) and avoid the need to maintain ageing and largely unused code. The backport is largely clean, once paths are shuffled. The differences lie in net_util_md.{c,h}, mainly because 8u does not contain JDK-8034174, "Remove use of JVM_* functions from java.net code", but does contain JDK-8032808, "Support Solaris SO_FLOW_SLA socket option", which came later (and is in 9+ as part of JDK-8036979: "Support java.net.SocketOption<> in java.net socket types"). The backport sync the placement of the changes from 8032808 with their placement in 9u, following 8035949. A few other changes are also already present in 8u, and solaris_close.c does not exist; the equivalent change is to remove the aliasing of NET_Select to select in net_util_md.h. I've tested this on x86_64 GNU/Linux and will be doing builds on other GNU/Linux architectures over the next few days. Testing on Solaris & AIX would be much appreciated, to make sure we don't break those platforms. [0] https://sourceware.org/git/?p=glibc.git;a=patch;h=076f09afbac1aa57756faa7a8feadb7936a724e4 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From mark.reinhold at oracle.com Thu Apr 30 18:16:14 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Apr 2020 11:16:14 -0700 Subject: Result: New OpenJDK 8 Updates Reviewer: Andrew Dinn In-Reply-To: <5b39f24a-a3d8-522c-39c4-589bc8525055@redhat.com> References: <5b39f24a-a3d8-522c-39c4-589bc8525055@redhat.com> Message-ID: <20200430111614.663710891@eggemoggin.niobe.net> 2020/4/29 7:42:23 -0700, gnu.andrew at redhat.com: > Voting for Andrew Dinn [0] is now closed. > > Yes: 9 > Veto: 0 > Abstain: 0 > Invalid: 0 > > Turnout: 9% (9/100) > > According to the Bylaws definition of Three-Vote Consensus [1], this is > sufficient to approve the nomination. So recorded. - Mark