From gnu.andrew at redhat.com Tue Dec 1 04:56:11 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 1 Dec 2020 04:56:11 +0000 Subject: [8u] RFR: 8250636: iso8601_time returns incorrect offset part on MacOS In-Reply-To: <518A30D9-C051-4335-B79D-F2E1205EC7CB@azul.com> References: <96C47B35-C6CC-4C5C-854F-147925366FD0@azul.com> <20201130171619.GD28274@rincewind> <518A30D9-C051-4335-B79D-F2E1205EC7CB@azul.com> Message-ID: <20201201045611.GA255760@rincewind> On 17:36 Mon 30 Nov , Sergey Nazarkin wrote: > Hi Andrew, > > thanks for the review. Updated version with copyright update is here > https://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8250636.1/ > > > - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. > > + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved. > > > Sergey Nazarkin > Thanks, that looks better. Approved & pushed with 8251365. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Dec 1 05:25:13 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 1 Dec 2020 05:25:13 +0000 Subject: [8u] RFF:8256671: Incorrect assignment operator used in guarantee() in genCollectedHeap In-Reply-To: <03A93828-2CAF-41AB-8776-345AB84B5E68@tencent.com> References: <5B1D372C-FF83-4676-9A30-1C01DA6B995D@tencent.com> <03A93828-2CAF-41AB-8776-345AB84B5E68@tencent.com> Message-ID: <20201201052513.GB255760@rincewind> On 07:45 Wed 25 Nov , linzang(??) wrote: > > OK, thanks. Looks like the buggy code was gone by the time of JDK 9, > > so there's no need for a backport here. > > Thanks Andrew! > Sorry that I missed your reply. > Do I need to get more review about this webrev? Or may I ask your help to push it? > > BRs, > Lin > Approved and pushed. For the record, JDK-8076267: "Remove n_gens()" completely removed the line in OpenJDK 9. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Dec 1 06:26:52 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 1 Dec 2020 06:26:52 +0000 Subject: [IMPORTANT] 8u & 8u-dev now CLOSED FOR PUSHES for rampdown Message-ID: <20201201062652.GB348316@rincewind> Hi all, We are now ramping down for the release of OpenJDK 8u282 in January. I have tagged 8u-dev locally and will promote b04 once build testing is complete. jdk8u/jdk8u will be closed until this promotion is completion. After that, requests for regression fixes for 8u282 can be made using the jdk8u-critical-request label. jdk8u/jdk8u-dev will be closed until hgupdater is switched over to use openjdk8u292. Please await further e-mail before pushing changes. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Tue Dec 1 10:28:54 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Dec 2020 11:28:54 +0100 Subject: [8u] RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: <1215CA79-E87A-422B-882F-81D7A98FD862@amazon.com> References: <1215CA79-E87A-422B-882F-81D7A98FD862@amazon.com> Message-ID: <11582570f9e5febadb5adeb58c392b5ca1569bcd.camel@redhat.com> Hi Paul, On Thu, 2020-11-26 at 13:53 +0000, Hohensee, Paul wrote: > I'd add the copyright update for 8u, and file an 11u-only issue to fix the copyright dates in the 11u backport. This webrev brings all copyright lines to 2019. Only src/os/linux/vm/os Container_linux.hpp needed the actual update. All others had 2019 already. https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/jdk8/02/ Thoughts? Thanks, Severin > ?On 11/26/20, 2:49 AM, "Severin Gehwolf" wrote: > > On Tue, 2020-11-24 at 23:00 +0000, Hohensee, Paul wrote: > > All files need a copyright update to 2019. Otherwise, lgtm. > > Thanks for the review! > > Note that neither the original change[1] nor the JDK 11u backport[2] > has the copyright year update. I'm not sure we should do that in the 8u > backport now. Thoughts? > > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/1c242c2d037f > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2173ddc0b886 > > > On 11/4/20, 1:05 AM, "jdk8u-dev on behalf of Severin Gehwolf" wrote: > > > > Hi, > > > > Please review this OpenJDK 8u port of JDK-8217338, which is a) an > > Oracle JDK parity patch, b) a dependency of further container detection > > backports like JDK-8232207 and JDK-8227006. The JDK 11 patch does not > > apply cleanly. Changes I've done: > > > > * Split of the patch for hotspot and jdk repositories. JDK 11u is a > > unified repo. > > * JDK 11u has UL, which is being translated to PrintContainerInfo > > diagnostic flag in 8u. > > * Some differences in context with respect to import statements in > > Java code for Metrics > > > > Otherwise the patch is the same. We've had this patch JDK 11 since > > 11.0.7 and hasn't caused any problems as far as I'm aware. As mentioned > > previously, it makes getting further fixes (JDK-8232207, JDK-8227006) > > easier and less risky. Therefore, I'd like to get it included for > > 8u282. The risk for this backport should be acceptable given the > > circumstances. With that said, it's Linux-only. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217338 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/jdk8/01/ > > > > Testing: Container tests on Linux x86_64 (cgroup v1). Manual test[1]. > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8217338?focusedCommentId=14378230&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14378230 > > > > > > From jdowland at redhat.com Tue Dec 1 11:42:46 2020 From: jdowland at redhat.com (Jonathan Dowland) Date: Tue, 1 Dec 2020 11:42:46 +0000 Subject: [8u] RFR: 8038723: Openup some PrinterJob tests Message-ID: <20201201114246.knfgmbmzdw66nppr@qusp> Hi, Please review this OpenJDK 8u port of JDK-8038723. This is a dependency of JDK-6949753 which came up in the Backports scan, but discussing with others might be independently interesting. The patch introduces approx. 65 previously closed tests. The majority of these are new file additions. The exception is test/java/awt/print/PrinterJob/PrintTextTest.java. In jdk9, this file was touched twice: introduced by 8038723: Openup some PrinterJob tests modified by 8132890: Text overlapping on dot matrix printers. In jdk8u, 8132890 was already backported. The backporter introduced a different version of the test which has not been committed to jdk9 or any later version. That version of the test was an applet, and had a corresponding PrintTextTest.html. For this backport, I have committed the JDK9 version of the test and removed the (now superfluous) PrintTextTest.html. Please be sure to look at the changeset as well the webrev, since a binary file test/java/awt/print/PrinterJob/CustomFont/A.ttf is added which is not properly represented in the webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8038723 webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-8038723/webrev.00/ Testing: PrintTextTest is a manual-only test that requires the tester to print out pages and compare the output to on-screen. I've run this test once, it worked and the output looks correct. Note: If this is accepted, the follow-up backport JDK-6949753 deletes the test java/awt/print/PageFormat/PDialogTest.java. Thanks, -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat From akashche at redhat.com Tue Dec 1 12:59:19 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 1 Dec 2020 12:59:19 +0000 Subject: [8u] RFR: 8198411: [TEST_BUG] Two java2d tests are unstable in mach5 Message-ID: Hi, Please review the backport of JDK-8198411 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8198411 Original change: https://hg.openjdk.java.net/jdk/jdk/raw-rev/af2ed7605f8c 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8198411/webrev.00/ For 8u changes to ProblemList are excluded and paths are changed. Testing: checked that changed tests pass on Linux and Windows. -- -Alex From hohensee at amazon.com Tue Dec 1 14:46:09 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 1 Dec 2020 14:46:09 +0000 Subject: [8u] RFR: 8217338: [Containers] Improve systemd slice memory limit support Message-ID: <4F591C1F-AD42-49FD-A0ED-95D390ACC941@amazon.com> Looks good! Thanks, Paul ?On 12/1/20, 2:29 AM, "Severin Gehwolf" wrote: Hi Paul, On Thu, 2020-11-26 at 13:53 +0000, Hohensee, Paul wrote: > I'd add the copyright update for 8u, and file an 11u-only issue to fix the copyright dates in the 11u backport. This webrev brings all copyright lines to 2019. Only src/os/linux/vm/os Container_linux.hpp needed the actual update. All others had 2019 already. https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/jdk8/02/ Thoughts? Thanks, Severin > On 11/26/20, 2:49 AM, "Severin Gehwolf" wrote: > > On Tue, 2020-11-24 at 23:00 +0000, Hohensee, Paul wrote: > > All files need a copyright update to 2019. Otherwise, lgtm. > > Thanks for the review! > > Note that neither the original change[1] nor the JDK 11u backport[2] > has the copyright year update. I'm not sure we should do that in the 8u > backport now. Thoughts? > > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/1c242c2d037f > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2173ddc0b886 > > > On 11/4/20, 1:05 AM, "jdk8u-dev on behalf of Severin Gehwolf" wrote: > > > > Hi, > > > > Please review this OpenJDK 8u port of JDK-8217338, which is a) an > > Oracle JDK parity patch, b) a dependency of further container detection > > backports like JDK-8232207 and JDK-8227006. The JDK 11 patch does not > > apply cleanly. Changes I've done: > > > > * Split of the patch for hotspot and jdk repositories. JDK 11u is a > > unified repo. > > * JDK 11u has UL, which is being translated to PrintContainerInfo > > diagnostic flag in 8u. > > * Some differences in context with respect to import statements in > > Java code for Metrics > > > > Otherwise the patch is the same. We've had this patch JDK 11 since > > 11.0.7 and hasn't caused any problems as far as I'm aware. As mentioned > > previously, it makes getting further fixes (JDK-8232207, JDK-8227006) > > easier and less risky. Therefore, I'd like to get it included for > > 8u282. The risk for this backport should be acceptable given the > > circumstances. With that said, it's Linux-only. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217338 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/jdk8/01/ > > > > Testing: Container tests on Linux x86_64 (cgroup v1). Manual test[1]. > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8217338?focusedCommentId=14378230&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14378230 > > > > > > From gnu.andrew at redhat.com Tue Dec 1 16:08:25 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 1 Dec 2020 16:08:25 +0000 Subject: [8u] RFR: 8038723: Openup some PrinterJob tests In-Reply-To: <20201201114246.knfgmbmzdw66nppr@qusp> References: <20201201114246.knfgmbmzdw66nppr@qusp> Message-ID: <20201201160825.GA362425@rincewind> On 11:42 Tue 01 Dec , Jonathan Dowland wrote: > Hi, > > Please review this OpenJDK 8u port of JDK-8038723. This is a dependency > of JDK-6949753 which came up in the Backports scan, but discussing with > others might be independently interesting. > > The patch introduces approx. 65 previously closed tests. The majority of > these are new file additions. The exception is > test/java/awt/print/PrinterJob/PrintTextTest.java. > > In jdk9, this file was touched twice: > introduced by 8038723: Openup some PrinterJob tests > modified by 8132890: Text overlapping on dot matrix printers. > > In jdk8u, 8132890 was already backported. The backporter introduced a > different version of the test which has not been committed to jdk9 or > any later version. That version of the test was an applet, and had a > corresponding PrintTextTest.html. For this backport, I have committed > the JDK9 version of the test and removed the (now superfluous) > PrintTextTest.html. > > Please be sure to look at the changeset as well the webrev, since a > binary file test/java/awt/print/PrinterJob/CustomFont/A.ttf is added > which is not properly represented in the webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8038723 > webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-8038723/webrev.00/ > > Testing: PrintTextTest is a manual-only test that requires the tester to > print out pages and compare the output to on-screen. I've run this test > once, it worked and the output looks correct. > > Note: If this is accepted, the follow-up backport JDK-6949753 deletes > the test java/awt/print/PageFormat/PDialogTest.java. > > > Thanks, > > -- > ???? Jonathan Dowland > Senior Software Engineer, OpenJDK, Red Hat > Looks like you beat me to upstreaming this one :) http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/a5d77ccaa809 Our patches are the same, with the bonus that you remembered to remove the now redundant HTML file. From my own review of PrintTextTest.java, I agree the 9u one is the definitive one. Incidentally, you can use your new OpenJDK username as the commit username now, rather than relying on Contributed-by. Please flag for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alexander.scherbatiy at bell-sw.com Tue Dec 1 19:14:14 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Tue, 1 Dec 2020 22:14:14 +0300 Subject: [8u] RFR 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR Message-ID: <56edd471-f7d7-6a23-1554-e99d51ecf940@bell-sw.com> ?Hello, Could you review the backport of P2 JDK-8233228 to 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8233228 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a17295342862 8u webrev: http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.00 8233228 backport to 8u (compared to 11u): *?sun.security.ec.ECParameters -> sun.security.util.ECParameters *?sun.security.ec.NamedCurve?? -> sun.security.util.NamedCurve *?sun.security.ec.CurveDB????? -> sun.security.util.CurveDB * security/tools/keytool fixed context difference * DisabledAlgorithmConstraints.java fixed context difference * Manual merge in ConstraintsParameters.java (XECKey, NamedParameterSpec are not available in 8u). * CurveDB.SPLIT_PATTERN, CurveDB.getSupportedCurves() made public * NamedCurve class, getName(), getObjectId() made public * ECParameters.getAlgorithmParameters() made public * files java.security- are separate in each platform, applied identical changes in all The are no new failures in hotspot and compact3 tests comparing to the build without the fix. Thanks, Alexander. From hohensee at amazon.com Tue Dec 1 22:19:36 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 1 Dec 2020 22:19:36 +0000 Subject: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c In-Reply-To: <15BCA980-031B-4443-AE70-2690EBCF7D57@amazon.com> References: <15BCA980-031B-4443-AE70-2690EBCF7D57@amazon.com> Message-ID: <0E55CCC9-F5A6-4B75-806D-06AD127C4439@amazon.com> Redirect to jdk8u-dev. ?-----Original Message----- From: "Hohensee, Paul" Date: Tuesday, December 1, 2020 at 2:18 PM To: "Guo, James" , "jdk-updates-dev at openjdk.java.net" Subject: Re: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c Lgtm. Maintainers, please consider this as a candidate for an 8u282 critical fix. Thanks, Paul -----Original Message----- From: jdk-updates-dev on behalf of "Guo, James" Date: Tuesday, December 1, 2020 at 12:33 PM To: "jdk-updates-dev at openjdk.java.net" Subject: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8254982 https://git.openjdk.java.net/jdk/commit/55a0cad8 Although the original patch applies cleanly to 8u, yet the original patch doesn?t include updates of tzdata under test/sun/util/calendar/zi/tzdata/, which are removed after 11u. 8u webrev: http://cr.openjdk.java.net/~cverghese/webrevs/8254982-jdk8u/ Testing: x86_64 build, affected tests, tier1 Thanks, -James From gnu.andrew at redhat.com Wed Dec 2 04:53:01 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 2 Dec 2020 04:53:01 +0000 Subject: [IMPORTANT] 8u & 8u-dev now OPEN Message-ID: <20201202045301.GA387637@rincewind> 8u is now open for 8u282 regression fixes with the label jdk8u-critical-yes. 8u-dev is now open for 8u292 fixes with the label jdk8u-fix-yes. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Dec 2 05:22:27 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 2 Dec 2020 05:22:27 +0000 Subject: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c In-Reply-To: <0E55CCC9-F5A6-4B75-806D-06AD127C4439@amazon.com> References: <15BCA980-031B-4443-AE70-2690EBCF7D57@amazon.com> <0E55CCC9-F5A6-4B75-806D-06AD127C4439@amazon.com> Message-ID: <20201202052227.GB387637@rincewind> On 22:19 Tue 01 Dec , Hohensee, Paul wrote: > Redirect to jdk8u-dev. > > ?-----Original Message----- > From: "Hohensee, Paul" > Date: Tuesday, December 1, 2020 at 2:18 PM > To: "Guo, James" , "jdk-updates-dev at openjdk.java.net" > Subject: Re: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c > > Lgtm. Maintainers, please consider this as a candidate for an 8u282 critical fix. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on behalf of "Guo, James" > Date: Tuesday, December 1, 2020 at 12:33 PM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c > > Hi, > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8254982 > https://git.openjdk.java.net/jdk/commit/55a0cad8 > > Although the original patch applies cleanly to 8u, yet the original patch doesn?t include > updates of tzdata under test/sun/util/calendar/zi/tzdata/, which are removed after 11u. > > 8u webrev: > http://cr.openjdk.java.net/~cverghese/webrevs/8254982-jdk8u/ > > Testing: x86_64 build, affected tests, tier1 > > Thanks, > -James > > > > This looks incorrect. The formatting is being changed on the 2015 Fiji line in australasia and a line is removed from the copy of the europe file in the test tree. Corrected version: https://cr.openjdk.java.net/~andrew/openjdk8/8254982/webrev.01/ Note that, although it doesn't affect this particular change, tzdata for 8u needs to be converted to rearguard format, not simply backported. I was planning to do tzdata2020c & tzdata2020d in one patch for this reason, but I guess we can go with this one alone now. Please review the revised webrev and then we can push. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Dec 2 05:34:30 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 2 Dec 2020 05:34:30 +0000 Subject: [8u] RFR 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR In-Reply-To: <56edd471-f7d7-6a23-1554-e99d51ecf940@bell-sw.com> References: <56edd471-f7d7-6a23-1554-e99d51ecf940@bell-sw.com> Message-ID: <20201202053430.GC387637@rincewind> On 22:14 Tue 01 Dec , Alexander Scherbatiy wrote: > > ?Hello, > > Could you review the backport of P2 JDK-8233228 to 8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233228 > 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a17295342862 > 8u webrev: http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.00 > > > 8233228 backport to 8u (compared to 11u): > *?sun.security.ec.ECParameters -> sun.security.util.ECParameters > *?sun.security.ec.NamedCurve?? -> sun.security.util.NamedCurve > *?sun.security.ec.CurveDB????? -> sun.security.util.CurveDB > * security/tools/keytool fixed context difference > * DisabledAlgorithmConstraints.java fixed context difference > * Manual merge in ConstraintsParameters.java (XECKey, NamedParameterSpec are > not available in 8u). > * CurveDB.SPLIT_PATTERN, CurveDB.getSupportedCurves() made public > * NamedCurve class, getName(), getObjectId() made public > * ECParameters.getAlgorithmParameters() made public > * files java.security- are separate in each platform, applied > identical changes in all > Why is it necessary to move the package these files are in? If we really need to do this, it should be done as a separate backport of JDK-8035166, but I'm not yet convinced this is necessary, given the disruption it will cause to code that relies on the code being in the current locations. > The are no new failures in hotspot and compact3 tests comparing to the build > without the fix. I'm not sure how HotSpot tests would relate to a crypto change. What crypto tests were run? > > Thanks, > Alexander. > Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Dec 2 05:39:15 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 2 Dec 2020 05:39:15 +0000 Subject: OpenJDK 8u282-b03 EA Released Message-ID: <20201202053915.GA391430@rincewind> I've made available an early access source bundle for 8u282, based on the tag jdk8u282-b03: https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b03-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b03-ea.tar.xz.sig This is signed by our new 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: ac72aff6a3deec97b5ddc7a967e0f576fc0ce176070cc9a65f748bb5d4f885f9 openjdk8u282-b03-ea.tar.xz 196347fbeedbb062d798aa91a30e35a7d6a45e0207aa5a0944a05b956edf701a openjdk8u282-b03-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b03-ea.sha256 Changes in 8u282-b03: - JDK-8008657: JSpinner setComponentOrientation doesn't affect on text orientation - JDK-8041592: [TEST_BUG] Move 42 AWT hw/lw mixing tests to jdk - JDK-8163161: [PIT][TEST_BUG] increase timeout in javax/swing/plaf/nimbus/8057791/bug8057791.java - JDK-8168292: [TESTBUG] [macosx] Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X - JDK-8168682: jdk/test/java/lang/ClassLoader/forNameLeak/ClassForNameLeak.java fails with -Xcomp - JDK-8223108: Test java/awt/EventQueue/NonComponentSourcePost.java is unstable - JDK-8255603: Memory/Performance regression after JDK-8210985 Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Dec 2 05:40:38 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 2 Dec 2020 05:40:38 +0000 Subject: OpenJDK 8u282-b04 EA Released Message-ID: <20201202054038.GA391751@rincewind> I've made available an early access source bundle for 8u282, based on the tag jdk8u282-b04: https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b04-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b04-ea.tar.xz.sig This is signed by our new 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: 7fd72637fbd8d785ad8c1365bf63ca2fad4da0c00bbed932d9e0b12f5f655f15 openjdk8u282-b04-ea.tar.xz 9e83b0388384dbbf101b694fd119626109ef7f32668713dbc52bce16ce659ee7 openjdk8u282-b04-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b04-ea.sha256 Changes in 8u282-b04: - JDK-8022535: [TEST BUG] javax/swing/text/html/parser/Test8017492.java fails - JDK-8043126: move awt automated functional tests from AWT_Events/Lw and AWT_Events/AWT to OpenJDK repository - JDK-8043131: Move ShapedAndTranslucentWindows and GC functional AWT tests to regression tree - JDK-8043899: compiler/5091921/Test7005594.java fails if specified -Xmx is less than 1600m - JDK-8044157: [TEST_BUG] Improve recently submitted AWT_Mixing tests - JDK-8044172: [TEST_BUG] Move regtests for 4523758 and AltPlusNumberKeyCombinationsTest to jdk - JDK-8044429: move awt automated tests for AWT_Modality to OpenJDK repository - JDK-8044765: Move functional tests AWT_SystemTray/Automated to openjdk repository - JDK-8046221: [TEST_BUG] Cleanup datatransfer tests - JDK-8047180: Move functional tests AWT_Headless/Automated to OpenJDK repository - JDK-8047367: move awt automated tests from AWT_Modality to OpenJDK repository - part 2 - JDK-8048246: Move AWT_DnD/Clipboard/Automated functional tests to OpenJDK - JDK-8049617: move awt automated tests from AWT_Modality to OpenJDK repository - part 3 - JDK-8049694: Migrate functional AWT_DesktopProperties/Automated tests to OpenJDK - JDK-8050885: move awt automated tests from AWT_Modality to OpenJDK repository - part 4 - JDK-8051440: move tests about maximizing undecorated to OpenJDK - JDK-8052012: move awt automated tests from AWT_Modality to OpenJDK repository - part 5 - JDK-8052408: Move AWT_BAT functional tests to OpenJDK (3 of 3) - JDK-8053657: [TEST_BUG] move some 5 tests related to undecorated Frame/JFrame to JDK - JDK-8054143: move awt automated tests from AWT_Modality to OpenJDK repository - part 6 - JDK-8054358: move awt automated tests from AWT_Modality to OpenJDK repository - part 7 - JDK-8054359: move awt automated tests from AWT_Modality to OpenJDK repository - part 8 - JDK-8055360: Move the rest part of AWT ShapedAndTranslucent tests to OpenJDK - JDK-8055664: move 14 tests about setLocationRelativeTo to jdk - JDK-8055836: move awt tests from AWT_Modality to OpenJDK repository - part 9 - JDK-8057694: move awt tests from AWT_Modality to OpenJDK repository - part 10 - JDK-8058805: [TEST_BUG]Test java/awt/TrayIcon/SecurityCheck/NoPermissionTest/NoPermissionTest.java fails - JDK-8063102: Change open awt regression tests to avoid sun.awt.SunToolkit.realSync, part 1 - JDK-8063104: Change open awt regression tests to avoid sun.awt.SunToolkit.realSync, part 2 - JDK-8063106: Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 1 - JDK-8063107: Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 2 - JDK-8064573: [TEST_BUG] javax/swing/text/AbstractDocument/6968363/Test6968363.java is asocial pressing VK_LEFT and not releasing - JDK-8064575: [TEST_BUG] javax/swing/JEditorPane/6917744/bug6917744.java 100 times press keys and never releases - JDK-8064809: [TEST_BUG] javax/swing/JComboBox/4199622/bug4199622.java contains a lot of keyPress and not a single keyRelease - JDK-8067441: Some tests fails with error: cannot find symbol getSystemMnemonicKeyCodes() - JDK-8068228: Test closed/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest fails with GTKLookAndFeel - JDK-8068275: Some tests failed after JDK-8063104 - JDK-8069211: (zipfs) ZipFileSystem creates corrupted zip if entry output stream gets closed more than once - JDK-8074807: Fix some tests unnecessary using internal API - JDK-8076315: move 4 manual functional swing tests to regression suite - JDK-8130772: Util.hitMnemonics does not work: getSystemMnemonicKeyCodes() returns ALT_MASK rather than VK_ALT - JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants - JDK-8156803: Turn StressLCM/StressGCM flags to diagnostic - JDK-8160761: [TESTBUG] Several compiler tests fail with product bits - JDK-8166015: [PIT][TEST_BUG] stray character in java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java - JDK-8166583: Add oopDesc::klass_or_null_acquire() - JDK-8166663: Simplify oops_on_card_seq_iterate_careful - JDK-8166862: CMS needs klass_or_null_acquire - JDK-8179083: Uninitialized notifier in Java Monitor Wait tracing event - JDK-8205507: jdk/javax/xml/crypto/dsig/GenerationTests.java timed out - JDK-8217362: Emergency dump does not work when disk=false is set - JDK-8217766: Container Support doesn't work for some Join Controllers combinations - JDK-8219013: Update Apache Santuario (XML Signature) to version 2.1.3 - JDK-8219562: Line of code in osContainer_linux.cpp L102 appears unreachable - JDK-8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp - JDK-8221340: [TESTBUG] TestCgroupMetrics.java fails after fix for JDK-8219562 - JDK-8221710: [TESTBUG] more configurable parameters for docker testing - JDK-8227006: [linux] Runtime.availableProcessors execution time increased by factor of 100 - JDK-8229868: Update Apache Santuario TPRM version - JDK-8233548: Update CUP to v0.11b - JDK-8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker - JDK-8246648: issue with OperatingSystemImpl getFreeSwapSpaceSize in docker after 8242480 - JDK-8249846: Change of behavior after JDK-8237117: Better ForkJoinPool behavior - JDK-8250636: iso8601_time returns incorrect offset part on MacOS - JDK-8251365: Build failure on AIX after 8250636 - JDK-8255717: Fix JFR crash in WriteObjectSampleStacktrace due to object not initialized - JDK-8256618: Zero: Linux x86_32 build still fails - JDK-8256671: Incorrect assignment operator used in guarantee() in genCollectedHeap - JDK-8256752: 8252395 incorrect copy rule for macos .dSYM folder - JDK-8257397: [TESTBUG] test/lib/containers/docker/Common.java refers to -Xlog:os+container=trace -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Wed Dec 2 12:31:31 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 02 Dec 2020 13:31:31 +0100 Subject: [8u] RFR 8255226: (tz) Upgrade time-zone data to tzdata2020d In-Reply-To: References: Message-ID: <8929db5f80cc8633264d997a630e7ef724ddaad8.camel@redhat.com> Hi, On Tue, 2020-12-01 at 20:29 +0000, Guo, James wrote: > Hi, > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8255226 > https://github.com/openjdk/jdk/commit/b65ff60a > > Although the original patch applies cleanly to 8u, yet the original patch doesn?t include > updates of tzdata under test/sun/util/calendar/zi/tzdata/, which are removed after 11u. > > 8u webrev: > http://cr.openjdk.java.net/~cverghese/webrevs/8255226-jdk8u/ > > Testing: x86_64 build, affected tests, tier1 This should be going to jdk8u-dev. Adding that and dropping jdk- updates-dev. James, please work with Andrew Hughes to get this reviewed. He mentioned that he'd already worked on this too. Thanks, Severin From sgehwolf at redhat.com Wed Dec 2 13:31:28 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 02 Dec 2020 14:31:28 +0100 Subject: [8u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible Message-ID: Hi! Please review this test-only backport for OpenJDK 8u. I'd like to backport this as it contains a test fix for TestCgroupMetrics and TestSystemMetrics which occasionally can fail for equal values for CPU usages (before/after). See changes in MetricsTester.java. On its own it's useful too since it also makes the tests work with an alternative container engine: podman. Since this mostly changes test library code it's duplicated for jdk tests in the jdk repo and hotspot tests in the hotspot repo. As such the original JDK 11 patch doesn't apply cleanly. There is also no jtreg-ext directory in 8u, so I've dropped the changes to VMProps.java. It's not applicable. Some context changes in DockerTestUtils.java due to JDK-8222888 and JDK-8222299, both not in 8u and no plan to backport them at this point. Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/jdk8/ Testing: Container tests on Linux x86_64 using docker/podman. Thoughts? Thanks, Severin From jhuttana at redhat.com Wed Dec 2 14:57:35 2020 From: jhuttana at redhat.com (Jayashree Huttanagoudar) Date: Wed, 2 Dec 2020 20:27:35 +0530 Subject: OpenJDK 8u282-b03 EA Released In-Reply-To: <20201202053915.GA391430@rincewind> References: <20201202053915.GA391430@rincewind> Message-ID: Hi All, On Wed, Dec 2, 2020 at 11:10 AM Andrew Hughes wrote: > I've made available an early access source bundle for 8u282, based on > the tag jdk8u282-b03: > > https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b03-ea.tar.xz > > The tarball is accompanied by a digital signature available at: > > https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b03-ea.tar.xz.sig > > This is signed by our new 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 > Binaries to go with this are here: https://adoptopenjdk.net/upstream.html?variant=openjdk8&ga=ea Thanks and Regards, Jaya > SHA256 checksums: > > ac72aff6a3deec97b5ddc7a967e0f576fc0ce176070cc9a65f748bb5d4f885f9 > openjdk8u282-b03-ea.tar.xz > 196347fbeedbb062d798aa91a30e35a7d6a45e0207aa5a0944a05b956edf701a > openjdk8u282-b03-ea.tar.xz.sig > > They are listed at > https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b03-ea.sha256 > > Changes in 8u282-b03: > - JDK-8008657: JSpinner setComponentOrientation doesn't affect on text > orientation > - JDK-8041592: [TEST_BUG] Move 42 AWT hw/lw mixing tests to jdk > - JDK-8163161: [PIT][TEST_BUG] increase timeout in > javax/swing/plaf/nimbus/8057791/bug8057791.java > - JDK-8168292: [TESTBUG] [macosx] Test > java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X > - JDK-8168682: > jdk/test/java/lang/ClassLoader/forNameLeak/ClassForNameLeak.java fails with > -Xcomp > - JDK-8223108: Test java/awt/EventQueue/NonComponentSourcePost.java is > unstable > - JDK-8255603: Memory/Performance regression after JDK-8210985 > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > From hohensee at amazon.com Wed Dec 2 17:07:47 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 2 Dec 2020 17:07:47 +0000 Subject: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c Message-ID: <0360DBA8-EEB8-44B6-BD61-F2BF8F8F829D@amazon.com> My bad, your version looks correct. Thanks, Paul ?-----Original Message----- From: Andrew Hughes Date: Tuesday, December 1, 2020 at 9:22 PM To: "Hohensee, Paul" Cc: "Guo, James" , jdk8u-dev Subject: RE: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c On 22:19 Tue 01 Dec , Hohensee, Paul wrote: > Redirect to jdk8u-dev. > > ?-----Original Message----- > From: "Hohensee, Paul" > Date: Tuesday, December 1, 2020 at 2:18 PM > To: "Guo, James" , "jdk-updates-dev at openjdk.java.net" > Subject: Re: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c > > Lgtm. Maintainers, please consider this as a candidate for an 8u282 critical fix. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on behalf of "Guo, James" > Date: Tuesday, December 1, 2020 at 12:33 PM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c > > Hi, > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8254982 > https://git.openjdk.java.net/jdk/commit/55a0cad8 > > Although the original patch applies cleanly to 8u, yet the original patch doesn?t include > updates of tzdata under test/sun/util/calendar/zi/tzdata/, which are removed after 11u. > > 8u webrev: > http://cr.openjdk.java.net/~cverghese/webrevs/8254982-jdk8u/ > > Testing: x86_64 build, affected tests, tier1 > > Thanks, > -James > > > > This looks incorrect. The formatting is being changed on the 2015 Fiji line in australasia and a line is removed from the copy of the europe file in the test tree. Corrected version: https://cr.openjdk.java.net/~andrew/openjdk8/8254982/webrev.01/ Note that, although it doesn't affect this particular change, tzdata for 8u needs to be converted to rearguard format, not simply backported. I was planning to do tzdata2020c & tzdata2020d in one patch for this reason, but I guess we can go with this one alone now. Please review the revised webrev and then we can push. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alexander.scherbatiy at bell-sw.com Thu Dec 3 16:30:11 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Thu, 3 Dec 2020 19:30:11 +0300 Subject: [8u] RFR 8035166: Remove dependency on EC classes from pkcs11 provider Message-ID: Hello, Could you review the backport of JDK-8035166 to 8u. This backport was requested during review [1] of ?? JDK-8233228 Disable weak named curves by default in TLS, CertPath, and Signed JAR Bug: https://bugs.openjdk.java.net/browse/JDK-8035166 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/daa21271c03b 8u webrev: http://cr.openjdk.java.net/~alexsch/sercher/8035166/webrev.00 The classes ECParameters, NamedCurve, and CurveDB needs to be moved from sun.security.ec package to sun.security.util for JDK-8233228 because sun.security.ec is placed in sunec.jar and these classes are not accessible from ConstraintsParameters, DisabledAlgorithmConstraints which are stored in rt.jar. 8035166 backport to 8u (compared to 11u): * Manual merge in ConstraintsParameters.java (XECKey, NamedParameterSpec are not available in 8u). * files java.security- are separate in each platform, applied identical changes in all * context differences in multiple files The tests compact3, java_security, java_security_infra, needs_jdk, and needs_jre were run. In total they contain the following security and crypto tests: ? sun/security/tools/jarsigner/* ? com/sun/crypto/provider/* ? com/sun/security/* ? java/security/* ? javax/crypto/* ? javax/net/ssl/* ? javax/security/* ? javax/xml/crypto/* ? sun/security/* ? security/infra/java/security/* The are no new failures comparing to the build without the fix. [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-December/013164.html Thanks, Alexander. From gnu.andrew at redhat.com Thu Dec 3 16:31:39 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 3 Dec 2020 16:31:39 +0000 Subject: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c In-Reply-To: <0360DBA8-EEB8-44B6-BD61-F2BF8F8F829D@amazon.com> References: <0360DBA8-EEB8-44B6-BD61-F2BF8F8F829D@amazon.com> Message-ID: <20201203163139.GB432428@rincewind> On 17:07 Wed 02 Dec , Hohensee, Paul wrote: > My bad, your version looks correct. > > Thanks, > Paul > Thanks, Paul! I'll flag this for approval. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Dec 3 16:35:10 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 3 Dec 2020 16:35:10 +0000 Subject: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c In-Reply-To: <20201203163139.GB432428@rincewind> References: <0360DBA8-EEB8-44B6-BD61-F2BF8F8F829D@amazon.com> <20201203163139.GB432428@rincewind> Message-ID: <20201203163510.GC432428@rincewind> On 16:31 Thu 03 Dec , Andrew Hughes wrote: > On 17:07 Wed 02 Dec , Hohensee, Paul wrote: > > My bad, your version looks correct. > > > > Thanks, > > Paul > > > > Thanks, Paul! I'll flag this for approval. > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Or approve the existing critical request rather... :-) -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alexander.scherbatiy at bell-sw.com Thu Dec 3 16:36:08 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Thu, 3 Dec 2020 19:36:08 +0300 Subject: [8u] RFR 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR In-Reply-To: <20201202053430.GC387637@rincewind> References: <56edd471-f7d7-6a23-1554-e99d51ecf940@bell-sw.com> <20201202053430.GC387637@rincewind> Message-ID: <73edda88-69d4-0ef1-37f8-755307b60594@bell-sw.com> Hello, Could you review the updated backport of JDK-8233228 to 8u. ? 8u webrev: http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.01 The classes ECParameters, NamedCurve, and CurveDB needs to be moved from sun.security.ec packageto sun.security.util because sun.security.ec is placed in sunec.jar and these classes are not accessible from ConstraintsParameters, DisabledAlgorithmConstraints which are stored in rt.jar. Moving ECParameters, NamedCurve, and CurveDB classes is sent as a part of a separate request [1] ?? JDK-8035166: Remove dependency on EC classes from pkcs11 provider The patch for JDK-8035166 needs to be applied first and the patch for JDK-8233228 on top of it. The tests compact3, java_security, java_security_infra, needs_jdk, and needs_jre were run. In total they contain the following crypto and security tests: ? sun/security/tools/jarsigner/* ? com/sun/crypto/provider/* ? com/sun/security/* ? java/security/* ? javax/crypto/* ? javax/net/ssl/* ? javax/security/* ? javax/xml/crypto/* ? sun/security/* ? security/infra/java/security/* The are no new failures comparing to the build without the fix. [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-December/013171.html Thanks, Alexander On 12/2/20 8:34 AM, Andrew Hughes wrote: > On 22:14 Tue 01 Dec , Alexander Scherbatiy wrote: >> ?Hello, >> >> Could you review the backport of P2 JDK-8233228 to 8u. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8233228 >> 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a17295342862 >> 8u webrev: http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.00 >> >> >> 8233228 backport to 8u (compared to 11u): >> *?sun.security.ec.ECParameters -> sun.security.util.ECParameters >> *?sun.security.ec.NamedCurve?? -> sun.security.util.NamedCurve >> *?sun.security.ec.CurveDB????? -> sun.security.util.CurveDB >> * security/tools/keytool fixed context difference >> * DisabledAlgorithmConstraints.java fixed context difference >> * Manual merge in ConstraintsParameters.java (XECKey, NamedParameterSpec are >> not available in 8u). >> * CurveDB.SPLIT_PATTERN, CurveDB.getSupportedCurves() made public >> * NamedCurve class, getName(), getObjectId() made public >> * ECParameters.getAlgorithmParameters() made public >> * files java.security- are separate in each platform, applied >> identical changes in all >> > Why is it necessary to move the package these files are in? > > If we really need to do this, it should be done as a separate backport > of JDK-8035166, but I'm not yet convinced this is necessary, given the > disruption it will cause to code that relies on the code being in the > current locations. > >> The are no new failures in hotspot and compact3 tests comparing to the build >> without the fix. > I'm not sure how HotSpot tests would relate to a crypto change. What crypto > tests were run? > >> Thanks, >> Alexander. >> > Thanks, From gnu.andrew at redhat.com Thu Dec 3 16:36:44 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 3 Dec 2020 16:36:44 +0000 Subject: [8u] RFR 8035166: Remove dependency on EC classes from pkcs11 provider In-Reply-To: References: Message-ID: <20201203163644.GD432428@rincewind> On 19:30 Thu 03 Dec , Alexander Scherbatiy wrote: > Hello, > > Could you review the backport of JDK-8035166 to 8u. > This backport was requested during review [1] of > ?? JDK-8233228 Disable weak named curves by default in TLS, CertPath, and > Signed JAR > > Bug: https://bugs.openjdk.java.net/browse/JDK-8035166 > 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/daa21271c03b > 8u webrev: http://cr.openjdk.java.net/~alexsch/sercher/8035166/webrev.00 > > The classes ECParameters, NamedCurve, and CurveDB needs to be moved from > sun.security.ec package > to sun.security.util for JDK-8233228 because sun.security.ec is placed in > sunec.jar and these classes are not accessible > from ConstraintsParameters, DisabledAlgorithmConstraints which are stored in > rt.jar. > > 8035166 backport to 8u (compared to 11u): > * Manual merge in ConstraintsParameters.java (XECKey, NamedParameterSpec are > not available in 8u). > * files java.security- are separate in each platform, applied > identical changes in all > * context differences in multiple files > > The tests compact3, java_security, java_security_infra, needs_jdk, and > needs_jre were run. > > In total they contain the following security and crypto tests: > ? sun/security/tools/jarsigner/* > ? com/sun/crypto/provider/* > ? com/sun/security/* > ? java/security/* > ? javax/crypto/* > ? javax/net/ssl/* > ? javax/security/* > ? javax/xml/crypto/* > ? sun/security/* > ? security/infra/java/security/* > > The are no new failures comparing to the build without the fix. > > [1] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-December/013164.html > > Thanks, > Alexander. > It's still not been explained why these changes are required for JDK-8233228. Can you please answer that question? There may be no need for this backport if JDK-8233228 can be done another way. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Dec 3 17:30:33 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 3 Dec 2020 17:30:33 +0000 Subject: [8u] RFR 8035166: Remove dependency on EC classes from pkcs11 provider In-Reply-To: <20201203163644.GD432428@rincewind> References: <20201203163644.GD432428@rincewind> Message-ID: <20201203173033.GE432428@rincewind> On 16:36 Thu 03 Dec , Andrew Hughes wrote: > On 19:30 Thu 03 Dec , Alexander Scherbatiy wrote: > > Hello, > > > > Could you review the backport of JDK-8035166 to 8u. > > This backport was requested during review [1] of > > ?? JDK-8233228 Disable weak named curves by default in TLS, CertPath, and > > Signed JAR > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8035166 > > 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/daa21271c03b > > 8u webrev: http://cr.openjdk.java.net/~alexsch/sercher/8035166/webrev.00 > > > > The classes ECParameters, NamedCurve, and CurveDB needs to be moved from > > sun.security.ec package > > to sun.security.util for JDK-8233228 because sun.security.ec is placed in > > sunec.jar and these classes are not accessible > > from ConstraintsParameters, DisabledAlgorithmConstraints which are stored in > > rt.jar. > > > > 8035166 backport to 8u (compared to 11u): > > * Manual merge in ConstraintsParameters.java (XECKey, NamedParameterSpec are > > not available in 8u). > > * files java.security- are separate in each platform, applied > > identical changes in all > > * context differences in multiple files > > ^ This is JDK-8233228, isn't it? Those files aren't touched by JDK-8035166. > > The tests compact3, java_security, java_security_infra, needs_jdk, and > > needs_jre were run. > > > > In total they contain the following security and crypto tests: > > ? sun/security/tools/jarsigner/* > > ? com/sun/crypto/provider/* > > ? com/sun/security/* > > ? java/security/* > > ? javax/crypto/* > > ? javax/net/ssl/* > > ? javax/security/* > > ? javax/xml/crypto/* > > ? sun/security/* > > ? security/infra/java/security/* > > > > The are no new failures comparing to the build without the fix. > > > > [1] > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-December/013164.html > > > > Thanks, > > Alexander. > > > > It's still not been explained why these changes are required for JDK-8233228. > Can you please answer that question? There may be no need for this backport > if JDK-8233228 can be done another way. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Sorry, missed your explaination on first glance at this. The patch looks fine. The omission of the DOMKeyValue changes is correct, as they were removed by 8046724: "XML Signature ECKeyValue elements cannot be marshalled or unmarshalled". The omission of the SSL change is correct, as it seems the TLSv1.3 import is already referring to a sun.security.util.CurveDB that doesn't yet exist! [0] Please flag the bug with jdk8u-fix-request. This is not a regression fix and so is not suitable for 8u282 during rampdown. Such labels should also not be applied before review is complete. [0] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/share/classes/sun/security/ssl/SupportedGroupsExtension.java#l181 Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alexander.scherbatiy at bell-sw.com Fri Dec 4 09:47:28 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Fri, 4 Dec 2020 12:47:28 +0300 Subject: [8u] RFR 8035166: Remove dependency on EC classes from pkcs11 provider In-Reply-To: <20201203173033.GE432428@rincewind> References: <20201203163644.GD432428@rincewind> <20201203173033.GE432428@rincewind> Message-ID: <7ce29524-5509-537b-4de3-0381da8613f7@bell-sw.com> On 12/3/20 8:30 PM, Andrew Hughes wrote: > On 16:36 Thu 03 Dec , Andrew Hughes wrote: >> On 19:30 Thu 03 Dec , Alexander Scherbatiy wrote: >>> Hello, >>> >>> Could you review the backport of JDK-8035166 to 8u. >>> This backport was requested during review [1] of >>> ?? JDK-8233228 Disable weak named curves by default in TLS, CertPath, and >>> Signed JAR >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8035166 >>> 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/daa21271c03b >>> 8u webrev: http://cr.openjdk.java.net/~alexsch/sercher/8035166/webrev.00 >>> >>> The classes ECParameters, NamedCurve, and CurveDB needs to be moved from >>> sun.security.ec package >>> to sun.security.util for JDK-8233228 because sun.security.ec is placed in >>> sunec.jar and these classes are not accessible >>> from ConstraintsParameters, DisabledAlgorithmConstraints which are stored in >>> rt.jar. >>> >>> 8035166 backport to 8u (compared to 11u): >>> * Manual merge in ConstraintsParameters.java (XECKey, NamedParameterSpec are >>> not available in 8u). >>> * files java.security- are separate in each platform, applied >>> identical changes in all >>> * context differences in multiple files >>> > ^ This is JDK-8233228, isn't it? Those files aren't touched by JDK-8035166. ?Sorry. Here's the summary of conflicts resolved (compared to 11u version) * the patch doesn't apply to DOMKeyValue.java, as it doesn't access ECParameters class. * SupportedEllipticCurvesExtension.java is not present in 8u * context difference in ECKeyPairGenerator.java, SunPKCS11.java * copyright note in CurveDB is already up to date > >>> The tests compact3, java_security, java_security_infra, needs_jdk, and >>> needs_jre were run. >>> >>> In total they contain the following security and crypto tests: >>> ? sun/security/tools/jarsigner/* >>> ? com/sun/crypto/provider/* >>> ? com/sun/security/* >>> ? java/security/* >>> ? javax/crypto/* >>> ? javax/net/ssl/* >>> ? javax/security/* >>> ? javax/xml/crypto/* >>> ? sun/security/* >>> ? security/infra/java/security/* >>> >>> The are no new failures comparing to the build without the fix. >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-December/013164.html >>> >>> Thanks, >>> Alexander. >>> >> It's still not been explained why these changes are required for JDK-8233228. >> Can you please answer that question? There may be no need for this backport >> if JDK-8233228 can be done another way. >> >> Thanks, >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> OpenJDK Package Owner >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > Sorry, missed your explaination on first glance at this. > > The patch looks fine. The omission of the DOMKeyValue changes is > correct, as they were removed by 8046724: "XML Signature ECKeyValue > elements cannot be marshalled or unmarshalled". The omission of the > SSL change is correct, as it seems the TLSv1.3 import is already > referring to a sun.security.util.CurveDB that doesn't yet exist! [0] > > Please flag the bug with jdk8u-fix-request. This is not a regression > fix and so is not suitable for 8u282 during rampdown. Such labels > should also not be applied before review is complete. ?Thank you for the review. The jdk8u-fix-request flag has been added to the JDK-8035166. ?Thanks, ?Alexander. > > [0] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/share/classes/sun/security/ssl/SupportedGroupsExtension.java#l181 > > Thanks, From shade at redhat.com Fri Dec 4 17:40:25 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 4 Dec 2020 18:40:25 +0100 Subject: [8u] RFR (S) 8251397: NPE on ClassValue.ClassValueMap.cacheArray Message-ID: <80478c86-fee3-72c5-32a9-c9cb515e8b39@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8251397 https://git.openjdk.java.net/jdk/commit/81e2cf82 Original patch does not apply cleanly to 8u, because the context is different. I reapplied most (all, actually) hunks by hand. 8u variant: https://cr.openjdk.java.net/~shade/8251397/webrev.8u.01/ Testing: tier1 -- Thanks, -Aleksey From sgehwolf at redhat.com Fri Dec 4 18:26:05 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 04 Dec 2020 19:26:05 +0100 Subject: [8u] RFR (S) 8251397: NPE on ClassValue.ClassValueMap.cacheArray In-Reply-To: <80478c86-fee3-72c5-32a9-c9cb515e8b39@redhat.com> References: <80478c86-fee3-72c5-32a9-c9cb515e8b39@redhat.com> Message-ID: <247110e4fe24dcd698d96f9c5eead25aa6009b41.camel@redhat.com> On Fri, 2020-12-04 at 18:40 +0100, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8251397 > https://git.openjdk.java.net/jdk/commit/81e2cf82 > > Original patch does not apply cleanly to 8u, because the context is different. I reapplied most > (all, actually) hunks by hand. > > 8u variant: > https://cr.openjdk.java.net/~shade/8251397/webrev.8u.01/ Looks good to me. Note that JDK-8032606 removed the 'type' field from ClassValueMap. Hence the difference (other than sun.misc.Unsafe vs. jdk.internal.misc.Unsafe). Thanks, Severin From sgehwolf at redhat.com Fri Dec 4 18:41:09 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 04 Dec 2020 19:41:09 +0100 Subject: [8u] RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 Message-ID: <89ff0c43391cec9c67392484ca63475ed4835e67.camel@redhat.com> Hi, This is a follow-up, test-only patch to JDK-8227642 which I'd like to get into 8u so as to align (with 11 and jdk/jdk) how the container engine is being selected: Property renaming: jdk.test.docker.command => jdk.test.container.command Relevant bits to TEST.ROOT are not applicable to JDK 8 AFAICS. Bug: https://bugs.openjdk.java.net/browse/JDK-8228434 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/jdk8/01/ Testing: Container tests on Linux x86_64 using docker and podman. Thoughts? Thanks, Severin From alexander.scherbatiy at bell-sw.com Mon Dec 7 17:49:18 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Mon, 7 Dec 2020 20:49:18 +0300 Subject: [8u] RFR 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR In-Reply-To: <73edda88-69d4-0ef1-37f8-755307b60594@bell-sw.com> References: <56edd471-f7d7-6a23-1554-e99d51ecf940@bell-sw.com> <20201202053430.GC387637@rincewind> <73edda88-69d4-0ef1-37f8-755307b60594@bell-sw.com> Message-ID: <3d881947-313b-3b7b-ef0b-b09c66589374@bell-sw.com> Hello, Could you review the updated backport of JDK-8233228 to 8u. ? 8u webrev: http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.02/jdk.patch The only difference between the updated backport and the previous webrev.01 version is that the public modifier is removed from "static String[] getNamesByOID(String oid)" method of CurveDB class. All classes which use CurveDB.getNamesByOID(oid) method are placed in the same package as CurveDB and the original jdk11u patch has the package-private CurveDB.getNamesByOID(oid) method. Thanks, Alexander. On 12/3/20 7:36 PM, Alexander Scherbatiy wrote: > Hello, > > Could you review the updated backport of JDK-8233228 to 8u. > > ? 8u webrev: > http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.01 > > The classes ECParameters, NamedCurve, and CurveDB needs to be moved > from sun.security.ec packageto sun.security.util > because sun.security.ec is placed in sunec.jar and these classes are > not accessible > from ConstraintsParameters, DisabledAlgorithmConstraints which are > stored in rt.jar. > > Moving ECParameters, NamedCurve, and CurveDB classes is sent as a part > of a separate request [1] > ?? JDK-8035166: Remove dependency on EC classes from pkcs11 provider > > The patch for JDK-8035166 needs to be applied first and the patch for > JDK-8233228 on top of it. > > The tests compact3, java_security, java_security_infra, needs_jdk, and > needs_jre were run. > > In total they contain the following crypto and security tests: > ? sun/security/tools/jarsigner/* > ? com/sun/crypto/provider/* > ? com/sun/security/* > ? java/security/* > ? javax/crypto/* > ? javax/net/ssl/* > ? javax/security/* > ? javax/xml/crypto/* > ? sun/security/* > ? security/infra/java/security/* > > The are no new failures comparing to the build without the fix. > > [1] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-December/013171.html > > Thanks, > Alexander > > On 12/2/20 8:34 AM, Andrew Hughes wrote: >> On 22:14 Tue 01 Dec???? , Alexander Scherbatiy wrote: >>> ?Hello, >>> >>> Could you review the backport of P2 JDK-8233228 to 8u. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233228 >>> 11u patch: >>> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a17295342862 >>> 8u webrev: >>> http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.00 >>> >>> >>> 8233228 backport to 8u (compared to 11u): >>> *?sun.security.ec.ECParameters -> sun.security.util.ECParameters >>> *?sun.security.ec.NamedCurve?? -> sun.security.util.NamedCurve >>> *?sun.security.ec.CurveDB????? -> sun.security.util.CurveDB >>> * security/tools/keytool fixed context difference >>> * DisabledAlgorithmConstraints.java fixed context difference >>> * Manual merge in ConstraintsParameters.java (XECKey, >>> NamedParameterSpec are >>> not available in 8u). >>> * CurveDB.SPLIT_PATTERN, CurveDB.getSupportedCurves() made public >>> * NamedCurve class, getName(), getObjectId() made public >>> * ECParameters.getAlgorithmParameters() made public >>> * files java.security- are separate in each platform, applied >>> identical changes in all >>> >> Why is it necessary to move the package these files are in? >> >> If we really need to do this, it should be done as a separate backport >> of JDK-8035166, but I'm not yet convinced this is necessary, given the >> disruption it will cause to code that relies on the code being in the >> current locations. >> >>> The are no new failures in hotspot and compact3 tests comparing to >>> the build >>> without the fix. >> I'm not sure how HotSpot tests would relate to a crypto change. What >> crypto >> tests were run? >> >>> Thanks, >>> Alexander. >>> >> Thanks, From shade at redhat.com Mon Dec 7 19:30:58 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 7 Dec 2020 20:30:58 +0100 Subject: [8u] RFR (S) 8251397: NPE on ClassValue.ClassValueMap.cacheArray In-Reply-To: <247110e4fe24dcd698d96f9c5eead25aa6009b41.camel@redhat.com> References: <80478c86-fee3-72c5-32a9-c9cb515e8b39@redhat.com> <247110e4fe24dcd698d96f9c5eead25aa6009b41.camel@redhat.com> Message-ID: <6e70f3e6-533e-715c-eac6-c799d19179c6@redhat.com> On 12/4/20 7:26 PM, Severin Gehwolf wrote: > On Fri, 2020-12-04 at 18:40 +0100, Aleksey Shipilev wrote: >> Original bug: >> https://bugs.openjdk.java.net/browse/JDK-8251397 >> https://git.openjdk.java.net/jdk/commit/81e2cf82 >> >> Original patch does not apply cleanly to 8u, because the context is different. I reapplied most >> (all, actually) hunks by hand. >> >> 8u variant: >> https://cr.openjdk.java.net/~shade/8251397/webrev.8u.01/ > > Looks good to me. > > Note that JDK-8032606 removed the 'type' field from ClassValueMap. > Hence the difference (other than sun.misc.Unsafe > vs. jdk.internal.misc.Unsafe). Yes, exactly. I should have mentioned that, sorry. Tagged. -- Thanks, -Aleksey From akashche at redhat.com Tue Dec 8 13:42:53 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 8 Dec 2020 13:42:53 +0000 Subject: [8u] RFR: 8249588: libwindowsaccessbridge issues on 64bit Windows Message-ID: Hi, Please review the backport of JDK-8249588 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8249588 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/e2db803c2531 Original review thread: https://mail.openjdk.java.net/pipermail/swing-dev/2020-July/010544.html 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8249588/webrev.00/ Patch applies cleanly to 8u except paths and copyright year in WinAccessBridge.h (this year is different in original AB import in 8u [1] and mainline [2]). Testing: checked it with JAWS. [1] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/a8fa94609c3a#l62.5 [2] https://hg.openjdk.java.net/jdk/jdk/rev/e02d168adbc6#l57.5 -- -Alex From hohensee at amazon.com Tue Dec 8 15:29:25 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 8 Dec 2020 15:29:25 +0000 Subject: [8u] RFR: 8249588: libwindowsaccessbridge issues on 64bit Windows Message-ID: <5AEA4564-4626-482F-B6BF-7A22C72461A2@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Tuesday, December 8, 2020 at 5:43 AM To: jdk8u-dev Subject: [8u] RFR: 8249588: libwindowsaccessbridge issues on 64bit Windows Hi, Please review the backport of JDK-8249588 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8249588 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/e2db803c2531 Original review thread: https://mail.openjdk.java.net/pipermail/swing-dev/2020-July/010544.html 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8249588/webrev.00/ Patch applies cleanly to 8u except paths and copyright year in WinAccessBridge.h (this year is different in original AB import in 8u [1] and mainline [2]). Testing: checked it with JAWS. [1] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/a8fa94609c3a#l62.5 [2] https://hg.openjdk.java.net/jdk/jdk/rev/e02d168adbc6#l57.5 -- -Alex From hohensee at amazon.com Tue Dec 8 16:02:23 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 8 Dec 2020 16:02:23 +0000 Subject: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently In-Reply-To: References: <139d1e126a3f42d187da3c80703b4ecf@azul.com> <4CEFF951-CD47-4483-B309-05D3307A9E69@azul.com> <9ae99166-7cb5-3d7f-235c-df671de6df8b@azul.com> Message-ID: Ping. :) ?-----Original Message----- From: jdk8u-dev on behalf of "Hohensee, Paul" Date: Wednesday, November 25, 2020 at 1:43 PM To: Andrew Hughes , Andrey Petushkov , Aleksey Shipilev Cc: "jdk8u-dev at openjdk.java.net" Subject: RE: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently I've taken the liberty of re-doing the backport. It's clean except for a context diff at the start of hunk #1. JBS: https://bugs.openjdk.java.net/browse/JDK-8031126 Patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af53a220ea60 Webrev: http://cr.openjdk.java.net/~phh/8031126/webrev.8u.00/ Thanks, Paul On 2/19/20, 8:45 PM, "jdk8u-dev on behalf of Andrew Hughes" wrote: On 19/02/2020 13:00, Andrey Petushkov wrote: > Hi Andrew, > > Uploaded webrev at https://cr.openjdk.java.net/~fijiol/8031126/webrev.00/ > > Thanks, > Andrey > > On 19.02.2020 07:20, Andrew Hughes wrote: >> >> On 31/07/2019 16:23, Andrey Petushkov wrote: >>> Hi Aleksey, >>> >>> I'll do >>> >>> Thanks, >>> Andrey >>> >>>> On 31 Jul 2019, at 15:54, Aleksey Shipilev wrote: >>>> >>>> On 7/16/19 7:42 PM, Fedor Burdun wrote: >>>>> The issue described in bugs 8031126/8030631 is still reproducible on java8. >>>>> May I request a backport of the changeset http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af53a220ea60 to java8? >>>> This makes sense. Is there anyone from Azul to assist you with following this checklist? >>>> https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix >>>> >>>> Thanks, >>>> -Aleksey >> Is there a webrev for this backport? >> >> Thanks, > Thanks. Backport looks right, but I think we should probably backport JDK-8036122 first (which includes the changes to proc_stat_path). That should then make this change a clean backport. I take a look at this and get back to you. 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 akashche at redhat.com Tue Dec 8 16:29:28 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 8 Dec 2020 16:29:28 +0000 Subject: [8u] RFR: 8249588: libwindowsaccessbridge issues on 64bit Windows In-Reply-To: <5AEA4564-4626-482F-B6BF-7A22C72461A2@amazon.com> References: <5AEA4564-4626-482F-B6BF-7A22C72461A2@amazon.com> Message-ID: On 12/8/20, Hohensee, Paul wrote: > Lgtm. Thanks for the review! I've marked the issue for approval. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Alex > Kashchenko > Date: Tuesday, December 8, 2020 at 5:43 AM > To: jdk8u-dev > Subject: [8u] RFR: 8249588: libwindowsaccessbridge issues on 64bit Windows > > Hi, > > Please review the backport of JDK-8249588 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8249588 > > Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/e2db803c2531 > > Original review thread: > https://mail.openjdk.java.net/pipermail/swing-dev/2020-July/010544.html > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8249588/webrev.00/ > > Patch applies cleanly to 8u except paths and copyright year in > WinAccessBridge.h (this year is different in original AB import in 8u > [1] and mainline [2]). Testing: checked it with JAWS. > > > [1] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/a8fa94609c3a#l62.5 > [2] https://hg.openjdk.java.net/jdk/jdk/rev/e02d168adbc6#l57.5 > > -- > -Alex > > > -- -Alex From mbalao at redhat.com Tue Dec 8 20:25:05 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 8 Dec 2020 17:25:05 -0300 Subject: Result: New OpenJDK 8 Updates Committer: Alexey Bakhtin Message-ID: <6d518c54-39f5-ca3c-ca5e-f494535a7609@redhat.com> Voting for Alexey Bakhtin (abakhtin) [0] is now closed. Yes: 11 Veto: 0 Abstain: 0 Turnout: 4.8% (11/228) 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-November/013013.html [1] - https://openjdk.java.net/bylaws#lazy-consensus From gnu.andrew at redhat.com Thu Dec 10 04:37:44 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 10 Dec 2020 04:37:44 +0000 Subject: OpenJDK 8u282-b05 EA Released Message-ID: <20201210043744.GA1238825@rincewind> I've made available an early access source bundle for 8u282, based on the tag jdk8u282-b05: https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b05-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b05-ea.tar.xz.sig This is signed by our new 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: 3584c0849602f03b76f30fc356380832c87c90910a74dff3149310a3fc81288d openjdk8u282-b05-ea.tar.xz 11a7805f9e8885379cef488c807d3ee678d20a542382506aae4e351cfacf9a4a openjdk8u282-b05-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b05-ea.sha256 Changes in 8u282-b05: - JDK-8254982: (tz) Upgrade time-zone data to tzdata2020c Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From hedongbo at huawei.com Thu Dec 10 12:24:28 2020 From: hedongbo at huawei.com (hedongbo) Date: Thu, 10 Dec 2020 12:24:28 +0000 Subject: FW: RFR 8256642: [TEST_BUG] jdk/test/javax/sound/midi/MidiSystem/DefaultProperties.java failed Message-ID: <8FC616E5EC1A774287430B1CC2696FE3045F76FC@dggeml533-mbs.china.huawei.com> Ping? From: hedongbo Sent: Friday, November 20, 2020 9:41 AM To: 'jdk8u-dev' Subject: RFR 8256642: [TEST_BUG] jdk/test/javax/sound/midi/MidiSystem/DefaultProperties.java failed Hi, Please review this changes. Just adjusted the location of the sound.properties and removed some module tags. Bug: https://bugs.openjdk.java.net/browse/JDK-8256642 webrev: http://cr.openjdk.java.net/~dongbohe/8256642/webrev.00/ This code got introduced with JDK-8247840. In jdk8, the test case will look for files in ?lib?, but in jkd9 it will look for files in ?conf? jdk8: ./jdk/src/share/classes/com/sun/media/sound/JSSecurityManager.java:120 if (fname == null) { throw new Error("Can't find java.home ??"); } File f = new File(fname, "lib"); f = new File(f, filename); jdk9: jdk/src/java.desktop/share/classes/com/sun/media/sound/JSSecurityManager.java:117 if (fname == null) { throw new Error("Can't find java.home ??"); } File f = new File(fname, "conf"); f = new File(f, filename); Testing: Worked correctly after patch. Thanks, dongbohe From zgu at redhat.com Thu Dec 10 13:49:11 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 10 Dec 2020 08:49:11 -0500 Subject: FW: RFR 8256642: [TEST_BUG] jdk/test/javax/sound/midi/MidiSystem/DefaultProperties.java failed In-Reply-To: <8FC616E5EC1A774287430B1CC2696FE3045F76FC@dggeml533-mbs.china.huawei.com> References: <8FC616E5EC1A774287430B1CC2696FE3045F76FC@dggeml533-mbs.china.huawei.com> Message-ID: <959e13d6-9fe7-68ff-7c76-c08640373492@redhat.com> Looks good. -Zhengyu On 12/10/20 7:24 AM, hedongbo wrote: > Ping? > > From: hedongbo > Sent: Friday, November 20, 2020 9:41 AM > To: 'jdk8u-dev' > Subject: RFR 8256642: [TEST_BUG] jdk/test/javax/sound/midi/MidiSystem/DefaultProperties.java failed > > Hi, > > Please review this changes. Just adjusted the location of the sound.properties and removed some module tags. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8256642 > webrev: http://cr.openjdk.java.net/~dongbohe/8256642/webrev.00/ > > This code got introduced with JDK-8247840. In jdk8, the test case will look for files in ?lib?, but in jkd9 it will look for files in ?conf? > jdk8: ./jdk/src/share/classes/com/sun/media/sound/JSSecurityManager.java:120 > if (fname == null) { > throw new Error("Can't find java.home ??"); > } > File f = new File(fname, "lib"); > f = new File(f, filename); > jdk9: jdk/src/java.desktop/share/classes/com/sun/media/sound/JSSecurityManager.java:117 > if (fname == null) { > throw new Error("Can't find java.home ??"); > } > File f = new File(fname, "conf"); > f = new File(f, filename); > > > Testing: Worked correctly after patch. > > Thanks, > dongbohe > From hohensee at amazon.com Thu Dec 10 16:28:22 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 10 Dec 2020 16:28:22 +0000 Subject: [8u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible Message-ID: Lgtm. I've also reviewed the follow-on backport of 8228434. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Severin Gehwolf Date: Wednesday, December 2, 2020 at 5:32 AM To: jdk8u-dev Subject: [8u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible Hi! Please review this test-only backport for OpenJDK 8u. I'd like to backport this as it contains a test fix for TestCgroupMetrics and TestSystemMetrics which occasionally can fail for equal values for CPU usages (before/after). See changes in MetricsTester.java. On its own it's useful too since it also makes the tests work with an alternative container engine: podman. Since this mostly changes test library code it's duplicated for jdk tests in the jdk repo and hotspot tests in the hotspot repo. As such the original JDK 11 patch doesn't apply cleanly. There is also no jtreg-ext directory in 8u, so I've dropped the changes to VMProps.java. It's not applicable. Some context changes in DockerTestUtils.java due to JDK-8222888 and JDK-8222299, both not in 8u and no plan to backport them at this point. Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/jdk8/ Testing: Container tests on Linux x86_64 using docker/podman. Thoughts? Thanks, Severin From hohensee at amazon.com Thu Dec 10 16:28:31 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 10 Dec 2020 16:28:31 +0000 Subject: [8u] RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 Message-ID: <9C4F7C43-C0B7-43D0-B8F9-FB7972D51FFB@amazon.com> Lgtm. Thanks Paul ?-----Original Message----- From: jdk8u-dev on behalf of Severin Gehwolf Date: Friday, December 4, 2020 at 10:41 AM To: jdk8u-dev Subject: [8u] RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 Hi, This is a follow-up, test-only patch to JDK-8227642 which I'd like to get into 8u so as to align (with 11 and jdk/jdk) how the container engine is being selected: Property renaming: jdk.test.docker.command => jdk.test.container.command Relevant bits to TEST.ROOT are not applicable to JDK 8 AFAICS. Bug: https://bugs.openjdk.java.net/browse/JDK-8228434 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/jdk8/01/ Testing: Container tests on Linux x86_64 using docker and podman. Thoughts? Thanks, Severin From gnu.andrew at redhat.com Fri Dec 11 04:27:30 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Dec 2020 04:27:30 +0000 Subject: [8u] RFR 8255226: (tz) Upgrade time-zone data to tzdata2020d In-Reply-To: <8929db5f80cc8633264d997a630e7ef724ddaad8.camel@redhat.com> References: <8929db5f80cc8633264d997a630e7ef724ddaad8.camel@redhat.com> Message-ID: <20201211042730.GA1304625@rincewind> On 13:31 Wed 02 Dec , Severin Gehwolf wrote: > Hi, > > On Tue, 2020-12-01 at 20:29 +0000, Guo, James wrote: > > Hi, > > > > Original bug: > > https://bugs.openjdk.java.net/browse/JDK-8255226 > > https://github.com/openjdk/jdk/commit/b65ff60a > > > > Although the original patch applies cleanly to 8u, yet the original patch doesn?t include > > updates of tzdata under test/sun/util/calendar/zi/tzdata/, which are removed after 11u. > > > > 8u webrev: > > http://cr.openjdk.java.net/~cverghese/webrevs/8255226-jdk8u/ > > > > Testing: x86_64 build, affected tests, tier1 > > This should be going to jdk8u-dev. Adding that and dropping jdk- > updates-dev. > > James, please work with Andrew Hughes to get this reviewed. He > mentioned that he'd already worked on this too. > > Thanks, > Severin > Again, this seems to have some odd whitespace differences compared to 11u and my own copying of the files from the tzdata bundle. My version: https://cr.openjdk.java.net/~andrew/openjdk8/8255226/webrev.01/ If this looks ok, I'll flag with jdk8u-critical-request. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Dec 11 04:41:59 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Dec 2020 04:41:59 +0000 Subject: OpenJDK 8u and Backport Bugs Message-ID: <20201211044159.GB1304625@rincewind> Hi all, We've worked out a way we can create backport bugs for OpenJDK 8u issues and have them correctly resolved by hgupdater. For 8u, '8-pool' doesn't work as '11-pool' does with OpenJDK 11u. I assume this is because '8-pool' is assumed to refer to the Oracle fork of 8u, which also use 8u281, 8u291, etc. Sadly, a generic 'openjdk8u' seems not to work either. What does work is using the specific version of 'openjdk8ux'. We therefore propose the following, and I have updated the wiki to correspond with this: 1. When work is started on a backport, create a backport bug as follows: a. Log in to the OpenJDK bug database and go to the bug you want to backport. b. Click More ? Create Backport c. Set yourself as the Assignee and change Fix Version to 'openjdk8u'. d. On the new bug, clear the inherited 'Affected Versions' and labels. e. Set 'Affected Versions' to 'openjdk8u' f. Add any desired labels, such as 'jdk8u-', to the bug, where is your OpenJDK username. 2. Proceed as usual, but apply the jdk8u-needs-review label and make approval requests on the backport bug. This avoids the issue where labels on the parent issue are cloned to other bugs. 3. When a maintainer approves the bug, they will set the fix version to the release it is approved for. This should provide additional clarity as to which release the backport is approved for. For example, at present, jdk8u-critical-yes bugs will have a fix version of openjdk8u282 and jdk8u-fix-yes bugs will have a fix version of openjdk8u292. Please let me know if there are any questions about this process. Thanks to Severin Gehwolf and Jonathan Dowland for testing this process out. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Fri Dec 11 10:33:39 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 11 Dec 2020 11:33:39 +0100 Subject: OpenJDK 8u and Backport Bugs In-Reply-To: <20201211044159.GB1304625@rincewind> References: <20201211044159.GB1304625@rincewind> Message-ID: Hi Andrew, On Fri, 2020-12-11 at 04:41 +0000, Andrew Hughes wrote: > Hi all, > > We've worked out a way we can create backport bugs for OpenJDK 8u > issues and have them correctly resolved by hgupdater. > > For 8u, '8-pool' doesn't work as '11-pool' does with OpenJDK 11u. I > assume this is because '8-pool' is assumed to refer to the Oracle fork > of 8u, which also use 8u281, 8u291, etc. Sadly, a generic 'openjdk8u' > seems not to work either. > > What does work is using the specific version of 'openjdk8ux'. We > therefore propose the following, and I have updated the wiki to > correspond with this: > > 1. When work is started on a backport, create a backport bug as follows: > ? a. Log in to the OpenJDK bug database and go to the bug you want to backport. > ? b. Click More ? Create Backport > ? c. Set yourself as the Assignee and change Fix Version to 'openjdk8u'. > ? d. On the new bug, clear the inherited 'Affected Versions' and labels. > ? e. Set 'Affected Versions' to 'openjdk8u' > ? f. Add any desired labels, such as 'jdk8u-', to the bug, > ? where is your OpenJDK username. > > 2. Proceed as usual, but apply the jdk8u-needs-review label and make > approval requests on the backport bug.? This avoids the issue where > labels on the parent issue are cloned to other bugs. While point 2) would avoid the need to remove a couple of additional labels when the backport bug is being created, it doesn't really avoid the need of "clearing labels" entirely. There are very few bugs without labels at all. Also, the master bug serves as the place were all the info is being gathered. This is usefull, since the JDK 11 backporting info would be on the same bug as any JDK 8 backporting info. Doing certain labels on an explicit backport bug breaks this. Adding the label on the backport bug also suggests to add the "Fix Request" comment to the backport bug, moving further info away from the main bug. With my maintainer hat on, it's easier to do approvals by looking at the master bug directly and see how decisions panned out for other releases. For those reasons I think we should keep this part as-is: Keep applying the jdk8u-fix-request label to the master bug. Clearing 2-ish labels when creating the backport bug should be fine. I'd be happy to do that if people forget. Besides, the intention would be to create the backport bug as soon as somebody starts working on it. At that point, no jdk8u-fix-request label should be there anyway and, thus, would only apply if JDK 11u adopted this process too. Maybe I'm missing something. Thanks, Severin From sgehwolf at redhat.com Fri Dec 11 10:59:45 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 11 Dec 2020 11:59:45 +0100 Subject: [8u] RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: <9C4F7C43-C0B7-43D0-B8F9-FB7972D51FFB@amazon.com> References: <9C4F7C43-C0B7-43D0-B8F9-FB7972D51FFB@amazon.com> Message-ID: On Thu, 2020-12-10 at 16:28 +0000, Hohensee, Paul wrote: > Lgtm. Thanks for the review, Paul. Cheers, Severin From sgehwolf at redhat.com Fri Dec 11 14:57:17 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 11 Dec 2020 15:57:17 +0100 Subject: PING? [8u] RFR: 8226899: Problemlist compiler/rtm tests In-Reply-To: <17f9cda265405d773276134741b938c062c65ccb.camel@redhat.com> References: <17f9cda265405d773276134741b938c062c65ccb.camel@redhat.com> Message-ID: <1e9b4f69d47620610ebba819a02fe0f41ef5069a.camel@redhat.com> On Thu, 2020-08-06 at 17:54 +0200, Severin Gehwolf wrote: > Hi, > > For tier1 tests on OpenJDK 8u we frequently see failing rtm tests. > These have been problem-listed in JDK 11 and 13. I propose to do the > same to reduce noise. This patch depends on JDK-8078450[1] also > proposed for review. > > Only difference to JDK 11's version are context changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226899 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226899/01/webrev/ > > Testing: hotspot_tier1 with JDK-8078450 and JDK-8230388. No more rtm > failures. > > Thoughts? Anyone? > Thanks, > Severin > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012181.html > > From sgehwolf at redhat.com Fri Dec 11 15:14:38 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 11 Dec 2020 16:14:38 +0100 Subject: [8u] RFR: 8230388: Problemlist additional compiler/rtm tests Message-ID: Hi, Please review this backport for cleaner hotspot tier1 runs. It adds intermittently failing RTM tests to the newly added hotspot ProblemList.txt file. webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230388/01/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8230388 Testing: hotspot_tier1. No more RTM failures. Thoughts? Thanks, Severin From rwestrel at redhat.com Fri Dec 11 15:24:03 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 11 Dec 2020 16:24:03 +0100 Subject: PING? [8u] RFR: 8226899: Problemlist compiler/rtm tests In-Reply-To: <1e9b4f69d47620610ebba819a02fe0f41ef5069a.camel@redhat.com> References: <17f9cda265405d773276134741b938c062c65ccb.camel@redhat.com> <1e9b4f69d47620610ebba819a02fe0f41ef5069a.camel@redhat.com> Message-ID: <874kksicx8.fsf@redhat.com> >> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226899/01/webrev/ That looks reasonable to me. Roland. From gnu.andrew at redhat.com Fri Dec 11 15:41:43 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Dec 2020 15:41:43 +0000 Subject: OpenJDK 8u and Backport Bugs In-Reply-To: References: <20201211044159.GB1304625@rincewind> Message-ID: <20201211154143.GA1323090@rincewind> On 11:33 Fri 11 Dec , Severin Gehwolf wrote: > Hi Andrew, > > On Fri, 2020-12-11 at 04:41 +0000, Andrew Hughes wrote: > > Hi all, > > > > We've worked out a way we can create backport bugs for OpenJDK 8u > > issues and have them correctly resolved by hgupdater. > > > > For 8u, '8-pool' doesn't work as '11-pool' does with OpenJDK 11u. I > > assume this is because '8-pool' is assumed to refer to the Oracle fork > > of 8u, which also use 8u281, 8u291, etc. Sadly, a generic 'openjdk8u' > > seems not to work either. > > > > What does work is using the specific version of 'openjdk8ux'. We > > therefore propose the following, and I have updated the wiki to > > correspond with this: > > > > 1. When work is started on a backport, create a backport bug as follows: > > ? a. Log in to the OpenJDK bug database and go to the bug you want to backport. > > ? b. Click More ? Create Backport > > ? c. Set yourself as the Assignee and change Fix Version to 'openjdk8u'. > > ? d. On the new bug, clear the inherited 'Affected Versions' and labels. > > ? e. Set 'Affected Versions' to 'openjdk8u' > > ? f. Add any desired labels, such as 'jdk8u-', to the bug, > > ? where is your OpenJDK username. > > > > 2. Proceed as usual, but apply the jdk8u-needs-review label and make > > approval requests on the backport bug.? This avoids the issue where > > labels on the parent issue are cloned to other bugs. > > While point 2) would avoid the need to remove a couple of additional > labels when the backport bug is being created, it doesn't really avoid > the need of "clearing labels" entirely. There are very few bugs without > labels at all. > > Also, the master bug serves as the place were all the info is being > gathered. This is usefull, since the JDK 11 backporting info would be > on the same bug as any JDK 8 backporting info. Doing certain labels on > an explicit backport bug breaks this. Adding the label on the backport > bug also suggests to add the "Fix Request" comment to the backport bug, > moving further info away from the main bug. With my maintainer hat on, > it's easier to do approvals by looking at the master bug directly and > see how decisions panned out for other releases. > > For those reasons I think we should keep this part as-is: Keep applying > the jdk8u-fix-request label to the master bug. Clearing 2-ish labels > when creating the backport bug should be fine. I'd be happy to do that > if people forget. > > Besides, the intention would be to create the backport bug as soon as > somebody starts working on it. At that point, no jdk8u-fix-request > label should be there anyway and, thus, would only apply if JDK 11u > adopted this process too. Maybe I'm missing something. > > Thanks, > Severin > Yeah, #2 is after the backport bug has been created. What I'm referring to with "labels on the parent issue are cloned to other bugs" is a backport bug being created for another release. For example, I've seen bugs for Oracle backports appear in our queue because they get jdk8u-fix-request added by the cloning process. Even though they also have jdk8u-fix-yes, they don't match the filter because of the fix version not being an OpenJDK 8u one. The same would happen if the 13u backport was done after 8u too. Ideally, 8u should be the last, but that doesn't always happen. 7u may want to adopt this process too and that would be an issue there. I'm aware that it's a bit of a pain when it comes to approving the bug, but that's something that really only affects the three of us acting as maintainers and can be worked around easily by opening the parent bug. I think it's simpler and less confusing for someone working on the bug to have one bug to work with, not having to flick between two. Also, having their own 8u backport bug will hopefully encourage them to make it their own and not worry about adding to a bug shared by many others. I don't know how much of an issue bug noise is for people who aren't interested in the 8u backport process, but this would reduce it. So, I'd like some feedback from others before making a decision here. It doesn't seem a good idea to base the decision just on what works best for us as maintainers. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Fri Dec 11 15:44:49 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 11 Dec 2020 16:44:49 +0100 Subject: PING? [8u] RFR: 8226899: Problemlist compiler/rtm tests In-Reply-To: <874kksicx8.fsf@redhat.com> References: <17f9cda265405d773276134741b938c062c65ccb.camel@redhat.com> <1e9b4f69d47620610ebba819a02fe0f41ef5069a.camel@redhat.com> <874kksicx8.fsf@redhat.com> Message-ID: <8e8111a4e7299fba4f63aaab8c94144346d9bec5.camel@redhat.com> On Fri, 2020-12-11 at 16:24 +0100, Roland Westrelin wrote: > > > > webrev: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226899/01/webrev/ > > That looks reasonable to me. Thanks, Roland! Cheers, Severin From gnu.andrew at redhat.com Fri Dec 11 15:54:19 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Dec 2020 15:54:19 +0000 Subject: [8u] RFR: 8230388: Problemlist additional compiler/rtm tests In-Reply-To: References: Message-ID: <20201211155419.GB1323090@rincewind> On 16:14 Fri 11 Dec , Severin Gehwolf wrote: > Hi, > > Please review this backport for cleaner hotspot tier1 runs. It adds > intermittently failing RTM tests to the newly added hotspot > ProblemList.txt file. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230388/01/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8230388 > > Testing: hotspot_tier1. No more RTM failures. > > Thoughts? > > Thanks, > Severin > This has additional changes when compared to the trunk and jdk11 versions: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/61e48e3a5d80 https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230388/01/webrev/hotspot.patch Where are they coming from? -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Dec 11 15:57:02 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Dec 2020 15:57:02 +0000 Subject: PING? [8u] RFR: 8226899: Problemlist compiler/rtm tests In-Reply-To: <1e9b4f69d47620610ebba819a02fe0f41ef5069a.camel@redhat.com> References: <17f9cda265405d773276134741b938c062c65ccb.camel@redhat.com> <1e9b4f69d47620610ebba819a02fe0f41ef5069a.camel@redhat.com> Message-ID: <20201211155702.GC1323090@rincewind> On 15:57 Fri 11 Dec , Severin Gehwolf wrote: > On Thu, 2020-08-06 at 17:54 +0200, Severin Gehwolf wrote: > > Hi, > > > > For tier1 tests on OpenJDK 8u we frequently see failing rtm tests. > > These have been problem-listed in JDK 11 and 13. I propose to do the > > same to reduce noise. This patch depends on JDK-8078450[1] also > > proposed for review. > > > > Only difference to JDK 11's version are context changes. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226899 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226899/01/webrev/ > > > > Testing: hotspot_tier1 with JDK-8078450 and JDK-8230388. No more rtm > > failures. > > > > Thoughts? > > Anyone? > > > Thanks, > > Severin > > > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012181.html > > > > > > This one looks fine. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Fri Dec 11 16:14:05 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 11 Dec 2020 17:14:05 +0100 Subject: [8u] RFR: 8230388: Problemlist additional compiler/rtm tests In-Reply-To: <20201211155419.GB1323090@rincewind> References: <20201211155419.GB1323090@rincewind> Message-ID: On Fri, 2020-12-11 at 15:54 +0000, Andrew Hughes wrote: > On 16:14 Fri 11 Dec???? , Severin Gehwolf wrote: > > Hi, > > > > Please review this backport for cleaner hotspot tier1 runs. It adds > > intermittently failing RTM tests to the newly added hotspot > > ProblemList.txt file. > > > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230388/01/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230388 > > > > Testing: hotspot_tier1. No more RTM failures. > > > > Thoughts? > > > > Thanks, > > Severin > > > > This has additional changes when compared to the trunk and jdk11 > versions: > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/61e48e3a5d80 > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230388/01/webrev/hotspot.patch > > Where are they coming from? I've added them, since they also fail intermittently on JDK 8u. This is just test noise. Thanks, Severin From jdowland at redhat.com Fri Dec 11 16:19:47 2020 From: jdowland at redhat.com (Jonathan Dowland) Date: Fri, 11 Dec 2020 16:19:47 +0000 Subject: [8u] RFR: 6949753: [TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop Message-ID: <20201211161947.5meglzlwjz3yruku@qusp> Please review the following (trivial) patch for 8u. This is an Oracle parity backport patch that deletes a single test. The test was just brought in as part of a bundle in another backport. Original bug: https://bugs.openjdk.java.net/browse/JDK-6949753 Webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-6949753/webrev.00/ I've prepared a webrev because unshuffle_patch was unable to handle this. I tried both the version in the deprecated jdk/jdk HG repository and the git equivalent. (This is something for me to follow up on.) Best wishes -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat From hohensee at amazon.com Fri Dec 11 16:25:16 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 11 Dec 2020 16:25:16 +0000 Subject: [8u] RFR: 6949753: [TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop Message-ID: <9581571F-131B-4782-B874-0515AD2FADA0@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Jonathan Dowland Date: Friday, December 11, 2020 at 8:20 AM To: jdk8u-dev Subject: [8u] RFR: 6949753: [TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop Please review the following (trivial) patch for 8u. This is an Oracle parity backport patch that deletes a single test. The test was just brought in as part of a bundle in another backport. Original bug: https://bugs.openjdk.java.net/browse/JDK-6949753 Webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-6949753/webrev.00/ I've prepared a webrev because unshuffle_patch was unable to handle this. I tried both the version in the deprecated jdk/jdk HG repository and the git equivalent. (This is something for me to follow up on.) Best wishes -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat From sgehwolf at redhat.com Fri Dec 11 16:29:09 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 11 Dec 2020 17:29:09 +0100 Subject: [8u] RFR 8255226: (tz) Upgrade time-zone data to tzdata2020d In-Reply-To: <20201211042730.GA1304625@rincewind> References: <8929db5f80cc8633264d997a630e7ef724ddaad8.camel@redhat.com> <20201211042730.GA1304625@rincewind> Message-ID: <6dfcbe0602da68a60d49a09d77c38787236c5a73.camel@redhat.com> On Fri, 2020-12-11 at 04:27 +0000, Andrew Hughes wrote: > On 13:31 Wed 02 Dec???? , Severin Gehwolf wrote: > > Hi, > > > > On Tue, 2020-12-01 at 20:29 +0000, Guo, James wrote: > > > Hi, > > > > > > Original bug: > > > ? https://bugs.openjdk.java.net/browse/JDK-8255226< > > > https://bugs.openjdk.java.net/browse/JDK-8254982> > > > ? https://github.com/openjdk/jdk/commit/b65ff60a > > > > > > Although the original patch applies cleanly to 8u, yet the > > > original patch doesn?t include > > > updates of tzdata under test/sun/util/calendar/zi/tzdata/, which > > > are removed after 11u. > > > > > > 8u webrev: > > > http://cr.openjdk.java.net/~cverghese/webrevs/8255226-jdk8u/ > > > > > > Testing: x86_64 build, affected tests, tier1 > > > > This should be going to jdk8u-dev. Adding that and dropping jdk- > > updates-dev. > > > > James, please work with Andrew Hughes to get this reviewed. He > > mentioned that he'd already worked on this too. > > > > Thanks, > > Severin > > > > Again, this seems to have some odd whitespace differences compared to 11u and my > own copying of the files from the tzdata bundle. > > My version: > https://cr.openjdk.java.net/~andrew/openjdk8/8255226/webrev.01/ > > If this looks ok, I'll flag with jdk8u-critical-request. Either version looks fine to me. Thanks, Severin From gnu.andrew at redhat.com Fri Dec 11 16:36:37 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Dec 2020 16:36:37 +0000 Subject: [8u] RFR: 6949753: [TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop In-Reply-To: <20201211161947.5meglzlwjz3yruku@qusp> References: <20201211161947.5meglzlwjz3yruku@qusp> Message-ID: <20201211163637.GD1323090@rincewind> On 16:19 Fri 11 Dec , Jonathan Dowland wrote: > Please review the following (trivial) patch for 8u. This is an Oracle > parity backport patch that deletes a single test. The test was just > brought in as part of a bundle in another backport. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-6949753 > Webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-6949753/webrev.00/ > > I've prepared a webrev because unshuffle_patch was unable to handle > this. I tried both the version in the deprecated jdk/jdk HG repository > and the git equivalent. (This is something for me to follow up on.) > > > Best wishes > > -- > ???? Jonathan Dowland > Senior Software Engineer, OpenJDK, Red Hat > I don't think this even needs review, as the file being removed is identical in 8u to the one in 11u. I would always start with the version closest to 8u that the patch is in, rather than trunk. There should rarely be a reason that the patch is not in 11u first before coming to 8u. Shuffling worked for me, though 'hg rm' will do the same job. $ sh ../../jdk11/bin/unshuffle_patch.sh -to9 6949753.11u 6949753.9u WARNING: no match found for +++ /dev/null $ hg rm test/java/awt/print/PageFormat/PDialogTest.java $ hg diff | diff -u 6949753.9u.jdk - $ cat 6949753.9u 6949753.9u.jdk > 6949753.8u $ hg import 6949753.8u applying 6949753.8u $ hg export|diff -u 6949753.11u - Please flag the bug and I'll approve and push. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Dec 11 16:39:35 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Dec 2020 16:39:35 +0000 Subject: [8u] RFR 8255226: (tz) Upgrade time-zone data to tzdata2020d In-Reply-To: <6dfcbe0602da68a60d49a09d77c38787236c5a73.camel@redhat.com> References: <8929db5f80cc8633264d997a630e7ef724ddaad8.camel@redhat.com> <20201211042730.GA1304625@rincewind> <6dfcbe0602da68a60d49a09d77c38787236c5a73.camel@redhat.com> Message-ID: <20201211163935.GE1323090@rincewind> On 17:29 Fri 11 Dec , Severin Gehwolf wrote: ... > > Either version looks fine to me. > Ok... the first has clear whitespace differences that will create issues with future updates. We'll go with mine. I've flagged the backport bug for approval: https://bugs.openjdk.java.net/browse/JDK-8257585 Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Fri Dec 11 16:50:18 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 11 Dec 2020 17:50:18 +0100 Subject: OpenJDK 8u and Backport Bugs In-Reply-To: <20201211154143.GA1323090@rincewind> References: <20201211044159.GB1304625@rincewind> <20201211154143.GA1323090@rincewind> Message-ID: On Fri, 2020-12-11 at 15:41 +0000, Andrew Hughes wrote: So, I'd like some feedback from others before making a decision here. It doesn't seem a good idea to base the decision just on what works best for us as maintainers. Makes sense. Note that it seems a departure from general updates releases backporting process[1]. The more differences get introduced the harder it is to remember what release follows which process. """ An OpenJDK JDK Updates Author, Committer or Reviewer requesting their fix in a JDK Updates repo MUST label the corresponding master/parent issue with jdku-fix-request (where denotes the feature release version, e.g. jdk10u-fix-request) in the JDK Bug System. """ Note the master/parent issue phrasing. Thanks, Severin [1] https://openjdk.java.net/projects/jdk-updates/approval.html From gnu.andrew at redhat.com Fri Dec 11 16:53:56 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Dec 2020 16:53:56 +0000 Subject: [8u] RFR: 8230388: Problemlist additional compiler/rtm tests In-Reply-To: References: <20201211155419.GB1323090@rincewind> Message-ID: <20201211165356.GF1323090@rincewind> On 17:14 Fri 11 Dec , Severin Gehwolf wrote: > On Fri, 2020-12-11 at 15:54 +0000, Andrew Hughes wrote: > > On 16:14 Fri 11 Dec???? , Severin Gehwolf wrote: > > > Hi, > > > > > > Please review this backport for cleaner hotspot tier1 runs. It adds > > > intermittently failing RTM tests to the newly added hotspot > > > ProblemList.txt file. > > > > > > webrev: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230388/01/webrev/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230388 > > > > > > Testing: hotspot_tier1. No more RTM failures. > > > > > > Thoughts? > > > > > > Thanks, > > > Severin > > > > > > > This has additional changes when compared to the trunk and jdk11 > > versions: > > > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/61e48e3a5d80 > > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230388/01/webrev/hotspot.patch > > > > Where are they coming from? > > I've added them, since they also fail intermittently on JDK 8u. This is > just test noise. > > Thanks, > Severin > Right. How do they fail? Do they fail on later OpenJDK versions? If we're going to problem list these, it should be under a separate bug with the failures documented, not hidden away under this bug. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Dec 11 17:00:54 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Dec 2020 17:00:54 +0000 Subject: OpenJDK 8u and Backport Bugs In-Reply-To: References: <20201211044159.GB1304625@rincewind> <20201211154143.GA1323090@rincewind> Message-ID: <20201211170054.GG1323090@rincewind> On 17:50 Fri 11 Dec , Severin Gehwolf wrote: > On Fri, 2020-12-11 at 15:41 +0000, Andrew Hughes wrote: > So, I'd like some feedback from others before making a decision here. > It doesn't seem a good idea to base the decision just on what works > best for us as maintainers. > > Makes sense. > > Note that it seems a departure from general updates releases > backporting process[1]. The more differences get introduced the harder > it is to remember what release follows which process. > > """ > An OpenJDK JDK Updates Author, Committer or Reviewer requesting their > fix in a JDK Updates repo MUST label the corresponding master/parent > issue with jdku-fix-request (where denotes the > feature release version, e.g. jdk10u-fix-request) in the JDK Bug > System. > """ > > Note the master/parent issue phrasing. > > Thanks, > Severin > > [1] https://openjdk.java.net/projects/jdk-updates/approval.html > Yes, I'm aware of that. But how many people have actually had two bugs to deal with in practice? I can't recall seeing backport bugs created in this way ahead of time by anyone outside Oracle. So having two bugs at all is going to be new to most people. I'll cc jdk-updates-dev at openjdk.java.net for more input. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From snazarkin at azul.com Mon Dec 14 10:15:48 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Mon, 14 Dec 2020 10:15:48 +0000 Subject: [8u] ppc64 build failure after backport of 8152545 Message-ID: <945C53BA-C5C4-424D-B2EE-E17ED19B62F0@azul.com> Hi! Have anybody noticed that ppc64 build starts failing after u282-b04? Looks like the reason is backport of 8152545 (Use preprocessor instead of compiling a program to generate native nio constants). /Sergey From sgehwolf at redhat.com Mon Dec 14 10:41:11 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 14 Dec 2020 11:41:11 +0100 Subject: [8u] ppc64 build failure after backport of 8152545 In-Reply-To: <945C53BA-C5C4-424D-B2EE-E17ED19B62F0@azul.com> References: <945C53BA-C5C4-424D-B2EE-E17ED19B62F0@azul.com> Message-ID: Hi, On Mon, 2020-12-14 at 10:15 +0000, Sergey Nazarkin wrote: > Hi! > > Have anybody noticed that ppc64 build starts failing after u282-b04? > Looks like the reason is? backport of 8152545 (Use preprocessor > instead of compiling a program to generate native nio constants). What's the failure you are seeing exactly? Is this ppc64 (BE) or ppc64le? If the latter, there is at least one build I know of that works fine[1]. AFAIK, Andrew Hughes tests builds on ppc64 BE too before builds are being promoted. Is that right, Andrew? Thanks, Severin [1] https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-linux-ppc64le-hotspot/ From sgehwolf at redhat.com Mon Dec 14 11:11:20 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 14 Dec 2020 12:11:20 +0100 Subject: [8u] RFR: 8230388: Problemlist additional compiler/rtm tests In-Reply-To: <20201211165356.GF1323090@rincewind> References: <20201211155419.GB1323090@rincewind> <20201211165356.GF1323090@rincewind> Message-ID: <77ced259ecbbec63c63ca81e0f73ffe4daa10a0c.camel@redhat.com> On Fri, 2020-12-11 at 16:53 +0000, Andrew Hughes wrote: On 17:14 Fri 11 Dec???? , Severin Gehwolf wrote: > On Fri, 2020-12-11 at 15:54 +0000, Andrew Hughes wrote: > > On 16:14 Fri 11 Dec???? , Severin Gehwolf wrote: > > > Hi, > > > > > > > Please review this backport for cleaner hotspot tier1 runs. It adds > > > > intermittently failing RTM tests to the newly added hotspot > > > > ProblemList.txt file. > > > > > > > webrev: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230388/01/webrev/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230388 > > > > > > Testing: hotspot_tier1. No more RTM failures. > > > > > > Thoughts? > > > > > > Thanks, > > > Severin > > > > > > > > This has additional changes when compared to the trunk and jdk11 > > > versions: > > > > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/61e48e3a5d80 > > > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230388/01/webrev/hotspot.patch > > > > Where are they coming from? > > > I've added them, since they also fail intermittently on JDK 8u. This is > > just test noise. > Right. How do they fail? Do they fail on later OpenJDK versions? I don't know. From the looks of it, rtm tests are not part of the tier1 test set for JDK 11 and jdk head. If we're going to problem list these, it should be under a separate bug with the failures documented, not hidden away under this bug. OK. We should probably not problem list them, but perhaps exclude from the tier1 test set (so as to match later JDKs). Anyway, I've removed additional exclusions: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230388/02/webrev/ How does that look? Thanks, Severin From snazarkin at azul.com Mon Dec 14 16:06:46 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Mon, 14 Dec 2020 16:06:46 +0000 Subject: [8u] ppc64 build failure after backport of 8152545 In-Reply-To: References: <945C53BA-C5C4-424D-B2EE-E17ED19B62F0@azul.com> Message-ID: <518C64D3-75E7-486C-988C-7C8E5313FF19@azul.com> Thanks for the link. It seems the compiler we are using for cross compilation was not properly configured. Sorry for false alert. Sergey > On Dec 14, 2020, at 13:41, Severin Gehwolf wrote: > > Hi, > > On Mon, 2020-12-14 at 10:15 +0000, Sergey Nazarkin wrote: >> Hi! >> >> Have anybody noticed that ppc64 build starts failing after u282-b04? >> Looks like the reason is backport of 8152545 (Use preprocessor >> instead of compiling a program to generate native nio constants). > > What's the failure you are seeing exactly? Is this ppc64 (BE) or > ppc64le? If the latter, there is at least one build I know of that > works fine[1]. > > AFAIK, Andrew Hughes tests builds on ppc64 BE too before builds are > being promoted. Is that right, Andrew? > > Thanks, > Severin > > [1] https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-linux-ppc64le-hotspot/ From sgehwolf at redhat.com Mon Dec 14 16:37:02 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 14 Dec 2020 17:37:02 +0100 Subject: [8u] RFR: 8230388: Problemlist additional compiler/rtm tests In-Reply-To: <77ced259ecbbec63c63ca81e0f73ffe4daa10a0c.camel@redhat.com> References: <20201211155419.GB1323090@rincewind> <20201211165356.GF1323090@rincewind> <77ced259ecbbec63c63ca81e0f73ffe4daa10a0c.camel@redhat.com> Message-ID: On Mon, 2020-12-14 at 12:11 +0100, Severin Gehwolf wrote: > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230388/02/webrev/ I should mention that is is now applying clean (with fuzz) post path adjustments. Thanks, Severin From sgehwolf at redhat.com Mon Dec 14 17:22:24 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 14 Dec 2020 18:22:24 +0100 Subject: [8u] RFR: 8258241: [8u] Missing doPrivileged() hunks from JDK-8226575 Message-ID: <18312a23d33edcddf37ba32545bc4b6526e877b6.camel@redhat.com> Hi, Please review this 8u-only bug affecting the current jdk8u-dev tree. We've backported JDK-8226575 and later JDK-8217338. Since JDK-8217338 wasn't present in 8u at the time one hunk got omitted. This patch brings code-bases in sync. Bug: https://bugs.openjdk.java.net/browse/JDK-8258241 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8258241/01/webrev/ I've gone over the JDK 11 patch of 8226575 again and haven't found any other discrepancies. Thoughts? Thanks, Severin From gnu.andrew at redhat.com Mon Dec 14 18:04:46 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 14 Dec 2020 18:04:46 +0000 Subject: [8u] ppc64 build failure after backport of 8152545 In-Reply-To: References: <945C53BA-C5C4-424D-B2EE-E17ED19B62F0@azul.com> Message-ID: <20201214180446.GD44763@rincewind> On 11:41 Mon 14 Dec , Severin Gehwolf wrote: > Hi, > > On Mon, 2020-12-14 at 10:15 +0000, Sergey Nazarkin wrote: > > Hi! > > > > Have anybody noticed that ppc64 build starts failing after u282-b04? > > Looks like the reason is? backport of 8152545 (Use preprocessor > > instead of compiling a program to generate native nio constants). > > What's the failure you are seeing exactly? Is this ppc64 (BE) or > ppc64le? If the latter, there is at least one build I know of that > works fine[1]. > > AFAIK, Andrew Hughes tests builds on ppc64 BE too before builds are > being promoted. Is that right, Andrew? > > Thanks, > Severin > > [1] https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-linux-ppc64le-hotspot/ > Yes, before I promote each build, I do a build on RHEL 7 on ppc64, ppc64le, x86_64, and x86 and Zero (ppc32, s390x, aarch64). I have fixes in the pipeline which should enable the aarch64 JIT [0] and s390 (31-bit) on Zero. Specifically to this particular change, it also went out in the last release of IcedTea [1] so it's had testing there as well. It should actually make cross-compilation easier (it allowed me to exclude one related change from the AArch64 patch) [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-November/013121.html [1] https://bitly.com/it31700 Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Dec 14 18:06:50 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 14 Dec 2020 18:06:50 +0000 Subject: [8u] RFR: 8230388: Problemlist additional compiler/rtm tests In-Reply-To: References: <20201211155419.GB1323090@rincewind> <20201211165356.GF1323090@rincewind> <77ced259ecbbec63c63ca81e0f73ffe4daa10a0c.camel@redhat.com> Message-ID: <20201214180650.GE44763@rincewind> On 17:37 Mon 14 Dec , Severin Gehwolf wrote: > On Mon, 2020-12-14 at 12:11 +0100, Severin Gehwolf wrote: > > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230388/02/webrev/ > > I should mention that is is now applying clean (with fuzz) post path > adjustments. > > Thanks, > Severin > I was going to ask if it did in response to your first mail :-) Feel free to flag this for approval and I'll approve. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Dec 14 18:24:20 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 14 Dec 2020 18:24:20 +0000 Subject: [8u] RFR: 8258241: [8u] Missing doPrivileged() hunks from JDK-8226575 In-Reply-To: <18312a23d33edcddf37ba32545bc4b6526e877b6.camel@redhat.com> References: <18312a23d33edcddf37ba32545bc4b6526e877b6.camel@redhat.com> Message-ID: <20201214182420.GF44763@rincewind> On 18:22 Mon 14 Dec , Severin Gehwolf wrote: > Hi, > > Please review this 8u-only bug affecting the current jdk8u-dev tree. > We've backported JDK-8226575 and later JDK-8217338. Since JDK-8217338 > wasn't present in 8u at the time one hunk got omitted. This patch > brings code-bases in sync. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258241 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8258241/01/webrev/ > > I've gone over the JDK 11 patch of 8226575 again and haven't found any > other discrepancies. > > Thoughts? > > Thanks, > Severin > Makes sense and looks good to me. Please flag for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Mon Dec 14 19:17:19 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 14 Dec 2020 20:17:19 +0100 Subject: [8u] RFR: 8230388: Problemlist additional compiler/rtm tests In-Reply-To: <20201214180650.GE44763@rincewind> References: <20201211155419.GB1323090@rincewind> <20201211165356.GF1323090@rincewind> <77ced259ecbbec63c63ca81e0f73ffe4daa10a0c.camel@redhat.com> <20201214180650.GE44763@rincewind> Message-ID: On Mon, 2020-12-14 at 18:06 +0000, Andrew Hughes wrote: > Feel free to flag this for approval and I'll approve. Done. Thanks, Severin From sgehwolf at redhat.com Mon Dec 14 19:18:31 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 14 Dec 2020 20:18:31 +0100 Subject: [8u] RFR: 8258241: [8u] Missing doPrivileged() hunks from JDK-8226575 In-Reply-To: <20201214182420.GF44763@rincewind> References: <18312a23d33edcddf37ba32545bc4b6526e877b6.camel@redhat.com> <20201214182420.GF44763@rincewind> Message-ID: <132c09742aabce256c75fdbc0fa2dff6231d800b.camel@redhat.com> On Mon, 2020-12-14 at 18:24 +0000, Andrew Hughes wrote: > Makes sense and looks good to me. Please flag for approval. Thanks for the review! Flagged for approval. Cheers, Severin From christoph.langer at sap.com Tue Dec 15 07:44:58 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 15 Dec 2020 07:44:58 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: <20201211170313.GH1323090@rincewind> References: <20201211170313.GH1323090@rincewind> Message-ID: Hi Andrew, sorry for being late on this discussion, I just now found the time to go through the mail thread on 8u-dev in detail. But, hold on, why are you proposing this change to the process? What issues are you aiming to solve? So far, and it has worked very well at least in 11u, the process was to add fix request labels in the parent/master bug that is to be backported. Also, when somebody wants/needs to claim that they are working on a backport, they would claim it in a comment on the master bug. Eventually, this comment could also be modified to be the actual "Fix Request" comment with more details for the approver. For most cases, there is no need to create a backport item in advance as hgupdater will create it at the moment the backport is pushed. Exceptions are when e.g. CSRs have to be done. So, after all, we should not encourage to create backport items in advance. This can as well lead to orphaned items, e.g. when the person doing the backport then steps away and forgets about it or when the target release is labeled wrong and hgupdater creates another bug, leaving the intended backport alone. I know about the issues with 8-pool and 11-pool. For 8-pool, resolving OpenJDK backport releases doesn't work at all. And for 11-pool there's a danger that hgupdater will seize a backport that is intended for OpenJDK 11u backports when Oracle does a backport at the same time. Both can be circumvented by explicitly specifying the intended target update release, such as "openjdk8u291" or "11.0.11". In that case, however, there's a certain danger if the backporter misses a release and pushes the backport to a different release than set at the backport. Then a fresh backport issue would be created and the already existing one gets orphaned. So, both approaches have potential issues and need specific attention by the committers. Hence the safest way is to not open a backport bug at all and let hgupdater do the work whenever possible. As for the issue of copying all the labels to backport bugs, especially those fix request/approval labels that will flood the open/unpushed backport lists, that is a known issue. The Skara tooling has addressed this already ([0], [1]), so for 13u this isn't an issue any longer. And for 11u this will be solved once we go to Skara (Another reason for not waiting too long until migrating to Skara with 11u ??). So, after all, my opinion is: Please don't do this thing with the backport bugs. Not as a general process guideline. All the discussions and even the transient "jdk8u-andrew" and "jdk8u-needs-review" labels ought to be done on the main item. I would also hope that we could agree to have a consistent process between 11u and 8u that avoids these manual backport bugs. Thanks & Best regards Christoph [0] https://bugs.openjdk.java.net/browse/SKARA-819 [1] https://github.com/openjdk/skara/commit/4d1bcbac9f97925d68b5f5dbb3d0dbc91bdbb420 > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Hughes > Sent: Freitag, 11. Dezember 2020 18:03 > To: jdk-updates-dev at openjdk.java.net > Subject: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] > > Forwarding for wider input. > > The Oracle text on adding fix request labels specifies to use the > parent bug, but this has rarely been an issue in practice because > we've not been creating backport bugs ahead of time. > > So do people have a preference for using the backport bug or > the parent bug for fix requests? > > The latter is easier for us maintainers, but we are a small > group compared with that of all contributors. > > ----- Forwarded message from Andrew Hughes > ----- > > Date: Fri, 11 Dec 2020 15:41:43 +0000 > From: Andrew Hughes > To: Severin Gehwolf > Subject: Re: OpenJDK 8u and Backport Bugs > User-Agent: Mutt/1.10.1 (2018-07-13) > > On 11:33 Fri 11 Dec , Severin Gehwolf wrote: > > Hi Andrew, > > > > On Fri, 2020-12-11 at 04:41 +0000, Andrew Hughes wrote: > > > Hi all, > > > > > > We've worked out a way we can create backport bugs for OpenJDK 8u > > > issues and have them correctly resolved by hgupdater. > > > > > > For 8u, '8-pool' doesn't work as '11-pool' does with OpenJDK 11u. I > > > assume this is because '8-pool' is assumed to refer to the Oracle fork > > > of 8u, which also use 8u281, 8u291, etc. Sadly, a generic 'openjdk8u' > > > seems not to work either. > > > > > > What does work is using the specific version of 'openjdk8ux'. We > > > therefore propose the following, and I have updated the wiki to > > > correspond with this: > > > > > > 1. When work is started on a backport, create a backport bug as follows: > > > ? a. Log in to the OpenJDK bug database and go to the bug you want to > backport. > > > ? b. Click More ? Create Backport > > > ? c. Set yourself as the Assignee and change Fix Version to 'openjdk8u'. > > > ? d. On the new bug, clear the inherited 'Affected Versions' and labels. > > > ? e. Set 'Affected Versions' to 'openjdk8u' > > > ? f. Add any desired labels, such as 'jdk8u-', to the bug, > > > ? where is your OpenJDK username. > > > > > > 2. Proceed as usual, but apply the jdk8u-needs-review label and make > > > approval requests on the backport bug.? This avoids the issue where > > > labels on the parent issue are cloned to other bugs. > > > > While point 2) would avoid the need to remove a couple of additional > > labels when the backport bug is being created, it doesn't really avoid > > the need of "clearing labels" entirely. There are very few bugs without > > labels at all. > > > > Also, the master bug serves as the place were all the info is being > > gathered. This is usefull, since the JDK 11 backporting info would be > > on the same bug as any JDK 8 backporting info. Doing certain labels on > > an explicit backport bug breaks this. Adding the label on the backport > > bug also suggests to add the "Fix Request" comment to the backport bug, > > moving further info away from the main bug. With my maintainer hat on, > > it's easier to do approvals by looking at the master bug directly and > > see how decisions panned out for other releases. > > > > For those reasons I think we should keep this part as-is: Keep applying > > the jdk8u-fix-request label to the master bug. Clearing 2-ish labels > > when creating the backport bug should be fine. I'd be happy to do that > > if people forget. > > > > Besides, the intention would be to create the backport bug as soon as > > somebody starts working on it. At that point, no jdk8u-fix-request > > label should be there anyway and, thus, would only apply if JDK 11u > > adopted this process too. Maybe I'm missing something. > > > > Thanks, > > Severin > > > > Yeah, #2 is after the backport bug has been created. What I'm referring to > with "labels on the parent issue are cloned to other bugs" is a backport bug > being created for another release. For example, I've seen bugs for Oracle > backports appear in our queue because they get jdk8u-fix-request added by > the cloning process. Even though they also have jdk8u-fix-yes, they don't > match the filter because of the fix version not being an OpenJDK 8u one. > > The same would happen if the 13u backport was done after 8u too. > Ideally, 8u should be the last, but that doesn't always happen. 7u may > want to adopt this process too and that would be an issue there. > > I'm aware that it's a bit of a pain when it comes to approving the > bug, but that's something that really only affects the three of us > acting as maintainers and can be worked around easily by opening the > parent bug. I think it's simpler and less confusing for someone > working on the bug to have one bug to work with, not having to flick > between two. Also, having their own 8u backport bug will hopefully > encourage them to make it their own and not worry about adding to a > bug shared by many others. > > I don't know how much of an issue bug noise is for people who aren't > interested in the 8u backport process, but this would reduce it. > > So, I'd like some feedback from others before making a decision here. > It doesn't seem a good idea to base the decision just on what works > best for us as maintainers. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > > > ----- End forwarded message ----- > > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Tue Dec 15 08:52:51 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 15 Dec 2020 09:52:51 +0100 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: References: <20201211170313.GH1323090@rincewind> Message-ID: Hi Christoph, On Tue, 2020-12-15 at 07:44 +0000, Langer, Christoph wrote: > Hi Andrew, > > sorry for being late on this discussion, I just now found the time to > go through the mail thread on 8u-dev in detail. But, hold on, why are > you proposing this change to the process? What issues are you aiming > to solve? We need a way to distribute backporting work. The intention is to solve a couple of problems with it: * Allow for proper reporting. Time a backport bug gets opened until it is resolved kind of metrics. Using labels for this isn't working as well (less structure). * Assign specific backport issues to a certain user. This is a more formal > So far, and it has worked very well at least in 11u, the process was > to add fix request labels in the parent/master bug that is to be > backported. Also, when somebody wants/needs to claim that they are > working on a backport, they would claim it in a comment on the master > bug. Eventually, this comment could also be modified to be the actual > "Fix Request" comment with more details for the approver. > > For most cases, there is no need to create a backport item in advance > as hgupdater will create it at the moment the backport is pushed. > Exceptions are when e.g. CSRs have to be done. So, after all, we > should not encourage to create backport items in advance. This can as > well lead to orphaned items, e.g. when the person doing the backport > then steps away and forgets about it or when the target release is > labeled wrong and hgupdater creates another bug, leaving the intended > backport alone. > > I know about the issues with 8-pool and 11-pool. For 8-pool, > resolving OpenJDK backport releases doesn't work at all. And for 11- > pool there's a danger that hgupdater will seize a backport that is > intended for OpenJDK 11u backports when Oracle does a backport at the > same time. Both can be circumvented by explicitly specifying the > intended target update release, such as "openjdk8u291" or "11.0.11". > In that case, however, there's a certain danger if the backporter > misses a release and pushes the backport to a different release than > set at the backport. Then a fresh backport issue would be created and > the already existing one gets orphaned. So, both approaches have > potential issues and need specific attention by the committers. Hence > the safest way is to not open a backport bug at all and let hgupdater > do the work whenever possible. > > As for the issue of copying all the labels to backport bugs, > especially those fix request/approval labels that will flood the > open/unpushed backport lists, that is a known issue. The Skara > tooling has addressed this already ([0], [1]), so for 13u this isn't > an issue any longer. And for 11u this will be solved once we go to > Skara (Another reason for not waiting too long until migrating to > Skara with 11u ??). > > So, after all, my opinion is: Please don't do this thing with the > backport bugs. Not as a general process guideline. All the > discussions and even the transient "jdk8u-andrew" and "jdk8u-needs- > review" labels ought to be done on the main item. > > I would also hope that we could agree to have a consistent process > between 11u and 8u that avoids these manual backport bugs. > > Thanks & Best regards > Christoph > > [0] https://bugs.openjdk.java.net/browse/SKARA-819 > [1] > https://github.com/openjdk/skara/commit/4d1bcbac9f97925d68b5f5dbb3d0dbc91bdbb420 > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Andrew Hughes > > Sent: Freitag, 11. Dezember 2020 18:03 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] > > > > Forwarding for wider input. > > > > The Oracle text on adding fix request labels specifies to use the > > parent bug, but this has rarely been an issue in practice because > > we've not been creating backport bugs ahead of time. > > > > So do people have a preference for using the backport bug or > > the parent bug for fix requests? > > > > The latter is easier for us maintainers, but we are a small > > group compared with that of all contributors. > > > > ----- Forwarded message from Andrew Hughes > > ----- > > > > Date: Fri, 11 Dec 2020 15:41:43 +0000 > > From: Andrew Hughes > > To: Severin Gehwolf > > Subject: Re: OpenJDK 8u and Backport Bugs > > User-Agent: Mutt/1.10.1 (2018-07-13) > > > > On 11:33 Fri 11 Dec???? , Severin Gehwolf wrote: > > > Hi Andrew, > > > > > > On Fri, 2020-12-11 at 04:41 +0000, Andrew Hughes wrote: > > > > Hi all, > > > > > > > > We've worked out a way we can create backport bugs for OpenJDK > > > > 8u > > > > issues and have them correctly resolved by hgupdater. > > > > > > > > For 8u, '8-pool' doesn't work as '11-pool' does with OpenJDK > > > > 11u. I > > > > assume this is because '8-pool' is assumed to refer to the > > > > Oracle fork > > > > of 8u, which also use 8u281, 8u291, etc. Sadly, a generic > > > > 'openjdk8u' > > > > seems not to work either. > > > > > > > > What does work is using the specific version of 'openjdk8ux'. > > > > We > > > > therefore propose the following, and I have updated the wiki to > > > > correspond with this: > > > > > > > > 1. When work is started on a backport, create a backport bug as > > > > follows: > > > > ? a. Log in to the OpenJDK bug database and go to the bug you > > > > want to > > backport. > > > > ? b. Click More ? Create Backport > > > > ? c. Set yourself as the Assignee and change Fix Version to > > > > 'openjdk8u'. > > > > ? d. On the new bug, clear the inherited 'Affected Versions' > > > > and labels. > > > > ? e. Set 'Affected Versions' to 'openjdk8u' > > > > ? f. Add any desired labels, such as 'jdk8u-', to the > > > > bug, > > > > ? where is your OpenJDK username. > > > > > > > > 2. Proceed as usual, but apply the jdk8u-needs-review label and > > > > make > > > > approval requests on the backport bug.? This avoids the issue > > > > where > > > > labels on the parent issue are cloned to other bugs. > > > > > > While point 2) would avoid the need to remove a couple of > > > additional > > > labels when the backport bug is being created, it doesn't really > > > avoid > > > the need of "clearing labels" entirely. There are very few bugs > > > without > > > labels at all. > > > > > > Also, the master bug serves as the place were all the info is > > > being > > > gathered. This is usefull, since the JDK 11 backporting info > > > would be > > > on the same bug as any JDK 8 backporting info. Doing certain > > > labels on > > > an explicit backport bug breaks this. Adding the label on the > > > backport > > > bug also suggests to add the "Fix Request" comment to the > > > backport bug, > > > moving further info away from the main bug. With my maintainer > > > hat on, > > > it's easier to do approvals by looking at the master bug directly > > > and > > > see how decisions panned out for other releases. > > > > > > For those reasons I think we should keep this part as-is: Keep > > > applying > > > the jdk8u-fix-request label to the master bug. Clearing 2-ish > > > labels > > > when creating the backport bug should be fine. I'd be happy to do > > > that > > > if people forget. > > > > > > Besides, the intention would be to create the backport bug as > > > soon as > > > somebody starts working on it. At that point, no jdk8u-fix- > > > request > > > label should be there anyway and, thus, would only apply if JDK > > > 11u > > > adopted this process too. Maybe I'm missing something. > > > > > > Thanks, > > > Severin > > > > > > > Yeah, #2 is after the backport bug has been created. What I'm > > referring to > > with "labels on the parent issue are cloned to other bugs" is a > > backport bug > > being created for another release. For example, I've seen bugs for > > Oracle > > backports appear in our queue because they get jdk8u-fix-request > > added by > > the cloning process. Even though they also have jdk8u-fix-yes, they > > don't > > match the filter because of the fix version not being an OpenJDK 8u > > one. > > > > The same would happen if the 13u backport was done after 8u too. > > Ideally, 8u should be the last, but that doesn't always happen. 7u > > may > > want to adopt this process too and that would be an issue there. > > > > I'm aware that it's a bit of a pain when it comes to approving the > > bug, but that's something that really only affects the three of us > > acting as maintainers and can be worked around easily by opening > > the > > parent bug. I think it's simpler and less confusing for someone > > working on the bug to have one bug to work with, not having to > > flick > > between two. Also, having their own 8u backport bug will hopefully > > encourage them to make it their own and not worry about adding to a > > bug shared by many others. > > > > I don't know how much of an issue bug noise is for people who > > aren't > > interested in the 8u backport process, but this would reduce it. > > > > So, I'd like some feedback from others before making a decision > > here. > > It doesn't seem a good idea to base the decision just on what works > > best for us as maintainers. > > > > Thanks, > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > OpenJDK Package Owner > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04? C5A0 CFDA 0F9B 3596 4222 > > > > > > > > ----- End forwarded message ----- > > > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > OpenJDK Package Owner > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04? C5A0 CFDA 0F9B 3596 4222 From christoph.langer at sap.com Tue Dec 15 09:10:12 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 15 Dec 2020 09:10:12 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: References: <20201211170313.GH1323090@rincewind> Message-ID: Hi Severin, > > sorry for being late on this discussion, I just now found the time to > > go through the mail thread on 8u-dev in detail. But, hold on, why are > > you proposing this change to the process? What issues are you aiming > > to solve? > > We need a way to distribute backporting work. The intention is to solve > a couple of problems with it: > > * Allow for proper reporting. Time a backport bug gets opened until it is > resolved kind of metrics. Using labels for this isn't working as well > (less structure). > * Assign specific backport issues to a certain user. This is a more > formal > ata Don't know whether your mail got cut too early and there is more to come... ?? As for those two points: I can understand them - as specific requirements for your workflow within your company, I guess. So to solve these, I think it's ok to create backport items and track them. However, it comes with the issues I described before so correctly setting and double checking of the "fixed version" field before pushing is required. Having that said, I still don't think that opening backport items in advance should be the blueprint for contributors to the JDK updates projects, as the 8u Wiki currently suggests. If at all, it should be optional. And all the maintainer labeling and fix request comments should be done in the master bug - this makes life easier for maintainers, e.g. having all the relevant discussion in one place, being able to directly opening the original commit links, seeing where the item already got backported to etc. And it also keeps information consistent and in one place. Cheers Christoph From sgehwolf at redhat.com Tue Dec 15 09:23:42 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 15 Dec 2020 10:23:42 +0100 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: References: <20201211170313.GH1323090@rincewind> Message-ID: <0f1fe66e5fa0b74ca8e1cd7b58f741d4873ab372.camel@redhat.com> Hi Christoph, Sorry, previous email escaped unintentionally... (crtl+return pressed by mistake) On Tue, 2020-12-15 at 07:44 +0000, Langer, Christoph wrote: > Hi Andrew, > > sorry for being late on this discussion, I just now found the time to > go through the mail thread on 8u-dev in detail. But, hold on, why are > you proposing this change to the process? What issues are you aiming > to solve? Note that we've largely discussed this in the context of 8u. But in general we'd like to have a process that works for most (all?) updates releases. The main goal is for us to have a way to distribute backporting work. The intention is to solve a couple of problems with it - Allow for proper reporting. Time a backport bug gets opened until it is resolved kind of metrics. Using labels for this isn't working. - Assign specific backport issues to a certain user. This is a more formal approach than labels. It has the advantage of getting email notifications when certain events happen. Like a backport bug is created and assigned to someone. Somebody other than the backporter can assign bugs. The assignee would notice this by getting email notifications. - For CSR-needing bugs we need to do the explicit backport bug anyway. It would no longer be an exception to the rule. - Commenting on the master bug that somebody is doing the backport isn't really machine readable. Getting a report quickly as to who is doing the backport is difficult, especially figuring this out for different releases. I understand this also has the drawback of an additional step (creating the explicit bug), but we haven't found an alternative solution to cover all the cases. If you've got suggestions, I'd be all ears. > So far, and it has worked very well at least in 11u, the process was > to add fix request labels in the parent/master bug that is to be > backported. Also, when somebody wants/needs to claim that they are > working on a backport, they would claim it in a comment on the master > bug. Eventually, this comment could also be modified to be the actual > "Fix Request" comment with more details for the approver. The theory is that it works well when only few people do the work. It has a scalability problem. This process is rather implicit and relies on the process knowledge of the backporter. We feel the explicit bug is easier to understand for new contributors. > For most cases, there is no need to create a backport item in advance > as hgupdater will create it at the moment the backport is pushed. > Exceptions are when e.g. CSRs have to be done. So, after all, we > should not encourage to create backport items in advance. This can as > well lead to orphaned items, e.g. when the person doing the backport > then steps away and forgets about it or when the target release is > labeled wrong and hgupdater creates another bug, leaving the intended > backport alone. Makes sense. I wonder though, how it's different to the current process. One could go comment on the bug "I'm doing a backport of this for OpenJDK X" and then step away. Note that the explicit backport bug would remain unresolved in that case. Again, it would show up in the reporting and would get flagged. > I know about the issues with 8-pool and 11-pool. For 8-pool, > resolving OpenJDK backport releases doesn't work at all. And for 11- > pool there's a danger that hgupdater will seize a backport that is > intended for OpenJDK 11u backports when Oracle does a backport at the > same time. Both can be circumvented by explicitly specifying the > intended target update release, such as "openjdk8u291" or "11.0.11". > In that case, however, there's a certain danger if the backporter > misses a release and pushes the backport to a different release than > set at the backport. Then a fresh backport issue would be created and > the already existing one gets orphaned. So, both approaches have > potential issues and need specific attention by the committers. Hence > the safest way is to not open a backport bug at all and let hgupdater > do the work whenever possible. We've been testing this in 8u with setting the explicit bug to "Fix Version" -> openjdk8u292 (current jdk8u-dev). Then the bug would get properly resolved as you say. What we thought we'd do to avoid mistakes is for the maintainer to set the version correctly when the bug gets approved for push. So it wouldn't be the backporters responsibility. For 11u it's a non-issue as 11-pool works fine. It would sometimes need coordination with Oracle, but it would be an OK compromise IMO. > As for the issue of copying all the labels to backport bugs, > especially those fix request/approval labels that will flood the > open/unpushed backport lists, that is a known issue. The Skara > tooling has addressed this already ([0], [1]), so for 13u this isn't > an issue any longer. And for 11u this will be solved once we go to > Skara (Another reason for not waiting too long until migrating to > Skara with 11u ??). Right. I'm not convinced Skara will be a solution for 8u, though. So there is that problem. > So, after all, my opinion is: Please don't do this thing with the > backport bugs. Not as a general process guideline. This isn't set in stone. Exploratory at this point. We havent't found a better way to handle bug assignments, though. > All the discussions and even the transient "jdk8u-andrew" and "jdk8u- > needs-review" labels ought to be done on the main item. I agree on that one. Hence my objection to apply the label on the backport bug. It's a departure from the general updates process workflow too. So +1 for keeping the labels on the master bugs. > I would also hope that we could agree to have a consistent process > between 11u and 8u that avoids these manual backport bugs. We are open to suggestions. In our experience the existing process isn't structured enough to do proper assignment and reporting. Doing this collaboratively is another goal. Individuals from various institutions doing the work. Thanks, Severin > Thanks & Best regards > Christoph > > [0] https://bugs.openjdk.java.net/browse/SKARA-819 > [1] > https://github.com/openjdk/skara/commit/4d1bcbac9f97925d68b5f5dbb3d0dbc91bdbb420 > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Andrew Hughes > > Sent: Freitag, 11. Dezember 2020 18:03 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] > > > > Forwarding for wider input. > > > > The Oracle text on adding fix request labels specifies to use the > > parent bug, but this has rarely been an issue in practice because > > we've not been creating backport bugs ahead of time. > > > > So do people have a preference for using the backport bug or > > the parent bug for fix requests? > > > > The latter is easier for us maintainers, but we are a small > > group compared with that of all contributors. > > > > ----- Forwarded message from Andrew Hughes > > ----- > > > > Date: Fri, 11 Dec 2020 15:41:43 +0000 > > From: Andrew Hughes > > To: Severin Gehwolf > > Subject: Re: OpenJDK 8u and Backport Bugs > > User-Agent: Mutt/1.10.1 (2018-07-13) > > > > On 11:33 Fri 11 Dec???? , Severin Gehwolf wrote: > > > Hi Andrew, > > > > > > On Fri, 2020-12-11 at 04:41 +0000, Andrew Hughes wrote: > > > > Hi all, > > > > > > > > We've worked out a way we can create backport bugs for OpenJDK > > > > 8u > > > > issues and have them correctly resolved by hgupdater. > > > > > > > > For 8u, '8-pool' doesn't work as '11-pool' does with OpenJDK > > > > 11u. I > > > > assume this is because '8-pool' is assumed to refer to the > > > > Oracle fork > > > > of 8u, which also use 8u281, 8u291, etc. Sadly, a generic > > > > 'openjdk8u' > > > > seems not to work either. > > > > > > > > What does work is using the specific version of 'openjdk8ux'. > > > > We > > > > therefore propose the following, and I have updated the wiki to > > > > correspond with this: > > > > > > > > 1. When work is started on a backport, create a backport bug as > > > > follows: > > > > ? a. Log in to the OpenJDK bug database and go to the bug you > > > > want to > > backport. > > > > ? b. Click More ? Create Backport > > > > ? c. Set yourself as the Assignee and change Fix Version to > > > > 'openjdk8u'. > > > > ? d. On the new bug, clear the inherited 'Affected Versions' > > > > and labels. > > > > ? e. Set 'Affected Versions' to 'openjdk8u' > > > > ? f. Add any desired labels, such as 'jdk8u-', to the > > > > bug, > > > > ? where is your OpenJDK username. > > > > > > > > 2. Proceed as usual, but apply the jdk8u-needs-review label and > > > > make > > > > approval requests on the backport bug.? This avoids the issue > > > > where > > > > labels on the parent issue are cloned to other bugs. > > > > > > While point 2) would avoid the need to remove a couple of > > > additional > > > labels when the backport bug is being created, it doesn't really > > > avoid > > > the need of "clearing labels" entirely. There are very few bugs > > > without > > > labels at all. > > > > > > Also, the master bug serves as the place were all the info is > > > being > > > gathered. This is usefull, since the JDK 11 backporting info > > > would be > > > on the same bug as any JDK 8 backporting info. Doing certain > > > labels on > > > an explicit backport bug breaks this. Adding the label on the > > > backport > > > bug also suggests to add the "Fix Request" comment to the > > > backport bug, > > > moving further info away from the main bug. With my maintainer > > > hat on, > > > it's easier to do approvals by looking at the master bug directly > > > and > > > see how decisions panned out for other releases. > > > > > > For those reasons I think we should keep this part as-is: Keep > > > applying > > > the jdk8u-fix-request label to the master bug. Clearing 2-ish > > > labels > > > when creating the backport bug should be fine. I'd be happy to do > > > that > > > if people forget. > > > > > > Besides, the intention would be to create the backport bug as > > > soon as > > > somebody starts working on it. At that point, no jdk8u-fix- > > > request > > > label should be there anyway and, thus, would only apply if JDK > > > 11u > > > adopted this process too. Maybe I'm missing something. > > > > > > Thanks, > > > Severin > > > > > > > Yeah, #2 is after the backport bug has been created. What I'm > > referring to > > with "labels on the parent issue are cloned to other bugs" is a > > backport bug > > being created for another release. For example, I've seen bugs for > > Oracle > > backports appear in our queue because they get jdk8u-fix-request > > added by > > the cloning process. Even though they also have jdk8u-fix-yes, they > > don't > > match the filter because of the fix version not being an OpenJDK 8u > > one. > > > > The same would happen if the 13u backport was done after 8u too. > > Ideally, 8u should be the last, but that doesn't always happen. 7u > > may > > want to adopt this process too and that would be an issue there. > > > > I'm aware that it's a bit of a pain when it comes to approving the > > bug, but that's something that really only affects the three of us > > acting as maintainers and can be worked around easily by opening > > the > > parent bug. I think it's simpler and less confusing for someone > > working on the bug to have one bug to work with, not having to > > flick > > between two. Also, having their own 8u backport bug will hopefully > > encourage them to make it their own and not worry about adding to a > > bug shared by many others. > > > > I don't know how much of an issue bug noise is for people who > > aren't > > interested in the 8u backport process, but this would reduce it. > > > > So, I'd like some feedback from others before making a decision > > here. > > It doesn't seem a good idea to base the decision just on what works > > best for us as maintainers. > > > > Thanks, > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > OpenJDK Package Owner > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04? C5A0 CFDA 0F9B 3596 4222 > > > > > > > > ----- End forwarded message ----- > > > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > OpenJDK Package Owner > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04? C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Tue Dec 15 09:37:22 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 15 Dec 2020 10:37:22 +0100 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: References: <20201211170313.GH1323090@rincewind> Message-ID: <94db405b4203692cc3a0c89d078be4d1c1982706.camel@redhat.com> On Tue, 2020-12-15 at 09:10 +0000, Langer, Christoph wrote: > Hi Severin, > > > > sorry for being late on this discussion, I just now found the time to > > > go through the mail thread on 8u-dev in detail. But, hold on, why are > > > you proposing this change to the process? What issues are you aiming > > > to solve? > > > > We need a way to distribute backporting work. The intention is to solve > > a couple of problems with it: > > > > ?* Allow for proper reporting. Time a backport bug gets opened until it is > > ?? resolved kind of metrics. Using labels for this isn't working as > > well (less structure). > > ?* Assign specific backport issues to a certain user. This is a > > more formal > > > ata > Don't know whether your mail got cut too early and there is more to > come... ?? Sorry, yes. > As for those two points: I can understand them - as specific > requirements for your workflow within your company, I guess. So to > solve these, I think it's ok to create backport items and track them. That's the point. It shouldn't be a solution for one institution only. It should be a solution where people across different companies can participate and know who is doing what. > However, it comes with the issues I described before so correctly > setting and double checking of the "fixed version" field before > pushing is required. Yes. It would entail a bit more work for maintainers. To set the fix version accordingly (if it's not correct already). For 11u I don't anticipate this being a huge problem as 11-pool bugs get resolved properly on push. > Having that said, I still don't think that opening backport items in > advance should be the blueprint for contributors to the JDK updates > projects, as the 8u Wiki currently suggests. If at all, it should be > optional. One issue I'd see with making this optional is that the entire proces falls short figuring out stale issues, knowing current assignees etc. > And all the maintainer labeling and fix request comments should be > done in the master bug - this makes life easier for maintainers, e.g. > having all the relevant discussion in one place, being able to > directly opening the original commit links, seeing where the item > already got backported to etc. And it also keeps information > consistent and in one place. Agreed. This shouldn't change IMO. FWIW, Andrew's argument was that it inconveniences a few poeple (maintainers) by reducing the number of labels needing to get removed by more (developers). I'm not convinced this argument is sound as there are few bugs without labels (even if the bug was in jdk-head only). We are aware that the proposal isn't a perfect solution. Again, open to suggestions. Thanks, Severin From christoph.langer at sap.com Tue Dec 15 10:20:11 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 15 Dec 2020 10:20:11 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: <0f1fe66e5fa0b74ca8e1cd7b58f741d4873ab372.camel@redhat.com> References: <20201211170313.GH1323090@rincewind> <0f1fe66e5fa0b74ca8e1cd7b58f741d4873ab372.camel@redhat.com> Message-ID: Hi Severin, > > sorry for being late on this discussion, I just now found the time to > > go through the mail thread on 8u-dev in detail. But, hold on, why are > > you proposing this change to the process? What issues are you aiming > > to solve? > > Note that we've largely discussed this in the context of 8u. But in > general we'd like to have a process that works for most (all?) updates > releases. I wasn't aware of this discussion - I just saw the mails from last Friday. > The main goal is for us to have a way to distribute backporting work. > The intention is to solve a couple of problems with it > > - Allow for proper reporting. Time a backport bug gets opened until > it is resolved kind of metrics. Using labels for this isn't working. > - Assign specific backport issues to a certain user. This is a more > formal approach than labels. It has the advantage of getting email > notifications when certain events happen. Like a backport bug is > created and assigned to someone. Somebody other than the backporter > can assign bugs. The assignee would notice this by getting email > notifications. > - For CSR-needing bugs we need to do the explicit backport bug > anyway. It would no longer be an exception to the rule. > - Commenting on the master bug that somebody is doing the backport > isn't really machine readable. Getting a report quickly as to who > is doing the backport is difficult, especially figuring this out > for different releases. > > I understand this also has the drawback of an additional step (creating > the explicit bug), but we haven't found an alternative solution to > cover all the cases. If you've got suggestions, I'd be all ears. I can see your points. > > So far, and it has worked very well at least in 11u, the process was > > to add fix request labels in the parent/master bug that is to be > > backported. Also, when somebody wants/needs to claim that they are > > working on a backport, they would claim it in a comment on the master > > bug. Eventually, this comment could also be modified to be the actual > > "Fix Request" comment with more details for the approver. > > The theory is that it works well when only few people do the work. It > has a scalability problem. This process is rather implicit and relies > on the process knowledge of the backporter. We feel the explicit bug is > easier to understand for new contributors. I think there's always some process to be understood when one wants to contribute to OpenJDK updates maintenance. I at least can't see any major improvement when I have to check linked backports vs. comments in an issue. > > > For most cases, there is no need to create a backport item in advance > > as hgupdater will create it at the moment the backport is pushed. > > Exceptions are when e.g. CSRs have to be done. So, after all, we > > should not encourage to create backport items in advance. This can as > > well lead to orphaned items, e.g. when the person doing the backport > > then steps away and forgets about it or when the target release is > > labeled wrong and hgupdater creates another bug, leaving the intended > > backport alone. > > Makes sense. I wonder though, how it's different to the current > process. One could go comment on the bug "I'm doing a backport of this > for OpenJDK X" and then step away. Note that the explicit backport bug > would remain unresolved in that case. Again, it would show up in the > reporting and would get flagged. > > > I know about the issues with 8-pool and 11-pool. For 8-pool, > > resolving OpenJDK backport releases doesn't work at all. And for 11- > > pool there's a danger that hgupdater will seize a backport that is > > intended for OpenJDK 11u backports when Oracle does a backport at the > > same time. Both can be circumvented by explicitly specifying the > > intended target update release, such as "openjdk8u291" or "11.0.11". > > In that case, however, there's a certain danger if the backporter > > misses a release and pushes the backport to a different release than > > set at the backport. Then a fresh backport issue would be created and > > the already existing one gets orphaned. So, both approaches have > > potential issues and need specific attention by the committers. Hence > > the safest way is to not open a backport bug at all and let hgupdater > > do the work whenever possible. > > We've been testing this in 8u with setting the explicit bug to "Fix > Version" -> openjdk8u292 (current jdk8u-dev). Then the bug would get > properly resolved as you say. What we thought we'd do to avoid mistakes > is for the maintainer to set the version correctly when the bug gets > approved for push. So it wouldn't be the backporters responsibility. > For 11u it's a non-issue as 11-pool works fine. It would sometimes need > coordination with Oracle, but it would be an OK compromise IMO. I think actually 11-pool is a major issue here since there will be conflicts with Oracle. Especially for backport items that are open for a long time as once can never know if and when Oracle does backports and whether their engineer will also check JBS at the time of pushing. So, if we manually create the backport items, we should then set the intended target version explicitly. In fact, this seems to be what Oracle does as well. When they are working on a backport, they also sometimes create backport items with a certain target version. This would make life easier for the maintainers as well as they will only have to check whether the version is set correctly. > > As for the issue of copying all the labels to backport bugs, > > especially those fix request/approval labels that will flood the > > open/unpushed backport lists, that is a known issue. The Skara > > tooling has addressed this already ([0], [1]), so for 13u this isn't > > an issue any longer. And for 11u this will be solved once we go to > > Skara (Another reason for not waiting too long until migrating to > > Skara with 11u ??). > > Right. I'm not convinced Skara will be a solution for 8u, though. So > there is that problem. But 8u is only at the end of the chain... If no release higher than 8 generates this bug pollution, I think 8 won't suffer. > > So, after all, my opinion is: Please don't do this thing with the > > backport bugs. Not as a general process guideline. > > This isn't set in stone. Exploratory at this point. We havent't found a > better way to handle bug assignments, though. Yep, it needs some further discussion/refinement probably. > > All the discussions and even the transient "jdk8u-andrew" and "jdk8u- > > needs-review" labels ought to be done on the main item. > > I agree on that one. Hence my objection to apply the label on the > backport bug. It's a departure from the general updates process > workflow too. So +1 for keeping the labels on the master bugs. Great ?? Best regards Christoph From aph at redhat.com Tue Dec 15 10:24:48 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Dec 2020 10:24:48 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: <94db405b4203692cc3a0c89d078be4d1c1982706.camel@redhat.com> References: <20201211170313.GH1323090@rincewind> <94db405b4203692cc3a0c89d078be4d1c1982706.camel@redhat.com> Message-ID: On 15/12/2020 09:37, Severin Gehwolf wrote: > We are aware that the proposal isn't a perfect solution. Again, open to > suggestions. We must find a way for organizations and individual contributors to work without falling over each other. It should be possible for anyone to see what releases are being targeted and what work is in progress. And, of course, we don't want unnecessary overheads. In particular, semi-casual developers should be able to contribute to a backport release without having to learn much in the way of special processes. I don't think we should exclude Skara as a solution to these issues. It seems to have many of the features we need, and is the standard OpenJDK workflow. I know of no reason that moving JDK 8u to Skara would be any more difficult than moving anything else. We operate on the principle of a broad consensus, and we also should make sure that we don't end up with divergent processes for JDK 8 and 11. Whatever policy we decide on requires agreement between Red Hat, SAP, and others. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue Dec 15 10:46:17 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 15 Dec 2020 10:46:17 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: <94db405b4203692cc3a0c89d078be4d1c1982706.camel@redhat.com> References: <20201211170313.GH1323090@rincewind> <94db405b4203692cc3a0c89d078be4d1c1982706.camel@redhat.com> Message-ID: Hi, most of my comments have already been made in the other mail. > > As for those two points: I can understand them - as specific > > requirements for your workflow within your company, I guess. So to > > solve these, I think it's ok to create backport items and track them. > > That's the point. It shouldn't be a solution for one institution only. > It should be a solution where people across different companies can > participate and know who is doing what. > > > However, it comes with the issues I described before so correctly > > setting and double checking of the "fixed version" field before > > pushing is required. > > Yes. It would entail a bit more work for maintainers. To set the fix > version accordingly (if it's not correct already). For 11u I don't > anticipate this being a huge problem as 11-pool bugs get resolved > properly on push. As written in the other mail, I would then not use 11-pool but set the desired target version explicitly. This will avoid conflicts with Oracle backports as well as make life easier for maintainers who will only have to check whether the entered target is correct. Maintainers would then only need to modify target versions in case they change it explicitly for a reason. > > Having that said, I still don't think that opening backport items in > > advance should be the blueprint for contributors to the JDK updates > > projects, as the 8u Wiki currently suggests. If at all, it should be > > optional. > > One issue I'd see with making this optional is that the entire proces > falls short figuring out stale issues, knowing current assignees etc. I don't think so. As a human when you check the backport status of the bug, you first look at linked backport items and then go through the comments. You'll easily see whether it was already backported, somebody is working on it (or not) or if the backport got stale because somebody claimed to be doing it and then went away. The only valid point is that a machine generated report can only easily report on linked backport items. But I'm not sure whether this kind of reportability is worth mandating the effort of maintaining manual backport bugs for every single contributor while most of them won't be interested in such statistics. And at the end, when the backports are done, the traceable backport items will have been generated by hgupdater anyway. I can only see the benefit if inside your organization you want/need to track the work of backport assignees. So, I still see the backport bugs only as optional, not a must. Cheers Christoph From sgehwolf at redhat.com Tue Dec 15 11:06:54 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 15 Dec 2020 12:06:54 +0100 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: References: <20201211170313.GH1323090@rincewind> <0f1fe66e5fa0b74ca8e1cd7b58f741d4873ab372.camel@redhat.com> Message-ID: <05201e7d481acb344683ab071bada500f77b44fb.camel@redhat.com> On Tue, 2020-12-15 at 10:20 +0000, Langer, Christoph wrote: > Hi Severin, > > > > sorry for being late on this discussion, I just now found the time to > > > go through the mail thread on 8u-dev in detail. But, hold on, why are > > > you proposing this change to the process? What issues are you aiming > > > to solve? > > > > Note that we've largely discussed this in the context of 8u. But in > > general we'd like to have a process that works for most (all?) updates > > releases. > > I wasn't aware of this discussion - I just saw the mails from last Friday. > > > The main goal is for us to have a way to distribute backporting work. > > The intention is to solve a couple of problems with it > > > > - Allow for proper reporting. Time a backport bug gets opened until > > ? it is resolved kind of metrics. Using labels for this isn't working. > > - Assign specific backport issues to a certain user. This is a more > > ? formal approach than labels. It has the advantage of getting email > > ? notifications when certain events happen. Like a backport bug is > > ? created and assigned to someone. Somebody other than the backporter > > ? can assign bugs. The assignee would notice this by getting email > > ? notifications. > > - For CSR-needing bugs we need to do the explicit backport bug > > ? anyway. It would no longer be an exception to the rule. > > - Commenting on the master bug that somebody is doing the backport > > ? isn't really machine readable. Getting a report quickly as to who > > ? is doing the backport is difficult, especially figuring this out > > ? for different releases. > > > > I understand this also has the drawback of an additional step (creating > > the explicit bug), but we haven't found an alternative solution to > > cover all the cases. If you've got suggestions, I'd be all ears. > > I can see your points. > > > > So far, and it has worked very well at least in 11u, the process was > > > to add fix request labels in the parent/master bug that is to be > > > backported. Also, when somebody wants/needs to claim that they are > > > working on a backport, they would claim it in a comment on the master > > > bug. Eventually, this comment could also be modified to be the actual > > > "Fix Request" comment with more details for the approver. > > > > The theory is that it works well when only few people do the work. It > > has a scalability problem. This process is rather implicit and relies > > on the process knowledge of the backporter. We feel the explicit bug is > > easier to understand for new contributors. > > I think there's always some process to be understood when one wants > to contribute to OpenJDK updates maintenance. I at least can't see > any major improvement when I have to check linked backports vs. > comments in an issue. Agreed. There shouldn't be a need to check both: The master bug *and* the backport bug. Keeping relevant things for approval and decision making in the master bug makes sense. Right now the only difference would be to create an explicit backport bug for tracking/assigning people. > > > > > For most cases, there is no need to create a backport item in advance > > > as hgupdater will create it at the moment the backport is pushed. > > > Exceptions are when e.g. CSRs have to be done. So, after all, we > > > should not encourage to create backport items in advance. This can as > > > well lead to orphaned items, e.g. when the person doing the backport > > > then steps away and forgets about it or when the target release is > > > labeled wrong and hgupdater creates another bug, leaving the intended > > > backport alone. > > > > Makes sense. I wonder though, how it's different to the current > > process. One could go comment on the bug "I'm doing a backport of this > > for OpenJDK X" and then step away. Note that the explicit backport bug > > would remain unresolved in that case. Again, it would show up in the > > reporting and would get flagged. > > > > > I know about the issues with 8-pool and 11-pool. For 8-pool, > > > resolving OpenJDK backport releases doesn't work at all. And for > > > 11- > > > pool there's a danger that hgupdater will seize a backport that > > > is > > > intended for OpenJDK 11u backports when Oracle does a backport at > > > the > > > same time. Both can be circumvented by explicitly specifying the > > > intended target update release, such as "openjdk8u291" or > > > "11.0.11". > > > In that case, however, there's a certain danger if the backporter > > > misses a release and pushes the backport to a different release > > > than > > > set at the backport. Then a fresh backport issue would be created > > > and > > > the already existing one gets orphaned. So, both approaches have > > > potential issues and need specific attention by the committers. > > > Hence > > > the safest way is to not open a backport bug at all and let > > > hgupdater > > > do the work whenever possible. > > > > We've been testing this in 8u with setting the explicit bug to "Fix > > Version" -> openjdk8u292 (current jdk8u-dev). Then the bug would get > > properly resolved as you say. What we thought we'd do to avoid mistakes > > is for the maintainer to set the version correctly when the bug gets > > approved for push. So it wouldn't be the backporters responsibility. > > For 11u it's a non-issue as 11-pool works fine. It would sometimes need > > coordination with Oracle, but it would be an OK compromise IMO. > > I think actually 11-pool is a major issue here since there will be > conflicts with Oracle. Especially for backport items that are open > for a long time as once can never know if and when Oracle does > backports and whether their engineer will also check JBS at the time > of pushing. So, if we manually create the backport items, we should > then set the intended target version explicitly. In fact, this seems > to be what Oracle does as well. When they are working on a backport, > they also sometimes create backport items with a certain target > version. This would make life easier for the maintainers as well as > they will only have to check whether the version is set correctly. OK. So is the concern that by creating explicit backport bugs, setting Fix Version to "11-pool" makes it indistinguishable from a bug created by Oracle for their work? Setting the fix version to something like 11.0.11 (current jdk11u-dev) seems fine to me if that alleviates the concern. My understanding was that 11-pool bugs would be OpenJDK 11 bugs. Perhaps that's not the case. > > > > As for the issue of copying all the labels to backport bugs, > > > especially those fix request/approval labels that will flood the > > > open/unpushed backport lists, that is a known issue. The Skara > > > tooling has addressed this already ([0], [1]), so for 13u this isn't > > > an issue any longer. And for 11u this will be solved once we go to > > > Skara (Another reason for not waiting too long until migrating to > > > Skara with 11u ??). > > > > Right. I'm not convinced Skara will be a solution for 8u, though. So > > there is that problem. Perhaps we shouldn't rule out Skara :) It might well be part of the solution. I should keep an open mind about that. Mea culpa. > But 8u is only at the end of the chain... If no release higher than 8 > generates this bug pollution, I think 8 won't suffer. I'm not sure how skara would address the bug-distribution/assignment issue, though. Do you know of something that would handle it? > > Thanks, Severin From christoph.langer at sap.com Tue Dec 15 15:44:57 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 15 Dec 2020 15:44:57 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: <05201e7d481acb344683ab071bada500f77b44fb.camel@redhat.com> References: <20201211170313.GH1323090@rincewind> <0f1fe66e5fa0b74ca8e1cd7b58f741d4873ab372.camel@redhat.com> <05201e7d481acb344683ab071bada500f77b44fb.camel@redhat.com> Message-ID: Hi Severin, > > I think actually 11-pool is a major issue here since there will be > > conflicts with Oracle. Especially for backport items that are open > > for a long time as once can never know if and when Oracle does > > backports and whether their engineer will also check JBS at the time > > of pushing. So, if we manually create the backport items, we should > > then set the intended target version explicitly. In fact, this seems > > to be what Oracle does as well. When they are working on a backport, > > they also sometimes create backport items with a certain target > > version. This would make life easier for the maintainers as well as > > they will only have to check whether the version is set correctly. > > OK. So is the concern that by creating explicit backport bugs, setting > Fix Version to "11-pool" makes it indistinguishable from a bug created > by Oracle for their work? Setting the fix version to something like > 11.0.11 (current jdk11u-dev) seems fine to me if that alleviates the > concern. > > My understanding was that 11-pool bugs would be OpenJDK 11 bugs. > Perhaps that's not the case. > As far as I know, 11-pool works for both, Oracle and OpenJDK 11 update releases. So if somebody pushes a change to either openjdk 11u/11u-dev or any of Oracle's 11 branches, hgupdate goes and resolves open 11-pool backport as it finds them. (If none of the explicit fix version is present) > > > > As for the issue of copying all the labels to backport bugs, > > > > especially those fix request/approval labels that will flood the > > > > open/unpushed backport lists, that is a known issue. The Skara > > > > tooling has addressed this already ([0], [1]), so for 13u this isn't > > > > an issue any longer. And for 11u this will be solved once we go to > > > > Skara (Another reason for not waiting too long until migrating to > > > > Skara with 11u ??). > > > > > > Right. I'm not convinced Skara will be a solution for 8u, though. So > > > there is that problem. > > Perhaps we shouldn't rule out Skara :) It might well be part of the > solution. I should keep an open mind about that. Mea culpa. > > > But 8u is only at the end of the chain... If no release higher than 8 > > generates this bug pollution, I think 8 won't suffer. > > I'm not sure how skara would address the bug-distribution/assignment > issue, though. Do you know of something that would handle it? When talking of the benefits of Skara I had in mind that it would not unnecessarily copy labels to the backport bugs. But actually it's a good question how in the Skara workflow open backport bugs are handled. I would assume these get resolved in a similar manner like with hgupdater. So when a release uses git/Skara tooling I think manually opened backport items are still the thing to do. Best regards Christoph From gnu.andrew at redhat.com Tue Dec 15 18:32:18 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 15 Dec 2020 18:32:18 +0000 Subject: [8u] RFR: JDK-8257192: Integrate AArch64 JIT port into 8u In-Reply-To: References: <20201127072126.GJ488659@rincewind> <20201127073332.GA779738@rincewind> Message-ID: <20201215183218.GA131217@rincewind> On 08:57 Sat 28 Nov , Yangfei (Felix) wrote: > Hi, > > > -----Original Message----- > > From: jdk8u-dev [mailto:jdk8u-dev-retn at openjdk.java.net] On Behalf Of > > Andrew Hughes > > Sent: Friday, November 27, 2020 3:34 PM > > To: jdk8u-dev at openjdk.java.net > > Cc: aarch64-port-dev at openjdk.java.net > > Subject: Re: [8u] RFR: JDK-8257192: Integrate AArch64 JIT port into 8u > > > > On 07:21 Fri 27 Nov , Andrew Hughes wrote: > > > Umbrella Bug: https://bugs.openjdk.java.net/browse/JDK-8257192 > > > Webrevs: > > Thanks for bringing this to 8u upstream. > > I performed some testing on our platforms for the following patches based on the latest jdk8u-dev repo (jdk8u282-b03): > > https://cr.openjdk.java.net/~andrew/openjdk8/8257192/root/webrev.01/ > https://cr.openjdk.java.net/~andrew/openjdk8/8257192/jdk/webrev.01/ > https://cr.openjdk.java.net/~andrew/openjdk8/8257192/hotspot/webrev.02/ > > 1. Run full jtreg test with release build on x86_64-linux-gnu, no regression witnessed. > Passed jcstress test on x86_64-linux-gnu. > > 2. Run full jtreg test with release build on aarch64-linux-gnu, no regression witnessed. (Compared with jtreg test result of aarch64 release build from latest aarch64-port/jdk8u-shenandoah repo) > Passed jcstress test on my 128-core aarch64 Kunpeng server. > > 3. Performed specjbb2015 test with release build on aarch64-linux-gnu. > Performance numbers is reproducible as compared with aarch64 release build from latest aarch64-port/jdk8u-shenandoah repo. > > Hope that helps :-) > > Best regards, > Felix It does. Good to know it works for you :-) I'll make another revision, based on Aleksey's latest comments, and we'll try and get this in. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From hohensee at amazon.com Tue Dec 15 23:31:22 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 15 Dec 2020 23:31:22 +0000 Subject: RFR (XS): 8258430: 8u backport of JDK-8063107 missing test/javax/swing/JRadioButton/8041561/bug8041561.java changes Message-ID: <292E3B9F-B5A4-4874-892B-2ABD641EBB52@amazon.com> Please review this makeup backport. JBS: https://bugs.openjdk.java.net/browse/JDK-8258430 Webrev: http://cr.openjdk.java.net/~phh/8258430/webrev.8u.01/ JDK-8063107 patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4ef86895869c Applicable portion of original patch: --- a/test/javax/swing/JRadioButton/8041561/bug8041561.java Wed Nov 19 16:42:19 2014 +0400 +++ b/test/javax/swing/JRadioButton/8041561/bug8041561.java Fri Nov 21 16:11:03 2014 +0300 @@ -25,7 +25,6 @@ import java.awt.Color; import java.awt.Point; import java.awt.Robot; -import java.awt.Toolkit; import javax.swing.JFrame; import javax.swing.JPanel; import javax.swing.JRadioButton; @@ -34,7 +33,6 @@ import javax.swing.UnsupportedLookAndFeelException; import javax.swing.plaf.metal.DefaultMetalTheme; import javax.swing.plaf.metal.MetalLookAndFeel; -import sun.awt.SunToolkit; /** * @test @@ -62,7 +60,7 @@ } }); - ((SunToolkit) Toolkit.getDefaultToolkit()).realSync(); + new Robot().waitForIdle(); Thread.sleep(500); SwingUtilities.invokeAndWait(new Runnable() { Thanks, Paul From sgehwolf at redhat.com Wed Dec 16 10:37:02 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 16 Dec 2020 11:37:02 +0100 Subject: RFR (XS): 8258430: 8u backport of JDK-8063107 missing test/javax/swing/JRadioButton/8041561/bug8041561.java changes In-Reply-To: <292E3B9F-B5A4-4874-892B-2ABD641EBB52@amazon.com> References: <292E3B9F-B5A4-4874-892B-2ABD641EBB52@amazon.com> Message-ID: <4f172bc4bbc18297d7710517323c6536147dc6f1.camel@redhat.com> On Tue, 2020-12-15 at 23:31 +0000, Hohensee, Paul wrote: > Webrev: http://cr.openjdk.java.net/~phh/8258430/webrev.8u.01/ Looks good. Thanks, Severin From hohensee at amazon.com Wed Dec 16 15:19:35 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 16 Dec 2020 15:19:35 +0000 Subject: RFR (XS): 8258430: 8u backport of JDK-8063107 missing test/javax/swing/JRadioButton/8041561/bug8041561.java changes Message-ID: <5887C1D5-BAF7-44D0-AD6E-37E23EB370A8@amazon.com> Thanks, Severin. Tagged. ?-----Original Message----- From: Severin Gehwolf Date: Wednesday, December 16, 2020 at 2:38 AM To: "Hohensee, Paul" , jdk8u-dev Subject: RE: RFR (XS): 8258430: 8u backport of JDK-8063107 missing test/javax/swing/JRadioButton/8041561/bug8041561.java changes On Tue, 2020-12-15 at 23:31 +0000, Hohensee, Paul wrote: > Webrev: http://cr.openjdk.java.net/~phh/8258430/webrev.8u.01/ Looks good. Thanks, Severin From hohensee at amazon.com Wed Dec 16 18:43:56 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 16 Dec 2020 18:43:56 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] Message-ID: <77FE1446-6FCC-40C0-88B9-FAFDD0F53E82@amazon.com> I really like two things about the current setup, which are (1) all backport info and process is centralized in the original JBS issue, and (2) hgupdater creates the backport issues for me when I push. These mean I only have to look in a single place for backport and other info, and I don't have to spend time creating and maintaining backport issues. With respect to hgupdater getting things wrong, perhaps we could prevail upon Oracle to have hgupdater accept "openjdk-pool". Automatically tracking who's working on what is hard. Maybe I'm missing something, but I don't see a difference between tagging the original issue with, say, "jdk8u-andrew" to indicate that Andrew Hughes is working on it, and manually creating a backport issue. The latter is assigned to the original patch author, and its creator isn't necessarily the one who's working on it, so it will also have to be tagged. I.e., I expect to have to rely on backport issue tags too, so might as well rely on original issue tags. I'm happy to add a "jdku-" tag to an issue when I start work on it. Would that (in addition to the current comment requirements) be enough for tracking purposes? Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Langer, Christoph" Date: Tuesday, December 15, 2020 at 7:46 AM To: Severin Gehwolf , Andrew Hughes , "jdk-updates-dev at openjdk.java.net" Cc: jdk8u-dev Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] Hi Severin, > > I think actually 11-pool is a major issue here since there will be > > conflicts with Oracle. Especially for backport items that are open > > for a long time as once can never know if and when Oracle does > > backports and whether their engineer will also check JBS at the time > > of pushing. So, if we manually create the backport items, we should > > then set the intended target version explicitly. In fact, this seems > > to be what Oracle does as well. When they are working on a backport, > > they also sometimes create backport items with a certain target > > version. This would make life easier for the maintainers as well as > > they will only have to check whether the version is set correctly. > > OK. So is the concern that by creating explicit backport bugs, setting > Fix Version to "11-pool" makes it indistinguishable from a bug created > by Oracle for their work? Setting the fix version to something like > 11.0.11 (current jdk11u-dev) seems fine to me if that alleviates the > concern. > > My understanding was that 11-pool bugs would be OpenJDK 11 bugs. > Perhaps that's not the case. > As far as I know, 11-pool works for both, Oracle and OpenJDK 11 update releases. So if somebody pushes a change to either openjdk 11u/11u-dev or any of Oracle's 11 branches, hgupdate goes and resolves open 11-pool backport as it finds them. (If none of the explicit fix version is present) > > > > As for the issue of copying all the labels to backport bugs, > > > > especially those fix request/approval labels that will flood the > > > > open/unpushed backport lists, that is a known issue. The Skara > > > > tooling has addressed this already ([0], [1]), so for 13u this isn't > > > > an issue any longer. And for 11u this will be solved once we go to > > > > Skara (Another reason for not waiting too long until migrating to > > > > Skara with 11u ??). > > > > > > Right. I'm not convinced Skara will be a solution for 8u, though. So > > > there is that problem. > > Perhaps we shouldn't rule out Skara :) It might well be part of the > solution. I should keep an open mind about that. Mea culpa. > > > But 8u is only at the end of the chain... If no release higher than 8 > > generates this bug pollution, I think 8 won't suffer. > > I'm not sure how skara would address the bug-distribution/assignment > issue, though. Do you know of something that would handle it? When talking of the benefits of Skara I had in mind that it would not unnecessarily copy labels to the backport bugs. But actually it's a good question how in the Skara workflow open backport bugs are handled. I would assume these get resolved in a similar manner like with hgupdater. So when a release uses git/Skara tooling I think manually opened backport items are still the thing to do. Best regards Christoph From david.holmes at oracle.com Thu Dec 17 07:45:34 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Dec 2020 17:45:34 +1000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: <77FE1446-6FCC-40C0-88B9-FAFDD0F53E82@amazon.com> References: <77FE1446-6FCC-40C0-88B9-FAFDD0F53E82@amazon.com> Message-ID: <071675c1-b749-377a-9ce8-52d6c557dc95@oracle.com> Sorry to butt in but ... On 17/12/2020 4:43 am, Hohensee, Paul wrote: > I really like two things about the current setup, which are (1) all backport info and process is centralized in the original JBS issue, and (2) hgupdater creates the backport issues for me when I push. These mean I only have to look in a single place for backport and other info, and I don't have to spend time creating and maintaining backport issues. > > With respect to hgupdater getting things wrong, perhaps we could prevail upon Oracle to have hgupdater accept "openjdk-pool". > > Automatically tracking who's working on what is hard. Maybe I'm missing something, but I don't see a difference between tagging the original issue with, say, "jdk8u-andrew" to indicate that Andrew Hughes is working on it, and manually creating a backport issue. The latter is assigned to the original patch author, and its creator isn't necessarily the one who's working on it, so it will also have to be tagged. I.e., I expect to have to rely on backport issue tags too, so might as well rely on original issue tags. > > I'm happy to add a "jdku-" tag to an issue when I start work on it. Would that (in addition to the current comment requirements) be enough for tracking purposes? These "tags" (aka labels) create JBS pollution and email storms IMO. I don't want to see even more labels being applied to primary issues, when the label only relates to a specific backport - a backport issue is the place for that. And in the case of assignee we have a field for that so don't need a label/tag. Thanks, David > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf of "Langer, Christoph" > Date: Tuesday, December 15, 2020 at 7:46 AM > To: Severin Gehwolf , Andrew Hughes , "jdk-updates-dev at openjdk.java.net" > Cc: jdk8u-dev > Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] > > Hi Severin, > > > >>> I think actually 11-pool is a major issue here since there will be >>> conflicts with Oracle. Especially for backport items that are open >>> for a long time as once can never know if and when Oracle does >>> backports and whether their engineer will also check JBS at the time >>> of pushing. So, if we manually create the backport items, we should >>> then set the intended target version explicitly. In fact, this seems >>> to be what Oracle does as well. When they are working on a backport, >>> they also sometimes create backport items with a certain target >>> version. This would make life easier for the maintainers as well as >>> they will only have to check whether the version is set correctly. >> >> OK. So is the concern that by creating explicit backport bugs, setting >> Fix Version to "11-pool" makes it indistinguishable from a bug created >> by Oracle for their work? Setting the fix version to something like >> 11.0.11 (current jdk11u-dev) seems fine to me if that alleviates the >> concern. >> >> My understanding was that 11-pool bugs would be OpenJDK 11 bugs. >> Perhaps that's not the case. >> > > As far as I know, 11-pool works for both, Oracle and OpenJDK 11 update releases. So if somebody pushes a change to either openjdk 11u/11u-dev or any of Oracle's 11 branches, hgupdate goes and resolves open 11-pool backport as it finds them. (If none of the explicit fix version is present) > >>>>> As for the issue of copying all the labels to backport bugs, >>>>> especially those fix request/approval labels that will flood the >>>>> open/unpushed backport lists, that is a known issue. The Skara >>>>> tooling has addressed this already ([0], [1]), so for 13u this isn't >>>>> an issue any longer. And for 11u this will be solved once we go to >>>>> Skara (Another reason for not waiting too long until migrating to >>>>> Skara with 11u ??). >>>> >>>> Right. I'm not convinced Skara will be a solution for 8u, though. So >>>> there is that problem. >> >> Perhaps we shouldn't rule out Skara :) It might well be part of the >> solution. I should keep an open mind about that. Mea culpa. >> >>> But 8u is only at the end of the chain... If no release higher than 8 >>> generates this bug pollution, I think 8 won't suffer. >> >> I'm not sure how skara would address the bug-distribution/assignment >> issue, though. Do you know of something that would handle it? > > When talking of the benefits of Skara I had in mind that it would not unnecessarily copy labels to the backport bugs. But actually it's a good question how in the Skara workflow open backport bugs are handled. I would assume these get resolved in a similar manner like with hgupdater. So when a release uses git/Skara tooling I think manually opened backport items are still the thing to do. > > Best regards > Christoph > > > From mbalao at redhat.com Thu Dec 17 14:20:10 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 17 Dec 2020 11:20:10 -0300 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: References: <20201211170313.GH1323090@rincewind> Message-ID: On Tue, Dec 15, 2020 at 6:11 AM Langer, Christoph wrote: > As for those two points: I can understand them - as specific requirements for your workflow within your company, I guess. I believe the intention is quite the opposite. Instead of tracking or assigning backport assignments internally -what we've been doing so far-, we are proposing a process to do it in the open; so everyone in the community can participate in the same way. As you well pointed out, this could be potentially achieved with comments in the main ticket. However, I see value for every company/organization/individual in generating automatic reports and tracking overall progress easily -as Severin said, tracking comments is not feasible-. Again, this could be achieved with labels; but I agree with Dalvid in not polluting JBS main-bug tickets -particularly when there is a 'Backports' feature in JBS for exactly that, and we can make more things explicit in addition to the assignee-. I'll give you a more concrete example. If we want JDKs to remain compatible, we need to track bugs for parity. Ideally, this effort should be distributed throughout the community. We need to be able to get statistics of the overall progress, not just what we are doing internally at Red Hat. From hohensee at amazon.com Thu Dec 17 14:27:18 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 17 Dec 2020 14:27:18 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] Message-ID: The assignee for a backport is the original patch author, not the person doing the backport. Thanks, Paul ?-----Original Message----- From: David Holmes Organization: Oracle Corporation Date: Wednesday, December 16, 2020 at 11:46 PM To: "Hohensee, Paul" , "Langer, Christoph" , Severin Gehwolf , Andrew Hughes , "jdk-updates-dev at openjdk.java.net" Cc: jdk8u-dev Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] Sorry to butt in but ... On 17/12/2020 4:43 am, Hohensee, Paul wrote: > I really like two things about the current setup, which are (1) all backport info and process is centralized in the original JBS issue, and (2) hgupdater creates the backport issues for me when I push. These mean I only have to look in a single place for backport and other info, and I don't have to spend time creating and maintaining backport issues. > > With respect to hgupdater getting things wrong, perhaps we could prevail upon Oracle to have hgupdater accept "openjdk-pool". > > Automatically tracking who's working on what is hard. Maybe I'm missing something, but I don't see a difference between tagging the original issue with, say, "jdk8u-andrew" to indicate that Andrew Hughes is working on it, and manually creating a backport issue. The latter is assigned to the original patch author, and its creator isn't necessarily the one who's working on it, so it will also have to be tagged. I.e., I expect to have to rely on backport issue tags too, so might as well rely on original issue tags. > > I'm happy to add a "jdku-" tag to an issue when I start work on it. Would that (in addition to the current comment requirements) be enough for tracking purposes? These "tags" (aka labels) create JBS pollution and email storms IMO. I don't want to see even more labels being applied to primary issues, when the label only relates to a specific backport - a backport issue is the place for that. And in the case of assignee we have a field for that so don't need a label/tag. Thanks, David > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on behalf of "Langer, Christoph" > Date: Tuesday, December 15, 2020 at 7:46 AM > To: Severin Gehwolf , Andrew Hughes , "jdk-updates-dev at openjdk.java.net" > Cc: jdk8u-dev > Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] > > Hi Severin, > > > >>> I think actually 11-pool is a major issue here since there will be >>> conflicts with Oracle. Especially for backport items that are open >>> for a long time as once can never know if and when Oracle does >>> backports and whether their engineer will also check JBS at the time >>> of pushing. So, if we manually create the backport items, we should >>> then set the intended target version explicitly. In fact, this seems >>> to be what Oracle does as well. When they are working on a backport, >>> they also sometimes create backport items with a certain target >>> version. This would make life easier for the maintainers as well as >>> they will only have to check whether the version is set correctly. >> >> OK. So is the concern that by creating explicit backport bugs, setting >> Fix Version to "11-pool" makes it indistinguishable from a bug created >> by Oracle for their work? Setting the fix version to something like >> 11.0.11 (current jdk11u-dev) seems fine to me if that alleviates the >> concern. >> >> My understanding was that 11-pool bugs would be OpenJDK 11 bugs. >> Perhaps that's not the case. >> > > As far as I know, 11-pool works for both, Oracle and OpenJDK 11 update releases. So if somebody pushes a change to either openjdk 11u/11u-dev or any of Oracle's 11 branches, hgupdate goes and resolves open 11-pool backport as it finds them. (If none of the explicit fix version is present) > >>>>> As for the issue of copying all the labels to backport bugs, >>>>> especially those fix request/approval labels that will flood the >>>>> open/unpushed backport lists, that is a known issue. The Skara >>>>> tooling has addressed this already ([0], [1]), so for 13u this isn't >>>>> an issue any longer. And for 11u this will be solved once we go to >>>>> Skara (Another reason for not waiting too long until migrating to >>>>> Skara with 11u ??). >>>> >>>> Right. I'm not convinced Skara will be a solution for 8u, though. So >>>> there is that problem. >> >> Perhaps we shouldn't rule out Skara :) It might well be part of the >> solution. I should keep an open mind about that. Mea culpa. >> >>> But 8u is only at the end of the chain... If no release higher than 8 >>> generates this bug pollution, I think 8 won't suffer. >> >> I'm not sure how skara would address the bug-distribution/assignment >> issue, though. Do you know of something that would handle it? > > When talking of the benefits of Skara I had in mind that it would not unnecessarily copy labels to the backport bugs. But actually it's a good question how in the Skara workflow open backport bugs are handled. I would assume these get resolved in a similar manner like with hgupdater. So when a release uses git/Skara tooling I think manually opened backport items are still the thing to do. > > Best regards > Christoph > > > From sgehwolf at redhat.com Thu Dec 17 14:46:07 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 17 Dec 2020 15:46:07 +0100 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: References: Message-ID: <01ac8c4338d0bb4ba71d4b69034b0c4b901a694c.camel@redhat.com> On Thu, 2020-12-17 at 14:27 +0000, Hohensee, Paul wrote: > The assignee for a backport is the original patch author, not the > person doing the backport. That doesn't sound right. Clicking on More => Create Backport it asks for a version, enter e.g. openjdk8u292, and an assignee (OpenJDK username of that). It defaults to the user who worked the master bug. Could it be that you mean the reporter? See here for example: https://bugs.openjdk.java.net/browse/JDK-8258597 Has myself as assignee since I've set it so. What am I missing? Thanks, Severin > Thanks, > Paul > > ?-----Original Message----- > From: David Holmes > Organization: Oracle Corporation > Date: Wednesday, December 16, 2020 at 11:46 PM > To: "Hohensee, Paul" , "Langer, Christoph" < > christoph.langer at sap.com>, Severin Gehwolf , > Andrew Hughes , " > jdk-updates-dev at openjdk.java.net" > Cc: jdk8u-dev > Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport > Bugs] > > Sorry to butt in but ... > > On 17/12/2020 4:43 am, Hohensee, Paul wrote: > > I really like two things about the current setup, which are (1) all > > backport info and process is centralized in the original JBS issue, > > and (2) hgupdater creates the backport issues for me when I push. > > These mean I only have to look in a single place for backport and > > other info, and I don't have to spend time creating and maintaining > > backport issues. > > > > With respect to hgupdater getting things wrong, perhaps we could > > prevail upon Oracle to have hgupdater accept "openjdk-pool". > > > > Automatically tracking who's working on what is hard. Maybe I'm > > missing something, but I don't see a difference between tagging the > > original issue with, say, "jdk8u-andrew" to indicate that Andrew > > Hughes is working on it, and manually creating a backport issue. > > The latter is assigned to the original patch author, and its > > creator isn't necessarily the one who's working on it, so it will > > also have to be tagged. I.e., I expect to have to rely on backport > > issue tags too, so might as well rely on original issue tags. > > > > I'm happy to add a "jdku-" tag to an issue when I > > start work on it. Would that (in addition to the current comment > > requirements) be enough for tracking purposes? > > These "tags" (aka labels) create JBS pollution and email storms IMO. > I > don't want to see even more labels being applied to primary issues, > when > the label only relates to a specific backport - a backport issue is > the > place for that. And in the case of assignee we have a field for that > so > don't need a label/tag. > > Thanks, > David > > > Thanks, > > Paul > > > > -----Original Message----- > > From: jdk-updates-dev on > > behalf of "Langer, Christoph" > > Date: Tuesday, December 15, 2020 at 7:46 AM > > To: Severin Gehwolf , Andrew Hughes < > > gnu.andrew at redhat.com>, "jdk-updates-dev at openjdk.java.net" < > > jdk-updates-dev at openjdk.java.net> > > Cc: jdk8u-dev > > Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport > > Bugs] > > > > Hi Severin, > > > > > > > > > > I think actually 11-pool is a major issue here since there will > > > > be > > > > conflicts with Oracle. Especially for backport items that are > > > > open > > > > for a long time as once can never know if and when Oracle does > > > > backports and whether their engineer will also check JBS at the > > > > time > > > > of pushing. So, if we manually create the backport items, we > > > > should > > > > then set the intended target version explicitly. In fact, this > > > > seems > > > > to be what Oracle does as well. When they are working on a > > > > backport, > > > > they also sometimes create backport items with a certain target > > > > version. This would make life easier for the maintainers as > > > > well as > > > > they will only have to check whether the version is set > > > > correctly. > > > > > > OK. So is the concern that by creating explicit backport bugs, > > > setting > > > Fix Version to "11-pool" makes it indistinguishable from a bug > > > created > > > by Oracle for their work? Setting the fix version to something > > > like > > > 11.0.11 (current jdk11u-dev) seems fine to me if that alleviates > > > the > > > concern. > > > > > > My understanding was that 11-pool bugs would be OpenJDK 11 bugs. > > > Perhaps that's not the case. > > > > > > > As far as I know, 11-pool works for both, Oracle and OpenJDK 11 > > update releases. So if somebody pushes a change to either openjdk > > 11u/11u-dev or any of Oracle's 11 branches, hgupdate goes and > > resolves open 11-pool backport as it finds them. (If none of the > > explicit fix version is present) > > > > > > > > As for the issue of copying all the labels to backport > > > > > > bugs, > > > > > > especially those fix request/approval labels that will > > > > > > flood the > > > > > > open/unpushed backport lists, that is a known issue. The > > > > > > Skara > > > > > > tooling has addressed this already ([0], [1]), so for 13u > > > > > > this isn't > > > > > > an issue any longer. And for 11u this will be solved once > > > > > > we go to > > > > > > Skara (Another reason for not waiting too long until > > > > > > migrating to > > > > > > Skara with 11u ??). > > > > > > > > > > Right. I'm not convinced Skara will be a solution for 8u, > > > > > though. So > > > > > there is that problem. > > > > > > Perhaps we shouldn't rule out Skara :) It might well be part of > > > the > > > solution. I should keep an open mind about that. Mea culpa. > > > > > > > But 8u is only at the end of the chain... If no release higher > > > > than 8 > > > > generates this bug pollution, I think 8 won't suffer. > > > > > > I'm not sure how skara would address the bug- > > > distribution/assignment > > > issue, though. Do you know of something that would handle it? > > > > When talking of the benefits of Skara I had in mind that it would > > not unnecessarily copy labels to the backport bugs. But actually > > it's a good question how in the Skara workflow open backport bugs > > are handled. I would assume these get resolved in a similar manner > > like with hgupdater. So when a release uses git/Skara tooling I > > think manually opened backport items are still the thing to do. > > > > Best regards > > Christoph > > > > > > > From neugens at redhat.com Thu Dec 17 15:08:42 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 17 Dec 2020 16:08:42 +0100 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: References: Message-ID: I agree with David here - although I'm biased as I've been one proponent of creating backport bugs directly. In every project you usually get a bug you are working on and all the information is basically there, with OpenJDK we work over labels that need to be cleaned and maintained manually, and worse of all, require us to anyway add information to the original bug like links to email discussions and patches etc.. Those generate large number of emails but don't have any useful information, they can't really be used to track time and effort and they won't really say who is working on what because often the labels are created after the fact. A direct bug means we can close and assign to someone and we can all see who and when things get done, or, if there are blockers, why. Best of all, it scales up well if we add more people, and it's easier to understand for new contributors since is essentially what everyone already does in other projects and downstream. Just my .2 euro cents of course ;) Cheers, Mario On Thu, Dec 17, 2020 at 3:28 PM Hohensee, Paul wrote: > > The assignee for a backport is the original patch author, not the person doing the backport. > > Thanks, > Paul > > ?-----Original Message----- > From: David Holmes > Organization: Oracle Corporation > Date: Wednesday, December 16, 2020 at 11:46 PM > To: "Hohensee, Paul" , "Langer, Christoph" , Severin Gehwolf , Andrew Hughes , "jdk-updates-dev at openjdk.java.net" > Cc: jdk8u-dev > Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] > > Sorry to butt in but ... > > On 17/12/2020 4:43 am, Hohensee, Paul wrote: > > I really like two things about the current setup, which are (1) all backport info and process is centralized in the original JBS issue, and (2) hgupdater creates the backport issues for me when I push. These mean I only have to look in a single place for backport and other info, and I don't have to spend time creating and maintaining backport issues. > > > > With respect to hgupdater getting things wrong, perhaps we could prevail upon Oracle to have hgupdater accept "openjdk-pool". > > > > Automatically tracking who's working on what is hard. Maybe I'm missing something, but I don't see a difference between tagging the original issue with, say, "jdk8u-andrew" to indicate that Andrew Hughes is working on it, and manually creating a backport issue. The latter is assigned to the original patch author, and its creator isn't necessarily the one who's working on it, so it will also have to be tagged. I.e., I expect to have to rely on backport issue tags too, so might as well rely on original issue tags. > > > > I'm happy to add a "jdku-" tag to an issue when I start work on it. Would that (in addition to the current comment requirements) be enough for tracking purposes? > > These "tags" (aka labels) create JBS pollution and email storms IMO. I > don't want to see even more labels being applied to primary issues, when > the label only relates to a specific backport - a backport issue is the > place for that. And in the case of assignee we have a field for that so > don't need a label/tag. > > Thanks, > David > > > Thanks, > > Paul > > > > -----Original Message----- > > From: jdk-updates-dev on behalf of "Langer, Christoph" > > Date: Tuesday, December 15, 2020 at 7:46 AM > > To: Severin Gehwolf , Andrew Hughes , "jdk-updates-dev at openjdk.java.net" > > Cc: jdk8u-dev > > Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] > > > > Hi Severin, > > > > > > > >>> I think actually 11-pool is a major issue here since there will be > >>> conflicts with Oracle. Especially for backport items that are open > >>> for a long time as once can never know if and when Oracle does > >>> backports and whether their engineer will also check JBS at the time > >>> of pushing. So, if we manually create the backport items, we should > >>> then set the intended target version explicitly. In fact, this seems > >>> to be what Oracle does as well. When they are working on a backport, > >>> they also sometimes create backport items with a certain target > >>> version. This would make life easier for the maintainers as well as > >>> they will only have to check whether the version is set correctly. > >> > >> OK. So is the concern that by creating explicit backport bugs, setting > >> Fix Version to "11-pool" makes it indistinguishable from a bug created > >> by Oracle for their work? Setting the fix version to something like > >> 11.0.11 (current jdk11u-dev) seems fine to me if that alleviates the > >> concern. > >> > >> My understanding was that 11-pool bugs would be OpenJDK 11 bugs. > >> Perhaps that's not the case. > >> > > > > As far as I know, 11-pool works for both, Oracle and OpenJDK 11 update releases. So if somebody pushes a change to either openjdk 11u/11u-dev or any of Oracle's 11 branches, hgupdate goes and resolves open 11-pool backport as it finds them. (If none of the explicit fix version is present) > > > >>>>> As for the issue of copying all the labels to backport bugs, > >>>>> especially those fix request/approval labels that will flood the > >>>>> open/unpushed backport lists, that is a known issue. The Skara > >>>>> tooling has addressed this already ([0], [1]), so for 13u this isn't > >>>>> an issue any longer. And for 11u this will be solved once we go to > >>>>> Skara (Another reason for not waiting too long until migrating to > >>>>> Skara with 11u ). > >>>> > >>>> Right. I'm not convinced Skara will be a solution for 8u, though. So > >>>> there is that problem. > >> > >> Perhaps we shouldn't rule out Skara :) It might well be part of the > >> solution. I should keep an open mind about that. Mea culpa. > >> > >>> But 8u is only at the end of the chain... If no release higher than 8 > >>> generates this bug pollution, I think 8 won't suffer. > >> > >> I'm not sure how skara would address the bug-distribution/assignment > >> issue, though. Do you know of something that would handle it? > > > > When talking of the benefits of Skara I had in mind that it would not unnecessarily copy labels to the backport bugs. But actually it's a good question how in the Skara workflow open backport bugs are handled. I would assume these get resolved in a similar manner like with hgupdater. So when a release uses git/Skara tooling I think manually opened backport items are still the thing to do. > > > > Best regards > > Christoph > > > > > > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From goetz.lindenmaier at sap.com Thu Dec 17 17:39:09 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 17 Dec 2020 17:39:09 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: References: <20201211170313.GH1323090@rincewind> Message-ID: Hi, While I am currently fine with the process, I see some of the points that were made here. But the whole downport process will feel a lot different and change slightly with the move to github. We really should only change the process once we are all familiar with the new workflows. One thing that improves is that the downport issues opened automatically will contain as assignee the person that did the downport. Thus I would rather vote for driving the change to github, than discussing changes that might be pointless after the move. Anyways, on my side, the overheads are not on the reporting side. I would like to see the review and approval process slimmed down. I was kept busy monitoring changes for review and approval, coordinating it with testing and keeping the changes in proper order instead of discussing potential problems of the changes. But I don't want to raise this before we are in github. Just my 5 ct ?? Best, Goetz. -----Original Message----- From: jdk-updates-dev On Behalf Of Martin Balao Sent: Donnerstag, 17. Dezember 2020 15:20 To: Langer, Christoph Cc: Severin Gehwolf ; Andrew Hughes ; jdk-updates-dev at openjdk.java.net; jdk8u-dev Subject: Re: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] On Tue, Dec 15, 2020 at 6:11 AM Langer, Christoph wrote: > As for those two points: I can understand them - as specific requirements for your workflow within your company, I guess. I believe the intention is quite the opposite. Instead of tracking or assigning backport assignments internally -what we've been doing so far-, we are proposing a process to do it in the open; so everyone in the community can participate in the same way. As you well pointed out, this could be potentially achieved with comments in the main ticket. However, I see value for every company/organization/individual in generating automatic reports and tracking overall progress easily -as Severin said, tracking comments is not feasible-. Again, this could be achieved with labels; but I agree with Dalvid in not polluting JBS main-bug tickets -particularly when there is a 'Backports' feature in JBS for exactly that, and we can make more things explicit in addition to the assignee-. I'll give you a more concrete example. If we want JDKs to remain compatible, we need to track bugs for parity. Ideally, this effort should be distributed throughout the community. We need to be able to get statistics of the overall progress, not just what we are doing internally at Red Hat. From hohensee at amazon.com Thu Dec 17 18:20:06 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 17 Dec 2020 18:20:06 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] Message-ID: <0FA08346-2F3A-4A6B-B27C-1DF33928DA12@amazon.com> I should have written, "The assignee for an automatically generated backport issue is the original patch author, not the person doing the backport." See, e.g., https://bugs.openjdk.java.net/browse/JDK-8256904, which is the 8u backport issue for https://bugs.openjdk.java.net/browse/JDK-8255603. The backport issue's assignee is clanger, not the person who did the backport push, who was phh. Manually created backports can of course be assigned to anyone, but assigning them to anyone other the original patch author is a change from current practice. Thanks, Paul ?-----Original Message----- From: Severin Gehwolf Date: Thursday, December 17, 2020 at 6:46 AM To: "Hohensee, Paul" , David Holmes , "Langer, Christoph" , Andrew Hughes , "jdk-updates-dev at openjdk.java.net" Cc: jdk8u-dev Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] On Thu, 2020-12-17 at 14:27 +0000, Hohensee, Paul wrote: > The assignee for a backport is the original patch author, not the > person doing the backport. That doesn't sound right. Clicking on More => Create Backport it asks for a version, enter e.g. openjdk8u292, and an assignee (OpenJDK username of that). It defaults to the user who worked the master bug. Could it be that you mean the reporter? See here for example: https://bugs.openjdk.java.net/browse/JDK-8258597 Has myself as assignee since I've set it so. What am I missing? Thanks, Severin > Thanks, > Paul > > -----Original Message----- > From: David Holmes > Organization: Oracle Corporation > Date: Wednesday, December 16, 2020 at 11:46 PM > To: "Hohensee, Paul" , "Langer, Christoph" < > christoph.langer at sap.com>, Severin Gehwolf , > Andrew Hughes , " > jdk-updates-dev at openjdk.java.net" > Cc: jdk8u-dev > Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport > Bugs] > > Sorry to butt in but ... > > On 17/12/2020 4:43 am, Hohensee, Paul wrote: > > I really like two things about the current setup, which are (1) all > > backport info and process is centralized in the original JBS issue, > > and (2) hgupdater creates the backport issues for me when I push. > > These mean I only have to look in a single place for backport and > > other info, and I don't have to spend time creating and maintaining > > backport issues. > > > > With respect to hgupdater getting things wrong, perhaps we could > > prevail upon Oracle to have hgupdater accept "openjdk-pool". > > > > Automatically tracking who's working on what is hard. Maybe I'm > > missing something, but I don't see a difference between tagging the > > original issue with, say, "jdk8u-andrew" to indicate that Andrew > > Hughes is working on it, and manually creating a backport issue. > > The latter is assigned to the original patch author, and its > > creator isn't necessarily the one who's working on it, so it will > > also have to be tagged. I.e., I expect to have to rely on backport > > issue tags too, so might as well rely on original issue tags. > > > > I'm happy to add a "jdku-" tag to an issue when I > > start work on it. Would that (in addition to the current comment > > requirements) be enough for tracking purposes? > > These "tags" (aka labels) create JBS pollution and email storms IMO. > I > don't want to see even more labels being applied to primary issues, > when > the label only relates to a specific backport - a backport issue is > the > place for that. And in the case of assignee we have a field for that > so > don't need a label/tag. > > Thanks, > David > > > Thanks, > > Paul > > > > -----Original Message----- > > From: jdk-updates-dev on > > behalf of "Langer, Christoph" > > Date: Tuesday, December 15, 2020 at 7:46 AM > > To: Severin Gehwolf , Andrew Hughes < > > gnu.andrew at redhat.com>, "jdk-updates-dev at openjdk.java.net" < > > jdk-updates-dev at openjdk.java.net> > > Cc: jdk8u-dev > > Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport > > Bugs] > > > > Hi Severin, > > > > > > > > > > I think actually 11-pool is a major issue here since there will > > > > be > > > > conflicts with Oracle. Especially for backport items that are > > > > open > > > > for a long time as once can never know if and when Oracle does > > > > backports and whether their engineer will also check JBS at the > > > > time > > > > of pushing. So, if we manually create the backport items, we > > > > should > > > > then set the intended target version explicitly. In fact, this > > > > seems > > > > to be what Oracle does as well. When they are working on a > > > > backport, > > > > they also sometimes create backport items with a certain target > > > > version. This would make life easier for the maintainers as > > > > well as > > > > they will only have to check whether the version is set > > > > correctly. > > > > > > OK. So is the concern that by creating explicit backport bugs, > > > setting > > > Fix Version to "11-pool" makes it indistinguishable from a bug > > > created > > > by Oracle for their work? Setting the fix version to something > > > like > > > 11.0.11 (current jdk11u-dev) seems fine to me if that alleviates > > > the > > > concern. > > > > > > My understanding was that 11-pool bugs would be OpenJDK 11 bugs. > > > Perhaps that's not the case. > > > > > > > As far as I know, 11-pool works for both, Oracle and OpenJDK 11 > > update releases. So if somebody pushes a change to either openjdk > > 11u/11u-dev or any of Oracle's 11 branches, hgupdate goes and > > resolves open 11-pool backport as it finds them. (If none of the > > explicit fix version is present) > > > > > > > > As for the issue of copying all the labels to backport > > > > > > bugs, > > > > > > especially those fix request/approval labels that will > > > > > > flood the > > > > > > open/unpushed backport lists, that is a known issue. The > > > > > > Skara > > > > > > tooling has addressed this already ([0], [1]), so for 13u > > > > > > this isn't > > > > > > an issue any longer. And for 11u this will be solved once > > > > > > we go to > > > > > > Skara (Another reason for not waiting too long until > > > > > > migrating to > > > > > > Skara with 11u ??). > > > > > > > > > > Right. I'm not convinced Skara will be a solution for 8u, > > > > > though. So > > > > > there is that problem. > > > > > > Perhaps we shouldn't rule out Skara :) It might well be part of > > > the > > > solution. I should keep an open mind about that. Mea culpa. > > > > > > > But 8u is only at the end of the chain... If no release higher > > > > than 8 > > > > generates this bug pollution, I think 8 won't suffer. > > > > > > I'm not sure how skara would address the bug- > > > distribution/assignment > > > issue, though. Do you know of something that would handle it? > > > > When talking of the benefits of Skara I had in mind that it would > > not unnecessarily copy labels to the backport bugs. But actually > > it's a good question how in the Skara workflow open backport bugs > > are handled. I would assume these get resolved in a similar manner > > like with hgupdater. So when a release uses git/Skara tooling I > > think manually opened backport items are still the thing to do. > > > > Best regards > > Christoph > > > > > > > From sgehwolf at redhat.com Thu Dec 17 18:47:39 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 17 Dec 2020 19:47:39 +0100 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: <0FA08346-2F3A-4A6B-B27C-1DF33928DA12@amazon.com> References: <0FA08346-2F3A-4A6B-B27C-1DF33928DA12@amazon.com> Message-ID: <66350ccf4ced19cfd6bd1242e3842d9c261dba04.camel@redhat.com> Thanks for the clarification, Paul. On Thu, 2020-12-17 at 18:20 +0000, Hohensee, Paul wrote: > Manually created backports can of course be assigned to anyone, but > assigning them to anyone other the original patch author is a change > from current practice. This is a feature, not a bug, IMO. It more accurately reflects who did the backport. Thanks, Severin From christoph.langer at sap.com Thu Dec 17 23:07:56 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 17 Dec 2020 23:07:56 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: <66350ccf4ced19cfd6bd1242e3842d9c261dba04.camel@redhat.com> References: <0FA08346-2F3A-4A6B-B27C-1DF33928DA12@amazon.com> <66350ccf4ced19cfd6bd1242e3842d9c261dba04.camel@redhat.com> Message-ID: Hi, I'm also all in for stopping the label pollution ?? So, first of all, I fully agree that a backport bug should have the person doing the backport as the assignee. Currently this can only be set manually, e.g. at the time of manually creating a backport item but also any time later by manual intervention. hgupdater currently can't do that since current practice is mostly to submit a backport patch with the original authors/reviewers. This, however, will be solved by the Skara tooling when we switch there. Skara backporting will honor the backport authors (and reviewers) and also reflect that in the backport items in JBS. You can watch this already in real life in 13u. So this change in tooling and process is really one of the things I like about Skara and why I think we should go there for 11u rather sooner than later. But I do not want to have an obligation to manually create backport issues while the tooling can do it for you. People who want to do it - fine. But the machinery can do this for me. And I want to rely on it since it means less effort and thus process overhead for me. And, finally with Skara tooling in place, backport statistics via backport items will be fully correct. As for maintainer approvals: We currently do this via labels/comments on the main bug. I can imagine moving this process to GitHub issues eventually, after Skara was rolled out. E.g. backport authors would start a backport PR with all the reasoning in the PR comments. Skara could offer some command like "/approve"/"disapprove" for maintainers. This could become a prerequisite an "/integrate". But let's do one thing after the other... Best regards Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Donnerstag, 17. Dezember 2020 19:48 > To: Hohensee, Paul ; David Holmes > ; Langer, Christoph > ; Andrew Hughes ; > jdk-updates-dev at openjdk.java.net > Cc: jdk8u-dev > Subject: Re: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] > > Thanks for the clarification, Paul. > > On Thu, 2020-12-17 at 18:20 +0000, Hohensee, Paul wrote: > > Manually created backports can of course be assigned to anyone, but > > assigning them to anyone other the original patch author is a change > > from current practice. > > This is a feature, not a bug, IMO. It more accurately reflects who did > the backport. > > Thanks, > Severin From david.holmes at oracle.com Fri Dec 18 02:47:55 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Dec 2020 12:47:55 +1000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: References: Message-ID: <6f91d0bd-054c-5d81-0a4e-c41d2dad41df@oracle.com> On 18/12/2020 12:27 am, Hohensee, Paul wrote: > The assignee for a backport is the original patch author, not the person doing the backport. That is the default, but it can be changed. David > Thanks, > Paul > > ?-----Original Message----- > From: David Holmes > Organization: Oracle Corporation > Date: Wednesday, December 16, 2020 at 11:46 PM > To: "Hohensee, Paul" , "Langer, Christoph" , Severin Gehwolf , Andrew Hughes , "jdk-updates-dev at openjdk.java.net" > Cc: jdk8u-dev > Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] > > Sorry to butt in but ... > > On 17/12/2020 4:43 am, Hohensee, Paul wrote: >> I really like two things about the current setup, which are (1) all backport info and process is centralized in the original JBS issue, and (2) hgupdater creates the backport issues for me when I push. These mean I only have to look in a single place for backport and other info, and I don't have to spend time creating and maintaining backport issues. >> >> With respect to hgupdater getting things wrong, perhaps we could prevail upon Oracle to have hgupdater accept "openjdk-pool". >> >> Automatically tracking who's working on what is hard. Maybe I'm missing something, but I don't see a difference between tagging the original issue with, say, "jdk8u-andrew" to indicate that Andrew Hughes is working on it, and manually creating a backport issue. The latter is assigned to the original patch author, and its creator isn't necessarily the one who's working on it, so it will also have to be tagged. I.e., I expect to have to rely on backport issue tags too, so might as well rely on original issue tags. >> >> I'm happy to add a "jdku-" tag to an issue when I start work on it. Would that (in addition to the current comment requirements) be enough for tracking purposes? > > These "tags" (aka labels) create JBS pollution and email storms IMO. I > don't want to see even more labels being applied to primary issues, when > the label only relates to a specific backport - a backport issue is the > place for that. And in the case of assignee we have a field for that so > don't need a label/tag. > > Thanks, > David > >> Thanks, >> Paul >> >> -----Original Message----- >> From: jdk-updates-dev on behalf of "Langer, Christoph" >> Date: Tuesday, December 15, 2020 at 7:46 AM >> To: Severin Gehwolf , Andrew Hughes , "jdk-updates-dev at openjdk.java.net" >> Cc: jdk8u-dev >> Subject: RE: [gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs] >> >> Hi Severin, >> >> >> >>>> I think actually 11-pool is a major issue here since there will be >>>> conflicts with Oracle. Especially for backport items that are open >>>> for a long time as once can never know if and when Oracle does >>>> backports and whether their engineer will also check JBS at the time >>>> of pushing. So, if we manually create the backport items, we should >>>> then set the intended target version explicitly. In fact, this seems >>>> to be what Oracle does as well. When they are working on a backport, >>>> they also sometimes create backport items with a certain target >>>> version. This would make life easier for the maintainers as well as >>>> they will only have to check whether the version is set correctly. >>> >>> OK. So is the concern that by creating explicit backport bugs, setting >>> Fix Version to "11-pool" makes it indistinguishable from a bug created >>> by Oracle for their work? Setting the fix version to something like >>> 11.0.11 (current jdk11u-dev) seems fine to me if that alleviates the >>> concern. >>> >>> My understanding was that 11-pool bugs would be OpenJDK 11 bugs. >>> Perhaps that's not the case. >>> >> >> As far as I know, 11-pool works for both, Oracle and OpenJDK 11 update releases. So if somebody pushes a change to either openjdk 11u/11u-dev or any of Oracle's 11 branches, hgupdate goes and resolves open 11-pool backport as it finds them. (If none of the explicit fix version is present) >> >>>>>> As for the issue of copying all the labels to backport bugs, >>>>>> especially those fix request/approval labels that will flood the >>>>>> open/unpushed backport lists, that is a known issue. The Skara >>>>>> tooling has addressed this already ([0], [1]), so for 13u this isn't >>>>>> an issue any longer. And for 11u this will be solved once we go to >>>>>> Skara (Another reason for not waiting too long until migrating to >>>>>> Skara with 11u ??). >>>>> >>>>> Right. I'm not convinced Skara will be a solution for 8u, though. So >>>>> there is that problem. >>> >>> Perhaps we shouldn't rule out Skara :) It might well be part of the >>> solution. I should keep an open mind about that. Mea culpa. >>> >>>> But 8u is only at the end of the chain... If no release higher than 8 >>>> generates this bug pollution, I think 8 won't suffer. >>> >>> I'm not sure how skara would address the bug-distribution/assignment >>> issue, though. Do you know of something that would handle it? >> >> When talking of the benefits of Skara I had in mind that it would not unnecessarily copy labels to the backport bugs. But actually it's a good question how in the Skara workflow open backport bugs are handled. I would assume these get resolved in a similar manner like with hgupdater. So when a release uses git/Skara tooling I think manually opened backport items are still the thing to do. >> >> Best regards >> Christoph >> >> >> > From felix.yang at huawei.com Fri Dec 18 12:35:27 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 18 Dec 2020 12:35:27 +0000 Subject: RFR: 8258669: fastdebug jvm crashes when do event based tracing for monitor inflation Message-ID: Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8258669 Webrev: http://cr.openjdk.java.net/~fyang/8258669/webrev.00 By referencing jdk11u, I think the reason is that we are not setting the "cause" in post_monitor_inflate_event for jdk8u. Proposed patch adds back the missing code changes in: 8138562: Event based tracing should cover monitor inflation. Also enabled code in MonitorInflateCauseConstant::serialize. Since this only adds some extra "cause" information for the monitor inflation event, I think it should be low risk. Performed full jtreg test based on the latest jdk8u-dev. OK? Thanks, Felix From alvdavi at amazon.com Fri Dec 18 16:26:28 2020 From: alvdavi at amazon.com (Alvarez, David) Date: Fri, 18 Dec 2020 16:26:28 +0000 Subject: SSLSocketImpl.java related patches for 8u Message-ID: Hi, After deploying 8u275 to our services, we have noticed occasional socket related failures in some of our services that seemed related to JDK-8245468 [1], the TLSv1.3 backport. During the investigation, I noticed there was a set of SSLSocketImpl related patches that were applied to 11u after 11.0.7 that have not been backported to 8u, and I think we should bring them. The full list ist: [1] JDK-8209333: Socket reset issue for TLS 1.3 socket close [2] JDK-8240827: Downport SSLSocketImpl.java from "8221882: Use fiber- friendly java.util.concurrent.locks in JSSE" [3] JDK-8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl [4] JDK-8235263: Revert TLS 1.3 change that wrapped IOExceptions [5] JDK-8239798: SSLSocket closes socket both socket endpoints on a SocketTimeoutException [6] JDK-8242294: JSSE Client does not throw SSLException when an alert occurs during handshaking [7] JDK-8246031: SSLSocket.getSession() doesn't close connection for timeout/ interrupts [8] JDK-8236464: SO_LINGER option is ignored by SSLSocket in JDK 11 Most of these changes have also been included by Oracle in 8u261 or 8u271, with two exceptions. [2] is there only as a prerequisite of [3], and although there is an entry for a [3] backport to 8u281, but it is marked as Won't Fix, I'll leave to the maintainers to decide whether we want to include [3] or not. Regarding the backports, only [1] and [5] weren't clean, I will be sending RFRs for them. Additionally, I have located two other Socket related patches that Oracle included in 8 and 11 that we are missing: [9] JDK-8256818: SSLSocket that is never bound or connected leaks socket resources [10] JDK-8224829: AsyncSSLSocketClose.java has timing issue If and when these two patches are included in 11u, I think we should bring them to 8u too. I already sent an email to jdk-updates-dev for clarification on how to proceed with [10], as it interacts with how [2] was done. Out of this list, I would be interested in knowing which patches the maintainers think should made it to 8u. Given how interwoven most of them are, which ones are included will affect whether and RFR is needed or not, and how the RFR would look like. Thanks, David -- [1] https://bugs.openjdk.java.net/browse/JDK-8209333 [2] https://bugs.openjdk.java.net/browse/JDK-8240827 [3] https://bugs.openjdk.java.net/browse/JDK-8219991 [4] https://bugs.openjdk.java.net/browse/JDK-8235263 [5] https://bugs.openjdk.java.net/browse/JDK-8239798 [6] https://bugs.openjdk.java.net/browse/JDK-8242294 [7] https://bugs.openjdk.java.net/browse/JDK-8246031 [8] https://bugs.openjdk.java.net/browse/JDK-8236464 [9] https://bugs.openjdk.java.net/browse/JDK-8256818 [10] https://bugs.openjdk.java.net/browse/JDK-8224829 From gnu.andrew at redhat.com Tue Dec 22 02:42:45 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 22 Dec 2020 02:42:45 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: <0FA08346-2F3A-4A6B-B27C-1DF33928DA12@amazon.com> References: <0FA08346-2F3A-4A6B-B27C-1DF33928DA12@amazon.com> Message-ID: <20201222024245.GA51872@rincewind> On 18:20 Thu 17 Dec , Hohensee, Paul wrote: > I should have written, "The assignee for an automatically generated backport issue is the original patch author, not the person doing the backport." See, e.g., https://bugs.openjdk.java.net/browse/JDK-8256904, which is the 8u backport issue for https://bugs.openjdk.java.net/browse/JDK-8255603. The backport issue's assignee is clanger, not the person who did the backport push, who was phh. Manually created backports can of course be assigned to anyone, but assigning them to anyone other the original patch author is a change from current practice. > > Thanks, > Paul > There is no current practice for manually created backports, because we haven't been using them :) If you mean the current practice for the changeset author for a backport, which becomes the assignee of the auto-generated backport bug, then the current practice is more convoluted than just "use the original patch author": "The change can now be committed & pushed to the appropriate jdk8u-dev repository. If you don't have committer or above status, someone will need to to do so on your behalf. Patches that apply cleanly or only need a few minor changes which don't alter the code (e.g. copyright header fixes, same changes in a different context) should use the original author & reviewers for the commit. If the fix was reviewed, those reviewers should be appended to the end of the list. If substantial code changes were needed to create the 8u fix, authorship should go to the backporter and reviewers should only list those who reviewed the altered patch." [0] For what it's worth, the practice used by Oracle, who have been using manual backport bugs for some time, seems to be to assign to the backporter. Moreover, the backport bug assignee does not need to match the changeset author. The entire point of creating backport bugs ahead of time is to assign them to the person working on them. Assigning them to the author of the original changeset, who may have no interest in working on a backport, doesn't make any sense. [0] https://wiki.openjdk.java.net/display/jdk8u/Main -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Dec 22 02:44:57 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 22 Dec 2020 02:44:57 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: <071675c1-b749-377a-9ce8-52d6c557dc95@oracle.com> References: <77FE1446-6FCC-40C0-88B9-FAFDD0F53E82@amazon.com> <071675c1-b749-377a-9ce8-52d6c557dc95@oracle.com> Message-ID: <20201222024457.GB51872@rincewind> On 17:45 Thu 17 Dec , David Holmes wrote: snip... > > These "tags" (aka labels) create JBS pollution and email storms IMO. I don't > want to see even more labels being applied to primary issues, when the label > only relates to a specific backport - a backport issue is the place for > that. And in the case of assignee we have a field for that so don't need a > label/tag. > > Thanks, > David > Thanks for this feedback, David. I had a feeling backport-specific labels on the parent bug might be a nuisance for others not working on the backport, and this seems like a good opportunity to move those to the backport bug. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Dec 22 02:50:10 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 22 Dec 2020 02:50:10 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: References: <20201211170313.GH1323090@rincewind> Message-ID: <20201222025010.GC51872@rincewind> On 17:39 Thu 17 Dec , Lindenmaier, Goetz wrote: > Hi, > > While I am currently fine with the process, I see some of the points > that were made here. > > But the whole downport process will feel a lot different and change > slightly with the move to github. We really should only change the > process once we are all familiar with the new workflows. > One thing that improves is that the downport issues opened > automatically will contain as assignee the person that did the > downport. > > Thus I would rather vote for driving the change to github, than > discussing changes that might be pointless after the move. > > Anyways, on my side, the overheads are not on the reporting side. > I would like to see the review and approval process slimmed > down. I was kept busy monitoring changes for review and approval, > coordinating it with testing and keeping the changes in proper > order instead of discussing potential problems of the changes. > But I don't want to raise this before we are in github. > > Just my 5 ct ?? > > Best, > Goetz. > There is no plan to move 8u development to github. As we have already discussed, it shouldn't be something we consider for 11u until it is clear that it is workable for a long-term support release that needs to do bulk pushes of quarterly security updates. At this point, there hasn't even been a release from a git-maintained tree. It is honestly getting a little tiresome to have it raised in otherwise unrelated discussions as if it is the solution to every problem. It also rather undermines the idea that 8u & 11u should follow the same process, if it is being suggested that 11u move to a different version control system. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Dec 22 06:28:37 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 22 Dec 2020 06:28:37 +0000 Subject: SSLSocketImpl.java related patches for 8u In-Reply-To: References: Message-ID: <20201222062837.GA58371@rincewind> On 16:26 Fri 18 Dec , Alvarez, David wrote: > Hi, > > After deploying 8u275 to our services, we have noticed occasional > socket related failures in some of our services that seemed related to > JDK-8245468 [1], the TLSv1.3 backport. During the investigation, I > noticed there was a set of SSLSocketImpl related patches that were > applied to 11u after 11.0.7 that have not been backported to 8u, and I > think we should bring them. The full list ist: > > [1] JDK-8209333: Socket reset issue for TLS 1.3 socket close > [2] JDK-8240827: Downport SSLSocketImpl.java from "8221882: Use fiber- > friendly java.util.concurrent.locks in JSSE" > [3] JDK-8219991: New fix of the deadlock in > sun.security.ssl.SSLSocketImpl > [4] JDK-8235263: Revert TLS 1.3 change that wrapped IOExceptions > [5] JDK-8239798: SSLSocket closes socket both socket endpoints on a > SocketTimeoutException > [6] JDK-8242294: JSSE Client does not throw SSLException when an alert > occurs during handshaking > [7] JDK-8246031: SSLSocket.getSession() doesn't close connection for > timeout/ interrupts > [8] JDK-8236464: SO_LINGER option is ignored by SSLSocket in JDK 11 > > Most of these changes have also been included by Oracle in 8u261 or > 8u271, with two exceptions. [2] is there only as a prerequisite of [3], > and although there is an entry for a [3] backport to 8u281, but it is > marked as Won't Fix, I'll leave to the maintainers to decide whether we > want to include [3] or not. Regarding the backports, only [1] and [5] > weren't clean, I will be sending RFRs for them. > > Additionally, I have located two other Socket related patches that > Oracle included in 8 and 11 that we are missing: > [9] JDK-8256818: SSLSocket that is never bound or connected leaks > socket resources > [10] JDK-8224829: AsyncSSLSocketClose.java has timing issue > > If and when these two patches are included in 11u, I think we should > bring them to 8u too. I already sent an email to jdk-updates-dev for > clarification on how to proceed with [10], as it interacts with how [2] > was done. > > Out of this list, I would be interested in knowing which patches the > maintainers think should made it to 8u. Given how interwoven most of > them are, which ones are included will affect whether and RFR is needed > or not, and how the RFR would look like. > > Thanks, > > David > > -- > [1] https://bugs.openjdk.java.net/browse/JDK-8209333 > [2] https://bugs.openjdk.java.net/browse/JDK-8240827 > [3] https://bugs.openjdk.java.net/browse/JDK-8219991 > [4] https://bugs.openjdk.java.net/browse/JDK-8235263 > [5] https://bugs.openjdk.java.net/browse/JDK-8239798 > [6] https://bugs.openjdk.java.net/browse/JDK-8242294 > [7] https://bugs.openjdk.java.net/browse/JDK-8246031 > [8] https://bugs.openjdk.java.net/browse/JDK-8236464 > [9] https://bugs.openjdk.java.net/browse/JDK-8256818 > [10] https://bugs.openjdk.java.net/browse/JDK-8224829 > > > > > Thanks for looking into this (and for the links!) I've been meaning to do the same since the backport was integrated. I'll have a look at them in detail tomorrow. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From aph at redhat.com Tue Dec 22 11:18:41 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Dec 2020 11:18:41 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: <20201222025010.GC51872@rincewind> References: <20201211170313.GH1323090@rincewind> <20201222025010.GC51872@rincewind> Message-ID: <0c4bdefe-913b-595e-b54e-3a456296e3db@redhat.com> On 12/22/20 2:50 AM, Andrew Hughes wrote: > It is honestly getting a little tiresome to have it raised in > otherwise unrelated discussions as if it is the solution to every > problem. It also rather undermines the idea that 8u & 11u should > follow the same process, if it is being suggested that 11u move to a > different version control system. It should, as long as the overheads of the shift don't dominate. The Skara process, and Github itself, are vastly better than what they replaced. Unless we move we'll seriously restrict the developers prepared to do backporting, too. -- 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 peter.zhelezniakov at bell-sw.com Tue Dec 22 12:14:49 2020 From: peter.zhelezniakov at bell-sw.com (Peter Zhelezniakov) Date: Tue, 22 Dec 2020 15:14:49 +0300 Subject: RFR [1/3]: 8057038 Speculative traps not robust when compilation and class unloading are concurrent Message-ID: <9A1F0FBE-AC8D-4A17-B014-1C8EFF6F21E8@getmailspring.com> Hi, This is the first backport request in a series of 3: [1], [2], [3]. These fixes introduce atomicity and mutexes to Hotspot code. They help address crashes that occur in Apache Geode when running on a server with tens of CPU cores. The patch from jdk9 did not apply as is, some contextual changes were needed. This fix had a flaw that was later identified and fixed under [2]. Request for [2] is coming next in the series. Testing: Hotspot JTreg tests. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8057038 Webrev: http://cr.openjdk.java.net/~avoitylov/peterz/8057038/8057038/ Thanks! Peter [1] https://bugs.openjdk.java.net/browse/JDK-8057038 [2] https://bugs.openjdk.java.net/browse/JDK-8139247 [3] https://bugs.openjdk.java.net/browse/JDK-8231501 From peter.zhelezniakov at bell-sw.com Tue Dec 22 12:17:21 2020 From: peter.zhelezniakov at bell-sw.com (Peter Zhelezniakov) Date: Tue, 22 Dec 2020 15:17:21 +0300 Subject: RFR [2/3]: 8139247 Improper locking of MethodData::_extra_data_lock Message-ID: <676B63EA-7E73-477C-BCAA-639BF6C87787@getmailspring.com> Hi, This is the second backport request in a series of 3: [1], [2], [3]. This fix corrects a flaw that was made in the fix for [1]. The patch from jdk9 did not apply as is. One small change was needed to introduce err_msg that was absent in jdk9 code base. Tested with Hotspot JTreg tests. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8139247 Webrev: http://cr.openjdk.java.net/~avoitylov/peterz/8139247/8139247/ Thanks! Peter [1] https://bugs.openjdk.java.net/browse/JDK-8057038 [2] https://bugs.openjdk.java.net/browse/JDK-8139247 [3] https://bugs.openjdk.java.net/browse/JDK-8231501 From peter.zhelezniakov at bell-sw.com Tue Dec 22 12:22:58 2020 From: peter.zhelezniakov at bell-sw.com (Peter Zhelezniakov) Date: Tue, 22 Dec 2020 15:22:58 +0300 Subject: RFR [3/3]: 8231501 VM crash in MethodData::clean_extra_data(CleanExtraDataClosure*): fatal error: unexpected tag 99 Message-ID: <1FFC903D-3F4E-46C4-91BF-223F9258B546@getmailspring.com> Hi, This is the final backport request in a series of 3: [1], [2], [3]. The patch did not apply cleanly because context has changed significantly. Tested with Hotspot JTreg tests. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8231501 Webrev: http://cr.openjdk.java.net/~avoitylov/peterz/8231501/8231501/ Thanks! Peter [1] https://bugs.openjdk.java.net/browse/JDK-8057038 [2] https://bugs.openjdk.java.net/browse/JDK-8139247 [3] https://bugs.openjdk.java.net/browse/JDK-8231501 From yano-masanori at fujitsu.com Wed Dec 23 07:57:39 2020 From: yano-masanori at fujitsu.com (yano-masanori at fujitsu.com) Date: Wed, 23 Dec 2020 07:57:39 +0000 Subject: [PING] RE: 8180478: tools/launcher/MultipleJRE.sh fails on Windows because of extra-'' Message-ID: Hello, Please reply if anyone can be a sponsor. Regards, Masanori Yano > -----Original Message----- > From: Yano, Masanori/?? ?? > Sent: Wednesday, November 11, 2020 4:06 PM > To: 'jdk8u-dev at openjdk.java.net' > Subject: 8180478: tools/launcher/MultipleJRE.sh fails on Windows because of > extra-'' > > Hello. > > I would like to contribute for JDK-8180478. > > The test of tools/launcher/MultipleJRE.sh fails on the JDK8 for the Windows because > the 'RELEASE' variable contains the carriage return. > > The 'RELEASE' variable is created from the third word in the first line of the "java > -version" command. > But this is a last word of the line, so the 'RELEASE' variable contains the carriage > return. > The 'RELEASE' variable is compared to the actual java version, but does not match > because of the carriage return difference. > > Since JDK 11, this is no longer a problem because the date has been added as a fourth > word. > Therefore, the test for JDK8 should be fixed to remove the carriage returns. > > Please sponsor the following change. > > diff -r 4c5dceabd4c6 test/tools/launcher/MultipleJRE.sh > --- a/test/tools/launcher/MultipleJRE.sh Mon Apr 21 14:35:14 2014 +0400 > +++ b/test/tools/launcher/MultipleJRE.sh Tue Nov 10 20:08:05 2020 > +0900 > @@ -308,7 +308,7 @@ > # Main test sequence starts here > # > RELEASE=`$JAVA -version 2>&1 | head -n 1 | cut -d ' ' -f 3 | \ > - sed -e "s/\"//g"` > + sed -e "s/\"//g" | sed -e "s/\r//g"` > BASE_RELEASE=`echo $RELEASE | sed -e "s/-.*//g"` > > # > > Regards, > Masanori Yano From sgehwolf at redhat.com Wed Dec 23 11:43:39 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 23 Dec 2020 12:43:39 +0100 Subject: [8u] RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem Message-ID: Hi, Please review this JDK 8u patch which I'd like to get into OpenJDK 8u since Oracle backported it too. The patch is about better error checking (catching UncheckedIOException in various places including initialization code). The JDK 11 patch didn't apply cleanly due to context difference in the import of SubSystem.java. That's all. Trivially resolved. Bug: https://bugs.openjdk.java.net/browse/JDK-8255908 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8255908/jdk8/02/webrev/ Thoughts? Thanks, Severin From aph at redhat.com Wed Dec 23 13:15:07 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Dec 2020 13:15:07 +0000 Subject: [8u] RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem In-Reply-To: References: Message-ID: <612c5789-12af-0536-a85d-3bde2f822f2c@redhat.com> On 12/23/20 11:43 AM, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8255908 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8255908/jdk8/02/webrev/ > > Thoughts? Looks fine. -- 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 Wed Dec 23 13:43:47 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 23 Dec 2020 14:43:47 +0100 Subject: [8u] RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem In-Reply-To: <612c5789-12af-0536-a85d-3bde2f822f2c@redhat.com> References: <612c5789-12af-0536-a85d-3bde2f822f2c@redhat.com> Message-ID: On Wed, 2020-12-23 at 13:15 +0000, Andrew Haley wrote: > On 12/23/20 11:43 AM, Severin Gehwolf wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255908 > > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8255908/jdk8/02/webrev/ > > Looks fine. Thanks for the review. Tagged for approval. Cheers, Severin From felix.yang at huawei.com Thu Dec 24 11:03:00 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 24 Dec 2020 11:03:00 +0000 Subject: RFR Backport: 8166607: G1 needs klass_or_null_acquire Message-ID: Hi, As mentioned in [1], JDK-8160369 have not been backported to JDK8u. This is necessary for RMO architectures like aarch64. JDK- 8166607 is a subtask of JDK-8160369. Original bug: https://bugs.openjdk.java.net/browse/JDK-8166607 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1a33f585a889 Original RFR thread: https://mail.openjdk.java.net/pipermail/hotspot-dev/2016-September/024687.html The original patch for JDK- 8166607 does not apply cleanly to jdk8u-dev due to path and code refactoring work in jdk9+. Webrev for 8u: http://cr.openjdk.java.net/~fyang/8166607-8u/webrev.00/ Except for path adaption, two extra changes are needed here: 1. Use hr->isHumongous() instead of hr->is_humongous(). Function name for isHumongous() and friends are normalized by 8058495. 2. Wrap error messages used in assertion using err_msg. Performed full jtreg test with release build both on aarch64-linux and x86_64-linux platforms. OK to backport? Thanks, Felix [1] https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030313.html From aph at redhat.com Fri Dec 25 11:02:13 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Dec 2020 11:02:13 +0000 Subject: RFR Backport: 8166607: G1 needs klass_or_null_acquire In-Reply-To: References: Message-ID: <42cd761e-737f-2c21-d3b3-07663cccc57c@redhat.com> On 12/24/20 11:03 AM, Yangfei (Felix) wrote: > Webrev for 8u: > http://cr.openjdk.java.net/~fyang/8166607-8u/webrev.00/ > > Except for path adaption, two extra changes are needed here: > 1. Use hr->isHumongous() instead of hr->is_humongous(). Function name for isHumongous() and friends are normalized by 8058495. > 2. Wrap error messages used in assertion using err_msg. > > Performed full jtreg test with release build both on aarch64-linux and x86_64-linux platforms. > > OK to backport? 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 felix.yang at huawei.com Sat Dec 26 00:53:44 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Sat, 26 Dec 2020 00:53:44 +0000 Subject: RFR Backport: 8166607: G1 needs klass_or_null_acquire In-Reply-To: <42cd761e-737f-2c21-d3b3-07663cccc57c@redhat.com> References: <42cd761e-737f-2c21-d3b3-07663cccc57c@redhat.com> Message-ID: > -----Original Message----- > From: jdk8u-dev [mailto:jdk8u-dev-retn at openjdk.java.net] On Behalf Of > Andrew Haley > Sent: Friday, December 25, 2020 7:02 PM > To: jdk8u-dev at openjdk.java.net > Subject: Re: RFR Backport: 8166607: G1 needs klass_or_null_acquire > > On 12/24/20 11:03 AM, Yangfei (Felix) wrote: > > Webrev for 8u: > > http://cr.openjdk.java.net/~fyang/8166607-8u/webrev.00/ > > > > Except for path adaption, two extra changes are needed here: > > 1. Use hr->isHumongous() instead of hr->is_humongous(). Function name > for isHumongous() and friends are normalized by 8058495. > > 2. Wrap error messages used in assertion using err_msg. > > > > Performed full jtreg test with release build both on aarch64-linux and > x86_64-linux platforms. > > > > OK to backport? > > OK, thanks. Thanks for the review. Tagged for approval. Best Regards, Felix From gnu.andrew at redhat.com Thu Dec 31 03:11:29 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 31 Dec 2020 03:11:29 +0000 Subject: OpenJDK 8u282-b07 EA Released Message-ID: <20201231031129.GA273418@rincewind> I've made available an early access source bundle for 8u282, based on the tag jdk8u282-b07: https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b07-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b07-ea.tar.xz.sig This is signed by our new 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: 375f3812fa1f6a7572b781faa88494574f48cf12135bceec8bbd3589a3f96c79 openjdk8u282-b07-ea.tar.xz 272e79a5efd21419225cb5dd07174513d334629ffc1149baf4b7ab9f7874bd0f openjdk8u282-b07-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u282-b07-ea.sha256 Changes in 8u282-b07: - JDK-8225072: Add LuxTrust certificate that is expiring in March 2021 to list of allowed but expired certs - JDK-8239105: Add exception for expiring Digicert root certificates to VerifyCACerts test - JDK-8258630: Add expiry exception for QuoVadis root certificate Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Dec 31 03:13:13 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 31 Dec 2020 03:13:13 +0000 Subject: [FREEZE] 8u282 NOW FROZEN Message-ID: <20201231031313.GA274215@rincewind> The release forest: https://hg.openjdk.java.net/jdk8u/jdk8u (and friends) is now frozen in preparation for release around 2021-01-19. The final public pre-release build was jdk8u282-b07. The final release tag will be no lower than jdk8u282-b08. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From felix.yang at huawei.com Thu Dec 31 03:28:01 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 31 Dec 2020 03:28:01 +0000 Subject: [8u] RFR: JDK-8257192: Integrate AArch64 JIT port into 8u In-Reply-To: <20201215183218.GA131217@rincewind> References: <20201127072126.GJ488659@rincewind> <20201127073332.GA779738@rincewind> <20201215183218.GA131217@rincewind> Message-ID: Hi, > -----Original Message----- > From: Andrew Hughes [mailto:gnu.andrew at redhat.com] > Sent: Wednesday, December 16, 2020 2:32 AM > To: Yangfei (Felix) > Cc: jdk8u-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net > Subject: Re: [8u] RFR: JDK-8257192: Integrate AArch64 JIT port into 8u > > On 08:57 Sat 28 Nov , Yangfei (Felix) wrote: > > Hi, > > > > > -----Original Message----- > > > From: jdk8u-dev [mailto:jdk8u-dev-retn at openjdk.java.net] On Behalf > > > Of Andrew Hughes > > > Sent: Friday, November 27, 2020 3:34 PM > > > To: jdk8u-dev at openjdk.java.net > > > Cc: aarch64-port-dev at openjdk.java.net > > > Subject: Re: [8u] RFR: JDK-8257192: Integrate AArch64 JIT port into > > > 8u > > > > > > On 07:21 Fri 27 Nov , Andrew Hughes wrote: > > > > Umbrella Bug: https://bugs.openjdk.java.net/browse/JDK-8257192 > > > > Webrevs: > > > > Thanks for bringing this to 8u upstream. > > > > I performed some testing on our platforms for the following patches based > on the latest jdk8u-dev repo (jdk8u282-b03): > > > > > https://cr.openjdk.java.net/~andrew/openjdk8/8257192/root/webrev.01/ > > > https://cr.openjdk.java.net/~andrew/openjdk8/8257192/jdk/webrev.01/ > > > > > https://cr.openjdk.java.net/~andrew/openjdk8/8257192/hotspot/webrev.0 > 2 > > / > > > > 1. Run full jtreg test with release build on x86_64-linux-gnu, no regression > witnessed. > > Passed jcstress test on x86_64-linux-gnu. > > > > 2. Run full jtreg test with release build on aarch64-linux-gnu, no regression > witnessed. (Compared with jtreg test result of aarch64 release build from > latest aarch64-port/jdk8u-shenandoah repo) > > Passed jcstress test on my 128-core aarch64 Kunpeng server. > > > > 3. Performed specjbb2015 test with release build on aarch64-linux-gnu. > > Performance numbers is reproducible as compared with aarch64 release > build from latest aarch64-port/jdk8u-shenandoah repo. > > > > Hope that helps :-) > > > > Best regards, > > Felix > > It does. > > Good to know it works for you :-) > > I'll make another revision, based on Aleksey's latest comments, and we'll try > and get this in. I find aarch64 release & fastdebug fail to build with the three patches based on the latest jdk8u-dev repo. I am using gcc version 7.5.0. sh configure --prefix=/home/yangfei/jdk8u-release --with-jvm-variants=server --with-debug-level=release --enable-unlimited-crypto --with-native-debug-symbols=internal --with-boot-jdk=/home/yangfei/tools/jdk8u275-b01 Compile error message: /home/yangfei/openjdk8u-dev/hotspot/src/cpu/aarch64/vm/aarch64.ad: In member function ?virtual void cmpFastLockNode::emit(CodeBuffer&, PhaseRegAlloc*) const?: /home/yangfei/openjdk8u-dev/hotspot/src/cpu/aarch64/vm/aarch64.ad:3354:85: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] __ mov(tmp, (address) (~(os::vm_page_size()-1) | markOopDesc::lock_mask_in_place)); ^ ^ I think we might need to add one extra patch here: http://hg.openjdk.java.net/jdk/jdk/rev/964186594f5f This patch is trivial and applies after path shuffling. OK to build aarch64 release & fastdebug with this extra patch. Please take a look. Thanks, Felix