From mbalao at redhat.com Tue Dec 1 03:37:04 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 1 Dec 2020 00:37:04 -0300 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> <315008ad-73ae-f77d-5731-854d22083148@redhat.com> <92ed6f9d-9476-795c-eb16-65bce15db1c5@redhat.com> <062fb54a-71b0-5695-14e7-aec475316d04@redhat.com> Message-ID: <28304f4f-4dae-dee6-bc2d-90e9908de662@redhat.com> Quick update: I'm not done yet but here you have a preview of my changes: http://people.redhat.com/mbalaoal/openjdk/workspace/sunjsse_experimental_fips_support_and_dh_jdk11u/test_experimental_fips_with_dh.jdk11u.v1.patch That fix looks enough for the reproducer to pass, but I still need to track a few things to make sure only SunJSSE's FIPS provider (if one) is used. When done, I'll create a new bug and send a Webrev for review. If we can't meet the ramp-down deadline, I'll request a critical fix for maintainers to decide. Thanks, Martin.- On 11/30/20 11:43 AM, Martin Balao wrote: > Hi Goetz, > > Thanks for having a look at this. > > On 11/30/20 7:06 AM, Lindenmaier, Goetz wrote: >> >> I have been looking at your test, but it is not yet working >> on my machine. It skips the test after initializing. >> > > Yes, NSS tests require some help from the environment so they might be > skipped. A Linux-based environment with the NSS library located in the > (major distros) standard path should make it. Let me know if I can help > with that. > >> Before backing out, we should consider whether >> not having the new EC curves introduced by 8171279 >> in 11.0.10 is acceptable. This is an extension that is >> documented as CSR and might be expected by people. >> It is in 11.0.10-oracle, too. >> > > I should be able to come up with a fix later today. The fix looks > straight forward -it's essentially replacing KeyAgreement::getInstance > calls with the previous calls-, but I want to make sure that everything > else is fine. > >> To me, it seems more relevant than the FIPS feature broken, >> which never has been an official feature as I understand, >> and of which it has been communicated (inofficially) that it >> does not work any more since 9. > > FIPS support in SunJSSE works up to 13, and our users rely on that. The > comment about stopping to work in 9 is wrong -I'll try to have it fixed, > as it has caused enough confusion-. There is a public API to initialize > FIPS in SunJSSE, which is through the java.security configuration file > (when you pass an argument to the SunJSSE security provider line). > > Thanks, > Martin.- > From yan at openjdk.java.net Tue Dec 1 07:23:01 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 1 Dec 2020 07:23:01 GMT Subject: [jdk13u-dev] RFR: 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR In-Reply-To: <3VKDuaH-g0zsEcyxVSmwGg5N4SUkw2GRpu-68KQnk5M=.ce8d498d-578d-46e9-824c-494845a4c219@github.com> References: <3VKDuaH-g0zsEcyxVSmwGg5N4SUkw2GRpu-68KQnk5M=.ce8d498d-578d-46e9-824c-494845a4c219@github.com> Message-ID: On Wed, 25 Nov 2020 14:14:58 GMT, Sergey Chernyshev wrote: > Hello, > > I would like to create a backport of 8233228 in 13u. The backport is already in production in 11u. > > The proposed 8233228 patch is exactly the same as 15u version, except for Hunk #9 at line 258(299): > > [https://github.com/openjdk/jdk13u-dev/commit/edec2fc6d79678111f97fa9da81d3bc1d2010538#diff-499d805909084ecc06c50b4706f8a2b3ec70ab9aaf55d54a6156c518f85f1bd6](https://github.com/openjdk/jdk13u-dev/commit/edec2fc6d79678111f97fa9da81d3bc1d2010538#diff-499d805909084ecc06c50b4706f8a2b3ec70ab9aaf55d54a6156c518f85f1bd6) > > in which the 8244479 is already applied. In comparison, the 15u version applies 8244479 on top of 8233228, so the changes are in reverse order. Otherwise there are no code / logic changes in the code. > > Thank you. > > Best regards, > Sergey Chernyshev > BellSoft Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/32 From yan at openjdk.java.net Tue Dec 1 11:53:03 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 1 Dec 2020 11:53:03 GMT Subject: [jdk13u-dev] RFR: 8234347: "Turkey" meta time zone does not generate composed localized names Message-ID: This fix should resolve both JDK-8236548 and JDK-8234347. It does require CSR (JDK-8257501) and will be pushed after the approval of it. The patch applies clean with only extra context changes in copyright dates. The change is in both jdk15 and jdk11. ------------- Commit messages: - Backport 5c3a01591c5c945926636fdc9f164d60b5b4f29e Changes: https://git.openjdk.java.net/jdk13u-dev/pull/40/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=40&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234347 Stats: 352 lines in 10 files changed: 99 ins; 176 del; 77 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/40.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/40/head:pull/40 PR: https://git.openjdk.java.net/jdk13u-dev/pull/40 From thomas.stuefe at gmail.com Tue Dec 1 12:39:34 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 1 Dec 2020 13:39:34 +0100 Subject: [11u] RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned Message-ID: Hi, may I please have reviews for the following downport: Original issue: https://bugs.openjdk.java.net/browse/JDK-8256287 Original patch: https://github.com/openjdk/jdk/commit/0357db35.diff Modified patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8256287-windows-add-loop-fuse-to-map_or_reserve_memory_aligned-for-11.diff The original patch does not apply cleanly since this function had been heavily reworked. I rewrote it from scratch, but since the problem is simple this should be simple to review. Thanks, Thomas From martin.doerr at sap.com Tue Dec 1 13:16:48 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 1 Dec 2020 13:16:48 +0000 Subject: [11u] RFR: 8257408: Bump update version for OpenJDK: jdk-11.0.11 In-Reply-To: References: Message-ID: Hi G?tz, looks good. Thanks, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 30. November 2020 12:37 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8257408: Bump update version for OpenJDK: jdk-11.0.11 > > Hi, > > to start development of jdk-11.0.11, we need to bump > the version: > http://cr.openjdk.java.net/~goetz/wr20/8257408-version_11.0.11-jdk11/01/ > > Please review. > > Naturally, I will only push this after dev close of 11.0.10, > and after JBS was updated to tag for 11.0.11. > > For the date, see also https://www.oracle.com/security-alerts/ > > Thanks, > Goetz. From goetz.lindenmaier at sap.com Tue Dec 1 13:49:56 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Dec 2020 13:49:56 +0000 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: <28304f4f-4dae-dee6-bc2d-90e9908de662@redhat.com> References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> <315008ad-73ae-f77d-5731-854d22083148@redhat.com> <92ed6f9d-9476-795c-eb16-65bce15db1c5@redhat.com> <062fb54a-71b0-5695-14e7-aec475316d04@redhat.com> <28304f4f-4dae-dee6-bc2d-90e9908de662@redhat.com> Message-ID: Hi Martin, Thanks for your hints and the patch! I got the test running and can reproduce the issue. And yes, your change fixes the test. I understand the code in 11 needs to check whether there is a cryptoProvider preselected in SunJSSE. I think you don't need to rush, the rampdown period is 4 weeks, and it is dedicated to fix such issues. So I think it's completely fine if this goes to jdk11u. But it is good the issue is detected and understood before rampdown, thanks again for your help! Best regards, Goetz. > -----Original Message----- > From: Martin Balao > Sent: Tuesday, December 1, 2020 4:37 AM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Cc: 'Andrew Haley' ; Severin Gehwolf > > Subject: Re: [11u] RFR: 8171279: Support X25519 and X448 in TLS > > Quick update: > > I'm not done yet but here you have a preview of my changes: > http://people.redhat.com/mbalaoal/openjdk/workspace/sunjsse_experimen > tal_fips_support_and_dh_jdk11u/test_experimental_fips_with_dh.jdk11u.v1. > patch > > That fix looks enough for the reproducer to pass, but I still need to > track a few things to make sure only SunJSSE's FIPS provider (if one) is > used. When done, I'll create a new bug and send a Webrev for review. If > we can't meet the ramp-down deadline, I'll request a critical fix for > maintainers to decide. > > Thanks, > Martin.- > > > On 11/30/20 11:43 AM, Martin Balao wrote: > > Hi Goetz, > > > > Thanks for having a look at this. > > > > On 11/30/20 7:06 AM, Lindenmaier, Goetz wrote: > >> > >> I have been looking at your test, but it is not yet working > >> on my machine. It skips the test after initializing. > >> > > > > Yes, NSS tests require some help from the environment so they might be > > skipped. A Linux-based environment with the NSS library located in the > > (major distros) standard path should make it. Let me know if I can help > > with that. > > > >> Before backing out, we should consider whether > >> not having the new EC curves introduced by 8171279 > >> in 11.0.10 is acceptable. This is an extension that is > >> documented as CSR and might be expected by people. > >> It is in 11.0.10-oracle, too. > >> > > > > I should be able to come up with a fix later today. The fix looks > > straight forward -it's essentially replacing KeyAgreement::getInstance > > calls with the previous calls-, but I want to make sure that everything > > else is fine. > > > >> To me, it seems more relevant than the FIPS feature broken, > >> which never has been an official feature as I understand, > >> and of which it has been communicated (inofficially) that it > >> does not work any more since 9. > > > > FIPS support in SunJSSE works up to 13, and our users rely on that. The > > comment about stopping to work in 9 is wrong -I'll try to have it fixed, > > as it has caused enough confusion-. There is a public API to initialize > > FIPS in SunJSSE, which is through the java.security configuration file > > (when you pass an argument to the SunJSSE security provider line). > > > > Thanks, > > Martin.- > > From rob.mckenna at oracle.com Tue Dec 1 14:30:55 2020 From: rob.mckenna at oracle.com (Robert McKenna) Date: Tue, 1 Dec 2020 14:30:55 +0000 Subject: [16u Communication] Heads up: Skara adoption Message-ID: <1831c3d7-b855-75da-222e-501130648232@oracle.com> Hi folks, As I'm sure you're all aware, jdk/jdk has moved to git. A natural consequence of this is that we will be forking the jdk16u repo from a git repository. So from jdk16u forward the jdk-updates project will get to leverage the great work done by the Skara team. ??? -Rob From yan at openjdk.java.net Tue Dec 1 15:39:09 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 1 Dec 2020 15:39:09 GMT Subject: [jdk13u-dev] RFR: 8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?" Message-ID: I'd like to downport it, too, as it is in both 15 and 11 ------------- Commit messages: - Backport bbcb3b638b0488d4705cae73add15455ca3de977 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/41/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=41&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8230402 Stats: 93 lines in 3 files changed: 81 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/41.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/41/head:pull/41 PR: https://git.openjdk.java.net/jdk13u-dev/pull/41 From yan at openjdk.java.net Tue Dec 1 15:56:01 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 1 Dec 2020 15:56:01 GMT Subject: [jdk13u-dev] Integrated: 8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?" In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 15:34:06 GMT, Yuri Nesterenko wrote: > I'd like to downport it, too, as it is in both 15 and 11 This pull request has now been integrated. Changeset: 420ec53c Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/420ec53c Stats: 93 lines in 3 files changed: 81 ins; 9 del; 3 mod 8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?" Remove assert that is only hit with hand written edge case tests. Backport-of: bbcb3b638b0488d4705cae73add15455ca3de977 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/41 From goetz.lindenmaier at sap.com Tue Dec 1 16:55:35 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Dec 2020 16:55:35 +0000 Subject: [11u notice]: jdk 11.0.10 rampdown starts now. Message-ID: Hi, Jdk 11.0.10 rampdown starts now. The current state of jdk11u-dev will be merged to jdk11u, no further merges will take place. Further changes for 11.0.10 must be requested with jdk11u-critical-request tags, and they need to be pushed directly to repository jdk11u. Repository jdk11u-dev is closed now. Please don't push to jdk11u-dev until tag 11.0.11+0 arrived in the repo. This will happen soon. Best regards, Goetz From junguoj at amazon.com Tue Dec 1 20:29:54 2020 From: junguoj at amazon.com (Guo, James) Date: Tue, 1 Dec 2020 20:29:54 +0000 Subject: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c Message-ID: 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 junguoj at amazon.com Tue Dec 1 20:29:56 2020 From: junguoj at amazon.com (Guo, James) Date: Tue, 1 Dec 2020 20:29:56 +0000 Subject: [8u] RFR 8255226: (tz) Upgrade time-zone data to tzdata2020d Message-ID: 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 Thanks, -James From mbalao at redhat.com Tue Dec 1 22:06:47 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 1 Dec 2020 19:06:47 -0300 Subject: [11u] RFR 8257545: SunJSSE FIPS regression in key exchange after JDK-8171279 11u backport Message-ID: <086ed992-91fd-713a-edb8-775cf6d29a67@redhat.com> Hi, As discussed in [1], this is a fix for the JDK-8257545 regression affecting 11u [2]. I'd like to have a review of Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8257545/8257545.webrev.00/ The fix is about picking the crypto provider used to initialized SunJSSE (if any) while performing the key exchange phase of the TLS handshake. Please note that SunPKCS11 does not register AlgorithmParameters for the DiffieHellman algorithm. Other crypto providers may do that as well. So it's not always possible to identify a Named Group based on the parameter values. Even though I see no downside of making SunPKCS11 register AlgorithmParameters for DiffieHellman with the DHParameters class, I prefer to stay on a more conservative side at this time and also cover non-SunPKCS11 cases. As a result, we skip the Named Group identification in NamedGroup.java if ng.functions.getParameters returned value is null. Note: this is what 11.0.9 and previous releases are doing, as checked debugging old releases. This is unlikely to affect JDK releases after 13u because AlgorithmParameters may be obtained from any crypto provider, and not only the one used to initialize SunJSSE (if one). I'm currently running regression testing. Let you know if I find something wrong. Thanks, Martin.- -- [1] - http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-November/004164.html [2] - https://bugs.openjdk.java.net/browse/JDK-8257545 From mbalao at redhat.com Tue Dec 1 22:09:22 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 1 Dec 2020 19:09:22 -0300 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> <315008ad-73ae-f77d-5731-854d22083148@redhat.com> <92ed6f9d-9476-795c-eb16-65bce15db1c5@redhat.com> <062fb54a-71b0-5695-14e7-aec475316d04@redhat.com> <28304f4f-4dae-dee6-bc2d-90e9908de662@redhat.com> Message-ID: Hi Goetz, On Tue, Dec 1, 2020 at 10:50 AM Lindenmaier, Goetz wrote: > Thanks for your hints and the patch! > I got the test running and can reproduce the issue. And yes, > your change fixes the test. I understand the code in 11 > needs to check whether there is a cryptoProvider preselected > in SunJSSE. Great. Thanks for checking that. > > I think you don't need to rush, the rampdown period is 4 weeks, > and it is dedicated to fix such issues. So I think it's completely > fine if this goes to jdk11u. But it is good the issue is > detected and understood before rampdown, thanks again > for your help! > Sure. Followup discussion here: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004313.html Martin.- From hohensee at amazon.com Tue Dec 1 22:17:38 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 1 Dec 2020 22:17:38 +0000 Subject: [8u] RFR 8254982: (tz) Upgrade time-zone data to tzdata2020c In-Reply-To: References: Message-ID: <15BCA980-031B-4443-AE70-2690EBCF7D57@amazon.com> 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 thomas.stuefe at gmail.com Wed Dec 2 08:30:46 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 2 Dec 2020 09:30:46 +0100 Subject: [11u] RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned Message-ID: Hi, I'd like to get reviews for the backport of the following fix: Original issue: https://bugs.openjdk.java.net/browse/JDK-8256287 Original patch: https://github.com/openjdk/jdk/commit/0357db35 Modified patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8256287-windows-add-loop-fuse-to-map_or_reserve_memory_aligned-for-11.diff This patch had to be rewritten for 11 since most of the surroundings changed since 11 due to cleanups. But the patch itself is straightforward. Thank you, Thomas From github.com+6394632+sercher at openjdk.java.net Wed Dec 2 08:51:59 2020 From: github.com+6394632+sercher at openjdk.java.net (Sergey Chernyshev) Date: Wed, 2 Dec 2020 08:51:59 GMT Subject: [jdk13u-dev] Integrated: 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR In-Reply-To: <3VKDuaH-g0zsEcyxVSmwGg5N4SUkw2GRpu-68KQnk5M=.ce8d498d-578d-46e9-824c-494845a4c219@github.com> References: <3VKDuaH-g0zsEcyxVSmwGg5N4SUkw2GRpu-68KQnk5M=.ce8d498d-578d-46e9-824c-494845a4c219@github.com> Message-ID: On Wed, 25 Nov 2020 14:14:58 GMT, Sergey Chernyshev wrote: > Hello, > > I would like to create a backport of 8233228 in 13u. The backport is already in production in 11u. > > The proposed 8233228 patch is exactly the same as 15u version, except for Hunk #9 at line 258(299): > > [https://github.com/openjdk/jdk13u-dev/commit/edec2fc6d79678111f97fa9da81d3bc1d2010538#diff-499d805909084ecc06c50b4706f8a2b3ec70ab9aaf55d54a6156c518f85f1bd6](https://github.com/openjdk/jdk13u-dev/commit/edec2fc6d79678111f97fa9da81d3bc1d2010538#diff-499d805909084ecc06c50b4706f8a2b3ec70ab9aaf55d54a6156c518f85f1bd6) > > in which the 8244479 is already applied. In comparison, the 15u version applies 8244479 on top of 8233228, so the changes are in reverse order. Otherwise there are no code / logic changes in the code. > > Thank you. > > Best regards, > Sergey Chernyshev > BellSoft This pull request has now been integrated. Changeset: b452c821 Author: ascarpino Committer: Alexander Scherbatiy URL: https://git.openjdk.java.net/jdk13u-dev/commit/b452c821 Stats: 195 lines in 7 files changed: 154 ins; 7 del; 34 mod 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR Reviewed-by: yan ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/32 From shade at redhat.com Wed Dec 2 11:55:48 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Dec 2020 12:55:48 +0100 Subject: [11u] RFR (XS) 8256806: Shenandoah: optimize shenandoah/jni/TestPinnedGarbage.java test Message-ID: <581d3aa8-0f14-28be-3707-7490b87522ec@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8256806 https://github.com/openjdk/jdk/commit/86f36027 It does not apply cleanly to 11u, because test got swept in global "randomness" refactoring. I redid it to use the same ThreadLocalRandom as it did in current 11u. 11u webrev: https://cr.openjdk.java.net/~shade/8256806/webrev.11u.01/ Testing: affected test on Linux x86_64 -- Thanks, -Aleksey From shade at redhat.com Wed Dec 2 12:11:34 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Dec 2020 13:11:34 +0100 Subject: [11u] RFR (XS) 8240751: Shenandoah: fold ShenandoahTracer definition Message-ID: Original RFE: https://bugs.openjdk.java.net/browse/JDK-8240751 https://git.openjdk.java.net/jdk/commit/382b8fed The context have changed, so patch does not apply cleanly. The patch itself is rather trivial. 11u webrev: https://cr.openjdk.java.net/~shade/8240751/webrev.11u.01/ Testing: Linux x86_64 {fastdebug,release} builds -- Thanks, -Aleksey From rkennke at redhat.com Wed Dec 2 14:08:23 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 2 Dec 2020 15:08:23 +0100 Subject: [11u] RFR (XS) 8256806: Shenandoah: optimize shenandoah/jni/TestPinnedGarbage.java test In-Reply-To: <581d3aa8-0f14-28be-3707-7490b87522ec@redhat.com> References: <581d3aa8-0f14-28be-3707-7490b87522ec@redhat.com> Message-ID: <9fb93ec8-3ec3-b7e4-c392-f1076de24e89@redhat.com> > Original fix: > ? https://bugs.openjdk.java.net/browse/JDK-8256806 > ? https://github.com/openjdk/jdk/commit/86f36027 > > It does not apply cleanly to 11u, because test got swept in global > "randomness" refactoring. I redid it to use the same ThreadLocalRandom > as it did in current 11u. > > 11u webrev: > ? https://cr.openjdk.java.net/~shade/8256806/webrev.11u.01/ > > Testing: affected test on Linux x86_64 Yes, looks fine! Thanks! Roman From rkennke at redhat.com Wed Dec 2 14:09:15 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 2 Dec 2020 15:09:15 +0100 Subject: [11u] RFR (XS) 8240751: Shenandoah: fold ShenandoahTracer definition In-Reply-To: References: Message-ID: <386ea7c6-8a97-cf31-8d43-19ecb11d04ee@redhat.com> > Original RFE: > ? https://bugs.openjdk.java.net/browse/JDK-8240751 > ? https://git.openjdk.java.net/jdk/commit/382b8fed > > The context have changed, so patch does not apply cleanly. The patch > itself is rather trivial. > > 11u webrev: > ? https://cr.openjdk.java.net/~shade/8240751/webrev.11u.01/ > > Testing: Linux x86_64 {fastdebug,release} builds Looks good, thank you! Roman From shade at redhat.com Wed Dec 2 14:17:42 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Dec 2020 15:17:42 +0100 Subject: [11u] RFR (XS) 8256806: Shenandoah: optimize shenandoah/jni/TestPinnedGarbage.java test In-Reply-To: <9fb93ec8-3ec3-b7e4-c392-f1076de24e89@redhat.com> References: <581d3aa8-0f14-28be-3707-7490b87522ec@redhat.com> <9fb93ec8-3ec3-b7e4-c392-f1076de24e89@redhat.com> Message-ID: <28011792-e012-d113-4606-d8e908fffd26@redhat.com> On 12/2/20 3:08 PM, Roman Kennke wrote: >> Original fix: >> ? https://bugs.openjdk.java.net/browse/JDK-8256806 >> ? https://github.com/openjdk/jdk/commit/86f36027 >> >> It does not apply cleanly to 11u, because test got swept in global >> "randomness" refactoring. I redid it to use the same ThreadLocalRandom >> as it did in current 11u. >> >> 11u webrev: >> ? https://cr.openjdk.java.net/~shade/8256806/webrev.11u.01/ >> >> Testing: affected test on Linux x86_64 > > Yes, looks fine! Thanks! Thanks, tagged. -- Thanks, -Aleksey From shade at redhat.com Wed Dec 2 14:17:54 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Dec 2020 15:17:54 +0100 Subject: [11u] RFR (XS) 8240751: Shenandoah: fold ShenandoahTracer definition In-Reply-To: <386ea7c6-8a97-cf31-8d43-19ecb11d04ee@redhat.com> References: <386ea7c6-8a97-cf31-8d43-19ecb11d04ee@redhat.com> Message-ID: <75a5219c-4f7a-a627-695d-572342ec16a1@redhat.com> On 12/2/20 3:09 PM, Roman Kennke wrote: >> Original RFE: >> ? https://bugs.openjdk.java.net/browse/JDK-8240751 >> ? https://git.openjdk.java.net/jdk/commit/382b8fed >> >> The context have changed, so patch does not apply cleanly. The patch >> itself is rather trivial. >> >> 11u webrev: >> ? https://cr.openjdk.java.net/~shade/8240751/webrev.11u.01/ >> >> Testing: Linux x86_64 {fastdebug,release} builds > > Looks good, thank you! Thanks, tagged. -- -Aleksey From goetz.lindenmaier at sap.com Wed Dec 2 14:59:49 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Dec 2020 14:59:49 +0000 Subject: [11u] RFR 8257545: SunJSSE FIPS regression in key exchange after JDK-8171279 11u backport In-Reply-To: <086ed992-91fd-713a-edb8-775cf6d29a67@redhat.com> References: <086ed992-91fd-713a-edb8-775cf6d29a67@redhat.com> Message-ID: Hi Martin, The change passed our nightly testing. It looks good to me, but I can not comment on the very internals of it. Thanks again for fixing this! Best regards, Goetz > -----Original Message----- > From: Martin Balao > Sent: Tuesday, December 1, 2020 11:07 PM > To: jdk-updates-dev at openjdk.java.net; Lindenmaier, Goetz > > Cc: Andrew Haley ; Severin Gehwolf > > Subject: [11u] RFR 8257545: SunJSSE FIPS regression in key exchange after > JDK-8171279 11u backport > > Hi, > > As discussed in [1], this is a fix for the JDK-8257545 regression > affecting 11u [2]. > > I'd like to have a review of Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8257545/8257545.webrev.00/ > > The fix is about picking the crypto provider used to initialized SunJSSE > (if any) while performing the key exchange phase of the TLS handshake. > > Please note that SunPKCS11 does not register AlgorithmParameters for the > DiffieHellman algorithm. Other crypto providers may do that as well. So > it's not always possible to identify a Named Group based on the > parameter values. Even though I see no downside of making SunPKCS11 > register AlgorithmParameters for DiffieHellman with the DHParameters > class, I prefer to stay on a more conservative side at this time and > also cover non-SunPKCS11 cases. As a result, we skip the Named Group > identification in NamedGroup.java if ng.functions.getParameters returned > value is null. Note: this is what 11.0.9 and previous releases are > doing, as checked debugging old releases. This is unlikely to affect JDK > releases after 13u because AlgorithmParameters may be obtained from any > crypto provider, and not only the one used to initialize SunJSSE (if one). > > I'm currently running regression testing. Let you know if I find > something wrong. > > Thanks, > Martin.- > > -- > [1] - > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > November/004164.html > [2] - https://bugs.openjdk.java.net/browse/JDK-8257545 From yan at openjdk.java.net Wed Dec 2 15:10:06 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 2 Dec 2020 15:10:06 GMT Subject: [jdk13u-dev] RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b Message-ID: We should catch up timezone data advance: this is tzdata2020b. The patch had one conflict with GendataTZDB.gmk renaming (and no content conflicts there) and a conflict in a test amounted to one symbol change. All relevant regtests do pass AFAIS ------------- Commit messages: - Backport 9c9349098ac2f1f797cdf8490e2eefccb95ecde2 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/42/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=42&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254177 Stats: 480 lines in 27 files changed: 138 ins; 133 del; 209 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/42.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/42/head:pull/42 PR: https://git.openjdk.java.net/jdk13u-dev/pull/42 From dcherepanov at openjdk.java.net Wed Dec 2 15:43:58 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Wed, 2 Dec 2020 15:43:58 GMT Subject: [jdk13u-dev] RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 15:06:05 GMT, Yuri Nesterenko wrote: > We should catch up timezone data advance: this is tzdata2020b. The patch had one conflict with GendataTZDB.gmk renaming (and no content conflicts there) and a conflict in a test amounted to one symbol change. All relevant regtests do pass AFAIS Marked as reviewed by dcherepanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/42 From yan at openjdk.java.net Wed Dec 2 15:43:59 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 2 Dec 2020 15:43:59 GMT Subject: [jdk13u-dev] Integrated: 8254177: (tz) Upgrade time-zone data to tzdata2020b In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 15:06:05 GMT, Yuri Nesterenko wrote: > We should catch up timezone data advance: this is tzdata2020b. The patch had one conflict with GendataTZDB.gmk renaming (and no content conflicts there) and a conflict in a test amounted to one symbol change. All relevant regtests do pass AFAIS This pull request has now been integrated. Changeset: b31ff272 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/b31ff272 Stats: 480 lines in 27 files changed: 138 ins; 133 del; 209 mod 8254177: (tz) Upgrade time-zone data to tzdata2020b Reviewed-by: dcherepanov Backport-of: 9c9349098ac2f1f797cdf8490e2eefccb95ecde2 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/42 From aph at redhat.com Wed Dec 2 16:39:21 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 2 Dec 2020 16:39:21 +0000 Subject: [11u] RFR 8257545: SunJSSE FIPS regression in key exchange after JDK-8171279 11u backport In-Reply-To: <086ed992-91fd-713a-edb8-775cf6d29a67@redhat.com> References: <086ed992-91fd-713a-edb8-775cf6d29a67@redhat.com> Message-ID: <1684d743-0654-7cae-61aa-cbd1dc1f2f39@redhat.com> On 01/12/2020 22:06, Martin Balao wrote: > I'd like to have a review of Webrev.00: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8257545/8257545.webrev.00/ > > The fix is about picking the crypto provider used to initialized SunJSSE > (if any) while performing the key exchange phase of the TLS handshake. 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 evergizova at openjdk.java.net Wed Dec 2 19:46:11 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 2 Dec 2020 19:46:11 GMT Subject: [jdk13u-dev] RFR: 8231209: [REDO] ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread Message-ID: I would like to backport 8231209 to 13u. CSR for 13u is filed and approved: JDK-8257412. The patch applies cleanly but it requires some modifications: - since javadoc tag for getCurrentThreadAllocatedBytes() should be changed from 14 to 13.0.6 - JMM_VERSION should not be modified The necessity of these changes is described in JDK-8253134 for 11u, it's applicable for 13u as well. Tested with ThreadMXBean tests and tier1. ------------- Commit messages: - Backport 1bce27d4027e56f9bd1aba5d8f587b0cda9b966a Changes: https://git.openjdk.java.net/jdk13u-dev/pull/43/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=43&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231209 Stats: 354 lines in 11 files changed: 233 ins; 32 del; 89 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/43/head:pull/43 PR: https://git.openjdk.java.net/jdk13u-dev/pull/43 From evergizova at openjdk.java.net Thu Dec 3 07:48:09 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 3 Dec 2020 07:48:09 GMT Subject: [jdk13u-dev] RFR: 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker Message-ID: I'd like to backport 8242480 to 13u for parity with 11u. The patch applies cleanly. Tested with container tests, the only failure is containers/docker/TestMemoryAwareness.java which is fixed by follow-up JDK-8246648, the plan is to push them together. ------------- Commit messages: - Backport f6f97ea24b60a20cd3a613928840fdb5d7bd63e0 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/44/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=44&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242480 Stats: 124 lines in 3 files changed: 122 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/44.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/44/head:pull/44 PR: https://git.openjdk.java.net/jdk13u-dev/pull/44 From yan at openjdk.java.net Thu Dec 3 08:11:01 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 3 Dec 2020 08:11:01 GMT Subject: [jdk13u-dev] RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c Message-ID: It is time to backport tzdata2020c here, too. The patch applies without any adjustment. All relevant tests pass. ------------- Commit messages: - Backport 55a0cad82751940076aa56e7644fb812d6cad3ba Changes: https://git.openjdk.java.net/jdk13u-dev/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=45&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254982 Stats: 33 lines in 4 files changed: 30 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk13u-dev/pull/45 From dcherepanov at openjdk.java.net Thu Dec 3 08:37:55 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 3 Dec 2020 08:37:55 GMT Subject: [jdk13u-dev] RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 08:06:13 GMT, Yuri Nesterenko wrote: > It is time to backport tzdata2020c here, too. The patch applies without any adjustment. All relevant tests pass. Marked as reviewed by dcherepanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/45 From yan at openjdk.java.net Thu Dec 3 08:57:55 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 3 Dec 2020 08:57:55 GMT Subject: [jdk13u-dev] Integrated: 8254982: (tz) Upgrade time-zone data to tzdata2020c In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 08:06:13 GMT, Yuri Nesterenko wrote: > It is time to backport tzdata2020c here, too. The patch applies without any adjustment. All relevant tests pass. This pull request has now been integrated. Changeset: 28cc6c2a Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/28cc6c2a Stats: 33 lines in 4 files changed: 30 ins; 0 del; 3 mod 8254982: (tz) Upgrade time-zone data to tzdata2020c Reviewed-by: dcherepanov Backport-of: 55a0cad82751940076aa56e7644fb812d6cad3ba ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/45 From yan at openjdk.java.net Thu Dec 3 09:44:55 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 3 Dec 2020 09:44:55 GMT Subject: [jdk13u-dev] RFR: 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics In-Reply-To: References: Message-ID: <2IeXpmGpTyEhAFBpzGRpQsdg13nC3Kyrf4bFOlS1AtY=.55347861-51b4-4a13-bbe5-7f065e64993e@github.com> On Fri, 27 Nov 2020 19:26:31 GMT, Ekaterina Vergizova wrote: > I would like to backport 8250627 to 13u for parity with 11u. > The patch doesn't apply cleanly since 13u doesn't have cgroups v2 support (JDK-8231111), reapplied manually. > Tested with container tests, including new one and tier1. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/38 From alexey at azul.com Thu Dec 3 14:58:01 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 3 Dec 2020 14:58:01 +0000 Subject: [11u] RFR: 8076190 Customizing the generation of a PKCS12 keystore Message-ID: Hello All, I would like to backport JDK-8076190 to 11u. CSR for 11u is filed: JDK-8257680. The patch applies cleanly except of test/lib/jdk/test/lib/security/DerUtils.java which is already backported to 11u as part of JDK-8215694 (see https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/551bc745f05d#l9.1) This feature minimizes behaviour differences between JKS and PKCS12 keystores. Also, it fixes issue with incorrectly decoded KDF algorithm as described in JDK-8245169 Webrev: http://cr.openjdk.java.net/~abakhtin/8076190/webrev.v0/ JBS: https://bugs.openjdk.java.net/browse/JDK-8076190 CSR for 11u: https://bugs.openjdk.java.net/browse/JDK-8257680 [1] https://bugs.openjdk.java.net/browse/JDK-8245169 [2] https://bugs.openjdk.java.net/browse/JDK-8215694 [3] https://bugs.openjdk.java.net/browse/JDK-8228455 Regards Alexey From hohensee at amazon.com Thu Dec 3 19:25:32 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 3 Dec 2020 19:25:32 +0000 Subject: [11u]: 8255351: Add detection for Graviton 2 CPUs Message-ID: <2F4CB87B-32DF-4BC0-8EEC-FF3D169315DC@amazon.com> Please review this 11u backport. JBS: https://bugs.openjdk.java.net/browse/JDK-8255351 Patch: https://git.openjdk.java.net/jdk/commit/2215e5a4 Webrev: http://cr.openjdk.java.net/~phh/8255351/webrev.11u.01/ Patch changed by adding copyright date update, and modifying trailing context in hunk #2. Thanks, Paul From vladimir.kozlov at oracle.com Thu Dec 3 19:34:35 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 3 Dec 2020 11:34:35 -0800 Subject: [11u]: 8255351: Add detection for Graviton 2 CPUs In-Reply-To: <2F4CB87B-32DF-4BC0-8EEC-FF3D169315DC@amazon.com> References: <2F4CB87B-32DF-4BC0-8EEC-FF3D169315DC@amazon.com> Message-ID: Changes look good but I don't see backport request in JBS. Thanks, Vladimir K On 12/3/20 11:25 AM, Hohensee, Paul wrote: > Please review this 11u backport. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8255351 > Patch: https://git.openjdk.java.net/jdk/commit/2215e5a4 > Webrev: http://cr.openjdk.java.net/~phh/8255351/webrev.11u.01/ > > Patch changed by adding copyright date update, and modifying trailing context in hunk #2. > > Thanks, > Paul > From hohensee at amazon.com Thu Dec 3 19:53:59 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 3 Dec 2020 19:53:59 +0000 Subject: [11u]: 8255351: Add detection for Graviton 2 CPUs Message-ID: Thanks for the very quick review, Vladimir. Protocol is to tag issues that need review after review approval. Now that I have yours I've tagged 8255351. Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Vladimir Kozlov Date: Thursday, December 3, 2020 at 11:35 AM To: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u]: 8255351: Add detection for Graviton 2 CPUs Changes look good but I don't see backport request in JBS. Thanks, Vladimir K On 12/3/20 11:25 AM, Hohensee, Paul wrote: > Please review this 11u backport. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8255351 > Patch: https://git.openjdk.java.net/jdk/commit/2215e5a4 > Webrev: http://cr.openjdk.java.net/~phh/8255351/webrev.11u.01/ > > Patch changed by adding copyright date update, and modifying trailing context in hunk #2. > > Thanks, > Paul > From richard.reingruber at sap.com Thu Dec 3 20:07:50 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 3 Dec 2020 20:07:50 +0000 Subject: [11u] RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned In-Reply-To: References: Message-ID: Hi Thomas, patch looks good to me. You might want to remove the extraneous whitespace between the ++ operator and its operand in the line below. 3086 for (int attempt = 0; attempt < max_attempts && aligned_base == NULL; attempt ++) { Thanks, Richard. -----Original Message----- From: jdk-updates-dev On Behalf Of Thomas St?fe Sent: Mittwoch, 2. Dezember 2020 09:31 To: jdk-updates-dev Cc: Hotspot dev runtime Subject: [11u] RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned Hi, I'd like to get reviews for the backport of the following fix: Original issue: https://bugs.openjdk.java.net/browse/JDK-8256287 Original patch: https://github.com/openjdk/jdk/commit/0357db35 Modified patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8256287-windows-add-loop-fuse-to-map_or_reserve_memory_aligned-for-11.diff This patch had to be rewritten for 11 since most of the surroundings changed since 11 due to cleanups. But the patch itself is straightforward. Thank you, Thomas From volker.simonis at gmail.com Thu Dec 3 20:12:12 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 3 Dec 2020 21:12:12 +0100 Subject: [11u]: 8255351: Add detection for Graviton 2 CPUs In-Reply-To: References: Message-ID: Hi Paul, Vladimir, I think we should only downport this change together with JDK-8257436 and JDK-8256488 which fix some regressions for the SIMD case. I've put a corresponding comment into JDK-8255351 and linked the two issues there (sorry, should have done this earlier). Best regards, Volker On Thu, Dec 3, 2020 at 8:54 PM Hohensee, Paul wrote: > > Thanks for the very quick review, Vladimir. Protocol is to tag issues that need review after review approval. Now that I have yours I've tagged 8255351. > > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf of Vladimir Kozlov > Date: Thursday, December 3, 2020 at 11:35 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: RE: [11u]: 8255351: Add detection for Graviton 2 CPUs > > Changes look good but I don't see backport request in JBS. > > Thanks, > Vladimir K > > On 12/3/20 11:25 AM, Hohensee, Paul wrote: > > Please review this 11u backport. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8255351 > > Patch: https://git.openjdk.java.net/jdk/commit/2215e5a4 > > Webrev: http://cr.openjdk.java.net/~phh/8255351/webrev.11u.01/ > > > > Patch changed by adding copyright date update, and modifying trailing context in hunk #2. > > > > Thanks, > > Paul > > > From thomas.stuefe at gmail.com Thu Dec 3 20:26:59 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 3 Dec 2020 21:26:59 +0100 Subject: [11u] RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned In-Reply-To: References: Message-ID: Thank you Richard. Will do. .:Thomas On Thu, Dec 3, 2020 at 9:07 PM Reingruber, Richard < richard.reingruber at sap.com> wrote: > Hi Thomas, > > patch looks good to me. > > You might want to remove the extraneous whitespace between the ++ operator > and > its operand in the line below. > > 3086 for (int attempt = 0; attempt < max_attempts && aligned_base == > NULL; attempt ++) { > > Thanks, Richard. > > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Thomas St?fe > Sent: Mittwoch, 2. Dezember 2020 09:31 > To: jdk-updates-dev > Cc: Hotspot dev runtime > Subject: [11u] RFR: JDK-8256287: [windows] add loop fuse to > map_or_reserve_memory_aligned > > Hi, > > I'd like to get reviews for the backport of the following fix: > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8256287 > Original patch: https://github.com/openjdk/jdk/commit/0357db35 > Modified patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8256287-windows-add-loop-fuse-to-map_or_reserve_memory_aligned-for-11.diff > > This patch had to be rewritten for 11 since most of the surroundings > changed since 11 due to cleanups. But the patch itself is straightforward. > > Thank you, Thomas > From hohensee at amazon.com Thu Dec 3 21:32:20 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 3 Dec 2020 21:32:20 +0000 Subject: [11u]: 8255351: Add detection for Graviton 2 CPUs Message-ID: <013C245D-13D1-4C16-8A1E-220D396D51D4@amazon.com> In that case: maintainers, what's your sense of whether 8256488 and 8257436 backports would be approved? The two patches apply cleanly net of copyright date and context. Thanks, Paul ?-----Original Message----- From: Volker Simonis Date: Thursday, December 3, 2020 at 12:13 PM To: "Hohensee, Paul" Cc: Vladimir Kozlov , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u]: 8255351: Add detection for Graviton 2 CPUs Hi Paul, Vladimir, I think we should only downport this change together with JDK-8257436 and JDK-8256488 which fix some regressions for the SIMD case. I've put a corresponding comment into JDK-8255351 and linked the two issues there (sorry, should have done this earlier). Best regards, Volker On Thu, Dec 3, 2020 at 8:54 PM Hohensee, Paul wrote: > > Thanks for the very quick review, Vladimir. Protocol is to tag issues that need review after review approval. Now that I have yours I've tagged 8255351. > > Paul > > -----Original Message----- > From: jdk-updates-dev on behalf of Vladimir Kozlov > Date: Thursday, December 3, 2020 at 11:35 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: RE: [11u]: 8255351: Add detection for Graviton 2 CPUs > > Changes look good but I don't see backport request in JBS. > > Thanks, > Vladimir K > > On 12/3/20 11:25 AM, Hohensee, Paul wrote: > > Please review this 11u backport. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8255351 > > Patch: https://git.openjdk.java.net/jdk/commit/2215e5a4 > > Webrev: http://cr.openjdk.java.net/~phh/8255351/webrev.11u.01/ > > > > Patch changed by adding copyright date update, and modifying trailing context in hunk #2. > > > > Thanks, > > Paul > > > From yan at openjdk.java.net Fri Dec 4 07:35:58 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 4 Dec 2020 07:35:58 GMT Subject: [jdk13u-dev] RFR: 8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread In-Reply-To: References: Message-ID: <7jr_nYJoaqKqGaf3aw8GqXQbZco8TZkC49mh8x8rwwI=.87f7bcc5-5dc2-4f70-8663-ac27b92e4c42@github.com> On Wed, 2 Dec 2020 19:40:04 GMT, Ekaterina Vergizova wrote: > I would like to backport 8231209 to 13u. CSR for 13u is filed and approved: JDK-8257412. > The patch applies cleanly but it requires some modifications: > - since javadoc tag for getCurrentThreadAllocatedBytes() should be changed from 14 to 13.0.6 > - JMM_VERSION should not be modified > > The necessity of these changes is described in JDK-8253134 for 11u, it's applicable for 13u as well. > Tested with ThreadMXBean tests and tier1. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/43 From evergizova at openjdk.java.net Fri Dec 4 07:48:58 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 4 Dec 2020 07:48:58 GMT Subject: [jdk13u-dev] Integrated: 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 19:26:31 GMT, Ekaterina Vergizova wrote: > I would like to backport 8250627 to 13u for parity with 11u. > The patch doesn't apply cleanly since 13u doesn't have cgroups v2 support (JDK-8231111), reapplied manually. > Tested with container tests, including new one and tier1. This pull request has now been integrated. Changeset: 18bd8e24 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/18bd8e24 Stats: 173 lines in 7 files changed: 172 ins; 0 del; 1 mod 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics Reviewed-by: yan Backport-of: e6517d1ae2628f16442e09fd8f48190762517d2e ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/38 From evergizova at openjdk.java.net Fri Dec 4 07:52:02 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 4 Dec 2020 07:52:02 GMT Subject: [jdk13u-dev] Integrated: 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 07:43:27 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8242480 to 13u for parity with 11u. > The patch applies cleanly. > Tested with container tests, the only failure is containers/docker/TestMemoryAwareness.java which is fixed by follow-up JDK-8246648, the plan is to push them together. This pull request has now been integrated. Changeset: 021a35e3 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/021a35e3 Stats: 124 lines in 3 files changed: 122 ins; 0 del; 2 mod 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker Backport-of: f6f97ea24b60a20cd3a613928840fdb5d7bd63e0 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/44 From evergizova at openjdk.java.net Fri Dec 4 08:00:00 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 4 Dec 2020 08:00:00 GMT Subject: [jdk13u-dev] Integrated: 8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 19:40:04 GMT, Ekaterina Vergizova wrote: > I would like to backport 8231209 to 13u. CSR for 13u is filed and approved: JDK-8257412. > The patch applies cleanly but it requires some modifications: > - since javadoc tag for getCurrentThreadAllocatedBytes() should be changed from 14 to 13.0.6 > - JMM_VERSION should not be modified > > The necessity of these changes is described in JDK-8253134 for 11u, it's applicable for 13u as well. > Tested with ThreadMXBean tests and tier1. This pull request has now been integrated. Changeset: 93f5fc00 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/93f5fc00 Stats: 354 lines in 11 files changed: 233 ins; 32 del; 89 mod 8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread Add com.sun.management.getCurrentThreadAllocatedBytes, implement getThreadAllocatedBytes(long) independent of getThreadAllocatedBytes(long[]) Reviewed-by: yan Backport-of: 1bce27d4027e56f9bd1aba5d8f587b0cda9b966a ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/43 From evergizova at openjdk.java.net Fri Dec 4 08:15:00 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 4 Dec 2020 08:15:00 GMT Subject: [jdk13u-dev] RFR: 8246648: issue with OperatingSystemImpl getFreeSwapSpaceSize in docker after 8242480 Message-ID: I'd like to backport 8246648 to 13u as follow-up fix for 8242480 that is already included to 13u. The patch applies cleanly. Tested with container tests, the affected test passed. ------------- Commit messages: - Backport 7d6c1cf4a88b7e284ace10cb79e7f136dd6dc576 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/46/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=46&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246648 Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/46.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/46/head:pull/46 PR: https://git.openjdk.java.net/jdk13u-dev/pull/46 From evergizova at openjdk.java.net Fri Dec 4 08:29:09 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 4 Dec 2020 08:29:09 GMT Subject: [jdk13u-dev] RFR: 8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes Message-ID: I'd like to backport 8231968 to 13u as follow-up fix for JDK-8231209 that is already included to 13u. CSR for 13u is approved: JDK-8257410. The patch applies cleanly. Tested with ThreadMXBean tests and tier1. ------------- Commit messages: - Backport 68e5c40f6f0f42a893595d2a3ecbebcd81742543 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/47/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=47&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231968 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/47.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/47/head:pull/47 PR: https://git.openjdk.java.net/jdk13u-dev/pull/47 From evergizova at openjdk.java.net Fri Dec 4 08:39:02 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 4 Dec 2020 08:39:02 GMT Subject: [jdk13u-dev] Integrated: 8246648: issue with OperatingSystemImpl getFreeSwapSpaceSize in docker after 8242480 In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 08:08:47 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8246648 to 13u as follow-up fix for 8242480 that is already included to 13u. > The patch applies cleanly. > Tested with container tests, the affected test passed. This pull request has now been integrated. Changeset: 4881f8ed Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/4881f8ed Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod 8246648: issue with OperatingSystemImpl getFreeSwapSpaceSize in docker after 8242480 Backport-of: 7d6c1cf4a88b7e284ace10cb79e7f136dd6dc576 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/46 From evergizova at openjdk.java.net Fri Dec 4 09:14:53 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 4 Dec 2020 09:14:53 GMT Subject: [jdk13u-dev] Integrated: 8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 08:23:37 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8231968 to 13u as follow-up fix for JDK-8231209 that is already included to 13u. > CSR for 13u is approved: JDK-8257410. > The patch applies cleanly. > Tested with ThreadMXBean tests and tier1. This pull request has now been integrated. Changeset: e22699c8 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/e22699c8 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod 8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes Pass Thread.currentThread().getId() to getThreadAllocatedBytes, remove its implSpec Backport-of: 68e5c40f6f0f42a893595d2a3ecbebcd81742543 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/47 From evergizova at openjdk.java.net Fri Dec 4 11:08:19 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 4 Dec 2020 11:08:19 GMT Subject: [jdk13u-dev] RFR: 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 =?UTF-8?B?4oCm?= Message-ID: I'd like to backport 8250984 to 13u for parity with 11u. The patch doesn't apply cleanly since 13u doesn't have cgroups v2 support (JDK-8231111), reapplied manually. The following changes are made: - some changes are reapplied to different files where the functionality originally located before cgroups v2 support (CgroupV1MemorySubSystemController.java -> MemorySubsystem in cgroupv1/SubSystem.java, CgroupV1Subsystem.java -> cgroupv1/Metrics.java, MetricsTesterCgroupV1.java -> MetricsTester.java) - changes in tests TestMemoryAwareness.java and MetricsMemoryTester.java are adjusted due to different context (JDK-8231111 and different implementation of JDK-8226575 for 13u) - changes in ProblemLists and PlainRead.java are skipped, they are not applicable to 13u Tested with tier1 and container tests. ------------- Commit messages: - Backport 0187567704d79ecf394d4cb656d0ba4c886351f1 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/48/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=48&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250984 Stats: 94 lines in 5 files changed: 51 ins; 2 del; 41 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/48.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/48/head:pull/48 PR: https://git.openjdk.java.net/jdk13u-dev/pull/48 From yan at openjdk.java.net Fri Dec 4 11:28:11 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 4 Dec 2020 11:28:11 GMT Subject: [jdk13u-dev] RFR: 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 11:03:13 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8250984 to 13u for parity with 11u. > The patch doesn't apply cleanly since 13u doesn't have cgroups v2 support (JDK-8231111), reapplied manually. > The following changes are made: > - some changes are reapplied to different files where the functionality originally located before cgroups v2 support > (CgroupV1MemorySubSystemController.java -> MemorySubsystem in cgroupv1/SubSystem.java, CgroupV1Subsystem.java -> cgroupv1/Metrics.java, MetricsTesterCgroupV1.java -> MetricsTester.java) > - changes in tests TestMemoryAwareness.java and MetricsMemoryTester.java are adjusted due to different context > (JDK-8231111 and different implementation of JDK-8226575 for 13u) > - changes in ProblemLists and PlainRead.java are skipped, they are not applicable to 13u > > Tested with tier1 and container tests. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/48 From evergizova at openjdk.java.net Fri Dec 4 11:41:11 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 4 Dec 2020 11:41:11 GMT Subject: [jdk13u-dev] Integrated: 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 11:03:13 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8250984 to 13u for parity with 11u. > The patch doesn't apply cleanly since 13u doesn't have cgroups v2 support (JDK-8231111), reapplied manually. > The following changes are made: > - some changes are reapplied to different files where the functionality originally located before cgroups v2 support > (CgroupV1MemorySubSystemController.java -> MemorySubsystem in cgroupv1/SubSystem.java, CgroupV1Subsystem.java -> cgroupv1/Metrics.java, MetricsTesterCgroupV1.java -> MetricsTester.java) > - changes in tests TestMemoryAwareness.java and MetricsMemoryTester.java are adjusted due to different context > (JDK-8231111 and different implementation of JDK-8226575 for 13u) > - changes in ProblemLists and PlainRead.java are skipped, they are not applicable to 13u > > Tested with tier1 and container tests. This pull request has now been integrated. Changeset: a48eb784 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/a48eb784 Stats: 94 lines in 5 files changed: 51 ins; 2 del; 41 mod 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities Reviewed-by: yan Backport-of: 0187567704d79ecf394d4cb656d0ba4c886351f1 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/48 From sgehwolf at redhat.com Fri Dec 4 13:01:43 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 04 Dec 2020 14:01:43 +0100 Subject: [11u]: 8255351: Add detection for Graviton 2 CPUs In-Reply-To: <013C245D-13D1-4C16-8A1E-220D396D51D4@amazon.com> References: <013C245D-13D1-4C16-8A1E-220D396D51D4@amazon.com> Message-ID: <75e43b1e31ea07bcff5959b01b460a49e086381a.camel@redhat.com> On Thu, 2020-12-03 at 21:32 +0000, Hohensee, Paul wrote: > In that case: maintainers, what's your sense of whether 8256488 and > 8257436 backports would be approved? The two patches apply cleanly > net of copyright date and context. Andrew Haley, thoughts? My thinking is that these are performance improvements, so not necessarily candidates for 11u backport. On the other hand, if they are low-risk I wouldn't object. They're aarch64- only. What do you think? Thanks, Severin > ?-----Original Message----- > From: Volker Simonis > Date: Thursday, December 3, 2020 at 12:13 PM > To: "Hohensee, Paul" > Cc: Vladimir Kozlov , "jdk-updates-dev at openjdk.java.net" > Subject: RE: [11u]: 8255351: Add detection for Graviton 2 CPUs > > Hi Paul, Vladimir, > > I think we should only downport this change together with JDK-8257436 > and JDK-8256488 which fix some regressions for the SIMD case. > > I've put a corresponding comment into JDK-8255351 and linked the two > issues there (sorry, should have done this earlier). > > Best regards, > Volker > > On Thu, Dec 3, 2020 at 8:54 PM Hohensee, Paul wrote: > > Thanks for the very quick review, Vladimir. Protocol is to tag issues that need review after review approval. Now that I have yours I've tagged 8255351. > > > > Paul > > > > -----Original Message----- > > From: jdk-updates-dev on behalf of Vladimir Kozlov > > Date: Thursday, December 3, 2020 at 11:35 AM > > To: "jdk-updates-dev at openjdk.java.net" > > Subject: RE: [11u]: 8255351: Add detection for Graviton 2 CPUs > > > > Changes look good but I don't see backport request in JBS. > > > > Thanks, > > Vladimir K > > > > On 12/3/20 11:25 AM, Hohensee, Paul wrote: > > > Please review this 11u backport. > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8255351 > > > Patch: https://git.openjdk.java.net/jdk/commit/2215e5a4 > > > Webrev: http://cr.openjdk.java.net/~phh/8255351/webrev.11u.01/ > > > > > > Patch changed by adding copyright date update, and modifying trailing context in hunk #2. > > > > > > Thanks, > > > Paul > > > From aph at redhat.com Fri Dec 4 14:28:20 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 4 Dec 2020 14:28:20 +0000 Subject: [11u]: 8255351: Add detection for Graviton 2 CPUs In-Reply-To: <75e43b1e31ea07bcff5959b01b460a49e086381a.camel@redhat.com> References: <013C245D-13D1-4C16-8A1E-220D396D51D4@amazon.com> <75e43b1e31ea07bcff5959b01b460a49e086381a.camel@redhat.com> Message-ID: On 04/12/2020 13:01, Severin Gehwolf wrote: > On Thu, 2020-12-03 at 21:32 +0000, Hohensee, Paul wrote: >> In that case: maintainers, what's your sense of whether 8256488 and >> 8257436 backports would be approved? The two patches apply cleanly >> net of copyright date and context. > > Andrew Haley, thoughts? My thinking is that these are performance > improvements, so not necessarily candidates for 11u backport. On the > other hand, if they are low-risk I wouldn't object. They're aarch64- > only. What do you think? My first thought is I wish people would stop fiddling with memory copy. People have been committing improvements for one microarchitecture that are regressions on another. But under the circumstances, given that the SIMD copy is a regression, I'd accept it. But I'd like to see a moratorium on any further backports of such things. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Fri Dec 4 22:58:47 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 4 Dec 2020 22:58:47 +0000 Subject: [11u] RFR: 8256488: [aarch64] Use ldpq/stpq instead of ld4/st4 for small copies in StubGenerator::copy_memory Message-ID: Please review this backport to 11u. The backport is clean except for a copyright update. It?s the first of two follow-ons from the backport of JDK-8255351: Add detection for Graviton 2 CPUs. JBS: https://bugs.openjdk.java.net/browse/JDK-8256488 Patch: https://github.com/openjdk/jdk/commit/6e006223 Webrev: http://cr.openjdk.java.net/~phh/8256488/webrev.11u.00/ Thanks, Paul From hohensee at amazon.com Fri Dec 4 23:45:00 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 4 Dec 2020 23:45:00 +0000 Subject: [11u] RFR: 8257436: [aarch64] Regressions in ArrayCopyUnalignedDst.testByte/testChar for 65-78 bytes when UseSIMDForMemoryOps is on Message-ID: <2099E62A-809A-47AE-BD83-22E19683DD9F@amazon.com> Please review this backport to 11u. This is the second follow-on backport after 8255351: Add detection for Graviton 2 CPUs. After the first follow-on backport (8257436, review request posted), patch applies cleanly except for a context difference at the end of hunk #1. JBS: https://bugs.openjdk.java.net/browse/JDK-8257436 Patch: https://github.com/openjdk/jdk/commit/e8363962 Webrev: http://cr.openjdk.java.net/~phh/8257436/webrev.11u.00/ Thanks, Paul From hohensee at amazon.com Fri Dec 4 23:45:29 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 4 Dec 2020 23:45:29 +0000 Subject: [11u] RFR: 8256488: [aarch64] Use ldpq/stpq instead of ld4/st4 for small copies in StubGenerator::copy_memory In-Reply-To: <0504AB1D-7DC8-4233-9F2C-6885E2B46F7F@amazon.com> References: <0504AB1D-7DC8-4233-9F2C-6885E2B46F7F@amazon.com> Message-ID: <35706C29-7D4A-418E-A61D-27ACF45D99E8@amazon.com> Thank you, Evgeny. Paul ?-----Original Message----- From: "Astigeevich, Evgeny" Date: Friday, December 4, 2020 at 3:09 PM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: Re: [11u] RFR: 8256488: [aarch64] Use ldpq/stpq instead of ld4/st4 for small copies in StubGenerator::copy_memory Hi Paul, The backport looks correct to me. Thanks, Evgeny On 04/12/2020, 23:01, "jdk-updates-dev on behalf of Hohensee, Paul" wrote: Please review this backport to 11u. The backport is clean except for a copyright update. It?s the first of two follow-ons from the backport of JDK-8255351: Add detection for Graviton 2 CPUs. JBS: https://bugs.openjdk.java.net/browse/JDK-8256488 Patch: https://github.com/openjdk/jdk/commit/6e006223 Webrev: http://cr.openjdk.java.net/~phh/8256488/webrev.11u.00/ Thanks, Paul From hohensee at amazon.com Fri Dec 4 23:47:52 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 4 Dec 2020 23:47:52 +0000 Subject: [11u]: 8255351: Add detection for Graviton 2 CPUs Message-ID: Thanks, Andrew. I've posted review requests for 8256488 and 8257436 backports. Paul ?-----Original Message----- From: Andrew Haley Date: Friday, December 4, 2020 at 6:29 AM To: Severin Gehwolf , "Hohensee, Paul" , Volker Simonis Cc: Vladimir Kozlov , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u]: 8255351: Add detection for Graviton 2 CPUs On 04/12/2020 13:01, Severin Gehwolf wrote: > On Thu, 2020-12-03 at 21:32 +0000, Hohensee, Paul wrote: >> In that case: maintainers, what's your sense of whether 8256488 and >> 8257436 backports would be approved? The two patches apply cleanly >> net of copyright date and context. > > Andrew Haley, thoughts? My thinking is that these are performance > improvements, so not necessarily candidates for 11u backport. On the > other hand, if they are low-risk I wouldn't object. They're aarch64- > only. What do you think? My first thought is I wish people would stop fiddling with memory copy. People have been committing improvements for one microarchitecture that are regressions on another. But under the circumstances, given that the SIMD copy is a regression, I'd accept it. But I'd like to see a moratorium on any further backports of such things. -- 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 omikhaltcova at openjdk.java.net Sun Dec 6 11:55:15 2020 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Sun, 6 Dec 2020 11:55:15 GMT Subject: [jdk13u-dev] RFR: 8240197: Cannot start JVM when $JAVA_HOME includes CJK characters Message-ID: I'd like to backport JDK-8240197 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested with tier1, tier2, tier3. No regression in tests. ------------- Commit messages: - Backport 3490262a6b8e684673966e5aa63578ccfeae5da1 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/49/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=49&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240197 Stats: 149 lines in 1 file changed: 75 ins; 52 del; 22 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/49/head:pull/49 PR: https://git.openjdk.java.net/jdk13u-dev/pull/49 From omikhaltcova at openjdk.java.net Sun Dec 6 12:08:12 2020 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Sun, 6 Dec 2020 12:08:12 GMT Subject: [jdk13u-dev] Integrated: 8240197: Cannot start JVM when $JAVA_HOME includes CJK characters In-Reply-To: References: Message-ID: On Sun, 6 Dec 2020 11:51:00 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8240197 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested with tier1, tier2, tier3. No regression in tests. This pull request has now been integrated. Changeset: 6456cadb Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/6456cadb Stats: 149 lines in 1 file changed: 75 ins; 52 del; 22 mod 8240197: Cannot start JVM when $JAVA_HOME includes CJK characters Backport-of: 3490262a6b8e684673966e5aa63578ccfeae5da1 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/49 From bae at openjdk.java.net Mon Dec 7 09:55:12 2020 From: bae at openjdk.java.net (Andrew Brygin) Date: Mon, 7 Dec 2020 09:55:12 GMT Subject: [jdk13u-dev] RFR: 8234347: "Turkey" meta time zone does not generate composed localized names In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 11:49:05 GMT, Yuri Nesterenko wrote: > This fix should resolve both JDK-8236548 and JDK-8234347. It does require CSR (JDK-8257501) and will be pushed after the approval of it. The patch applies clean with only extra context changes in copyright dates. The change is in both jdk15 and jdk11. Looks fine. ------------- Marked as reviewed by bae (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/40 From yan at openjdk.java.net Mon Dec 7 10:04:22 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 7 Dec 2020 10:04:22 GMT Subject: [jdk13u-dev] Integrated: 8234347: "Turkey" meta time zone does not generate composed localized names In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 11:49:05 GMT, Yuri Nesterenko wrote: > This fix should resolve both JDK-8236548 and JDK-8234347. It does require CSR (JDK-8257501) and will be pushed after the approval of it. The patch applies clean with only extra context changes in copyright dates. The change is in both jdk15 and jdk11. This pull request has now been integrated. Changeset: c4c63b91 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/c4c63b91 Stats: 352 lines in 10 files changed: 99 ins; 176 del; 77 mod 8234347: "Turkey" meta time zone does not generate composed localized names 8236548: Localized time zone name inconsistency between English and other locales Reviewed-by: bae Backport-of: 5c3a01591c5c945926636fdc9f164d60b5b4f29e ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/40 From aph at redhat.com Mon Dec 7 11:48:18 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 7 Dec 2020 11:48:18 +0000 Subject: [11u] RFR: 8257436: [aarch64] Regressions in ArrayCopyUnalignedDst.testByte/testChar for 65-78 bytes when UseSIMDForMemoryOps is on In-Reply-To: <2099E62A-809A-47AE-BD83-22E19683DD9F@amazon.com> References: <2099E62A-809A-47AE-BD83-22E19683DD9F@amazon.com> Message-ID: <974cd9de-577e-31c3-0278-655804591bc0@redhat.com> is lOn 04/12/2020 23:45, Hohensee, Paul wrote: > Please review this backport to 11u. This is the second follow-on backport after 8255351: Add detection for Graviton 2 CPUs. After the first follow-on backport (8257436, review request posted), patch applies cleanly except for a context difference at the end of hunk #1. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8257436 > Patch: https://github.com/openjdk/jdk/commit/e8363962 > Webrev: http://cr.openjdk.java.net/~phh/8257436/webrev.11u.00/ OK. It's rather a kludge, but maybe the best we can do. It looks like future AArch64 silicon is much better equipped with read and write ports, so such things can (hopefully!) go away over time. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Dec 7 12:13:39 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 7 Dec 2020 12:13:39 +0000 Subject: [11u]: 8255351: Add detection for Graviton 2 CPUs In-Reply-To: References: Message-ID: <0da92b75-f469-e87f-4e0e-6e07941095d6@redhat.com> On 03/12/2020 19:53, Hohensee, Paul wrote: > Thanks for the very quick review, Vladimir. Protocol is to tag issues that need review after review approval. Now that I have yours I've tagged 8255351. There is no 11u backport label there. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Mon Dec 7 15:55:21 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 7 Dec 2020 15:55:21 +0000 Subject: [11u]: 8255351: Add detection for Graviton 2 CPUs In-Reply-To: <0da92b75-f469-e87f-4e0e-6e07941095d6@redhat.com> References: <0da92b75-f469-e87f-4e0e-6e07941095d6@redhat.com> Message-ID: Could've sworn there was. There's one now. :) Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Andrew Haley Date: Monday, December 7, 2020 at 4:14 AM To: "jdk-updates-dev at openjdk.java.net" Subject: RE: [EXTERNAL] [11u]: 8255351: Add detection for Graviton 2 CPUs On 03/12/2020 19:53, Hohensee, Paul wrote: > Thanks for the very quick review, Vladimir. Protocol is to tag issues that need review after review approval. Now that I have yours I've tagged 8255351. There is no 11u backport label there. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Mon Dec 7 15:57:08 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 7 Dec 2020 15:57:08 +0000 Subject: [11u] RFR: 8256488: [aarch64] Use ldpq/stpq instead of ld4/st4 for small copies in StubGenerator::copy_memory In-Reply-To: <35706C29-7D4A-418E-A61D-27ACF45D99E8@amazon.com> References: <0504AB1D-7DC8-4233-9F2C-6885E2B46F7F@amazon.com> <35706C29-7D4A-418E-A61D-27ACF45D99E8@amazon.com> Message-ID: May I get a review from a Reviewer please? Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Friday, December 4, 2020 at 3:46 PM To: "Astigeevich, Evgeny" , "jdk-updates-dev at openjdk.java.net" Subject: Re: [11u] RFR: 8256488: [aarch64] Use ldpq/stpq instead of ld4/st4 for small copies in StubGenerator::copy_memory Thank you, Evgeny. Paul -----Original Message----- From: "Astigeevich, Evgeny" Date: Friday, December 4, 2020 at 3:09 PM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: Re: [11u] RFR: 8256488: [aarch64] Use ldpq/stpq instead of ld4/st4 for small copies in StubGenerator::copy_memory Hi Paul, The backport looks correct to me. Thanks, Evgeny On 04/12/2020, 23:01, "jdk-updates-dev on behalf of Hohensee, Paul" wrote: Please review this backport to 11u. The backport is clean except for a copyright update. It?s the first of two follow-ons from the backport of JDK-8255351: Add detection for Graviton 2 CPUs. JBS: https://bugs.openjdk.java.net/browse/JDK-8256488 Patch: https://github.com/openjdk/jdk/commit/6e006223 Webrev: http://cr.openjdk.java.net/~phh/8256488/webrev.11u.00/ Thanks, Paul From hohensee at amazon.com Mon Dec 7 16:00:21 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 7 Dec 2020 16:00:21 +0000 Subject: [11u] RFR: 8257436: [aarch64] Regressions in ArrayCopyUnalignedDst.testByte/testChar for 65-78 bytes when UseSIMDForMemoryOps is on Message-ID: <5E1B3B46-CA0A-4CB1-A539-A46A51FC58BC@amazon.com> Thanks, Andrew. Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Andrew Haley Date: Monday, December 7, 2020 at 3:51 AM To: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: 8257436: [aarch64] Regressions in ArrayCopyUnalignedDst.testByte/testChar for 65-78 bytes when UseSIMDForMemoryOps is on is lOn 04/12/2020 23:45, Hohensee, Paul wrote: > Please review this backport to 11u. This is the second follow-on backport after 8255351: Add detection for Graviton 2 CPUs. After the first follow-on backport (8257436, review request posted), patch applies cleanly except for a context difference at the end of hunk #1. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8257436 > Patch: https://github.com/openjdk/jdk/commit/e8363962 > Webrev: http://cr.openjdk.java.net/~phh/8257436/webrev.11u.00/ OK. It's rather a kludge, but maybe the best we can do. It looks like future AArch64 silicon is much better equipped with read and write ports, so such things can (hopefully!) go away over time. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Dec 7 16:57:25 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 7 Dec 2020 16:57:25 +0000 Subject: [11u] RFR: 8256488: [aarch64] Use ldpq/stpq instead of ld4/st4 for small copies in StubGenerator::copy_memory In-Reply-To: References: <0504AB1D-7DC8-4233-9F2C-6885E2B46F7F@amazon.com> <35706C29-7D4A-418E-A61D-27ACF45D99E8@amazon.com> Message-ID: <18f949cb-c279-07cf-c3b9-5b79c52c3304@redhat.com> On 07/12/2020 15:57, Hohensee, Paul wrote: > May I get a review from a Reviewer please? OK. It's a clean backport, so it's a formality. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Dec 7 16:57:30 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 7 Dec 2020 16:57:30 +0000 Subject: [11u]: 8255351: Add detection for Graviton 2 CPUs In-Reply-To: References: <0da92b75-f469-e87f-4e0e-6e07941095d6@redhat.com> Message-ID: <30631be4-e705-c98f-7f59-72dea2359db4@redhat.com> On 07/12/2020 15:55, Hohensee, Paul wrote: > Could've sworn there was. There's one now. :) Also missing on https://bugs.openjdk.java.net/browse/JDK-8256488. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Mon Dec 7 19:13:59 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 7 Dec 2020 19:13:59 +0000 Subject: [11u] RFR: 8256488: [aarch64] Use ldpq/stpq instead of ld4/st4 for small copies in StubGenerator::copy_memory Message-ID: Except for the copyright date. :) Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Andrew Haley Date: Monday, December 7, 2020 at 8:58 AM To: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: 8256488: [aarch64] Use ldpq/stpq instead of ld4/st4 for small copies in StubGenerator::copy_memory On 07/12/2020 15:57, Hohensee, Paul wrote: > May I get a review from a Reviewer please? OK. It's a clean backport, so it's a formality. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Mon Dec 7 19:16:03 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 7 Dec 2020 19:16:03 +0000 Subject: [11u]: 8255351: Add detection for Graviton 2 CPUs Message-ID: <929ADF42-6674-4E6C-BB97-7DCA497707FC@amazon.com> Thanks, Andrew. Tagged. Paul ?-----Original Message----- From: Andrew Haley Date: Monday, December 7, 2020 at 8:58 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u]: 8255351: Add detection for Graviton 2 CPUs On 07/12/2020 15:55, Hohensee, Paul wrote: > Could've sworn there was. There's one now. :) Also missing on https://bugs.openjdk.java.net/browse/JDK-8256488. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Mon Dec 7 19:16:33 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 7 Dec 2020 19:16:33 +0000 Subject: [11u] RFR: 8257436: [aarch64] Regressions in ArrayCopyUnalignedDst.testByte/testChar for 65-78 bytes when UseSIMDForMemoryOps is on In-Reply-To: <0C86B3E6-B760-4937-A84E-D2B902E3342B@amazon.com> References: <2099E62A-809A-47AE-BD83-22E19683DD9F@amazon.com> <0C86B3E6-B760-4937-A84E-D2B902E3342B@amazon.com> Message-ID: Thanks, Evgeny. Paul ?-----Original Message----- From: "Astigeevich, Evgeny" Date: Monday, December 7, 2020 at 8:37 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: Re: [11u] RFR: 8257436: [aarch64] Regressions in ArrayCopyUnalignedDst.testByte/testChar for 65-78 bytes when UseSIMDForMemoryOps is on Hi Paul, The backport looks good to me. Thanks, Evgeny On 04/12/2020, 23:48, "jdk-updates-dev on behalf of Hohensee, Paul" wrote: Please review this backport to 11u. This is the second follow-on backport after 8255351: Add detection for Graviton 2 CPUs. After the first follow-on backport (8257436, review request posted), patch applies cleanly except for a context difference at the end of hunk #1. JBS: https://bugs.openjdk.java.net/browse/JDK-8257436 Patch: https://github.com/openjdk/jdk/commit/e8363962 Webrev: http://cr.openjdk.java.net/~phh/8257436/webrev.11u.00/ Thanks, Paul From aph at redhat.com Tue Dec 8 09:47:07 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Dec 2020 09:47:07 +0000 Subject: [11u] RFR: 8256488: [aarch64] Use ldpq/stpq instead of ld4/st4 for small copies in StubGenerator::copy_memory In-Reply-To: References: Message-ID: On 07/12/2020 19:13, Hohensee, Paul wrote: > Except for the copyright date. :) Uh, no. :-P -- 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 yan at openjdk.java.net Tue Dec 8 19:16:00 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 8 Dec 2020 19:16:00 GMT Subject: [jdk13u-dev] RFR: 8250844: Make sure {type, obj}ArrayOopDesc accessors check the bounds Message-ID: We need these asserts in 13u, too. The patch doesn't require any adjustments, tier1 tests pass. ------------- Commit messages: - Backport ddb726d4a09ec6c87d4c2035c9d4f3642d9a151b Changes: https://git.openjdk.java.net/jdk13u-dev/pull/50/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=50&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250844 Stats: 28 lines in 2 files changed: 26 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/50/head:pull/50 PR: https://git.openjdk.java.net/jdk13u-dev/pull/50 From yan at openjdk.java.net Wed Dec 9 07:00:37 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 9 Dec 2020 07:00:37 GMT Subject: [jdk13u-dev] Integrated: 8250844: Make sure {type, obj}ArrayOopDesc accessors check the bounds In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 15:09:49 GMT, Yuri Nesterenko wrote: > We need these asserts in 13u, too. The patch doesn't require any adjustments, tier1 tests pass. This pull request has now been integrated. Changeset: f0373364 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/f0373364 Stats: 28 lines in 2 files changed: 26 ins; 0 del; 2 mod 8250844: Make sure {type,obj}ArrayOopDesc accessors check the bounds Backport-of: ddb726d4a09ec6c87d4c2035c9d4f3642d9a151b ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/50 From snazarki at openjdk.java.net Wed Dec 9 14:47:48 2020 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 9 Dec 2020 14:47:48 GMT Subject: [jdk13u-dev] RFR: 8250636: iso8601_time returns incorrect offset part on MacOS Message-ID: This backport aligns jdk13 with jdk11/8 siblings. Backport of 8251365 is required after this patch ------------- Commit messages: - Backport 1d480a7b96005f049c1dcb16344ca48f86f01f91 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/51/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=51&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250636 Stats: 35 lines in 1 file changed: 14 ins; 19 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/51.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/51/head:pull/51 PR: https://git.openjdk.java.net/jdk13u-dev/pull/51 From snazarki at openjdk.java.net Wed Dec 9 15:29:57 2020 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 9 Dec 2020 15:29:57 GMT Subject: [jdk13u-dev] RFR: 8250636: iso8601_time returns incorrect offset part on MacOS [v2] In-Reply-To: References: Message-ID: > This backport aligns jdk13 with jdk11/8 siblings. Backport of 8251365 is required after this patch Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision: Update os.cpp Copyright year update ------------- Changes: - all: https://git.openjdk.java.net/jdk13u-dev/pull/51/files - new: https://git.openjdk.java.net/jdk13u-dev/pull/51/files/0bf4ad01..f84217b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=51&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=51&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/51.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/51/head:pull/51 PR: https://git.openjdk.java.net/jdk13u-dev/pull/51 From zgu at redhat.com Wed Dec 9 16:49:42 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 9 Dec 2020 11:49:42 -0500 Subject: [11u] RFR 8229474: Shenandoah: Cleanup CM::update_roots() Message-ID: <1168d9d8-43e4-9f22-6095-b39928fa1da0@redhat.com> I would like to backport this patch to 11u, it is a Shenandoah-only patch. The original patch does not apply cleanly, but conflicts are easy to resolve manually. Also, traversal GC part does not apply, as it has been removed. The original bug: https://bugs.openjdk.java.net/browse/JDK-8229474 The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/23e13076e102 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8229474-11u/webrev.00/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu From snazarki at openjdk.java.net Wed Dec 9 18:25:55 2020 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 9 Dec 2020 18:25:55 GMT Subject: [jdk13u-dev] Withdrawn: 8250636: iso8601_time returns incorrect offset part on MacOS In-Reply-To: References: Message-ID: <1ry1XfnBMRcNIe6WCAwavCi5OWldoVkV0qKOZvqZVXo=.d3cd191c-4c6b-489b-9655-a14c55987959@github.com> On Wed, 9 Dec 2020 14:42:57 GMT, Sergey Nazarkin wrote: > This backport aligns jdk13 with jdk11/8 siblings. Backport of 8251365 is required after this patch This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/51 From snazarki at openjdk.java.net Wed Dec 9 18:25:59 2020 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 9 Dec 2020 18:25:59 GMT Subject: [jdk13u-dev] RFR: 8250636: iso8601_time returns incorrect offset part on MacOS Message-ID: This backport aligns jdk13 with jdk16/11/8. Backport of 8251365 is required after this patch ------------- Commit messages: - Backport 1d480a7b96005f049c1dcb16344ca48f86f01f91 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/52/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=52&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250636 Stats: 35 lines in 1 file changed: 14 ins; 19 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk13u-dev/pull/52 From rkennke at redhat.com Wed Dec 9 19:17:01 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 9 Dec 2020 20:17:01 +0100 Subject: [11u] RFR 8229474: Shenandoah: Cleanup CM::update_roots() In-Reply-To: <1168d9d8-43e4-9f22-6095-b39928fa1da0@redhat.com> References: <1168d9d8-43e4-9f22-6095-b39928fa1da0@redhat.com> Message-ID: Looks good to me, thank you! Roman > I would like to backport this patch to 11u, it is a Shenandoah-only patch. > > The original patch does not apply cleanly, but conflicts are easy to > resolve manually. Also, traversal GC part does not apply, as it has been > removed. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8229474 > The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/23e13076e102 > > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8229474-11u/webrev.00/ > > Test: > ? hotspot_gc_shenandoah > > > Thanks, > > -Zhengyu > From yan at openjdk.java.net Thu Dec 10 12:32:41 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 10 Dec 2020 12:32:41 GMT Subject: [jdk13u-dev] RFR: 8233686: XML transformer uses excessive amount of memory Message-ID: <_nvCwwY637z2R0BkWhNnYjeYHa3smV2FrVmDpqposnc=.bc6efc74-c1dc-46b2-ad63-aae2ff1215dc@github.com> I'd like to port it here, too. Patch applies without any adjustment, tests tier1 and 2 pass ------------- Commit messages: - Backport cef999178cf5ad0b5481da2938169bdd2084d612 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/54/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=54&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233686 Stats: 26 lines in 2 files changed: 23 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/54.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/54/head:pull/54 PR: https://git.openjdk.java.net/jdk13u-dev/pull/54 From yan at openjdk.java.net Thu Dec 10 12:37:44 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 10 Dec 2020 12:37:44 GMT Subject: [jdk13u-dev] Integrated: 8233686: XML transformer uses excessive amount of memory In-Reply-To: <_nvCwwY637z2R0BkWhNnYjeYHa3smV2FrVmDpqposnc=.bc6efc74-c1dc-46b2-ad63-aae2ff1215dc@github.com> References: <_nvCwwY637z2R0BkWhNnYjeYHa3smV2FrVmDpqposnc=.bc6efc74-c1dc-46b2-ad63-aae2ff1215dc@github.com> Message-ID: On Thu, 10 Dec 2020 12:27:39 GMT, Yuri Nesterenko wrote: > I'd like to port it here, too. Patch applies without any adjustment, tests tier1 and 2 pass This pull request has now been integrated. Changeset: 7ccba65b Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/7ccba65b Stats: 26 lines in 2 files changed: 23 ins; 1 del; 2 mod 8233686: XML transformer uses excessive amount of memory Remove unnecessary object creation and also update xalan.md file Backport-of: cef999178cf5ad0b5481da2938169bdd2084d612 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/54 From sgehwolf at redhat.com Thu Dec 10 13:07:00 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 10 Dec 2020 14:07:00 +0100 Subject: [11u] RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem Message-ID: Hi! Could I please get a review of this bugfix which improves error checking in the Java Metrics container detection code? The patch is basically a rewrite, since there is no cgroups v2 in JDK 11, and places where UncheckedIOException need to be handled are different enough for the JDK head patch to not apply properly. The gist is to handle UncheckedIOException, possibly thrown because of interrupts, and exit gracefully rather than failing to initialize and crash. Bug: https://bugs.openjdk.java.net/browse/JDK-8255908 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8255908/01/webrev/ Testing: Container tests on x86_64 Linux (cgroups v1) and tier 1. Thoughts? Thanks, Severin From christoph.langer at sap.com Thu Dec 10 14:09:41 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 Dec 2020 14:09:41 +0000 Subject: [11u] RFR (XS): 8215583: Exclude runtime/handshake/HandshakeWalkSuspendExitTest.java Message-ID: Hi, please help reviewing this exclude list backport. We're intermittently seeing runtime/handshake/HandshakeWalkSuspendExitTest.java failing in our test env. There have been fixes in JDK13 but for 11 I think the test can/should be excluded. Please review as the patch didn't apply. Bug: https://bugs.openjdk.java.net/browse/JDK-8215583 Original Change: http://hg.openjdk.java.net/jdk/jdk12/rev/a0eb3da69586 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215583.11u.0/ Thanks Christoph From yan at openjdk.java.net Thu Dec 10 14:12:41 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 10 Dec 2020 14:12:41 GMT Subject: [jdk13u-dev] RFR: 8254081: java/security/cert/PolicyNode/GetPolicyQualifiers.java fails due to an expired certificate Message-ID: Annoying failure in tier2 test fixed here. Patch applies without adjustments. ------------- Commit messages: - Backport 54b340b44f1f3dca2c3f3e8cd2abd8196e0027d8 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/55/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=55&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254081 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/55.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/55/head:pull/55 PR: https://git.openjdk.java.net/jdk13u-dev/pull/55 From yan at openjdk.java.net Thu Dec 10 14:17:37 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 10 Dec 2020 14:17:37 GMT Subject: [jdk13u-dev] Integrated: 8254081: java/security/cert/PolicyNode/GetPolicyQualifiers.java fails due to an expired certificate In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 14:07:12 GMT, Yuri Nesterenko wrote: > Annoying failure in tier2 test fixed here. Patch applies without adjustments. This pull request has now been integrated. Changeset: 7a2731e2 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/7a2731e2 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8254081: java/security/cert/PolicyNode/GetPolicyQualifiers.java fails due to an expired certificate Perform backdated validation of test certificate. Backport-of: 54b340b44f1f3dca2c3f3e8cd2abd8196e0027d8 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/55 From sgehwolf at redhat.com Thu Dec 10 14:20:58 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 10 Dec 2020 15:20:58 +0100 Subject: [11u] RFR (XS): 8215583: Exclude runtime/handshake/HandshakeWalkSuspendExitTest.java In-Reply-To: References: Message-ID: <15442ffbb666852390fae404798202e3e3e358c4.camel@redhat.com> On Thu, 2020-12-10 at 14:09 +0000, Langer, Christoph wrote: > Hi, > > please help reviewing this exclude list backport. > > We're intermittently seeing > runtime/handshake/HandshakeWalkSuspendExitTest.java failing in our > test env. There have been fixes in JDK13 but for 11 I think the test > can/should be excluded. Please review as the patch didn't apply. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215583 > Original Change: > http://hg.openjdk.java.net/jdk/jdk12/rev/a0eb3da69586 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215583.11u.0/ Looks fine. Thanks, Severin From matthias.baesken at sap.com Thu Dec 10 14:26:08 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 10 Dec 2020 14:26:08 +0000 Subject: [11u] RFR (XS): 8215583: Exclude runtime/handshake/HandshakeWalkSuspendExitTest.java Message-ID: Hi Christoph, thanks for backporting looks good . Best regards, Matthias ------------------------------- Hi, please help reviewing this exclude list backport. We're intermittently seeing runtime/handshake/HandshakeWalkSuspendExitTest.java failing in our test env. There have been fixes in JDK13 but for 11 I think the test can/should be excluded. Please review as the patch didn't apply. Bug: https://bugs.openjdk.java.net/browse/JDK-8215583 Original Change: http://hg.openjdk.java.net/jdk/jdk12/rev/a0eb3da69586 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215583.11u.0/ Thanks Christoph From christoph.langer at sap.com Thu Dec 10 14:41:20 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 Dec 2020 14:41:20 +0000 Subject: [11u] RFR (XS): 8215583: Exclude runtime/handshake/HandshakeWalkSuspendExitTest.java In-Reply-To: <15442ffbb666852390fae404798202e3e3e358c4.camel@redhat.com> References: <15442ffbb666852390fae404798202e3e3e358c4.camel@redhat.com> Message-ID: Thanks, Matthias and Severin! I just pushed it. > -----Original Message----- > From: Severin Gehwolf > Sent: Donnerstag, 10. Dezember 2020 15:21 > To: Langer, Christoph ; jdk-updates-dev updates-dev at openjdk.java.net> > Subject: Re: [11u] RFR (XS): 8215583: Exclude > runtime/handshake/HandshakeWalkSuspendExitTest.java > > On Thu, 2020-12-10 at 14:09 +0000, Langer, Christoph wrote: > > Hi, > > > > please help reviewing this exclude list backport. > > > > We're intermittently seeing > > runtime/handshake/HandshakeWalkSuspendExitTest.java failing in our > > test env. There have been fixes in JDK13 but for 11 I think the test > > can/should be excluded. Please review as the patch didn't apply. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215583 > > Original Change: > > http://hg.openjdk.java.net/jdk/jdk12/rev/a0eb3da69586 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215583.11u.0/ > > Looks fine. > > Thanks, > Severin From christoph.langer at sap.com Thu Dec 10 14:59:54 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 Dec 2020 14:59:54 +0000 Subject: [11u] RFR (XS): 8255050: Add pkcs11/KeyStore/ClientAuth.sh to Problem list Message-ID: Hi, here is an RFR for another test exclusion. Test pkcs11/KeyStore/ClientAuth.sh is now constantly failing on Solaris. It is probably due to some expired certificate(s) which would have to be updated. Oracle excluded the test with JDK-8255050, deferring solution to JDK-8254806. Unfortunately the latter bug is closed. Oracle made this exclusion in both releases, 8 and 11. As there is no original change to pull in, I suggest this patch: diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -640,6 +640,7 @@ # jdk_security sun/security/pkcs11/ec/TestKeyFactory.java 8026976 generic-all +sun/security/pkcs11/KeyStore/ClientAuth.sh 8254806 solaris-all sun/security/pkcs11/Secmod/AddTrustedCert.java 8180837 generic-all sun/security/pkcs11/tls/TestKeyMaterial.java 8180837 generic-all sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java 8161536 generic-all Thanks Christoph From matthias.baesken at sap.com Thu Dec 10 15:12:26 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 10 Dec 2020 15:12:26 +0000 Subject: [11u] RFR (XS): 8255050: Add pkcs11/KeyStore/ClientAuth.sh to Problem list Message-ID: Looks good to me . Best regards, Matthias ------------------------------------------------------------------------------------- Hi, here is an RFR for another test exclusion. Test pkcs11/KeyStore/ClientAuth.sh is now constantly failing on Solaris. It is probably due to some expired certificate(s) which would have to be updated. Oracle excluded the test with JDK-8255050, deferring solution to JDK-8254806. Unfortunately the latter bug is closed. Oracle made this exclusion in both releases, 8 and 11. As there is no original change to pull in, I suggest this patch: diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -640,6 +640,7 @@ # jdk_security sun/security/pkcs11/ec/TestKeyFactory.java 8026976 generic-all +sun/security/pkcs11/KeyStore/ClientAuth.sh 8254806 solaris-all sun/security/pkcs11/Secmod/AddTrustedCert.java 8180837 generic-all sun/security/pkcs11/tls/TestKeyMaterial.java 8180837 generic-all sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java 8161536 generic-all Thanks Christoph From sandhya.viswanathan at intel.com Thu Dec 10 21:00:34 2020 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Thu, 10 Dec 2020 21:00:34 +0000 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions Message-ID: I would like to backport the CRC32 optimization using AVX512 instructions to JDK 11u. This optimization was introduced in JDK 15. JBS: https://bugs.openjdk.java.net/browse/JDK-8245512 Webrev: http://cr.openjdk.java.net/~sviswanathan/8245512/webrev.00/ Only one change was needed to the original patch in src/hotspot/cpu/x86/assembler_x86.cpp. The following in Assembler::blendvpb(), line 7908: emit_int24(0x4C, (0xC0 | encode), (0xF0 & src2_enc << 4)); was replaced by equivalent: emit_int8((unsigned char)0x4C); emit_int8((unsigned char)(0xC0 | encode)); emit_int8((unsigned char)(0xF0 & src2_enc<<4)); The patch applies cleanly otherwise. Please review this backport to 11u. Best Regards, Sandhya From vladimir.kozlov at oracle.com Thu Dec 10 23:07:12 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Dec 2020 15:07:12 -0800 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions In-Reply-To: References: Message-ID: Changes are fine but you need to follow process: http://openjdk.java.net/projects/jdk-updates/approval.html Also it is performance improvement which may not be accepted. Regards, Vladimi On 12/10/20 1:00 PM, Viswanathan, Sandhya wrote: > I would like to backport the CRC32 optimization using AVX512 instructions to JDK 11u. > This optimization was introduced in JDK 15. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245512 > Webrev: http://cr.openjdk.java.net/~sviswanathan/8245512/webrev.00/ > > Only one change was needed to the original patch in src/hotspot/cpu/x86/assembler_x86.cpp. > > The following in Assembler::blendvpb(), line 7908: > > emit_int24(0x4C, (0xC0 | encode), (0xF0 & src2_enc << 4)); > was replaced by equivalent: > emit_int8((unsigned char)0x4C); > emit_int8((unsigned char)(0xC0 | encode)); > emit_int8((unsigned char)(0xF0 & src2_enc<<4)); > > The patch applies cleanly otherwise. > > Please review this backport to 11u. > > Best Regards, > Sandhya > From sandhya.viswanathan at intel.com Thu Dec 10 23:46:51 2020 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Thu, 10 Dec 2020 23:46:51 +0000 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions In-Reply-To: References: Message-ID: Thanks a lot Vladimir for review and link to the process. I requested the backport in JBS. Best Regards, Sandhya -----Original Message----- From: Vladimir Kozlov Sent: Thursday, December 10, 2020 3:07 PM To: Viswanathan, Sandhya ; jdk-updates-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Subject: Re: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions Changes are fine but you need to follow process: http://openjdk.java.net/projects/jdk-updates/approval.html Also it is performance improvement which may not be accepted. Regards, Vladimi On 12/10/20 1:00 PM, Viswanathan, Sandhya wrote: > I would like to backport the CRC32 optimization using AVX512 instructions to JDK 11u. > This optimization was introduced in JDK 15. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245512 > Webrev: http://cr.openjdk.java.net/~sviswanathan/8245512/webrev.00/ > > Only one change was needed to the original patch in src/hotspot/cpu/x86/assembler_x86.cpp. > > The following in Assembler::blendvpb(), line 7908: > > emit_int24(0x4C, (0xC0 | encode), (0xF0 & src2_enc << 4)); was > replaced by equivalent: > emit_int8((unsigned char)0x4C); > emit_int8((unsigned char)(0xC0 | encode)); emit_int8((unsigned > char)(0xF0 & src2_enc<<4)); > > The patch applies cleanly otherwise. > > Please review this backport to 11u. > > Best Regards, > Sandhya > From snazarki at openjdk.java.net Fri Dec 11 08:35:00 2020 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Fri, 11 Dec 2020 08:35:00 GMT Subject: [jdk13u-dev] Integrated: 8250636: iso8601_time returns incorrect offset part on MacOS In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 17:58:15 GMT, Sergey Nazarkin wrote: > This backport aligns jdk13 with jdk16/11/8. Backport of 8251365 is required after this patch This pull request has now been integrated. Changeset: cf0e9356 Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/cf0e9356 Stats: 35 lines in 1 file changed: 14 ins; 19 del; 2 mod 8250636: iso8601_time returns incorrect offset part on MacOS Backport-of: 1d480a7b96005f049c1dcb16344ca48f86f01f91 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/52 From evergizova at openjdk.java.net Fri Dec 11 08:59:02 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 11 Dec 2020 08:59:02 GMT Subject: [jdk13u-dev] RFR: 8243114: Implement montgomery{Multiply, Square}intrinsics on Windows Message-ID: I'd like to backport 8243114 to 13u for parity with 11u. The patch doesn't apply cleanly due to minor context difference in stubGenerator_x86_64.cpp, reapplied manually. Tested with tier1 and jdk_security with additional options -XX:+UseMontgomeryMultiplyIntrinsic -XX:+UseMontgomerySquareIntrinsic. ------------- Commit messages: - Backport 47e465cf1bc5e78fe0b5ee1b574fdfa2385d7f2c Changes: https://git.openjdk.java.net/jdk13u-dev/pull/56/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=56&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243114 Stats: 99 lines in 2 files changed: 42 ins; 25 del; 32 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/56.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/56/head:pull/56 PR: https://git.openjdk.java.net/jdk13u-dev/pull/56 From snazarki at openjdk.java.net Fri Dec 11 09:07:08 2020 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Fri, 11 Dec 2020 09:07:08 GMT Subject: [jdk13u-dev] RFR: 8251365: Build failure on AIX after 8250636 Message-ID: Mandatory backport to fix issue introduced with 8250636. Patch applies cleanly. ------------- Commit messages: - Backport 28f963f6fc0f1c7e84d8abad395c11d38c6b5fbd Changes: https://git.openjdk.java.net/jdk13u-dev/pull/57/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=57&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251365 Stats: 11 lines in 1 file changed: 7 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/57.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/57/head:pull/57 PR: https://git.openjdk.java.net/jdk13u-dev/pull/57 From snazarki at openjdk.java.net Fri Dec 11 09:16:01 2020 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Fri, 11 Dec 2020 09:16:01 GMT Subject: [jdk13u-dev] Integrated: 8251365: Build failure on AIX after 8250636 In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 09:00:35 GMT, Sergey Nazarkin wrote: > Mandatory backport to fix issue introduced with 8250636. > Patch applies cleanly. This pull request has now been integrated. Changeset: 91e8812f Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/91e8812f Stats: 11 lines in 1 file changed: 7 ins; 3 del; 1 mod 8251365: Build failure on AIX after 8250636 Backport-of: 28f963f6fc0f1c7e84d8abad395c11d38c6b5fbd ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/57 From yan at openjdk.java.net Fri Dec 11 11:12:56 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 11 Dec 2020 11:12:56 GMT Subject: [jdk13u-dev] RFR: 8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: References: Message-ID: <1MNqwc-qOCUDM2FlM2KCnF-vpuUH3nqL838CssJ_F6Q=.652acf3c-74ca-4a15-ad94-a10f35485b5e@github.com> On Fri, 11 Dec 2020 08:54:02 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8243114 to 13u for parity with 11u. > The patch doesn't apply cleanly due to minor context difference in stubGenerator_x86_64.cpp, reapplied manually. > Tested with tier1 and jdk_security with additional options -XX:+UseMontgomeryMultiplyIntrinsic -XX:+UseMontgomerySquareIntrinsic. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/56 From evergizova at openjdk.java.net Fri Dec 11 11:22:00 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 11 Dec 2020 11:22:00 GMT Subject: [jdk13u-dev] Integrated: 8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: References: Message-ID: <4UR0f8UkWG9dkvYS5YdFPQOqrbLJgEUIhtB-_0QWFn4=.681f6544-692e-4119-847e-35815d644224@github.com> On Fri, 11 Dec 2020 08:54:02 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8243114 to 13u for parity with 11u. > The patch doesn't apply cleanly due to minor context difference in stubGenerator_x86_64.cpp, reapplied manually. > Tested with tier1 and jdk_security with additional options -XX:+UseMontgomeryMultiplyIntrinsic -XX:+UseMontgomerySquareIntrinsic. This pull request has now been integrated. Changeset: 496b66fe Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/496b66fe Stats: 99 lines in 2 files changed: 42 ins; 25 del; 32 mod 8243114: Implement montgomery{Multiply,Square}intrinsics on Windows Reviewed-by: yan Backport-of: 47e465cf1bc5e78fe0b5ee1b574fdfa2385d7f2c ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/56 From evergizova at openjdk.java.net Fri Dec 11 11:37:05 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 11 Dec 2020 11:37:05 GMT Subject: [jdk13u-dev] RFR: 8248347: windows build broken by JDK-8243114 Message-ID: I would like to backport 8248347 to 13u as follow-up fix for 8243114 that is already included to 13. The patch applies cleanly. Debug configurations are built successfully after applying the patch. ------------- Commit messages: - Backport b87302ca99ff30a03e311ab1c0f524684ed37596 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/58/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=58&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248347 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/58.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/58/head:pull/58 PR: https://git.openjdk.java.net/jdk13u-dev/pull/58 From evergizova at openjdk.java.net Fri Dec 11 12:09:59 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 11 Dec 2020 12:09:59 GMT Subject: [jdk13u-dev] Integrated: 8248347: windows build broken by JDK-8243114 In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 11:31:38 GMT, Ekaterina Vergizova wrote: > I would like to backport 8248347 to 13u as follow-up fix for 8243114 that is already included to 13. > The patch applies cleanly. > Debug configurations are built successfully after applying the patch. This pull request has now been integrated. Changeset: b7937d83 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/b7937d83 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8248347: windows build broken by JDK-8243114 Backport-of: b87302ca99ff30a03e311ab1c0f524684ed37596 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/58 From richard.reingruber at sap.com Fri Dec 11 15:16:45 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 11 Dec 2020 15:16:45 +0000 Subject: [11u] RFR 8244340: Handshake processing thread lacks yielding Message-ID: Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8244340 https://hg.openjdk.java.net/jdk/jdk/rev/67a435ce2dc2 Prerequisite downport: https://bugs.openjdk.java.net/browse/JDK-8214180 Original patch does not apply cleanly to 11u because it is based on handshakes in jdk15 which is quite different from handshakes in 11u, e.g. jdk15 has direct handshakes. 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8244340_11u_Handshake_processing_thread_lacks_yielding/webrev.0/ Testing: Tier1 with and without ZGC. With ZGC I got a few failures. Most of them if not all were OOME because 11u ZGC cannot handle small heaps. The same tests fail without the patch. CI testing @sap. Thanks, Richard. From rwestrel at redhat.com Fri Dec 11 15:55:10 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 11 Dec 2020 16:55:10 +0100 Subject: [11u] RFR 8257547: Handle multiple prereqs on the same line in deps files Message-ID: <871rfwibhd.fsf@redhat.com> Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8257547 https://github.com/openjdk/jdk/commit/36209b70 Original patch does not apply cleanly to 11u because in 16: - solaris support was dropped - this patch was on top of JDK-8256810 which it reworks entirely (so backporting it first doesn't seem to be worth it) 11u webrev: http://cr.openjdk.java.net/~roland/8257547.11u/ I cherry-picked the comment from JDK-8256810. Testing: x86_64 build, included test Thanks, -Monty From gnu.andrew at redhat.com Fri Dec 11 17:03:13 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 11 Dec 2020 17:03:13 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] Message-ID: <20201211170313.GH1323090@rincewind> 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 hedongbo at huawei.com Mon Dec 14 01:37:16 2020 From: hedongbo at huawei.com (hedongbo) Date: Mon, 14 Dec 2020 01:37:16 +0000 Subject: [11u] RFR:8214230: Classes generated by SystemModulesPlugin.java are not reproducable Message-ID: <8FC616E5EC1A774287430B1CC2696FE30460EDF3@dggeml513-mbs.china.huawei.com> Hi, Please review the backport of JDK-8214230 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8214230 Original commit: http://hg.openjdk.java.net/jdk/jdk/rev/abccada595dd 11u webrev: http://cr.openjdk.java.net/~dongbohe/8214230/webrev.00/ Patch applies cleanly to11u, but I added a static method `mismatch(Path, Path)` to the test file because it only exists in jdk12[1]. Moreover, I also modified the copyright year. Tested with tier1, tier2. No regression in tests. [1] https://bugs.openjdk.java.net/browse/JDK-8202302 Thanks, dongbohe From hohensee at amazon.com Mon Dec 14 17:29:32 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 14 Dec 2020 17:29:32 +0000 Subject: [11u] RFR:8214230: Classes generated by SystemModulesPlugin.java are not reproducable Message-ID: <45B07E1D-FFD3-4E17-ADA5-302E3901F61A@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of hedongbo Date: Sunday, December 13, 2020 at 5:38 PM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR:8214230: Classes generated by SystemModulesPlugin.java are not reproducable Hi, Please review the backport of JDK-8214230 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8214230 Original commit: http://hg.openjdk.java.net/jdk/jdk/rev/abccada595dd 11u webrev: http://cr.openjdk.java.net/~dongbohe/8214230/webrev.00/ Patch applies cleanly to11u, but I added a static method `mismatch(Path, Path)` to the test file because it only exists in jdk12[1]. Moreover, I also modified the copyright year. Tested with tier1, tier2. No regression in tests. [1] https://bugs.openjdk.java.net/browse/JDK-8202302 Thanks, dongbohe From goetz.lindenmaier at sap.com Tue Dec 15 07:24:09 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 15 Dec 2020 07:24:09 +0000 Subject: [11u] RFR 8244340: Handshake processing thread lacks yielding In-Reply-To: References: Message-ID: Hi Richard, Thanks for downporting this bug. It is good you target it for 11.0.11. I cannot see why Oracle pushed it to 11.0.10 that late. Maye they just downported the tiny fix !is_mp()... discussed in the mail thread. The downport looks good. I can sponsor this for you. Please ping me once it is labeled jdk11u-fix-yes. Best regards, Goetz > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Reingruber, Richard > Sent: Friday, December 11, 2020 4:17 PM > To: jdk-updates-dev > Subject: [11u] RFR 8244340: Handshake processing thread lacks yielding > > Hi, > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8244340 > https://hg.openjdk.java.net/jdk/jdk/rev/67a435ce2dc2 > > Prerequisite downport: > https://bugs.openjdk.java.net/browse/JDK-8214180 > > Original patch does not apply cleanly to 11u because it is based on > handshakes > in jdk15 which is quite different from handshakes in 11u, e.g. jdk15 has direct > handshakes. > > 11u webrev: > > http://cr.openjdk.java.net/~rrich/webrevs/8244340_11u_Handshake_proces > sing_thread_lacks_yielding/webrev.0/ > > Testing: > > Tier1 with and without ZGC. > > With ZGC I got a few failures. Most of them if not all were OOME because > 11u ZGC > cannot handle small heaps. The same tests fail without the patch. > > CI testing @sap. > > Thanks, Richard. 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 jaroslav.bachorik at datadoghq.com Tue Dec 15 08:21:33 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 15 Dec 2020 09:21:33 +0100 Subject: [11u] RFR: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default) Message-ID: Greetings, I would like to ask for review of this JDK11u backport patch: Issue : https://bugs.openjdk.java.net/browse/JDK-8257602 Webrev: http://cr.openjdk.java.net/~jbachorik/8257602/jdk11/00/webrev/ The webrev contains the main change backported from JDK-8257602 and the followup patch for AIX build failure resolved as JDK-8258094. I decided to roll both changesets into one webrev to get a fully buildable system once this backport request is approved. The original changeset of JDK-8257602 had to be slightly adjusted for the following: * hunk offsets not matching because of larger structural changes resolution: the appropriate code was inserted manually * missing Atomic::load_acquire and Atomic::release_store functions resolution: used OrderAccess::* equivalents * different argument order for Atomic::cmpxchg and Atomic::store resolution: modified the call-site argument order to match what is provided by Atomic::* * [test] missing support for event streaming resolution: used the recording in non-streaming mode while keeping the test semantics All tier1, tier2 and jdk_jfr tests are passing with the changes applied. Cheers, -JB- 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 richard.reingruber at sap.com Tue Dec 15 10:13:41 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 15 Dec 2020 10:13:41 +0000 Subject: [11u] RFR 8244340: Handshake processing thread lacks yielding In-Reply-To: References: Message-ID: Hi Goetz, > Thanks for downporting this bug. > It is good you target it for 11.0.11. I cannot see why Oracle > pushed it to 11.0.10 that late. > Maye they just downported the tiny fix !is_mp()... discussed > in the mail thread. Maybe they have done that. I (partially) reread the mail thread and learned that the fix solves also issues on MP systems. But I think these issues relate to direct handshakes and biased lock revocation (both introduced after jdk11). Interesting also that the original repro case was for jdk14. > The downport looks good. Thanks. > I can sponsor this for you. Please ping me once it is > labeled jdk11u-fix-yes. Thanks, the label is there now. Cheers, Richard. -----Original Message----- From: Lindenmaier, Goetz Sent: Dienstag, 15. Dezember 2020 08:24 To: Reingruber, Richard ; jdk-updates-dev Subject: RE: [11u] RFR 8244340: Handshake processing thread lacks yielding Hi Richard, Thanks for downporting this bug. It is good you target it for 11.0.11. I cannot see why Oracle pushed it to 11.0.10 that late. Maye they just downported the tiny fix !is_mp()... discussed in the mail thread. The downport looks good. I can sponsor this for you. Please ping me once it is labeled jdk11u-fix-yes. Best regards, Goetz > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Reingruber, Richard > Sent: Friday, December 11, 2020 4:17 PM > To: jdk-updates-dev > Subject: [11u] RFR 8244340: Handshake processing thread lacks yielding > > Hi, > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8244340 > https://hg.openjdk.java.net/jdk/jdk/rev/67a435ce2dc2 > > Prerequisite downport: > https://bugs.openjdk.java.net/browse/JDK-8214180 > > Original patch does not apply cleanly to 11u because it is based on > handshakes > in jdk15 which is quite different from handshakes in 11u, e.g. jdk15 has direct > handshakes. > > 11u webrev: > > http://cr.openjdk.java.net/~rrich/webrevs/8244340_11u_Handshake_proces > sing_thread_lacks_yielding/webrev.0/ > > Testing: > > Tier1 with and without ZGC. > > With ZGC I got a few failures. Most of them if not all were OOME because > 11u ZGC > cannot handle small heaps. The same tests fail without the patch. > > CI testing @sap. > > Thanks, Richard. 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 akashche at redhat.com Tue Dec 15 11:02:04 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 15 Dec 2020 11:02:04 +0000 Subject: [11u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources Message-ID: Hi, Please review the backport of JDK-8256818 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8256818 Original change: https://github.com/openjdk/jdk/commit/93b6ab56 11u webrev: https://cr.openjdk.java.net/~akasko/jdk11u/8256818/webrev.00/ Patch depends on JDK-8240704 [1], that applies cleanly and is on approval. Patch doesn't apply cleanly: FileUtils.java in 11u doesn't contain recent changes from mainline and needed adjustments; libFileUtils.c cannot be placed into test/lib/ because 11u doesn't have JDK-8248667 [2], it is placed under test/jdk/native_util/ instead. Testing: checked that changed tests pass on Linux and Windows, ran jtreg:jdk/sun/security/ssl/ and jck:api/javax_net/ssl . I also intend to backport subsequent updates to SSLSocketLeak.java from mainline. [1] https://bugs.openjdk.java.net/browse/JDK-8240704 [2] https://bugs.openjdk.java.net/browse/JDK-8248667 -- -Alex 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 martin.doerr at sap.com Tue Dec 15 20:49:45 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 15 Dec 2020 20:49:45 +0000 Subject: [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure Message-ID: Hi, JDK-8234796 is backported to 11.0.11-oracle. I'd like to backport it for parity. It's only a refactoring. Unfortunately, it doesn't apply cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8234796 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/99b71c5b02ff 11u backport: http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/webrev.00/ Resolution steps: - Manually integrated includes, forward declarations and Copyright updates due to different context. - Handshake operations (handshake.cpp): Removed _executed field from patch which was added by JDK-8191890 which is not in 11u. - Skipped "RevokeOneBias" (biasedLocking.cpp) which is also part of JDK-8191890 which is not in 11u. - Skipped "DeoptimizeMarkedTC" (deoptimization.cpp) which is part of JDK-8226705 which is not in 11u. - Skipped "HandshakeALotTC" (vmThread.cpp) which is part of JDK-8220774 which is not in 11u. - Skipped "NMethodMarkingThreadClosure" (sweeper.cpp) which is part of JDK-8132849 which is not in 11u (it was in 11.0.8-oracle, but backed out later due to problems). - Skipped "ShenandoahUnloadRendezvousClosure" and "ZRendezvousClosure" which don't exist in 11u at all. (Also uploaded here with complete listing of non-automatically applied hunks: http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/8234796_handshake_integration.txt) Please review. Best regards, Martin From richard.reingruber at sap.com Wed Dec 16 10:54:07 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 16 Dec 2020 10:54:07 +0000 Subject: [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure In-Reply-To: References: Message-ID: Hi Martin, I've compared the proposed change for 11u with the original change. It looks good to me. Thanks, Richard. -----Original Message----- From: hotspot-runtime-dev On Behalf Of Doerr, Martin Sent: Dienstag, 15. Dezember 2020 21:50 To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: [CAUTION] [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure Hi, JDK-8234796 is backported to 11.0.11-oracle. I'd like to backport it for parity. It's only a refactoring. Unfortunately, it doesn't apply cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8234796 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/99b71c5b02ff 11u backport: http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/webrev.00/ Resolution steps: - Manually integrated includes, forward declarations and Copyright updates due to different context. - Handshake operations (handshake.cpp): Removed _executed field from patch which was added by JDK-8191890 which is not in 11u. - Skipped "RevokeOneBias" (biasedLocking.cpp) which is also part of JDK-8191890 which is not in 11u. - Skipped "DeoptimizeMarkedTC" (deoptimization.cpp) which is part of JDK-8226705 which is not in 11u. - Skipped "HandshakeALotTC" (vmThread.cpp) which is part of JDK-8220774 which is not in 11u. - Skipped "NMethodMarkingThreadClosure" (sweeper.cpp) which is part of JDK-8132849 which is not in 11u (it was in 11.0.8-oracle, but backed out later due to problems). - Skipped "ShenandoahUnloadRendezvousClosure" and "ZRendezvousClosure" which don't exist in 11u at all. (Also uploaded here with complete listing of non-automatically applied hunks: http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/8234796_handshake_integration.txt) Please review. Best regards, Martin From martin.doerr at sap.com Wed Dec 16 11:03:02 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 16 Dec 2020 11:03:02 +0000 Subject: [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure In-Reply-To: References: Message-ID: Hi Richard, thanks for reviewing! Best regards, Martin > -----Original Message----- > From: Reingruber, Richard > Sent: Mittwoch, 16. Dezember 2020 11:54 > To: Doerr, Martin ; hotspot-runtime- > dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8234796: Refactor Handshake::execute to take a more > complex type than ThreadClosure > > Hi Martin, > > I've compared the proposed change for 11u with the original change. It looks > good to me. > > Thanks, > Richard. > > -----Original Message----- > From: hotspot-runtime-dev > On Behalf Of Doerr, Martin > Sent: Dienstag, 15. Dezember 2020 21:50 > To: hotspot-runtime-dev at openjdk.java.net; jdk-updates- > dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: [CAUTION] [11u] RFR: 8234796: Refactor Handshake::execute to > take a more complex type than ThreadClosure > > Hi, > > JDK-8234796 is backported to 11.0.11-oracle. I'd like to backport it for parity. > It's only a refactoring. > Unfortunately, it doesn't apply cleanly. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8234796 > > Original change: > https://hg.openjdk.java.net/jdk/jdk/rev/99b71c5b02ff > > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/webrev.00/ > > Resolution steps: > - Manually integrated includes, forward declarations and Copyright updates > due to different context. > - Handshake operations (handshake.cpp): Removed _executed field from > patch which was added by JDK-8191890 which is not in 11u. > - Skipped "RevokeOneBias" (biasedLocking.cpp) which is also part of JDK- > 8191890 which is not in 11u. > - Skipped "DeoptimizeMarkedTC" (deoptimization.cpp) which is part of JDK- > 8226705 which is not in 11u. > - Skipped "HandshakeALotTC" (vmThread.cpp) which is part of JDK-8220774 > which is not in 11u. > - Skipped "NMethodMarkingThreadClosure" (sweeper.cpp) which is part of > JDK-8132849 which is not in 11u (it was in 11.0.8-oracle, but backed out later > due to problems). > - Skipped "ShenandoahUnloadRendezvousClosure" and > "ZRendezvousClosure" which don't exist in 11u at all. > > (Also uploaded here with complete listing of non-automatically applied > hunks: > http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/8234796_han > dshake_integration.txt) > > Please review. > > Best regards, > Martin From martin.doerr at sap.com Wed Dec 16 13:39:17 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 16 Dec 2020 13:39:17 +0000 Subject: [11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module Message-ID: Hi, JDK-8211825 is backported to 11.0.11-oracle. I'd like to backport it for parity. The original change applies cleanly, by javac from 11u has a problem with the new AutomaticModulesTest: AutomaticModulesTest.java:70: error: reference to createJarFile is ambiguous JarUtils.createJarFile(LIB.resolve("alib.jar"), CLASSES); ^ both method createJarFile(Path,Path,Path...) in JarUtils and method createJarFile(Path,Path,String...) in JarUtils match I suggest to resolve it this way: http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/test_fix.patch Bug: https://bugs.openjdk.java.net/browse/JDK-8211825 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/a42c378b6f01 11u webrev: http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/webrev.00/ Please review. Best regards, Martin 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 dcherepanov at openjdk.java.net Thu Dec 17 11:25:08 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 17 Dec 2020 11:25:08 GMT Subject: [jdk13u-dev] RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d Message-ID: Request to backport tzdata2020d. Applies cleanly, no regressions found. ------------- Commit messages: - Backport b65ff60a8e36bd1f4b531abe68962f4691359964 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/59/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=59&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255226 Stats: 61 lines in 4 files changed: 38 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/59/head:pull/59 PR: https://git.openjdk.java.net/jdk13u-dev/pull/59 From dcherepanov at openjdk.java.net Thu Dec 17 12:41:00 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 17 Dec 2020 12:41:00 GMT Subject: [jdk13u-dev] Integrated: 8255226: (tz) Upgrade time-zone data to tzdata2020d In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 11:20:08 GMT, Dmitry Cherepanov wrote: > Request to backport tzdata2020d. Applies cleanly, no regressions found. This pull request has now been integrated. Changeset: 2f9e4584 Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/2f9e4584 Stats: 61 lines in 4 files changed: 38 ins; 2 del; 21 mod 8255226: (tz) Upgrade time-zone data to tzdata2020d Backport-of: b65ff60a8e36bd1f4b531abe68962f4691359964 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/59 From christoph.langer at sap.com Thu Dec 17 13:45:00 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 17 Dec 2020 13:45:00 +0000 Subject: [11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module In-Reply-To: References: Message-ID: Hi Martin, this makes sense. Thanks for doing the backport. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf Of > Doerr, Martin > Sent: Mittwoch, 16. Dezember 2020 14:39 > To: core-libs-dev ; jdk-updates- > dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 8211825: > ModuleLayer.defineModulesWithXXX does not setup delegation when > module reads automatic module > > Hi, > > JDK-8211825 is backported to 11.0.11-oracle. I'd like to backport it for parity. > The original change applies cleanly, by javac from 11u has a problem with the > new AutomaticModulesTest: > AutomaticModulesTest.java:70: error: reference to createJarFile is > ambiguous > JarUtils.createJarFile(LIB.resolve("alib.jar"), CLASSES); > ^ > both method createJarFile(Path,Path,Path...) in JarUtils and method > createJarFile(Path,Path,String...) in JarUtils match > > I suggest to resolve it this way: > http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/test_fix.p > atch > > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211825 > > Original change: > http://hg.openjdk.java.net/jdk/jdk/rev/a42c378b6f01 > > 11u webrev: > http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/webrev.0 > 0/ > > Please review. > > Best regards, > Martin 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 martin.doerr at sap.com Thu Dec 17 15:50:55 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 17 Dec 2020 15:50:55 +0000 Subject: [11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review! Best regards, Martin > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 17. Dezember 2020 14:45 > To: Doerr, Martin ; core-libs-dev dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does > not setup delegation when module reads automatic module > > Hi Martin, > > this makes sense. Thanks for doing the backport. > > Best regards > Christoph > > > -----Original Message----- > > From: core-libs-dev On Behalf Of > > Doerr, Martin > > Sent: Mittwoch, 16. Dezember 2020 14:39 > > To: core-libs-dev ; jdk-updates- > > dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR: 8211825: > > ModuleLayer.defineModulesWithXXX does not setup delegation when > > module reads automatic module > > > > Hi, > > > > JDK-8211825 is backported to 11.0.11-oracle. I'd like to backport it for parity. > > The original change applies cleanly, by javac from 11u has a problem with > the > > new AutomaticModulesTest: > > AutomaticModulesTest.java:70: error: reference to createJarFile is > > ambiguous > > JarUtils.createJarFile(LIB.resolve("alib.jar"), CLASSES); > > ^ > > both method createJarFile(Path,Path,Path...) in JarUtils and method > > createJarFile(Path,Path,String...) in JarUtils match > > > > I suggest to resolve it this way: > > > http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/test_fix.p > > atch > > > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8211825 > > > > Original change: > > http://hg.openjdk.java.net/jdk/jdk/rev/a42c378b6f01 > > > > 11u webrev: > > > http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/webrev.0 > > 0/ > > > > Please review. > > > > Best regards, > > Martin From goetz.lindenmaier at sap.com Thu Dec 17 17:20:53 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 17 Dec 2020 17:20:53 +0000 Subject: [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure In-Reply-To: References: Message-ID: Looks good to me. Thanks for backporting, and thanks for the detailed description of your changes! Best regards, Goetz. -----Original Message----- From: Reingruber, Richard Sent: Mittwoch, 16. Dezember 2020 11:54 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: RE: [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure Hi Martin, I've compared the proposed change for 11u with the original change. It looks good to me. Thanks, Richard. -----Original Message----- From: hotspot-runtime-dev On Behalf Of Doerr, Martin Sent: Dienstag, 15. Dezember 2020 21:50 To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: [CAUTION] [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure Hi, JDK-8234796 is backported to 11.0.11-oracle. I'd like to backport it for parity. It's only a refactoring. Unfortunately, it doesn't apply cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8234796 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/99b71c5b02ff 11u backport: http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/webrev.00/ Resolution steps: - Manually integrated includes, forward declarations and Copyright updates due to different context. - Handshake operations (handshake.cpp): Removed _executed field from patch which was added by JDK-8191890 which is not in 11u. - Skipped "RevokeOneBias" (biasedLocking.cpp) which is also part of JDK-8191890 which is not in 11u. - Skipped "DeoptimizeMarkedTC" (deoptimization.cpp) which is part of JDK-8226705 which is not in 11u. - Skipped "HandshakeALotTC" (vmThread.cpp) which is part of JDK-8220774 which is not in 11u. - Skipped "NMethodMarkingThreadClosure" (sweeper.cpp) which is part of JDK-8132849 which is not in 11u (it was in 11.0.8-oracle, but backed out later due to problems). - Skipped "ShenandoahUnloadRendezvousClosure" and "ZRendezvousClosure" which don't exist in 11u at all. (Also uploaded here with complete listing of non-automatically applied hunks: http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/8234796_handshake_integration.txt) Please review. Best regards, Martin 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 martin.doerr at sap.com Thu Dec 17 17:50:30 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 17 Dec 2020 17:50:30 +0000 Subject: [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Best regards, Martin > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 17. Dezember 2020 18:21 > To: Reingruber, Richard ; Doerr, Martin > ; hotspot-runtime-dev at openjdk.java.net; jdk- > updates-dev at openjdk.java.net > Subject: RE: [11u] RFR: 8234796: Refactor Handshake::execute to take a more > complex type than ThreadClosure > > Looks good to me. > > Thanks for backporting, and thanks for the detailed description of your > changes! > > Best regards, > Goetz. > > -----Original Message----- > From: Reingruber, Richard > Sent: Mittwoch, 16. Dezember 2020 11:54 > To: Doerr, Martin ; hotspot-runtime- > dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8234796: Refactor Handshake::execute to take a more > complex type than ThreadClosure > > Hi Martin, > > I've compared the proposed change for 11u with the original change. It looks > good to me. > > Thanks, > Richard. > > -----Original Message----- > From: hotspot-runtime-dev > On Behalf Of Doerr, Martin > Sent: Dienstag, 15. Dezember 2020 21:50 > To: hotspot-runtime-dev at openjdk.java.net; jdk-updates- > dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: [CAUTION] [11u] RFR: 8234796: Refactor Handshake::execute to > take a more complex type than ThreadClosure > > Hi, > > JDK-8234796 is backported to 11.0.11-oracle. I'd like to backport it for parity. > It's only a refactoring. > Unfortunately, it doesn't apply cleanly. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8234796 > > Original change: > https://hg.openjdk.java.net/jdk/jdk/rev/99b71c5b02ff > > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/webrev.00/ > > Resolution steps: > - Manually integrated includes, forward declarations and Copyright updates > due to different context. > - Handshake operations (handshake.cpp): Removed _executed field from > patch which was added by JDK-8191890 which is not in 11u. > - Skipped "RevokeOneBias" (biasedLocking.cpp) which is also part of JDK- > 8191890 which is not in 11u. > - Skipped "DeoptimizeMarkedTC" (deoptimization.cpp) which is part of JDK- > 8226705 which is not in 11u. > - Skipped "HandshakeALotTC" (vmThread.cpp) which is part of JDK-8220774 > which is not in 11u. > - Skipped "NMethodMarkingThreadClosure" (sweeper.cpp) which is part of > JDK-8132849 which is not in 11u (it was in 11.0.8-oracle, but backed out later > due to problems). > - Skipped "ShenandoahUnloadRendezvousClosure" and > "ZRendezvousClosure" which don't exist in 11u at all. > > (Also uploaded here with complete listing of non-automatically applied > hunks: > http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/8234796_han > dshake_integration.txt) > > Please review. > > Best regards, > Martin 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 suenaga at oss.nttdata.com Fri Dec 18 07:42:52 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 18 Dec 2020 16:42:52 +0900 Subject: [11u] RFR: 8205992: jhsdb cannot attach to Java processes running in Docker containers Message-ID: Hi all, Please review the backport of JDK-8205992 to 11u: JBS: https://bugs.openjdk.java.net/browse/JDK-8205992 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/220c9188db4f 11u webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8205992/jdk11/webrev.00/ Original change cannot apply cleanly due to JDK-8202884. The conflict is caused by header file inclusion, the others can be applied cleanly. Thanks, Yasumasa From evergizova at openjdk.java.net Fri Dec 18 09:28:03 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 18 Dec 2020 09:28:03 GMT Subject: [jdk13u-dev] RFR: 8237499: JFR: Include stack trace in the ThreadStart event Message-ID: I'd like to backport 8237499 to 13u for parity with 11u. The plan is to backport it together with follow-up fix 8239886. The patch doesn't apply cleanly due to context difference in jfrThreadLocal.cpp, reapplied manually. Tested with tier1 and jdk/jfr, no regressions. ------------- Commit messages: - Backport 52d7a61e8d58a547a943f8f705764dc1898c621d Changes: https://git.openjdk.java.net/jdk13u-dev/pull/60/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=60&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8237499 Stats: 56 lines in 8 files changed: 48 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/60/head:pull/60 PR: https://git.openjdk.java.net/jdk13u-dev/pull/60 From omikhaltcova at openjdk.java.net Fri Dec 18 09:54:10 2020 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 18 Dec 2020 09:54:10 GMT Subject: [jdk13u-dev] RFR: 8239000: handle ContendedPaddingWidth in vm_version_ppc Message-ID: I'd like to backport JDK-8239000 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested with tier1, tier2, tier3. No regression in tests. ------------- Commit messages: - Backport cf4291db370bb0bfaa7c8354308886315e1c3901 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/61/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=61&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8239000 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk13u-dev/pull/61 From dcherepanov at openjdk.java.net Fri Dec 18 09:57:58 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Fri, 18 Dec 2020 09:57:58 GMT Subject: [jdk13u-dev] RFR: 8237499: JFR: Include stack trace in the ThreadStart event In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 09:22:58 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8237499 to 13u for parity with 11u. The plan is to backport it together with follow-up fix 8239886. > The patch doesn't apply cleanly due to context difference in jfrThreadLocal.cpp, reapplied manually. > Tested with tier1 and jdk/jfr, no regressions. Marked as reviewed by dcherepanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/60 From sgehwolf at redhat.com Fri Dec 18 10:08:29 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 18 Dec 2020 11:08:29 +0100 Subject: [11u] RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem In-Reply-To: References: Message-ID: <3fac46683c381ffab97f00c4a220c411dd72f21f.camel@redhat.com> On Thu, 2020-12-10 at 14:07 +0100, Severin Gehwolf wrote: > Hi! > > Could I please get a review of this bugfix which improves error > checking in the Java Metrics container detection code? The patch is > basically a rewrite, since there is no cgroups v2 in JDK 11, and places > where UncheckedIOException need to be handled are different enough for > the JDK head patch to not apply properly. > > The gist is to handle UncheckedIOException, possibly thrown because of > interrupts, and exit gracefully rather than failing to initialize and > crash. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255908 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8255908/01/webrev/ > > Testing: Container tests on x86_64 Linux (cgroups v1) and tier 1. > > Thoughts? Anyone? Thanks, Severin From aph at redhat.com Fri Dec 18 10:08:45 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 18 Dec 2020 10:08:45 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: References: <20201211170313.GH1323090@rincewind> Message-ID: <077ea8ae-dca1-aa1f-4f54-e9aed1c6d51a@redhat.com> On 12/17/20 5:39 PM, Lindenmaier, Goetz wrote: > 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. This is a good point. We're on the threshold of moving to github, and the new workflow addresses some of the issues that we're wrestling with here. It'll take some time for most of the non- core backporters to come to terms with any workflow change, so it makes little sense to create a new way of working that'll be gone almost as soon as it is implemented. We should do the JDK 11u move to github first. Let's meet in the new year after the CPU is out. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dcherepanov at openjdk.java.net Fri Dec 18 14:04:40 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Fri, 18 Dec 2020 14:04:40 GMT Subject: [jdk13u-dev] RFR: 8247867: Upgrade to freetype 2.10.2 Message-ID: Request to backport the upgrade to freetype 2.10.2. Applies cleanly, running desktop tests doesn't reveal any issues. ------------- Commit messages: - Backport e0989c0068009c27614cb34815ef0c8529c82544 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/62/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=62&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247867 Stats: 3716 lines in 274 files changed: 3090 ins; 76 del; 550 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/62.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/62/head:pull/62 PR: https://git.openjdk.java.net/jdk13u-dev/pull/62 From bae at openjdk.java.net Fri Dec 18 14:10:28 2020 From: bae at openjdk.java.net (Andrew Brygin) Date: Fri, 18 Dec 2020 14:10:28 GMT Subject: [jdk13u-dev] RFR: 8247867: Upgrade to freetype 2.10.2 In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 13:58:18 GMT, Dmitry Cherepanov wrote: > Request to backport the upgrade to freetype 2.10.2. > Applies cleanly, running desktop tests doesn't reveal any issues. The change looks fine to me. ------------- Marked as reviewed by bae (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/62 From dcherepanov at openjdk.java.net Fri Dec 18 14:17:30 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Fri, 18 Dec 2020 14:17:30 GMT Subject: [jdk13u-dev] Integrated: 8247867: Upgrade to freetype 2.10.2 In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 13:58:18 GMT, Dmitry Cherepanov wrote: > Request to backport the upgrade to freetype 2.10.2. > Applies cleanly, running desktop tests doesn't reveal any issues. This pull request has now been integrated. Changeset: 20251b70 Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/20251b70 Stats: 3716 lines in 274 files changed: 3090 ins; 76 del; 550 mod 8247867: Upgrade to freetype 2.10.2 Reviewed-by: bae Backport-of: e0989c0068009c27614cb34815ef0c8529c82544 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/62 From evergizova at openjdk.java.net Fri Dec 18 14:40:27 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 18 Dec 2020 14:40:27 GMT Subject: [jdk13u-dev] Integrated: 8237499: JFR: Include stack trace in the ThreadStart event In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 09:22:58 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8237499 to 13u for parity with 11u. The plan is to backport it together with follow-up fix 8239886. > The patch doesn't apply cleanly due to context difference in jfrThreadLocal.cpp, reapplied manually. > Tested with tier1 and jdk/jfr, no regressions. This pull request has now been integrated. Changeset: 85b79081 Author: Ekaterina Vergizova Committer: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/85b79081 Stats: 56 lines in 8 files changed: 48 ins; 2 del; 6 mod 8237499: JFR: Include stack trace in the ThreadStart event Reviewed-by: dcherepanov Backport-of: 52d7a61e8d58a547a943f8f705764dc1898c621d ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/60 From evergizova at openjdk.java.net Fri Dec 18 14:56:37 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 18 Dec 2020 14:56:37 GMT Subject: [jdk13u-dev] RFR: 8239886: Minimal VM build fails after JDK-8237499 Message-ID: I'd like to backport 8239886 to 13u as follow-up fix for JDK-8237499 that is already included to 13u. The patch applies cleanly. Minimal VM variant are built successfully after applying the patch. ------------- Commit messages: - Backport 5a7b5863f0ac34f73496913b4319e73f1eb47e73 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/63/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=63&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8239886 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/63.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/63/head:pull/63 PR: https://git.openjdk.java.net/jdk13u-dev/pull/63 From evergizova at openjdk.java.net Fri Dec 18 15:04:27 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 18 Dec 2020 15:04:27 GMT Subject: [jdk13u-dev] Integrated: 8239886: Minimal VM build fails after JDK-8237499 In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 14:51:11 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8239886 to 13u as follow-up fix for JDK-8237499 that is already included to 13u. > The patch applies cleanly. > Minimal VM variant are built successfully after applying the patch. This pull request has now been integrated. Changeset: 05ac56a8 Author: Ekaterina Vergizova Committer: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/05ac56a8 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8239886: Minimal VM build fails after JDK-8237499 Backport-of: 5a7b5863f0ac34f73496913b4319e73f1eb47e73 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/63 From alvdavi at amazon.com Fri Dec 18 15:56:13 2020 From: alvdavi at amazon.com (Alvarez, David) Date: Fri, 18 Dec 2020 15:56:13 +0000 Subject: Bringing the OutputRecord's lock of JDK-8221882 that was left out by JDK-8240827 Message-ID: <94c1f2397b7f96bdd4e5e648993366f120ccf70d.camel@amazon.com> Hi, I'm currently working on a backport of JDK-8224829 [1]. However, back in the day, instead of backporting JDK-8221882 [2] completely, a downport of the SSLSocketImpl.java was done as part of JDK-8240827 [3]. This mean that other changes included in JDK-8221882 did not made it to 11u. For JDK-8224829, I would need the lock that was added to OutputRecord (as the lock call is replaced with a tryLock with timeout). During the RFR of JDK-8240827, a small discussion regarding the lock in OutputRecord [4] was started, but they ended up not being included. I would like to bring the OutputRecord's lock changes to 11u, and once I have them, backport JDK-8224829. Can I get an opinion from the maintainers? Would it be possible to have a bug for 11u created for these OutputRecord's lock changes? Thanks, David -- [1] https://bugs.openjdk.java.net/browse/JDK-8224829 [2] https://bugs.openjdk.java.net/browse/JDK-8221882 [3] https://bugs.openjdk.java.net/browse/JDK-8240827 [4] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002808.html From sgehwolf at redhat.com Fri Dec 18 17:31:02 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 18 Dec 2020 18:31:02 +0100 Subject: [11u] RFR: 8225072: Add LuxTrust certificate that is expiring in March 2021 to list of allowed but expired certs Message-ID: <3626fb818557aaeef6e33483cc24eb5399316943.camel@redhat.com> Please review this test-only backport which adds QuoVadis and LuxTrust certificate to the allowed but soon-to-expire list. The JDK 17 patch didn't apply cleanly since 11 is missing JDK-8243559. It's not clear at this point when we'll include it in JDK 11. I've ported the changes manually. The patch will resolve 11 backports for both JDK-8225072 and JDK- 8258630. Bug(s): https://bugs.openjdk.java.net/browse/JDK-8225072 https://bugs.openjdk.java.net/browse/JDK-8258630 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8225072/01/webrev/ Testing: VerifyCACerts test fails before and passes after. Thoughts? Thanks, Severin From sgehwolf at redhat.com Fri Dec 18 18:34:49 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 18 Dec 2020 19:34:49 +0100 Subject: [11u] RFR: 8202343: Disable TLS 1.0 and 1.1 Message-ID: Hi, Please review this downport for disabling TLS 1.0 and 1.1 via the tls.disabledAlgorithms security property. The JDK 16 patch didn't apply cleanly. The differences are context changes mostly. The hunk to TlsContextTest.java has been omitted since that test has been introduced with JDK 12+ (via JDK-8239594, not in JDK 11). Once reviewed and approved my intention is to push this together with follow-ups JDK-8256682 and JDK-8257083. CSR for this is (reused from Oracle): https://bugs.openjdk.java.net/browse/JDK-8257122 Bug: https://bugs.openjdk.java.net/browse/JDK-8202343 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202343/01/webrev/ Testing: jdk_security tests. No regressions noted. Thoughts? Thanks, Severin From christoph.langer at sap.com Sat Dec 19 06:21:32 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 19 Dec 2020 06:21:32 +0000 Subject: [11u] RFR: 8225072: Add LuxTrust certificate that is expiring in March 2021 to list of allowed but expired certs In-Reply-To: <3626fb818557aaeef6e33483cc24eb5399316943.camel@redhat.com> References: <3626fb818557aaeef6e33483cc24eb5399316943.camel@redhat.com> Message-ID: Hi Severin, thanks for doing this backport, it looks correct. JDK-8243559 is planned by Oracle for the April update but we should only backport it once Oracle has done so, as well. So I agree, we need to now backport 8225072 with manual reshuffling and later on 8243559. As the test is failing in 11.0.10 as well, since it is time based, and it is in tier1, please push to 11.0.10 (11u). I'll approve this immediately once you've tagged it... Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Severin Gehwolf > Sent: Freitag, 18. Dezember 2020 18:31 > To: jdk-updates-dev > Subject: [11u] RFR: 8225072: Add LuxTrust certificate that is expiring in March > 2021 to list of allowed but expired certs > > Please review this test-only backport which adds QuoVadis and LuxTrust > certificate to the allowed but soon-to-expire list. The JDK 17 patch > didn't apply cleanly since 11 is missing JDK-8243559. It's not clear at > this point when we'll include it in JDK 11. I've ported the changes > manually. > > The patch will resolve 11 backports for both JDK-8225072 and JDK- > 8258630. > > Bug(s): https://bugs.openjdk.java.net/browse/JDK-8225072 > https://bugs.openjdk.java.net/browse/JDK-8258630 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8225072/01/webrev/ > > Testing: VerifyCACerts test fails before and passes after. > > Thoughts? > > Thanks, > Severin From hohensee at amazon.com Sun Dec 20 18:17:22 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Sun, 20 Dec 2020 18:17:22 +0000 Subject: [11u] RFR: 8222518: Remove unnecessary caching of Parker object in java.lang.Thread Message-ID: <0B57272A-5A4A-4832-A7AA-8474B5208EF6@amazon.com> Please review this small code deletion and footprint reduction backport. JBS: https://bugs.openjdk.java.net/browse/JDK-8222518 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/9ebb614d293d Webrev: http://cr.openjdk.java.net/~phh/8222518/webrev.11u.00/ The backport is not clean because (1) javaClasses.cpp needed a copyright date update to 2019 and the original 3rd hunk that deletes park_event() and set_park_event() contained slightly different code that does not check for non-existent Thread fields, and (2) unsafe.cpp needed a copyright update to 2019. Thanks, Paul From omikhaltcova at openjdk.java.net Mon Dec 21 03:33:04 2020 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 21 Dec 2020 03:33:04 GMT Subject: [jdk13u-dev] RFR: 8248532: Every time I change keyboard language at my MacBook, Java crashes Message-ID: I'd like to backport JDK-8248532 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested with jtreg:test/jdk:jdk_awt. No regression in tests. ------------- Commit messages: - Backport 6329de45045da3ce937cd22d82e74c3f142ea3f2 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/64/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=64&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248532 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/64.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/64/head:pull/64 PR: https://git.openjdk.java.net/jdk13u-dev/pull/64 From sgehwolf at redhat.com Mon Dec 21 08:56:59 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 21 Dec 2020 09:56:59 +0100 Subject: [11u] RFR: 8225072: Add LuxTrust certificate that is expiring in March 2021 to list of allowed but expired certs In-Reply-To: References: <3626fb818557aaeef6e33483cc24eb5399316943.camel@redhat.com> Message-ID: Hi Christoph, Hi Christoph, On Sat, 2020-12-19 at 06:21 +0000, Langer, Christoph wrote: > Hi Severin, > > thanks for doing this backport, it looks correct. Thanks for the review! > JDK-8243559 is planned by Oracle for the April update but we should > only backport it once Oracle has done so, as well. So I agree, we > need to now backport 8225072 with manual reshuffling and later on > 8243559. > > As the test is failing in 11.0.10 as well, since it is time based, > and it is in tier1, please push to 11.0.10 (11u). I'll approve this > immediately once you've tagged it... Tagged both bugs: https://bugs.openjdk.java.net/browse/JDK-8225072 https://bugs.openjdk.java.net/browse/JDK-8258630 Thanks, Severin > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Severin Gehwolf > > Sent: Freitag, 18. Dezember 2020 18:31 > > To: jdk-updates-dev > > Subject: [11u] RFR: 8225072: Add LuxTrust certificate that is > > expiring in March > > 2021 to list of allowed but expired certs > > > > Please review this test-only backport which adds QuoVadis and > > LuxTrust > > certificate to the allowed but soon-to-expire list. The JDK 17 > > patch > > didn't apply cleanly since 11 is missing JDK-8243559. It's not > > clear at > > this point when we'll include it in JDK 11. I've ported the changes > > manually. > > > > The patch will resolve 11 backports for both JDK-8225072 and JDK- > > 8258630. > > > > Bug(s): https://bugs.openjdk.java.net/browse/JDK-8225072 > > ??????? https://bugs.openjdk.java.net/browse/JDK-8258630 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8225072/01/webrev/ > > > > Testing: VerifyCACerts test fails before and passes after. > > > > Thoughts? > > > > Thanks, > > Severin > From christoph.langer at sap.com Mon Dec 21 09:09:10 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 21 Dec 2020 09:09:10 +0000 Subject: [11u] RFR: 8225072: Add LuxTrust certificate that is expiring in March 2021 to list of allowed but expired certs In-Reply-To: References: <3626fb818557aaeef6e33483cc24eb5399316943.camel@redhat.com> Message-ID: ...and approved. Cheers Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Montag, 21. Dezember 2020 09:57 > To: Langer, Christoph ; jdk-updates-dev updates-dev at openjdk.java.net> > Subject: Re: [11u] RFR: 8225072: Add LuxTrust certificate that is expiring in > March 2021 to list of allowed but expired certs > > Hi Christoph, > > Hi Christoph, > > On Sat, 2020-12-19 at 06:21 +0000, Langer, Christoph wrote: > > Hi Severin, > > > > thanks for doing this backport, it looks correct. > > Thanks for the review! > > > JDK-8243559 is planned by Oracle for the April update but we should > > only backport it once Oracle has done so, as well. So I agree, we > > need to now backport 8225072 with manual reshuffling and later on > > 8243559. > > > > As the test is failing in 11.0.10 as well, since it is time based, > > and it is in tier1, please push to 11.0.10 (11u). I'll approve this > > immediately once you've tagged it... > > Tagged both bugs: > https://bugs.openjdk.java.net/browse/JDK-8225072 > https://bugs.openjdk.java.net/browse/JDK-8258630 > > Thanks, > Severin > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of Severin Gehwolf > > > Sent: Freitag, 18. Dezember 2020 18:31 > > > To: jdk-updates-dev > > > Subject: [11u] RFR: 8225072: Add LuxTrust certificate that is > > > expiring in March > > > 2021 to list of allowed but expired certs > > > > > > Please review this test-only backport which adds QuoVadis and > > > LuxTrust > > > certificate to the allowed but soon-to-expire list. The JDK 17 > > > patch > > > didn't apply cleanly since 11 is missing JDK-8243559. It's not > > > clear at > > > this point when we'll include it in JDK 11. I've ported the changes > > > manually. > > > > > > The patch will resolve 11 backports for both JDK-8225072 and JDK- > > > 8258630. > > > > > > Bug(s): https://bugs.openjdk.java.net/browse/JDK-8225072 > > > ??????? https://bugs.openjdk.java.net/browse/JDK-8258630 > > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > 8225072/01/webrev/ > > > > > > Testing: VerifyCACerts test fails before and passes after. > > > > > > Thoughts? > > > > > > Thanks, > > > Severin > > > From dcherepanov at openjdk.java.net Mon Dec 21 10:23:07 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Mon, 21 Dec 2020 10:23:07 GMT Subject: [jdk13u-dev] RFR: 8245400: Upgrade to LittleCMS 2.11 Message-ID: Request to backport the upgrade to LittleCMS 2.11. Applies cleanly, running desktop tests doesn't reveal any issues. ------------- Commit messages: - Backport 62cc45c3df003c169993d7fa4453176e823a073e Changes: https://git.openjdk.java.net/jdk13u-dev/pull/65/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=65&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245400 Stats: 1251 lines in 30 files changed: 292 ins; 168 del; 791 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/65.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/65/head:pull/65 PR: https://git.openjdk.java.net/jdk13u-dev/pull/65 From martin.doerr at sap.com Mon Dec 21 10:30:08 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 10:30:08 +0000 Subject: [11u] RFR:8214230: Classes generated by SystemModulesPlugin.java are not reproducable In-Reply-To: <45B07E1D-FFD3-4E17-ADA5-302E3901F61A@amazon.com> References: <45B07E1D-FFD3-4E17-ADA5-302E3901F61A@amazon.com> Message-ID: Hi, we have seen intermittent failures in the new test which was introduced by this change: test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: assertEquals: expected -1 to equal 52944 (or other numbers at the end) Note that there's a follow-up change: https://bugs.openjdk.java.net/browse/JDK-8232864 Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Montag, 14. Dezember 2020 18:30 > To: hedongbo ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR:8214230: Classes generated by > SystemModulesPlugin.java are not reproducable > > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of hedongbo > Date: Sunday, December 13, 2020 at 5:38 PM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Subject: [11u] RFR:8214230: Classes generated by SystemModulesPlugin.java > are not reproducable > > Hi, > > > > Please review the backport of JDK-8214230 to 11u: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214230 > > > > Original commit: http://hg.openjdk.java.net/jdk/jdk/rev/abccada595dd > > > > 11u webrev: http://cr.openjdk.java.net/~dongbohe/8214230/webrev.00/ > > > > Patch applies cleanly to11u, but I added a static method `mismatch(Path, > Path)` to the test file because it only exists in jdk12[1]. Moreover, I also > modified the copyright year. > > > Tested with tier1, tier2. No regression in tests. > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8202302 > > > Thanks, > dongbohe From martin.doerr at sap.com Mon Dec 21 10:52:24 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 10:52:24 +0000 Subject: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag Message-ID: Hi, JDK-8235351 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly, because https://bugs.openjdk.java.net/browse/JDK-8233527 is not in 11u (jdk14 uses hasFullPrivilegeAccess(), but older versions use hasPrivateAccess()). Bug: https://bugs.openjdk.java.net/browse/JDK-8235351 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/4437d58547ce 11u backport: http://cr.openjdk.java.net/~mdoerr/8235351_methodhandles_11u/webrev.00/ This is the adaptation: diff -r a670e0826a66 src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Dec 06 15:10:40 2019 -0800 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Dec 18 18:01:25 2020 +0100 @@ -2074,8 +2074,8 @@ * Otherwise, if m is caller-sensitive, throw IllegalAccessException. */ Lookup findBoundCallerLookup(MemberName m) throws IllegalAccessException { - if (MethodHandleNatives.isCallerSensitive(m) && !hasFullPrivilegeAccess()) { - // Only lookups with full privilege access are allowed to resolve caller-sensitive methods + if (MethodHandleNatives.isCallerSensitive(m) && !hasPrivateAccess()) { + // Only lookups with private access are allowed to resolve caller-sensitive methods throw new IllegalAccessException("Attempt to lookup caller-sensitive method using restricted lookup object"); } return this; @@ -2335,9 +2335,9 @@ if (boundCaller.allowedModes == TRUSTED || !MethodHandleNatives.isCallerSensitive(method)) return mh; - // boundCaller must have full privilege access. + // boundCaller must have private access. // It should have been checked by findBoundCallerLookup. Safe to check this again. - if (!boundCaller.hasFullPrivilegeAccess()) + if (!boundCaller.hasPrivateAccess()) throw new IllegalAccessException("Attempt to lookup caller-sensitive method using restricted lookup object"); MethodHandle cbmh = MethodHandleImpl.bindCaller(mh, boundCaller.lookupClass); Please review. Best regards, Martin From dcherepanov at openjdk.java.net Mon Dec 21 11:50:59 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Mon, 21 Dec 2020 11:50:59 GMT Subject: [jdk13u-dev] RFR: 8248532: Every time I change keyboard language at my MacBook, Java crashes In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 03:28:28 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8248532 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested with jtreg:test/jdk:jdk_awt. No regression in tests. Looks good. We'll also need to backport 8257242. ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/64 From omikhaltcova at openjdk.java.net Mon Dec 21 11:50:59 2020 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 21 Dec 2020 11:50:59 GMT Subject: [jdk13u-dev] Integrated: 8248532: Every time I change keyboard language at my MacBook, Java crashes In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 03:28:28 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8248532 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested with jtreg:test/jdk:jdk_awt. No regression in tests. This pull request has now been integrated. Changeset: 501e942a Author: Olga Mikhaltsova Committer: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/501e942a Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8248532: Every time I change keyboard language at my MacBook, Java crashes Backport-of: 6329de45045da3ce937cd22d82e74c3f142ea3f2 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/64 From martin.doerr at sap.com Mon Dec 21 11:51:55 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 11:51:55 +0000 Subject: [11u] RFR: 8233164: C2 fails with assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr)) failed: correct memory chain Message-ID: Hi, JDK-8233164 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change applies almost cleanly. I only had to integrate the following hunk manually due to unrelated context changes: --- arraycopynode.cpp +++ arraycopynode.cpp @@ -574,8 +573,8 @@ Node* src = in(ArrayCopyNode::Src); Node* dest = in(ArrayCopyNode::Dest); - const TypePtr* atp_src = get_address_type(phase, src); - const TypePtr* atp_dest = get_address_type(phase, dest); + const TypePtr* atp_src = get_address_type(phase, _src_type, src); + const TypePtr* atp_dest = get_address_type(phase, _dest_type, dest); Node *in_mem = in(TypeFunc::Memory); if (!in_mem->is_MergeMem()) { Bug: https://bugs.openjdk.java.net/browse/JDK-8233164 Original change: https://hg.openjdk.java.net/jdk/jdk14/rev/be9033a248f7 11u backport: http://cr.openjdk.java.net/~mdoerr/8233164_C2_11u/webrev.00/ Please review. Best regards, Martin From dcherepanov at openjdk.java.net Mon Dec 21 12:14:00 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Mon, 21 Dec 2020 12:14:00 GMT Subject: [jdk13u-dev] Integrated: 8245400: Upgrade to LittleCMS 2.11 In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 10:17:45 GMT, Dmitry Cherepanov wrote: > Request to backport the upgrade to LittleCMS 2.11. > Applies cleanly, running desktop tests doesn't reveal any issues. This pull request has now been integrated. Changeset: 92aec525 Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/92aec525 Stats: 1251 lines in 30 files changed: 292 ins; 168 del; 791 mod 8245400: Upgrade to LittleCMS 2.11 Backport-of: 62cc45c3df003c169993d7fa4453176e823a073e ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/65 From goetz.lindenmaier at sap.com Mon Dec 21 13:30:50 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Dec 2020 13:30:50 +0000 Subject: [11u] RFR: 8205992: jhsdb cannot attach to Java processes running in Docker containers In-Reply-To: References: Message-ID: Hi Yasumasa First, your please need to use jdk11_u_-fix-request. The other tag was used in the ramp down of 11 years ago. Change looks good, it?s a trivial resolve. Best regards Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Yasumasa Suenaga > Sent: Friday, December 18, 2020 8:43 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8205992: jhsdb cannot attach to Java processes running > in Docker containers > > Hi all, > > Please review the backport of JDK-8205992 to 11u: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8205992 > Original change: http://hg.openjdk.java.net/jdk/jdk/rev/220c9188db4f > 11u webrev: http://cr.openjdk.java.net/~ysuenaga/JDK- > 8205992/jdk11/webrev.00/ > > Original change cannot apply cleanly due to JDK-8202884. > The conflict is caused by header file inclusion, the others can be applied > cleanly. > > > Thanks, > > Yasumasa From goetz.lindenmaier at sap.com Mon Dec 21 13:44:19 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Dec 2020 13:44:19 +0000 Subject: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag In-Reply-To: References: Message-ID: Hi Martin, The change looks good. The private methods have been called at those places before, so this is straight forward. Best regards, Goetz. From: Doerr, Martin Sent: Monday, December 21, 2020 11:52 AM To: core-libs-dev ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag Hi, JDK-8235351 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly, because https://bugs.openjdk.java.net/browse/JDK-8233527 is not in 11u (jdk14 uses hasFullPrivilegeAccess(), but older versions use hasPrivateAccess()). Bug: https://bugs.openjdk.java.net/browse/JDK-8235351 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/4437d58547ce 11u backport: http://cr.openjdk.java.net/~mdoerr/8235351_methodhandles_11u/webrev.00/ This is the adaptation: diff -r a670e0826a66 src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Dec 06 15:10:40 2019 -0800 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Dec 18 18:01:25 2020 +0100 @@ -2074,8 +2074,8 @@ * Otherwise, if m is caller-sensitive, throw IllegalAccessException. */ Lookup findBoundCallerLookup(MemberName m) throws IllegalAccessException { - if (MethodHandleNatives.isCallerSensitive(m) && !hasFullPrivilegeAccess()) { - // Only lookups with full privilege access are allowed to resolve caller-sensitive methods + if (MethodHandleNatives.isCallerSensitive(m) && !hasPrivateAccess()) { + // Only lookups with private access are allowed to resolve caller-sensitive methods throw new IllegalAccessException("Attempt to lookup caller-sensitive method using restricted lookup object"); } return this; @@ -2335,9 +2335,9 @@ if (boundCaller.allowedModes == TRUSTED || !MethodHandleNatives.isCallerSensitive(method)) return mh; - // boundCaller must have full privilege access. + // boundCaller must have private access. // It should have been checked by findBoundCallerLookup. Safe to check this again. - if (!boundCaller.hasFullPrivilegeAccess()) + if (!boundCaller.hasPrivateAccess()) throw new IllegalAccessException("Attempt to lookup caller-sensitive method using restricted lookup object"); MethodHandle cbmh = MethodHandleImpl.bindCaller(mh, boundCaller.lookupClass); Please review. Best regards, Martin From martin.doerr at sap.com Mon Dec 21 13:47:35 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 13:47:35 +0000 Subject: [11u] RFR: 8241911: AArch64: Fix a potential issue about register allocation effect rule in reduce_add2I Message-ID: Hi, JDK- 8241911 is backported to 11.0.11-oracle. I'd like to backport it for parity. The actual fix applies cleanly, but the change contains additional format changes which don't (see below) and which we can skip. Bug: https://bugs.openjdk.java.net/browse/JDK-8241911 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/4b76f0cc11c4 11u backport: http://cr.openjdk.java.net/~mdoerr/8241911_aarch64_11u/webrev.00/ Please review. Best regards, Martin --- aarch64.ad +++ aarch64.ad @@ -16265,7 +16265,7 @@ effect(TEMP_DEF dst, TEMP tmp); format %{ "fmaxs $dst, $src1, $src2\n\t" "ins $tmp, S, $src2, 0, 1\n\t" - "fmaxs $dst, $dst, $tmp\t max reduction2F" %} + "fmaxs $dst, $dst, $tmp\t# max reduction2F" %} ins_encode %{ __ fmaxs(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg), as_FloatRegister($src2$$reg)); __ ins(as_FloatRegister($tmp$$reg), __ S, as_FloatRegister($src2$$reg), 0, 1); @@ -16280,7 +16280,7 @@ ins_cost(INSN_COST); effect(TEMP_DEF dst); format %{ "fmaxv $dst, T4S, $src2\n\t" - "fmaxs $dst, $dst, $src1\t max reduction4F" %} + "fmaxs $dst, $dst, $src1\t# max reduction4F" %} ins_encode %{ __ fmaxv(as_FloatRegister($dst$$reg), __ T4S, as_FloatRegister($src2$$reg)); __ fmaxs(as_FloatRegister($dst$$reg), as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg)); @@ -16295,7 +16295,7 @@ effect(TEMP_DEF dst, TEMP tmp); format %{ "fmaxd $dst, $src1, $src2\n\t" "ins $tmp, D, $src2, 0, 1\n\t" - "fmaxd $dst, $dst, $tmp\t max reduction2D" %} + "fmaxd $dst, $dst, $tmp\t# max reduction2D" %} ins_encode %{ __ fmaxd(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg), as_FloatRegister($src2$$reg)); __ ins(as_FloatRegister($tmp$$reg), __ D, as_FloatRegister($src2$$reg), 0, 1); @@ -16311,7 +16311,7 @@ effect(TEMP_DEF dst, TEMP tmp); format %{ "fmins $dst, $src1, $src2\n\t" "ins $tmp, S, $src2, 0, 1\n\t" - "fmins $dst, $dst, $tmp\t min reduction2F" %} + "fmins $dst, $dst, $tmp\t# min reduction2F" %} ins_encode %{ __ fmins(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg), as_FloatRegister($src2$$reg)); __ ins(as_FloatRegister($tmp$$reg), __ S, as_FloatRegister($src2$$reg), 0, 1); @@ -16326,7 +16326,7 @@ ins_cost(INSN_COST); effect(TEMP_DEF dst); format %{ "fminv $dst, T4S, $src2\n\t" - "fmins $dst, $dst, $src1\t min reduction4F" %} + "fmins $dst, $dst, $src1\t# min reduction4F" %} ins_encode %{ __ fminv(as_FloatRegister($dst$$reg), __ T4S, as_FloatRegister($src2$$reg)); __ fmins(as_FloatRegister($dst$$reg), as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg)); @@ -16341,7 +16341,7 @@ effect(TEMP_DEF dst, TEMP tmp); format %{ "fmind $dst, $src1, $src2\n\t" "ins $tmp, D, $src2, 0, 1\n\t" - "fmind $dst, $dst, $tmp\t min reduction2D" %} + "fmind $dst, $dst, $tmp\t# min reduction2D" %} ins_encode %{ __ fmind(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg), as_FloatRegister($src2$$reg)); __ ins(as_FloatRegister($tmp$$reg), __ D, as_FloatRegister($src2$$reg), 0, 1); From goetz.lindenmaier at sap.com Mon Dec 21 13:48:44 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Dec 2020 13:48:44 +0000 Subject: [11u] RFR: 8233164: C2 fails with assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr)) failed: correct memory chain In-Reply-To: References: Message-ID: Hi Martin, Looks good and resolve was trivial (I guess ??) Best regards, Goetz. From: Doerr, Martin Sent: Monday, December 21, 2020 12:52 PM To: 'hotspot-compiler-dev at openjdk.java.net' ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8233164: C2 fails with assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr)) failed: correct memory chain Hi, JDK-8233164 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change applies almost cleanly. I only had to integrate the following hunk manually due to unrelated context changes: --- arraycopynode.cpp +++ arraycopynode.cpp @@ -574,8 +573,8 @@ Node* src = in(ArrayCopyNode::Src); Node* dest = in(ArrayCopyNode::Dest); - const TypePtr* atp_src = get_address_type(phase, src); - const TypePtr* atp_dest = get_address_type(phase, dest); + const TypePtr* atp_src = get_address_type(phase, _src_type, src); + const TypePtr* atp_dest = get_address_type(phase, _dest_type, dest); Node *in_mem = in(TypeFunc::Memory); if (!in_mem->is_MergeMem()) { Bug: https://bugs.openjdk.java.net/browse/JDK-8233164 Original change: https://hg.openjdk.java.net/jdk/jdk14/rev/be9033a248f7 11u backport: http://cr.openjdk.java.net/~mdoerr/8233164_C2_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Mon Dec 21 13:51:04 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 13:51:04 +0000 Subject: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Best regards, Martin From: Lindenmaier, Goetz Sent: Montag, 21. Dezember 2020 14:44 To: Doerr, Martin ; core-libs-dev ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag Hi Martin, The change looks good. The private methods have been called at those places before, so this is straight forward. Best regards, Goetz. From: Doerr, Martin > Sent: Monday, December 21, 2020 11:52 AM To: core-libs-dev >; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag Hi, JDK-8235351 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly, because https://bugs.openjdk.java.net/browse/JDK-8233527 is not in 11u (jdk14 uses hasFullPrivilegeAccess(), but older versions use hasPrivateAccess()). Bug: https://bugs.openjdk.java.net/browse/JDK-8235351 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/4437d58547ce 11u backport: http://cr.openjdk.java.net/~mdoerr/8235351_methodhandles_11u/webrev.00/ This is the adaptation: diff -r a670e0826a66 src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Dec 06 15:10:40 2019 -0800 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Dec 18 18:01:25 2020 +0100 @@ -2074,8 +2074,8 @@ * Otherwise, if m is caller-sensitive, throw IllegalAccessException. */ Lookup findBoundCallerLookup(MemberName m) throws IllegalAccessException { - if (MethodHandleNatives.isCallerSensitive(m) && !hasFullPrivilegeAccess()) { - // Only lookups with full privilege access are allowed to resolve caller-sensitive methods + if (MethodHandleNatives.isCallerSensitive(m) && !hasPrivateAccess()) { + // Only lookups with private access are allowed to resolve caller-sensitive methods throw new IllegalAccessException("Attempt to lookup caller-sensitive method using restricted lookup object"); } return this; @@ -2335,9 +2335,9 @@ if (boundCaller.allowedModes == TRUSTED || !MethodHandleNatives.isCallerSensitive(method)) return mh; - // boundCaller must have full privilege access. + // boundCaller must have private access. // It should have been checked by findBoundCallerLookup. Safe to check this again. - if (!boundCaller.hasFullPrivilegeAccess()) + if (!boundCaller.hasPrivateAccess()) throw new IllegalAccessException("Attempt to lookup caller-sensitive method using restricted lookup object"); MethodHandle cbmh = MethodHandleImpl.bindCaller(mh, boundCaller.lookupClass); Please review. Best regards, Martin From martin.doerr at sap.com Mon Dec 21 13:51:37 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 13:51:37 +0000 Subject: [11u] RFR: 8233164: C2 fails with assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr)) failed: correct memory chain In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Best regards, Martin From: Lindenmaier, Goetz Sent: Montag, 21. Dezember 2020 14:49 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8233164: C2 fails with assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr)) failed: correct memory chain Hi Martin, Looks good and resolve was trivial (I guess ??) Best regards, Goetz. From: Doerr, Martin > Sent: Monday, December 21, 2020 12:52 PM To: 'hotspot-compiler-dev at openjdk.java.net' >; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8233164: C2 fails with assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr)) failed: correct memory chain Hi, JDK-8233164 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change applies almost cleanly. I only had to integrate the following hunk manually due to unrelated context changes: --- arraycopynode.cpp +++ arraycopynode.cpp @@ -574,8 +573,8 @@ Node* src = in(ArrayCopyNode::Src); Node* dest = in(ArrayCopyNode::Dest); - const TypePtr* atp_src = get_address_type(phase, src); - const TypePtr* atp_dest = get_address_type(phase, dest); + const TypePtr* atp_src = get_address_type(phase, _src_type, src); + const TypePtr* atp_dest = get_address_type(phase, _dest_type, dest); Node *in_mem = in(TypeFunc::Memory); if (!in_mem->is_MergeMem()) { Bug: https://bugs.openjdk.java.net/browse/JDK-8233164 Original change: https://hg.openjdk.java.net/jdk/jdk14/rev/be9033a248f7 11u backport: http://cr.openjdk.java.net/~mdoerr/8233164_C2_11u/webrev.00/ Please review. Best regards, Martin From goetz.lindenmaier at sap.com Mon Dec 21 14:16:27 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Dec 2020 14:16:27 +0000 Subject: [11u] RFR: 8254104: MethodCounters must exist before nmethod is installed Message-ID: Hi, I am downporting this for 11.0.10 parity. It did not apply clean. I'll bring it to 11.0.11, i.e. jdk11u-dev. http://cr.openjdk.java.net/~goetz/wr20/8254104-MethodCounters_must_exist-jdk11/01/ I dropped the change to jvmciRuntime.cpp because it is for code that came with "8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library" https://bugs.openjdk.java.net/browse/JDK-8254104 https://git.openjdk.java.net/jdk/commit/4e5ef303 Please review. Best regards, Goetz. From suenaga at oss.nttdata.com Mon Dec 21 14:38:40 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 21 Dec 2020 23:38:40 +0900 Subject: [11u] RFR: 8205992: jhsdb cannot attach to Java processes running in Docker containers In-Reply-To: References: Message-ID: <775cd64f-6af4-f385-64be-44cb31136ade@oss.nttdata.com> Hi Goetz, Thanks for your review! On 2020/12/21 22:30, Lindenmaier, Goetz wrote: > Hi Yasumasa > > First, your please need to use jdk11_u_-fix-request. > The other tag was used in the ramp down of 11 years ago. Sorry, I've fixed the label to jdk11u-fix-request. Yasumasa > Change looks good, it?s a trivial resolve. > > Best regards > Goetz. > > >> -----Original Message----- >> From: jdk-updates-dev On Behalf >> Of Yasumasa Suenaga >> Sent: Friday, December 18, 2020 8:43 AM >> To: jdk-updates-dev at openjdk.java.net >> Subject: [11u] RFR: 8205992: jhsdb cannot attach to Java processes running >> in Docker containers >> >> Hi all, >> >> Please review the backport of JDK-8205992 to 11u: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8205992 >> Original change: http://hg.openjdk.java.net/jdk/jdk/rev/220c9188db4f >> 11u webrev: http://cr.openjdk.java.net/~ysuenaga/JDK- >> 8205992/jdk11/webrev.00/ >> >> Original change cannot apply cleanly due to JDK-8202884. >> The conflict is caused by header file inclusion, the others can be applied >> cleanly. >> >> >> Thanks, >> >> Yasumasa From martin.doerr at sap.com Mon Dec 21 14:43:22 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 14:43:22 +0000 Subject: [11u] RFR: 8254104: MethodCounters must exist before nmethod is installed In-Reply-To: References: Message-ID: Hi G?tz, thanks for backporting. Looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 21. Dezember 2020 15:16 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8254104: MethodCounters must exist before nmethod is > installed > > Hi, > > I am downporting this for 11.0.10 parity. It did not apply clean. > I'll bring it to 11.0.11, i.e. jdk11u-dev. > > http://cr.openjdk.java.net/~goetz/wr20/8254104- > MethodCounters_must_exist-jdk11/01/ > I dropped the change to jvmciRuntime.cpp because it is for code that came > with > "8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled > into shared library" > > https://bugs.openjdk.java.net/browse/JDK-8254104 > https://git.openjdk.java.net/jdk/commit/4e5ef303 > > Please review. > > Best regards, > Goetz. From goetz.lindenmaier at sap.com Mon Dec 21 14:44:14 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Dec 2020 14:44:14 +0000 Subject: [11u] RFR: 8254104: MethodCounters must exist before nmethod is installed In-Reply-To: References: Message-ID: Thanks for the quick review ?? Best Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Monday, December 21, 2020 3:43 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8254104: MethodCounters must exist before > nmethod is installed > > Hi G?tz, > > thanks for backporting. Looks good. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Montag, 21. Dezember 2020 15:16 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8254104: MethodCounters must exist before nmethod > is > > installed > > > > Hi, > > > > I am downporting this for 11.0.10 parity. It did not apply clean. > > I'll bring it to 11.0.11, i.e. jdk11u-dev. > > > > http://cr.openjdk.java.net/~goetz/wr20/8254104- > > MethodCounters_must_exist-jdk11/01/ > > I dropped the change to jvmciRuntime.cpp because it is for code that came > > with > > "8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler > compiled > > into shared library" > > > > https://bugs.openjdk.java.net/browse/JDK-8254104 > > https://git.openjdk.java.net/jdk/commit/4e5ef303 > > > > Please review. > > > > Best regards, > > Goetz. From jaroslav.bachorik at datadoghq.com Mon Dec 21 15:22:59 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 21 Dec 2020 16:22:59 +0100 Subject: [11u] RFR: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default) In-Reply-To: References: Message-ID: Greetings, The original attempt to generate webrev from two changesets failed miserably. Therefore I am updating the webrev links as follows: * Main issue: http://cr.openjdk.java.net/~jbachorik/8257602/jdk11/00/webrev/ * Followup AIX build fix: https://cr.openjdk.java.net/~jbachorik/8258094/jdk11/00/webrev/ Regards, -JB- On Tue, Dec 15, 2020 at 9:21 AM Jaroslav Bachor?k wrote: > > Greetings, > > I would like to ask for review of this JDK11u backport patch: > > Issue : https://bugs.openjdk.java.net/browse/JDK-8257602 > Webrev: http://cr.openjdk.java.net/~jbachorik/8257602/jdk11/00/webrev/ > > The webrev contains the main change backported from JDK-8257602 and > the followup patch for AIX build failure resolved as JDK-8258094. I > decided to roll both changesets into one webrev to get a fully > buildable system once this backport request is approved. > > The original changeset of JDK-8257602 had to be slightly adjusted for > the following: > * hunk offsets not matching because of larger structural changes > resolution: the appropriate code was inserted manually > * missing Atomic::load_acquire and Atomic::release_store functions > resolution: used OrderAccess::* equivalents > * different argument order for Atomic::cmpxchg and Atomic::store > resolution: modified the call-site argument order to match what is > provided by Atomic::* > * [test] missing support for event streaming > resolution: used the recording in non-streaming mode while keeping > the test semantics > > All tier1, tier2 and jdk_jfr tests are passing with the changes applied. > > Cheers, > > -JB- From hohensee at amazon.com Mon Dec 21 15:34:04 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 21 Dec 2020 15:34:04 +0000 Subject: [11u] RFR: 8222518: Remove unnecessary caching of Parker object in java.lang.Thread In-Reply-To: <0B57272A-5A4A-4832-A7AA-8474B5208EF6@amazon.com> References: <0B57272A-5A4A-4832-A7AA-8474B5208EF6@amazon.com> Message-ID: Passes tier1 as well as before the patch. We do, however, have 3 tier1 langtools failures independent of this patch. jdk/javadoc/doclet/testGeneratedBy/TestGeneratedBy.java: Verify that files use a common Generated By string jdk/javadoc/doclet/testVersionOption/TestVersionOption.java: javadoc should support --version and --full-version flags tools/javac/VersionOpt.java: tools/javac/versionOpt.sh fails on OpenJDK builds Test checks the version strings displayed by javac, using strings that come out of the Java runtime. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Sunday, December 20, 2020 at 10:18 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR: 8222518: Remove unnecessary caching of Parker object in java.lang.Thread Please review this small code deletion and footprint reduction backport. JBS: https://bugs.openjdk.java.net/browse/JDK-8222518 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/9ebb614d293d Webrev: http://cr.openjdk.java.net/~phh/8222518/webrev.11u.00/ The backport is not clean because (1) javaClasses.cpp needed a copyright date update to 2019 and the original 3rd hunk that deletes park_event() and set_park_event() contained slightly different code that does not check for non-existent Thread fields, and (2) unsafe.cpp needed a copyright update to 2019. Thanks, Paul From evergizova at openjdk.java.net Mon Dec 21 16:40:01 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Mon, 21 Dec 2020 16:40:01 GMT Subject: [jdk13u-dev] RFR: 8252090: JFR: StreamWriterHost::write_unbuffered() stucks in an infinite loop OpenJDK (build 13.0.1+9) Message-ID: <5RXx4J62W68uksMNQZqvtyncwnUO7Un-suTW_hwtFg8=.011e61f5-ca9f-4fbc-af80-6cc4d640b402@github.com> I'd like to backport 8252090 to 13u for parity with 11u. The patch doesn't apply cleanly due to multiple context differences in jfrChunkWriter.cpp, reapplied manually. Additionally 13u doesn't have JfrChunkHeadWriter::write_magic() method (JDK-8226511 is not in 13u), the corresponding changes are applied to JfrChunkWriter::open(). Tested with tier1 and jdk/jfr. ------------- Commit messages: - Backport 9924c45faebdba4084c9a5dd5b415dfe6c979024 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/66/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=66&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252090 Stats: 58 lines in 10 files changed: 22 ins; 4 del; 32 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/66.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/66/head:pull/66 PR: https://git.openjdk.java.net/jdk13u-dev/pull/66 From martin.doerr at sap.com Mon Dec 21 16:52:04 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 16:52:04 +0000 Subject: [11u] RFR: 8248901: Signed immediate support in .../share/assembler.hpp is broken.memory chain Message-ID: Hi, JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change applies cleanly, but precond macro is missing in 11u. I've taken it from JDK-8223140 (http://hg.openjdk.java.net/jdk/jdk/rev/6b77693eda6a). Bug: https://bugs.openjdk.java.net/browse/JDK-8248901 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/ce8fb40c9174 Clean 11u backport with added precond and postcond macros: http://cr.openjdk.java.net/~mdoerr/8248901_assembler_11u/webrev.00/ Please review. Best regards, Martin From dcherepanov at openjdk.java.net Mon Dec 21 17:00:55 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Mon, 21 Dec 2020 17:00:55 GMT Subject: [jdk13u-dev] RFR: 8252090: JFR: StreamWriterHost::write_unbuffered() stucks in an infinite loop OpenJDK (build 13.0.1+9) In-Reply-To: <5RXx4J62W68uksMNQZqvtyncwnUO7Un-suTW_hwtFg8=.011e61f5-ca9f-4fbc-af80-6cc4d640b402@github.com> References: <5RXx4J62W68uksMNQZqvtyncwnUO7Un-suTW_hwtFg8=.011e61f5-ca9f-4fbc-af80-6cc4d640b402@github.com> Message-ID: <6fdym4aWUyjctCfYLOR8LBIpTPLtO7wHXfa4BfVrjB8=.7b13cb56-a692-4925-b937-b7c98fc49b8f@github.com> On Mon, 21 Dec 2020 16:35:15 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8252090 to 13u for parity with 11u. > The patch doesn't apply cleanly due to multiple context differences in jfrChunkWriter.cpp, reapplied manually. > Additionally 13u doesn't have JfrChunkHeadWriter::write_magic() method (JDK-8226511 is not in 13u), the corresponding changes are applied to JfrChunkWriter::open(). > Tested with tier1 and jdk/jfr. Marked as reviewed by dcherepanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/66 From evergizova at openjdk.java.net Mon Dec 21 17:25:54 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Mon, 21 Dec 2020 17:25:54 GMT Subject: [jdk13u-dev] Integrated: 8252090: JFR: StreamWriterHost::write_unbuffered() stucks in an infinite loop OpenJDK (build 13.0.1+9) In-Reply-To: <5RXx4J62W68uksMNQZqvtyncwnUO7Un-suTW_hwtFg8=.011e61f5-ca9f-4fbc-af80-6cc4d640b402@github.com> References: <5RXx4J62W68uksMNQZqvtyncwnUO7Un-suTW_hwtFg8=.011e61f5-ca9f-4fbc-af80-6cc4d640b402@github.com> Message-ID: On Mon, 21 Dec 2020 16:35:15 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8252090 to 13u for parity with 11u. > The patch doesn't apply cleanly due to multiple context differences in jfrChunkWriter.cpp, reapplied manually. > Additionally 13u doesn't have JfrChunkHeadWriter::write_magic() method (JDK-8226511 is not in 13u), the corresponding changes are applied to JfrChunkWriter::open(). > Tested with tier1 and jdk/jfr. This pull request has now been integrated. Changeset: ead24ad7 Author: Ekaterina Vergizova Committer: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/ead24ad7 Stats: 58 lines in 10 files changed: 22 ins; 4 del; 32 mod 8252090: JFR: StreamWriterHost::write_unbuffered() stucks in an infinite loop OpenJDK (build 13.0.1+9) Reviewed-by: dcherepanov Backport-of: 9924c45faebdba4084c9a5dd5b415dfe6c979024 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/66 From hohensee at amazon.com Mon Dec 21 17:29:00 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 21 Dec 2020 17:29:00 +0000 Subject: [11u] RFR: 8248901: Signed immediate support in .../share/assembler.hpp is broken.memory chain Message-ID: <85B150E5-4134-4B31-A4F2-6F7CDB9922CC@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Doerr, Martin" Date: Monday, December 21, 2020 at 8:52 AM To: "'hotspot-compiler-dev at openjdk.java.net'" , "jdk-updates-dev at openjdk.java.net" Cc: "Langer, Christoph" , "Lindenmaier, Goetz" Subject: [11u] RFR: 8248901: Signed immediate support in .../share/assembler.hpp is broken.memory chain Hi, JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change applies cleanly, but precond macro is missing in 11u. I've taken it from JDK-8223140 (http://hg.openjdk.java.net/jdk/jdk/rev/6b77693eda6a). Bug: https://bugs.openjdk.java.net/browse/JDK-8248901 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/ce8fb40c9174 Clean 11u backport with added precond and postcond macros: http://cr.openjdk.java.net/~mdoerr/8248901_assembler_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Mon Dec 21 17:32:15 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 17:32:15 +0000 Subject: [11u] RFR: 8248901: Signed immediate support in .../share/assembler.hpp is broken.memory chain In-Reply-To: <85B150E5-4134-4B31-A4F2-6F7CDB9922CC@amazon.com> References: <85B150E5-4134-4B31-A4F2-6F7CDB9922CC@amazon.com> Message-ID: Hi Paul, thanks for the review! I'll have to backport it together with JDK-8247766 which doesn't apply cleanly in order to avoid breaking aarch64. Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Montag, 21. Dezember 2020 18:29 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net > Cc: Langer, Christoph ; Lindenmaier, Goetz > > Subject: RE: [11u] RFR: 8248901: Signed immediate support in > .../share/assembler.hpp is broken.memory chain > > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of "Doerr, Martin" > Date: Monday, December 21, 2020 at 8:52 AM > To: "'hotspot-compiler-dev at openjdk.java.net'" dev at openjdk.java.net>, "jdk-updates-dev at openjdk.java.net" updates-dev at openjdk.java.net> > Cc: "Langer, Christoph" , "Lindenmaier, Goetz" > > Subject: [11u] RFR: 8248901: Signed immediate support in > .../share/assembler.hpp is broken.memory chain > > Hi, > > JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for parity. > Change applies cleanly, but precond macro is missing in 11u. I've taken it from > JDK-8223140 (http://hg.openjdk.java.net/jdk/jdk/rev/6b77693eda6a). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8248901 > > Original change: > https://hg.openjdk.java.net/jdk/jdk/rev/ce8fb40c9174 > > Clean 11u backport with added precond and postcond macros: > http://cr.openjdk.java.net/~mdoerr/8248901_assembler_11u/webrev.00/ > > Please review. > > Best regards, > Martin > From martin.doerr at sap.com Mon Dec 21 20:53:52 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Dec 2020 20:53:52 +0000 Subject: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module Message-ID: Hi, JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change applies cleanly, but 11u needs minor adaptation: - Keep "import java.util.Iterator;" in Module.java. - "toModuleInfo" has one argument less in 11u, so pass one "null" less. Bug: https://bugs.openjdk.java.net/browse/JDK-8241770 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/493e7c5a7c30 11u backport: http://cr.openjdk.java.net/~mdoerr/8241770_module_11u/webrev.00/ Manual change in detail: diff -r d85e41e89ed5 src/java.base/share/classes/java/lang/Module.java --- a/src/java.base/share/classes/java/lang/Module.java Thu Jun 11 07:27:22 2020 +0100 +++ b/src/java.base/share/classes/java/lang/Module.java Mon Dec 21 21:23:47 2020 +0100 @@ -42,6 +42,7 @@ import java.security.PrivilegedAction; import java.util.HashMap; import java.util.HashSet; +import java.util.Iterator; import java.util.List; import java.util.Map; import java.util.Objects; diff -r d85e41e89ed5 src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java --- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Thu Jun 11 07:27:22 2020 +0100 +++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Mon Dec 21 21:23:47 2020 +0100 @@ -184,7 +184,7 @@ * module-info.class format. */ public static byte[] toBytes(ModuleDescriptor descriptor) { - return toModuleInfo(descriptor, null, null); + return toModuleInfo(descriptor, null); } /** Please review. Best regards, Martin 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 github.com+75672469+larry-n at openjdk.java.net Tue Dec 22 11:11:14 2020 From: github.com+75672469+larry-n at openjdk.java.net (Larry-N) Date: Tue, 22 Dec 2020 11:11:14 GMT Subject: [jdk13u-dev] RFR: 8236859: WebSocket over authenticating proxy fails with NPE Message-ID: Backport fix for bug 8236859 + small correction cache.store() calling because of method signature difference from 16 to 13 jdk. File: AuthenticationFilter.java ------------- Commit messages: - Backport c6da6681d418928c65cff6b1240e6b5d6bc5199b Changes: https://git.openjdk.java.net/jdk13u-dev/pull/53/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=53&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236859 Stats: 948 lines in 12 files changed: 909 ins; 5 del; 34 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/53.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/53/head:pull/53 PR: https://git.openjdk.java.net/jdk13u-dev/pull/53 From robilad at openjdk.java.net Tue Dec 22 11:11:14 2020 From: robilad at openjdk.java.net (Dalibor Topic) Date: Tue, 22 Dec 2020 11:11:14 GMT Subject: [jdk13u-dev] RFR: 8236859: WebSocket over authenticating proxy fails with NPE In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 11:03:00 GMT, Larry-N wrote: > Backport fix for bug 8236859 > + small correction cache.store() calling because of method signature difference from 16 to 13 jdk. > File: AuthenticationFilter.java Hi, Please send me an email to dalibor.topic at oracle.com so that I can verify your account. ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/53 From richard.reingruber at sap.com Tue Dec 22 11:12:56 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 22 Dec 2020 11:12:56 +0000 Subject: [11u] RFR 8240795: [REDO] 8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found" Message-ID: Hi, I would like to downport JDK-8240795 to 11u as prerequisite for the downport of JDK-8243670. I need to be sponsored for this too, please. Please review: Original bug: https://bugs.openjdk.java.net/browse/JDK-8240795 https://hg.openjdk.java.net/jdk/jdk/rev/993974f21271 11u webrev: http://cr.openjdk.java.net/~rrich/webrevs/8240795_11u_REDO__8238384_CTW__C2_compilation_fails_with__assert_dependence_cycle_found/webrev.0/ Modifications: The 2 hunks for loopnode.cpp were removed from the original patch. They do not apply because they are based on the enhancement 8238691 which has not been downported. These hunks introduced a bug which was fixed with 8252292. I don't intend to downport 8252292 but I have verified that the included test case succeeds even without it. Testing: test/hotspot/jtreg/compiler/escapeAnalysis/TestMissingAntiDependency.java - from 8252292 - succeeds independently of the patch under review - will not be downported test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDependency.java - included in the patch under review - fails without patch (assertion "dependence cycle found") - succeeds with patch CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. From goetz.lindenmaier at sap.com Tue Dec 22 12:01:32 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Dec 2020 12:01:32 +0000 Subject: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module In-Reply-To: References: Message-ID: Hi Martin, The change looks good. The additional argument is only used for an optional printout of platform information, so not relevant for this fix - besides that it is null anyways. Best regards, Goetz. From: Doerr, Martin Sent: Monday, December 21, 2020 9:54 PM To: core-libs-dev ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module Hi, JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change applies cleanly, but 11u needs minor adaptation: - Keep "import java.util.Iterator;" in Module.java. - "toModuleInfo" has one argument less in 11u, so pass one "null" less. Bug: https://bugs.openjdk.java.net/browse/JDK-8241770 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/493e7c5a7c30 11u backport: http://cr.openjdk.java.net/~mdoerr/8241770_module_11u/webrev.00/ Manual change in detail: diff -r d85e41e89ed5 src/java.base/share/classes/java/lang/Module.java --- a/src/java.base/share/classes/java/lang/Module.java Thu Jun 11 07:27:22 2020 +0100 +++ b/src/java.base/share/classes/java/lang/Module.java Mon Dec 21 21:23:47 2020 +0100 @@ -42,6 +42,7 @@ import java.security.PrivilegedAction; import java.util.HashMap; import java.util.HashSet; +import java.util.Iterator; import java.util.List; import java.util.Map; import java.util.Objects; diff -r d85e41e89ed5 src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java --- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Thu Jun 11 07:27:22 2020 +0100 +++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Mon Dec 21 21:23:47 2020 +0100 @@ -184,7 +184,7 @@ * module-info.class format. */ public static byte[] toBytes(ModuleDescriptor descriptor) { - return toModuleInfo(descriptor, null, null); + return toModuleInfo(descriptor, null); } /** Please review. Best regards, Martin From goetz.lindenmaier at sap.com Tue Dec 22 12:04:32 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Dec 2020 12:04:32 +0000 Subject: [11u] RFR: 8241911: AArch64: Fix a potential issue about register allocation effect rule in reduce_add2I In-Reply-To: References: Message-ID: Hi Martin, Change looks good. The rules that are missing in 11 came with "JDK-8214922: Aarch64: Add vectorization support for fmin/fmax" Which was pushed to 13 and not downported. So skipping the format changes is fine. Best regards, Goetz. From: Doerr, Martin Sent: Monday, December 21, 2020 2:48 PM To: 'hotspot-compiler-dev at openjdk.java.net' ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: RE: [11u] RFR: 8241911: AArch64: Fix a potential issue about register allocation effect rule in reduce_add2I Hi, JDK- 8241911 is backported to 11.0.11-oracle. I'd like to backport it for parity. The actual fix applies cleanly, but the change contains additional format changes which don't (see below) and which we can skip. Bug: https://bugs.openjdk.java.net/browse/JDK-8241911 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/4b76f0cc11c4 11u backport: http://cr.openjdk.java.net/~mdoerr/8241911_aarch64_11u/webrev.00/ Please review. Best regards, Martin --- aarch64.ad +++ aarch64.ad @@ -16265,7 +16265,7 @@ effect(TEMP_DEF dst, TEMP tmp); format %{ "fmaxs $dst, $src1, $src2\n\t" "ins $tmp, S, $src2, 0, 1\n\t" - "fmaxs $dst, $dst, $tmp\t max reduction2F" %} + "fmaxs $dst, $dst, $tmp\t# max reduction2F" %} ins_encode %{ __ fmaxs(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg), as_FloatRegister($src2$$reg)); __ ins(as_FloatRegister($tmp$$reg), __ S, as_FloatRegister($src2$$reg), 0, 1); @@ -16280,7 +16280,7 @@ ins_cost(INSN_COST); effect(TEMP_DEF dst); format %{ "fmaxv $dst, T4S, $src2\n\t" - "fmaxs $dst, $dst, $src1\t max reduction4F" %} + "fmaxs $dst, $dst, $src1\t# max reduction4F" %} ins_encode %{ __ fmaxv(as_FloatRegister($dst$$reg), __ T4S, as_FloatRegister($src2$$reg)); __ fmaxs(as_FloatRegister($dst$$reg), as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg)); @@ -16295,7 +16295,7 @@ effect(TEMP_DEF dst, TEMP tmp); format %{ "fmaxd $dst, $src1, $src2\n\t" "ins $tmp, D, $src2, 0, 1\n\t" - "fmaxd $dst, $dst, $tmp\t max reduction2D" %} + "fmaxd $dst, $dst, $tmp\t# max reduction2D" %} ins_encode %{ __ fmaxd(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg), as_FloatRegister($src2$$reg)); __ ins(as_FloatRegister($tmp$$reg), __ D, as_FloatRegister($src2$$reg), 0, 1); @@ -16311,7 +16311,7 @@ effect(TEMP_DEF dst, TEMP tmp); format %{ "fmins $dst, $src1, $src2\n\t" "ins $tmp, S, $src2, 0, 1\n\t" - "fmins $dst, $dst, $tmp\t min reduction2F" %} + "fmins $dst, $dst, $tmp\t# min reduction2F" %} ins_encode %{ __ fmins(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg), as_FloatRegister($src2$$reg)); __ ins(as_FloatRegister($tmp$$reg), __ S, as_FloatRegister($src2$$reg), 0, 1); @@ -16326,7 +16326,7 @@ ins_cost(INSN_COST); effect(TEMP_DEF dst); format %{ "fminv $dst, T4S, $src2\n\t" - "fmins $dst, $dst, $src1\t min reduction4F" %} + "fmins $dst, $dst, $src1\t# min reduction4F" %} ins_encode %{ __ fminv(as_FloatRegister($dst$$reg), __ T4S, as_FloatRegister($src2$$reg)); __ fmins(as_FloatRegister($dst$$reg), as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg)); @@ -16341,7 +16341,7 @@ effect(TEMP_DEF dst, TEMP tmp); format %{ "fmind $dst, $src1, $src2\n\t" "ins $tmp, D, $src2, 0, 1\n\t" - "fmind $dst, $dst, $tmp\t min reduction2D" %} + "fmind $dst, $dst, $tmp\t# min reduction2D" %} ins_encode %{ __ fmind(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg), as_FloatRegister($src2$$reg)); __ ins(as_FloatRegister($tmp$$reg), __ D, as_FloatRegister($src2$$reg), 0, 1); From goetz.lindenmaier at sap.com Tue Dec 22 12:26:05 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Dec 2020 12:26:05 +0000 Subject: [11u] RFR 8240795: [REDO] 8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found" In-Reply-To: References: Message-ID: Hi Richard, I had a look at this change. I assume you need it because the follow up calls is_known_instance(). The change looks good. "JDK-8238691: C2: turn subtype check into macro node" is not really a candidate for downport. Else I would fear the omitted chunk gets forgotten once that change is downported, as this bug will be marked as ported to 11. A solution would be a JBS issue of its own like "Bring parts of 8240795 to 11." But not really necessary here. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Reingruber, Richard > Sent: Tuesday, December 22, 2020 12:13 PM > To: jdk-updates-dev at openjdk.java.net; hotspot-compiler- > dev at openjdk.java.net > Subject: [11u] RFR 8240795: [REDO] 8238384 CTW: C2 compilation fails with > "assert(store != load->find_exact_control(load->in(0))) failed: dependence > cycle found" > > Hi, > > I would like to downport JDK-8240795 to 11u as prerequisite for the > downport of > JDK-8243670. > > I need to be sponsored for this too, please. > > Please review: > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8240795 > https://hg.openjdk.java.net/jdk/jdk/rev/993974f21271 > > 11u webrev: > > http://cr.openjdk.java.net/~rrich/webrevs/8240795_11u_REDO__8238384_ > CTW__C2_compilation_fails_with__assert_dependence_cycle_found/webre > v.0/ > > Modifications: > > The 2 hunks for loopnode.cpp were removed from the original patch. They > do not > apply because they are based on the enhancement 8238691 which has not > been > downported. These hunks introduced a bug which was fixed with 8252292. I > don't > intend to downport 8252292 but I have verified that the included test case > succeeds even without it. > > Testing: > > test/hotspot/jtreg/compiler/escapeAnalysis/TestMissingAntiDependency.jav > a > - from 8252292 > - succeeds independently of the patch under review > - will not be downported > > test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDepende > ncy.java > - included in the patch under review > - fails without patch (assertion "dependence cycle found") > - succeeds with patch > > > CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, > SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms > > Thanks, Richard. From martin.doerr at sap.com Tue Dec 22 13:12:06 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 22 Dec 2020 13:12:06 +0000 Subject: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Best regards, Martin From: Lindenmaier, Goetz Sent: Dienstag, 22. Dezember 2020 13:02 To: Doerr, Martin ; core-libs-dev ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module Hi Martin, The change looks good. The additional argument is only used for an optional printout of platform information, so not relevant for this fix - besides that it is null anyways. Best regards, Goetz. From: Doerr, Martin > Sent: Monday, December 21, 2020 9:54 PM To: core-libs-dev >; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module Hi, JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change applies cleanly, but 11u needs minor adaptation: - Keep "import java.util.Iterator;" in Module.java. - "toModuleInfo" has one argument less in 11u, so pass one "null" less. Bug: https://bugs.openjdk.java.net/browse/JDK-8241770 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/493e7c5a7c30 11u backport: http://cr.openjdk.java.net/~mdoerr/8241770_module_11u/webrev.00/ Manual change in detail: diff -r d85e41e89ed5 src/java.base/share/classes/java/lang/Module.java --- a/src/java.base/share/classes/java/lang/Module.java Thu Jun 11 07:27:22 2020 +0100 +++ b/src/java.base/share/classes/java/lang/Module.java Mon Dec 21 21:23:47 2020 +0100 @@ -42,6 +42,7 @@ import java.security.PrivilegedAction; import java.util.HashMap; import java.util.HashSet; +import java.util.Iterator; import java.util.List; import java.util.Map; import java.util.Objects; diff -r d85e41e89ed5 src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java --- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Thu Jun 11 07:27:22 2020 +0100 +++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Mon Dec 21 21:23:47 2020 +0100 @@ -184,7 +184,7 @@ * module-info.class format. */ public static byte[] toBytes(ModuleDescriptor descriptor) { - return toModuleInfo(descriptor, null, null); + return toModuleInfo(descriptor, null); } /** Please review. Best regards, Martin From martin.doerr at sap.com Tue Dec 22 13:12:24 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 22 Dec 2020 13:12:24 +0000 Subject: [11u] RFR: 8241911: AArch64: Fix a potential issue about register allocation effect rule in reduce_add2I In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Best regards, Martin From: Lindenmaier, Goetz Sent: Dienstag, 22. Dezember 2020 13:05 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8241911: AArch64: Fix a potential issue about register allocation effect rule in reduce_add2I Hi Martin, Change looks good. The rules that are missing in 11 came with "JDK-8214922: Aarch64: Add vectorization support for fmin/fmax" Which was pushed to 13 and not downported. So skipping the format changes is fine. Best regards, Goetz. From: Doerr, Martin > Sent: Monday, December 21, 2020 2:48 PM To: 'hotspot-compiler-dev at openjdk.java.net' >; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8241911: AArch64: Fix a potential issue about register allocation effect rule in reduce_add2I Hi, JDK- 8241911 is backported to 11.0.11-oracle. I'd like to backport it for parity. The actual fix applies cleanly, but the change contains additional format changes which don't (see below) and which we can skip. Bug: https://bugs.openjdk.java.net/browse/JDK-8241911 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/4b76f0cc11c4 11u backport: http://cr.openjdk.java.net/~mdoerr/8241911_aarch64_11u/webrev.00/ Please review. Best regards, Martin --- aarch64.ad +++ aarch64.ad @@ -16265,7 +16265,7 @@ effect(TEMP_DEF dst, TEMP tmp); format %{ "fmaxs $dst, $src1, $src2\n\t" "ins $tmp, S, $src2, 0, 1\n\t" - "fmaxs $dst, $dst, $tmp\t max reduction2F" %} + "fmaxs $dst, $dst, $tmp\t# max reduction2F" %} ins_encode %{ __ fmaxs(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg), as_FloatRegister($src2$$reg)); __ ins(as_FloatRegister($tmp$$reg), __ S, as_FloatRegister($src2$$reg), 0, 1); @@ -16280,7 +16280,7 @@ ins_cost(INSN_COST); effect(TEMP_DEF dst); format %{ "fmaxv $dst, T4S, $src2\n\t" - "fmaxs $dst, $dst, $src1\t max reduction4F" %} + "fmaxs $dst, $dst, $src1\t# max reduction4F" %} ins_encode %{ __ fmaxv(as_FloatRegister($dst$$reg), __ T4S, as_FloatRegister($src2$$reg)); __ fmaxs(as_FloatRegister($dst$$reg), as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg)); @@ -16295,7 +16295,7 @@ effect(TEMP_DEF dst, TEMP tmp); format %{ "fmaxd $dst, $src1, $src2\n\t" "ins $tmp, D, $src2, 0, 1\n\t" - "fmaxd $dst, $dst, $tmp\t max reduction2D" %} + "fmaxd $dst, $dst, $tmp\t# max reduction2D" %} ins_encode %{ __ fmaxd(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg), as_FloatRegister($src2$$reg)); __ ins(as_FloatRegister($tmp$$reg), __ D, as_FloatRegister($src2$$reg), 0, 1); @@ -16311,7 +16311,7 @@ effect(TEMP_DEF dst, TEMP tmp); format %{ "fmins $dst, $src1, $src2\n\t" "ins $tmp, S, $src2, 0, 1\n\t" - "fmins $dst, $dst, $tmp\t min reduction2F" %} + "fmins $dst, $dst, $tmp\t# min reduction2F" %} ins_encode %{ __ fmins(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg), as_FloatRegister($src2$$reg)); __ ins(as_FloatRegister($tmp$$reg), __ S, as_FloatRegister($src2$$reg), 0, 1); @@ -16326,7 +16326,7 @@ ins_cost(INSN_COST); effect(TEMP_DEF dst); format %{ "fminv $dst, T4S, $src2\n\t" - "fmins $dst, $dst, $src1\t min reduction4F" %} + "fmins $dst, $dst, $src1\t# min reduction4F" %} ins_encode %{ __ fminv(as_FloatRegister($dst$$reg), __ T4S, as_FloatRegister($src2$$reg)); __ fmins(as_FloatRegister($dst$$reg), as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg)); @@ -16341,7 +16341,7 @@ effect(TEMP_DEF dst, TEMP tmp); format %{ "fmind $dst, $src1, $src2\n\t" "ins $tmp, D, $src2, 0, 1\n\t" - "fmind $dst, $dst, $tmp\t min reduction2D" %} + "fmind $dst, $dst, $tmp\t# min reduction2D" %} ins_encode %{ __ fmind(as_FloatRegister($dst$$reg), as_FloatRegister($src1$$reg), as_FloatRegister($src2$$reg)); __ ins(as_FloatRegister($tmp$$reg), __ D, as_FloatRegister($src2$$reg), 0, 1); From omikhaltcova at openjdk.java.net Tue Dec 22 14:03:59 2020 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Tue, 22 Dec 2020 14:03:59 GMT Subject: [jdk13u-dev] Integrated: 8239000: handle ContendedPaddingWidth in vm_version_ppc In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 09:49:17 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8239000 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested with tier1, tier2, tier3. No regression in tests. This pull request has now been integrated. Changeset: 164abd40 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/164abd40 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod 8239000: handle ContendedPaddingWidth in vm_version_ppc Backport-of: cf4291db370bb0bfaa7c8354308886315e1c3901 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/61 From dcherepanov at openjdk.java.net Tue Dec 22 14:30:59 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Tue, 22 Dec 2020 14:30:59 GMT Subject: [jdk13u-dev] RFR: 8255603: Memory/Performance regression after JDK-8210985 Message-ID: Request to backport 8255603 to 13u. The patch applies cleanly. Tested with jdk_security test group. ------------- Commit messages: - Backport 64feeab70af61a52ffe4c64df87a33c16754de18 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/67/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=67&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255603 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/67.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/67/head:pull/67 PR: https://git.openjdk.java.net/jdk13u-dev/pull/67 From dcherepanov at openjdk.java.net Tue Dec 22 14:39:05 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Tue, 22 Dec 2020 14:39:05 GMT Subject: [jdk13u-dev] Integrated: 8255603: Memory/Performance regression after JDK-8210985 In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 14:25:02 GMT, Dmitry Cherepanov wrote: > Request to backport 8255603 to 13u. The patch applies cleanly. > Tested with jdk_security test group. This pull request has now been integrated. Changeset: 9db11218 Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/9db11218 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8255603: Memory/Performance regression after JDK-8210985 Backport-of: 64feeab70af61a52ffe4c64df87a33c16754de18 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/67 From richard.reingruber at sap.com Tue Dec 22 17:37:09 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 22 Dec 2020 17:37:09 +0000 Subject: [11u] RFR 8240795: [REDO] 8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found" In-Reply-To: References: Message-ID: Hi G?tz, > I had a look at this change. Thanks! > I assume you need it because the follow up calls is_known_instance(). Correct. > The change looks good. Thanks. > "JDK-8238691: C2: turn subtype check into macro node" is not really > a candidate for downport. Else I would fear the omitted chunk gets > forgotten once that change is downported, as this bug will be marked as > ported to 11. A solution would be a JBS issue of its own like "Bring parts > of 8240795 to 11." But not really necessary here. I agree. I'll be off-line now. Let's continue this if you don't mind when I'm back (likely Jan. 4). Cheers, Richard. -----Original Message----- From: Lindenmaier, Goetz Sent: Dienstag, 22. Dezember 2020 13:26 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Subject: RE: [11u] RFR 8240795: [REDO] 8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found" Hi Richard, I had a look at this change. I assume you need it because the follow up calls is_known_instance(). The change looks good. "JDK-8238691: C2: turn subtype check into macro node" is not really a candidate for downport. Else I would fear the omitted chunk gets forgotten once that change is downported, as this bug will be marked as ported to 11. A solution would be a JBS issue of its own like "Bring parts of 8240795 to 11." But not really necessary here. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Reingruber, Richard > Sent: Tuesday, December 22, 2020 12:13 PM > To: jdk-updates-dev at openjdk.java.net; hotspot-compiler- > dev at openjdk.java.net > Subject: [11u] RFR 8240795: [REDO] 8238384 CTW: C2 compilation fails with > "assert(store != load->find_exact_control(load->in(0))) failed: dependence > cycle found" > > Hi, > > I would like to downport JDK-8240795 to 11u as prerequisite for the > downport of > JDK-8243670. > > I need to be sponsored for this too, please. > > Please review: > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8240795 > https://hg.openjdk.java.net/jdk/jdk/rev/993974f21271 > > 11u webrev: > > http://cr.openjdk.java.net/~rrich/webrevs/8240795_11u_REDO__8238384_ > CTW__C2_compilation_fails_with__assert_dependence_cycle_found/webre > v.0/ > > Modifications: > > The 2 hunks for loopnode.cpp were removed from the original patch. They > do not > apply because they are based on the enhancement 8238691 which has not > been > downported. These hunks introduced a bug which was fixed with 8252292. I > don't > intend to downport 8252292 but I have verified that the included test case > succeeds even without it. > > Testing: > > test/hotspot/jtreg/compiler/escapeAnalysis/TestMissingAntiDependency.jav > a > - from 8252292 > - succeeds independently of the patch under review > - will not be downported > > test/hotspot/jtreg/compiler/escapeAnalysis/TestCopyOfBrokenAntiDepende > ncy.java > - included in the patch under review > - fails without patch (assertion "dependence cycle found") > - succeeds with patch > > > CI testing @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, > SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms > > Thanks, Richard. From evergizova at openjdk.java.net Tue Dec 22 19:31:06 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 22 Dec 2020 19:31:06 GMT Subject: [jdk13u-dev] RFR: 8254854: [cgroups v1] Metric limits not properly detected on some join controller combinations Message-ID: I'd like to backport 8254854 to 13u for parity with 11u. The patch doesn't apply cleanly since 13u doesn't have cgroups v2 support (JDK-8231111), so it reapplied manually to Metrics::setSubSystemPath() method instead of CgroupV1Subsystem::setSubSystemControllerPath() from the original patch. Tested with tier1 and container tests. ------------- Commit messages: - Backport a0b687bfb279761b79d3fbad8f9dfae9b12c225e Changes: https://git.openjdk.java.net/jdk13u-dev/pull/68/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=68&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254854 Stats: 36 lines in 1 file changed: 2 ins; 11 del; 23 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/68.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/68/head:pull/68 PR: https://git.openjdk.java.net/jdk13u-dev/pull/68 From akashche at redhat.com Tue Dec 22 21:17:35 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 22 Dec 2020 21:17:35 +0000 Subject: [11u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources In-Reply-To: References: Message-ID: On 12/15/20, Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8256818 to 11u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8256818 > > Original change: https://github.com/openjdk/jdk/commit/93b6ab56 > > 11u webrev: https://cr.openjdk.java.net/~akasko/jdk11u/8256818/webrev.00/ > > Patch depends on JDK-8240704 [1], that applies cleanly and is on approval. > > Patch doesn't apply cleanly: FileUtils.java in 11u doesn't contain > recent changes from mainline and needed adjustments; libFileUtils.c > cannot be placed into test/lib/ because 11u doesn't have JDK-8248667 > [2], it is placed under test/jdk/native_util/ instead. Testing: > checked that changed tests pass on Linux and Windows, ran > jtreg:jdk/sun/security/ssl/ and jck:api/javax_net/ssl . > > I also intend to backport subsequent updates to SSLSocketLeak.java > from mainline. > > > [1] https://bugs.openjdk.java.net/browse/JDK-8240704 > [2] https://bugs.openjdk.java.net/browse/JDK-8248667 JDK-8240704 was integrated, updated the webrev as a committed one on top of current 11u-dev (patch itself is the same): https://cr.openjdk.java.net/~akasko/jdk11u/8256818/webrev.01/ Note, the problem with leaking file descriptors in not present in current 11u-dev - in current version closeSocket() is indeed not called when socket was not connected, but (unlike the mainline jdk) FD is not open at this point. The problem may appear soon, when more TLSv1.3-related changes are backported, so it is proposed to have this patch added to 11 to anticipate that. -- -Alex From christoph.langer at sap.com Tue Dec 22 23:14:52 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Dec 2020 23:14:52 +0000 Subject: [11u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources In-Reply-To: References: Message-ID: Hi Alex, thanks for doing this backport. It looks good to me. As you mention, it should be pushed together with these follow up items which are all part of 11.0.11-oracle as well: https://bugs.openjdk.java.net/browse/JDK-8257670 https://bugs.openjdk.java.net/browse/JDK-8257884 https://bugs.openjdk.java.net/browse/JDK-8257997 Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Alex Kashchenko > Sent: Dienstag, 22. Dezember 2020 22:18 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8256818: SSLSocket that is never bound or connected > leaks socket resources > > On 12/15/20, Alex Kashchenko wrote: > > Hi, > > > > Please review the backport of JDK-8256818 to 11u: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8256818 > > > > Original change: https://github.com/openjdk/jdk/commit/93b6ab56 > > > > 11u webrev: > https://cr.openjdk.java.net/~akasko/jdk11u/8256818/webrev.00/ > > > > Patch depends on JDK-8240704 [1], that applies cleanly and is on approval. > > > > Patch doesn't apply cleanly: FileUtils.java in 11u doesn't contain > > recent changes from mainline and needed adjustments; libFileUtils.c > > cannot be placed into test/lib/ because 11u doesn't have JDK-8248667 > > [2], it is placed under test/jdk/native_util/ instead. Testing: > > checked that changed tests pass on Linux and Windows, ran > > jtreg:jdk/sun/security/ssl/ and jck:api/javax_net/ssl . > > > > I also intend to backport subsequent updates to SSLSocketLeak.java > > from mainline. > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8240704 > > [2] https://bugs.openjdk.java.net/browse/JDK-8248667 > > JDK-8240704 was integrated, updated the webrev as a committed one on > top of current 11u-dev (patch itself is the same): > > https://cr.openjdk.java.net/~akasko/jdk11u/8256818/webrev.01/ > > Note, the problem with leaking file descriptors in not present in > current 11u-dev - in current version closeSocket() is indeed not > called when socket was not connected, but (unlike the mainline jdk) FD > is not open at this point. The problem may appear soon, when more > TLSv1.3-related changes are backported, so it is proposed to have this > patch added to 11 to anticipate that. > > > -- > -Alex From christoph.langer at sap.com Tue Dec 22 23:29:29 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Dec 2020 23:29:29 +0000 Subject: Bringing the OutputRecord's lock of JDK-8221882 that was left out by JDK-8240827 In-Reply-To: <94c1f2397b7f96bdd4e5e648993366f120ccf70d.camel@amazon.com> References: <94c1f2397b7f96bdd4e5e648993366f120ccf70d.camel@amazon.com> Message-ID: Hi David, yes, at the time of downporting JDK-8219991, we decided to bring only a subset of the changes of JDK-8221882 to 11u in order to avoid churn. We left out the OutputRecord modifications. If you're in need of these changes now as you're backporting JDK-8224829, I think it's fine to bring them in. In my opinion you can either do that as a separate bug or as part of the backport of JDK-8224829 - just as you like. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Alvarez, David > Sent: Freitag, 18. Dezember 2020 16:56 > To: jdk-updates-dev at openjdk.java.net > Subject: Bringing the OutputRecord's lock of JDK-8221882 that was left out by > JDK-8240827 > > Hi, > > I'm currently working on a backport of JDK-8224829 [1]. However, back > in the day, instead of backporting JDK-8221882 [2] completely, a > downport of the SSLSocketImpl.java was done as part of JDK-8240827 [3]. > This mean that other changes included in JDK-8221882 did not made it to > 11u. > > For JDK-8224829, I would need the lock that was added to OutputRecord > (as the lock call is replaced with a tryLock with timeout). During the > RFR of JDK-8240827, a small discussion regarding the lock in > OutputRecord [4] was started, but they ended up not being included. > > I would like to bring the OutputRecord's lock changes to 11u, and once > I have them, backport JDK-8224829. Can I get an opinion from the > maintainers? Would it be possible to have a bug for 11u created for > these OutputRecord's lock changes? > > Thanks, > > David > -- > [1] https://bugs.openjdk.java.net/browse/JDK-8224829 > [2] https://bugs.openjdk.java.net/browse/JDK-8221882 > [3] https://bugs.openjdk.java.net/browse/JDK-8240827 > [4] > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > March/002808.html From christoph.langer at sap.com Wed Dec 23 06:29:23 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Dec 2020 06:29:23 +0000 Subject: [11u] RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem In-Reply-To: <3fac46683c381ffab97f00c4a220c411dd72f21f.camel@redhat.com> References: <3fac46683c381ffab97f00c4a220c411dd72f21f.camel@redhat.com> Message-ID: Hi Severin, I've checked your backport and I think you've hit all spots for catching UncheckedIOException in the 11u cgroup implementation. Looks good. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Severin Gehwolf > Sent: Freitag, 18. Dezember 2020 11:08 > To: jdk-updates-dev > Subject: Re: [11u] RFR: 8255908: ExceptionInInitializerError due to > UncheckedIOException while initializing cgroupv1 subsystem > > On Thu, 2020-12-10 at 14:07 +0100, Severin Gehwolf wrote: > > Hi! > > > > Could I please get a review of this bugfix which improves error > > checking in the Java Metrics container detection code? The patch is > > basically a rewrite, since there is no cgroups v2 in JDK 11, and places > > where UncheckedIOException need to be handled are different enough > for > > the JDK head patch to not apply properly. > > > > The gist is to handle UncheckedIOException, possibly thrown because of > > interrupts, and exit gracefully rather than failing to initialize and > > crash. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255908 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8255908/01/webrev/ > > > > Testing: Container tests on x86_64 Linux (cgroups v1) and tier 1. > > > > Thoughts? > > Anyone? > > Thanks, > Severin From omikhaltcova at openjdk.java.net Wed Dec 23 08:19:02 2020 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Wed, 23 Dec 2020 08:19:02 GMT Subject: [jdk13u-dev] RFR: 8257242: [macOS] Java app crashes while switching input methods Message-ID: I'd like to backport JDK-8257242 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested with jtreg:test/jdk:jdk_awt. No regression in tests. ------------- Commit messages: - Backport 822ee47459d3a33ab3acd7f8798525967a20d237 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/69/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=69&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257242 Stats: 8 lines in 2 files changed: 3 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/69.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/69/head:pull/69 PR: https://git.openjdk.java.net/jdk13u-dev/pull/69 From omikhaltcova at openjdk.java.net Wed Dec 23 08:36:59 2020 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Wed, 23 Dec 2020 08:36:59 GMT Subject: [jdk13u-dev] Integrated: 8257242: [macOS] Java app crashes while switching input methods In-Reply-To: References: Message-ID: <2sJgFcSeBvs0WnPx29_aknKGamgF5A3WSeNam5nyeP4=.e20615f4-1612-48da-b240-b465af747d0a@github.com> On Wed, 23 Dec 2020 08:11:55 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8257242 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested with jtreg:test/jdk:jdk_awt. No regression in tests. This pull request has now been integrated. Changeset: ea904d8c Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/ea904d8c Stats: 8 lines in 2 files changed: 3 ins; 3 del; 2 mod 8257242: [macOS] Java app crashes while switching input methods Backport-of: 822ee47459d3a33ab3acd7f8798525967a20d237 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/69 From evergizova at openjdk.java.net Wed Dec 23 08:57:12 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 23 Dec 2020 08:57:12 GMT Subject: [jdk13u-dev] RFR: 8210527: JShell: NullPointerException in jdk.jshell.Eval.translateExceptionStack Message-ID: I'd like to backport 8210527 and 8232855 to 13u for parity with 11u. The patch contains both fixes and applies cleanly. Tested with tier1 and jdk/jshell tests. ------------- Commit messages: - Backport dca6e3439749aa6b05f53d8a1cb43002469fc99a Changes: https://git.openjdk.java.net/jdk13u-dev/pull/70/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=70&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8210527 Stats: 62 lines in 3 files changed: 47 ins; 4 del; 11 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/70.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/70/head:pull/70 PR: https://git.openjdk.java.net/jdk13u-dev/pull/70 From christoph.langer at sap.com Wed Dec 23 09:12:05 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Dec 2020 09:12:05 +0000 Subject: [gnu.andrew@redhat.com: Re: OpenJDK 8u and Backport Bugs] In-Reply-To: <077ea8ae-dca1-aa1f-4f54-e9aed1c6d51a@redhat.com> References: <20201211170313.GH1323090@rincewind> <077ea8ae-dca1-aa1f-4f54-e9aed1c6d51a@redhat.com> Message-ID: Hi, > On 12/17/20 5:39 PM, Lindenmaier, Goetz wrote: > > 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. > > This is a good point. We're on the threshold of moving to github, > and the new workflow addresses some of the issues that we're > wrestling with here. It'll take some time for most of the non- > core backporters to come to terms with any workflow change, so it > makes little sense to create a new way of working that'll be gone > almost as soon as it is implemented. > > We should do the JDK 11u move to github first. Let's meet in the > new year after the CPU is out. +1 Let's discuss this for 11u after the Jan CPU is out. In my opinion we should look at switching over to Skara after the April CPU is out of the door - unless we identify important showstoppers. Best regards Christoph From dcherepanov at openjdk.java.net Wed Dec 23 09:19:58 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Wed, 23 Dec 2020 09:19:58 GMT Subject: [jdk13u-dev] RFR: 8254854: [cgroups v1] Metric limits not properly detected on some join controller combinations In-Reply-To: References: Message-ID: <78bd7nXlPc6IR79ChtquzFglXye1QSxUU3xgQwEh4SA=.530425bc-e45a-4958-a3bd-47f6340571d1@github.com> On Tue, 22 Dec 2020 19:27:00 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8254854 to 13u for parity with 11u. > The patch doesn't apply cleanly since 13u doesn't have cgroups v2 support (JDK-8231111), so it reapplied manually to Metrics::setSubSystemPath() method instead of CgroupV1Subsystem::setSubSystemControllerPath() from the original patch. > Tested with tier1 and container tests. Marked as reviewed by dcherepanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/68 From sgehwolf at redhat.com Wed Dec 23 09:32:16 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 23 Dec 2020 10:32:16 +0100 Subject: [11u] RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem In-Reply-To: References: <3fac46683c381ffab97f00c4a220c411dd72f21f.camel@redhat.com> Message-ID: <3105862dd889d45b92d3034b0ef52082afe82eb6.camel@redhat.com> On Wed, 2020-12-23 at 06:29 +0000, Langer, Christoph wrote: > Hi Severin, > > I've checked your backport and I think you've hit all spots for > catching UncheckedIOException in the 11u cgroup implementation. Looks > good. Thanks for the review, Christoph! Cheers, Severin > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Severin Gehwolf > > Sent: Freitag, 18. Dezember 2020 11:08 > > To: jdk-updates-dev > > Subject: Re: [11u] RFR: 8255908: ExceptionInInitializerError due to > > UncheckedIOException while initializing cgroupv1 subsystem > > > > On Thu, 2020-12-10 at 14:07 +0100, Severin Gehwolf wrote: > > > Hi! > > > > > > Could I please get a review of this bugfix which improves error > > > checking in the Java Metrics container detection code? The patch > > > is > > > basically a rewrite, since there is no cgroups v2 in JDK 11, and > > > places > > > where UncheckedIOException need to be handled are different > > > enough > > for > > > the JDK head patch to not apply properly. > > > > > > The gist is to handle UncheckedIOException, possibly thrown > > > because of > > > interrupts, and exit gracefully rather than failing to initialize > > > and > > > crash. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8255908 > > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8255908/01/webrev/ > > > > > > Testing: Container tests on x86_64 Linux (cgroups v1) and tier 1. > > > > > > Thoughts? > > > > Anyone? > > > > Thanks, > > Severin > From evergizova at openjdk.java.net Wed Dec 23 09:35:01 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 23 Dec 2020 09:35:01 GMT Subject: [jdk13u-dev] Integrated: 8254854: [cgroups v1] Metric limits not properly detected on some join controller combinations In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 19:27:00 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8254854 to 13u for parity with 11u. > The patch doesn't apply cleanly since 13u doesn't have cgroups v2 support (JDK-8231111), so it reapplied manually to Metrics::setSubSystemPath() method instead of CgroupV1Subsystem::setSubSystemControllerPath() from the original patch. > Tested with tier1 and container tests. This pull request has now been integrated. Changeset: cc78d10e Author: Ekaterina Vergizova Committer: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/cc78d10e Stats: 36 lines in 1 file changed: 2 ins; 11 del; 23 mod 8254854: [cgroups v1] Metric limits not properly detected on some join controller combinations Reviewed-by: dcherepanov Backport-of: a0b687bfb279761b79d3fbad8f9dfae9b12c225e ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/68 From christoph.langer at sap.com Wed Dec 23 11:02:53 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Dec 2020 11:02:53 +0000 Subject: [11u] RFR: 8222518: Remove unnecessary caching of Parker object in java.lang.Thread In-Reply-To: References: <0B57272A-5A4A-4832-A7AA-8474B5208EF6@amazon.com> Message-ID: Hi Paul, this is no review, rather a maintainer's statement. I've little knowledge or experience in the area of hotspot thread synchronization. With that disclaimer, the patch looks benign to me but I would want to hear another expert's assessment before being able to approve this with a good conscience. I could ask Richard from our team (on cc) to have a look when he's back from vacation. Or feel free to find somebody else to review and assess this backport from a technical pov. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Montag, 21. Dezember 2020 16:34 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8222518: Remove unnecessary caching of Parker > object in java.lang.Thread > > Passes tier1 as well as before the patch. We do, however, have 3 tier1 > langtools failures independent of this patch. > > jdk/javadoc/doclet/testGeneratedBy/TestGeneratedBy.java: Verify that > files use a common Generated By string > jdk/javadoc/doclet/testVersionOption/TestVersionOption.java: javadoc > should support --version and --full-version flags > tools/javac/VersionOpt.java: tools/javac/versionOpt.sh fails on OpenJDK > builds Test checks the version strings displayed by javac, using strings that > come out of the Java runtime. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of "Hohensee, Paul" > Date: Sunday, December 20, 2020 at 10:18 AM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Subject: [11u] RFR: 8222518: Remove unnecessary caching of Parker object in > java.lang.Thread > > Please review this small code deletion and footprint reduction backport. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8222518 > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/9ebb614d293d > Webrev: http://cr.openjdk.java.net/~phh/8222518/webrev.11u.00/ > > The backport is not clean because (1) javaClasses.cpp needed a copyright > date update to 2019 and the original 3rd hunk that deletes park_event() and > set_park_event() contained slightly different code that does not check for > non-existent Thread fields, and (2) unsafe.cpp needed a copyright update to > 2019. > > Thanks, > Paul > From christoph.langer at sap.com Wed Dec 23 11:34:19 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Dec 2020 11:34:19 +0000 Subject: [11u] RFR: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default) In-Reply-To: References: Message-ID: Hi Jaroslav, I think this is a great enhancement for JFR - but as the word "enhancement" says, it's not a bugfix. So it's not a "must have" for a backport to the LTS. With enhancements we need first of all be very cautious not to endanger stability. I suggest you get in touch with Red Hat's team around Mario Torre to discuss the idea and feasibility of backporting this to 11u. I think it really has to be discussed whether this item is a good candidate for a backport at all and if so, what testing and other precautions need to be taken before letting this in. So, for the moment I'll flag the bug with a jdk11u-fix-no. But feel invited to re-request approval via removing that flag after more discussion has been done and a consensus is reached in the community. Thanks for your understanding! Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Jaroslav Bachor?k > Sent: Montag, 21. Dezember 2020 16:23 > To: jdk-updates-dev > Subject: Re: [11u] RFR: 8257602: Introduce JFR Event Throttling and new > jdk.ObjectAllocationSample event (enabled by default) > > Greetings, > > The original attempt to generate webrev from two changesets failed > miserably. Therefore I am updating the webrev links as follows: > * Main issue: > http://cr.openjdk.java.net/~jbachorik/8257602/jdk11/00/webrev/ > * Followup AIX build fix: > https://cr.openjdk.java.net/~jbachorik/8258094/jdk11/00/webrev/ > > Regards, > > -JB- > > On Tue, Dec 15, 2020 at 9:21 AM Jaroslav Bachor?k > wrote: > > > > Greetings, > > > > I would like to ask for review of this JDK11u backport patch: > > > > Issue : https://bugs.openjdk.java.net/browse/JDK-8257602 > > Webrev: > http://cr.openjdk.java.net/~jbachorik/8257602/jdk11/00/webrev/ > > > > The webrev contains the main change backported from JDK-8257602 and > > the followup patch for AIX build failure resolved as JDK-8258094. I > > decided to roll both changesets into one webrev to get a fully > > buildable system once this backport request is approved. > > > > The original changeset of JDK-8257602 had to be slightly adjusted for > > the following: > > * hunk offsets not matching because of larger structural changes > > resolution: the appropriate code was inserted manually > > * missing Atomic::load_acquire and Atomic::release_store functions > > resolution: used OrderAccess::* equivalents > > * different argument order for Atomic::cmpxchg and Atomic::store > > resolution: modified the call-site argument order to match what is > > provided by Atomic::* > > * [test] missing support for event streaming > > resolution: used the recording in non-streaming mode while keeping > > the test semantics > > > > All tier1, tier2 and jdk_jfr tests are passing with the changes applied. > > > > Cheers, > > > > -JB- From yan at openjdk.java.net Wed Dec 23 11:59:59 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 23 Dec 2020 11:59:59 GMT Subject: [jdk13u-dev] RFR: 8236859: WebSocket over authenticating proxy fails with NPE In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 11:03:00 GMT, Larry-N wrote: > Backport fix for bug 8236859 > + small correction cache.store() calling because of method signature difference from 16 to 13 jdk. > File: AuthenticationFilter.java Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/53 From github.com+75672469+larry-n at openjdk.java.net Wed Dec 23 12:19:56 2020 From: github.com+75672469+larry-n at openjdk.java.net (Larry-N) Date: Wed, 23 Dec 2020 12:19:56 GMT Subject: [jdk13u-dev] Integrated: 8236859: WebSocket over authenticating proxy fails with NPE In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 11:03:00 GMT, Larry-N wrote: > Backport fix for bug 8236859 > + small correction cache.store() calling because of method signature difference from 16 to 13 jdk. > File: AuthenticationFilter.java This pull request has now been integrated. Changeset: 5d25a8ff Author: Ilarion Nakonechnyy Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/5d25a8ff Stats: 948 lines in 12 files changed: 909 ins; 5 del; 34 mod 8236859: WebSocket over authenticating proxy fails with NPE This change fixes several issues with WebSocket and proxy authentication. The AuthenticationFilter is changed to support an authenticating server accessed through an authenticating proxy. MultiExchange is fixed to close the previous connection if a new connection is necessary to establish the websocket (websocket connections are not cached and must be closed in that case). WebSocket OpeningHandshake is fixed to close the connection (without creating the RawChannel) if the opening handshake doesn't result in 101 upgrade protocol. Reviewed-by: yan Backport-of: c6da6681d418928c65cff6b1240e6b5d6bc5199b ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/53 From evergizova at openjdk.java.net Wed Dec 23 12:22:10 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 23 Dec 2020 12:22:10 GMT Subject: [jdk13u-dev] RFR: 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() Message-ID: <9eArO7YV2P2mV2W7JNtZNhYMHPwDaipfS9mYGWcnNmk=.7d05178d-f45b-4132-9a57-dd0750ba0b90@github.com> I'd like to backport 8234011 to 13u for parity with 11u. The patch applies cleanly. Tested with tier1 and jdk/nio/zipfs tests. ------------- Commit messages: - Backport a6fd1b4c4bad720a4fde0d51ace7f1cd56c8878c Changes: https://git.openjdk.java.net/jdk13u-dev/pull/71/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=71&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234011 Stats: 97 lines in 2 files changed: 96 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/71/head:pull/71 PR: https://git.openjdk.java.net/jdk13u-dev/pull/71 From evergizova at openjdk.java.net Wed Dec 23 12:27:01 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 23 Dec 2020 12:27:01 GMT Subject: [jdk13u-dev] Integrated: 8210527: JShell: NullPointerException in jdk.jshell.Eval.translateExceptionStack In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 08:51:48 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8210527 and 8232855 to 13u for parity with 11u. > The patch contains both fixes and applies cleanly. > Tested with tier1 and jdk/jshell tests. This pull request has now been integrated. Changeset: fba425dc Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/fba425dc Stats: 62 lines in 3 files changed: 47 ins; 4 del; 11 mod 8210527: JShell: NullPointerException in jdk.jshell.Eval.translateExceptionStack 8232855: jshell missing word in /help help Backport-of: dca6e3439749aa6b05f53d8a1cb43002469fc99a ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/70 From christoph.langer at sap.com Wed Dec 23 13:09:39 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Dec 2020 13:09:39 +0000 Subject: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions In-Reply-To: References: Message-ID: Hi, as we should be cautious about backports to an LTS release if something is not just a bugfix, I'm not sure whether this backport for a performance enhancement is good to go. Generally, if it can be proven that it's really just a potential performance improvement without side effects to other scenarios, I would be fine with it. But as I'm not an expert in this area, I'd prefer if it there was some further endorsement (or disapproval)... @Andrew Haley; @Lindenmaier, Goetz; @Doerr, Martin, what's your assessment? Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Viswanathan, Sandhya > Sent: Freitag, 11. Dezember 2020 00:47 > To: Vladimir Kozlov ; jdk-updates- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Subject: RE: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions > > Thanks a lot Vladimir for review and link to the process. I requested the > backport in JBS. > > Best Regards, > Sandhya > > -----Original Message----- > From: Vladimir Kozlov > Sent: Thursday, December 10, 2020 3:07 PM > To: Viswanathan, Sandhya ; jdk-updates- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Subject: Re: [11u] RFR 8245512: CRC32 optimization using AVX512 instructions > > Changes are fine but you need to follow process: > > http://openjdk.java.net/projects/jdk-updates/approval.html > > Also it is performance improvement which may not be accepted. > > Regards, > Vladimi > > On 12/10/20 1:00 PM, Viswanathan, Sandhya wrote: > > I would like to backport the CRC32 optimization using AVX512 instructions > to JDK 11u. > > This optimization was introduced in JDK 15. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245512 > > Webrev: http://cr.openjdk.java.net/~sviswanathan/8245512/webrev.00/ > > > > Only one change was needed to the original patch in > src/hotspot/cpu/x86/assembler_x86.cpp. > > > > The following in Assembler::blendvpb(), line 7908: > > > > emit_int24(0x4C, (0xC0 | encode), (0xF0 & src2_enc << 4)); was > > replaced by equivalent: > > emit_int8((unsigned char)0x4C); > > emit_int8((unsigned char)(0xC0 | encode)); emit_int8((unsigned > > char)(0xF0 & src2_enc<<4)); > > > > The patch applies cleanly otherwise. > > > > Please review this backport to 11u. > > > > Best Regards, > > Sandhya > > From martin.doerr at sap.com Wed Dec 23 15:11:15 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 23 Dec 2020 15:11:15 +0000 Subject: [11u] RFR: 8234742: Improve handshake logging Message-ID: Hi, JDK-8234742 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly at all, mainly because JDK-8244340 was integrated before this one which was in the wrong order. (Failing hunks are listed here: http://cr.openjdk.java.net/~mdoerr/8234742_handshake_11u/8234742_handshake_failing_hunks.txt) So my 11u backport is supposed to reflect the state of both changes integrated. Bug: https://bugs.openjdk.java.net/browse/JDK-8234742 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/c2ce3849c62f Other change which was backported in the wrong order and from which I've taken small parts: https://hg.openjdk.java.net/jdk/jdk/rev/67a435ce2dc2 11u backport: http://cr.openjdk.java.net/~mdoerr/8234742_handshake_11u/webrev.00/ Please review. Best regards, Martin From hohensee at amazon.com Wed Dec 23 16:13:09 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 23 Dec 2020 16:13:09 +0000 Subject: [11u] RFR: 8222518: Remove unnecessary caching of Parker object in java.lang.Thread Message-ID: Thanks, Christoph. I'll do that. Paul ?-----Original Message----- From: "Langer, Christoph" Date: Wednesday, December 23, 2020 at 3:03 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Cc: "Reingruber, Richard" Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker object in java.lang.Thread Hi Paul, this is no review, rather a maintainer's statement. I've little knowledge or experience in the area of hotspot thread synchronization. With that disclaimer, the patch looks benign to me but I would want to hear another expert's assessment before being able to approve this with a good conscience. I could ask Richard from our team (on cc) to have a look when he's back from vacation. Or feel free to find somebody else to review and assess this backport from a technical pov. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Montag, 21. Dezember 2020 16:34 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8222518: Remove unnecessary caching of Parker > object in java.lang.Thread > > Passes tier1 as well as before the patch. We do, however, have 3 tier1 > langtools failures independent of this patch. > > jdk/javadoc/doclet/testGeneratedBy/TestGeneratedBy.java: Verify that > files use a common Generated By string > jdk/javadoc/doclet/testVersionOption/TestVersionOption.java: javadoc > should support --version and --full-version flags > tools/javac/VersionOpt.java: tools/javac/versionOpt.sh fails on OpenJDK > builds Test checks the version strings displayed by javac, using strings that > come out of the Java runtime. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on > behalf of "Hohensee, Paul" > Date: Sunday, December 20, 2020 at 10:18 AM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Subject: [11u] RFR: 8222518: Remove unnecessary caching of Parker object in > java.lang.Thread > > Please review this small code deletion and footprint reduction backport. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8222518 > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/9ebb614d293d > Webrev: http://cr.openjdk.java.net/~phh/8222518/webrev.11u.00/ > > The backport is not clean because (1) javaClasses.cpp needed a copyright > date update to 2019 and the original 3rd hunk that deletes park_event() and > set_park_event() contained slightly different code that does not check for > non-existent Thread fields, and (2) unsafe.cpp needed a copyright update to > 2019. > > Thanks, > Paul > From robm at openjdk.java.net Wed Dec 23 19:58:05 2020 From: robm at openjdk.java.net (Rob McKenna) Date: Wed, 23 Dec 2020 19:58:05 GMT Subject: [jdk16u] RFR: 8258909: update jdk16u jcheck conf Message-ID: The jdk16u repository is forked from the jdk16 stabilization repository. The jcheck configuration should be updated post-fork to indicate that this repository is part of the jdk-updates project. ------------- Commit messages: - 8258909: update jdk16u jcheck conf Changes: https://git.openjdk.java.net/jdk16u/pull/1/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=1&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258909 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/1.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/1/head:pull/1 PR: https://git.openjdk.java.net/jdk16u/pull/1 From kcr at openjdk.java.net Wed Dec 23 20:17:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Dec 2020 20:17:58 GMT Subject: [jdk16u] RFR: 8258909: update jdk16u jcheck conf In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 19:23:03 GMT, Rob McKenna wrote: > The jdk16u repository is forked from the jdk16 stabilization repository. The jcheck configuration should be updated post-fork to indicate that this repository is part of the jdk-updates project. Looks good. ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk16u/pull/1 From martin.doerr at sap.com Wed Dec 23 21:25:07 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 23 Dec 2020 21:25:07 +0000 Subject: [11u] RFR: 8248901: Signed immediate support in .../share/assembler.hpp is broken.memory chain In-Reply-To: References: <85B150E5-4134-4B31-A4F2-6F7CDB9922CC@amazon.com> Message-ID: Hi, I noticed that I need additional fixes for PPC64 and SPARC (see below). I've taken the fix for the wrong assertion on PPC64 from upstream and added the missing functions to assembler_sparc.hpp. New webrev: http://cr.openjdk.java.net/~mdoerr/8248901_assembler_11u/webrev.01/ Best regards, Martin diff -r d8d8bd39cbbe src/hotspot/cpu/ppc/macroAssembler_ppc.cpp --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Mon Jul 06 21:29:51 2020 +0200 +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Wed Dec 23 22:08:52 2020 +0100 @@ -2302,7 +2302,7 @@ ) { // make sure arguments make sense assert_different_registers(obj, var_size_in_bytes, t1); - assert(0 <= con_size_in_bytes && is_simm13(con_size_in_bytes), "illegal object size"); + assert(0 <= con_size_in_bytes && is_simm16(con_size_in_bytes), "illegal object size"); assert((con_size_in_bytes & MinObjAlignmentInBytesMask) == 0, "object size is not multiple of alignment"); const Register new_top = t1; diff -r d8d8bd39cbbe src/hotspot/cpu/sparc/assembler_sparc.hpp --- a/src/hotspot/cpu/sparc/assembler_sparc.hpp Mon Jul 06 21:29:51 2020 +0200 +++ b/src/hotspot/cpu/sparc/assembler_sparc.hpp Wed Dec 23 22:08:52 2020 +0100 @@ -358,6 +358,13 @@ return is_in_wdisp_range(a, b, 30); } + static bool is_simm5(intptr_t x) { return is_simm(x, 5); } + static bool is_simm11(intptr_t x) { return is_simm(x, 11); } + static bool is_simm12(intptr_t x) { return is_simm(x, 12); } + static bool is_simm13(intptr_t x) { return is_simm(x, 13); } + + static int min_simm13() { return -4096; } + enum ASIs { // page 72, v9 ASI_PRIMARY = 0x80, ASI_PRIMARY_NOFAULT = 0x82, > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 21. Dezember 2020 18:32 > To: Hohensee, Paul ; 'hotspot-compiler- > dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net > Cc: Langer, Christoph ; Lindenmaier, Goetz > > Subject: RE: [11u] RFR: 8248901: Signed immediate support in > .../share/assembler.hpp is broken.memory chain > > Hi Paul, > > thanks for the review! I'll have to backport it together with JDK-8247766 > which doesn't apply cleanly in order to avoid breaking aarch64. > > Best regards, > Martin > > > > -----Original Message----- > > From: Hohensee, Paul > > Sent: Montag, 21. Dezember 2020 18:29 > > To: Doerr, Martin ; 'hotspot-compiler- > > dev at openjdk.java.net' ; jdk- > > updates-dev at openjdk.java.net > > Cc: Langer, Christoph ; Lindenmaier, Goetz > > > > Subject: RE: [11u] RFR: 8248901: Signed immediate support in > > .../share/assembler.hpp is broken.memory chain > > > > Lgtm. > > > > Thanks, > > Paul > > > > ?-----Original Message----- > > From: jdk-updates-dev on > > behalf of "Doerr, Martin" > > Date: Monday, December 21, 2020 at 8:52 AM > > To: "'hotspot-compiler-dev at openjdk.java.net'" > dev at openjdk.java.net>, "jdk-updates-dev at openjdk.java.net" > updates-dev at openjdk.java.net> > > Cc: "Langer, Christoph" , "Lindenmaier, > Goetz" > > > > Subject: [11u] RFR: 8248901: Signed immediate support in > > .../share/assembler.hpp is broken.memory chain > > > > Hi, > > > > JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for parity. > > Change applies cleanly, but precond macro is missing in 11u. I've taken it > from > > JDK-8223140 (http://hg.openjdk.java.net/jdk/jdk/rev/6b77693eda6a). > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8248901 > > > > Original change: > > https://hg.openjdk.java.net/jdk/jdk/rev/ce8fb40c9174 > > > > Clean 11u backport with added precond and postcond macros: > > http://cr.openjdk.java.net/~mdoerr/8248901_assembler_11u/webrev.00/ > > > > Please review. > > > > Best regards, > > Martin > > From martin.doerr at sap.com Wed Dec 23 21:27:30 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 23 Dec 2020 21:27:30 +0000 Subject: [11u] RFR: 8247766: [aarch64] guarantee(val < (1U << nbits)) failed: Field too big for insn Message-ID: Hi, JDK-8247766 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly. I had to apply failing hunks manually which are listed here: http://cr.openjdk.java.net/~mdoerr/8247766_aarch64_11u/8247766_aarch64_failed_hunks.txt Note that there are minor differences regarding integer types. I've taken the new implementation. In addition, I have taken "legitimize_address" from upstream. It was missing in 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8247766 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/40c07de877ab 11u backport: http://cr.openjdk.java.net/~mdoerr/8247766_aarch64_11u/webrev.00/ Please review. Best regards, Martin From coffeys at openjdk.java.net Wed Dec 23 22:26:56 2020 From: coffeys at openjdk.java.net (Sean Coffey) Date: Wed, 23 Dec 2020 22:26:56 GMT Subject: [jdk16u] RFR: 8258909: update jdk16u jcheck conf In-Reply-To: References: Message-ID: <2RrtyfiFTAPmtvvQTOl-UfoHuuLoMQ7k0Jq8dO8i_tQ=.58f69b17-45ab-4027-918e-41aec6be53d3@github.com> On Wed, 23 Dec 2020 19:23:03 GMT, Rob McKenna wrote: > The jdk16u repository is forked from the jdk16 stabilization repository. The jcheck configuration should be updated post-fork to indicate that this repository is part of the jdk-updates project. Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16u/pull/1 From evergizova at openjdk.java.net Thu Dec 24 07:04:08 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 24 Dec 2020 07:04:08 GMT Subject: [jdk13u-dev] Integrated: 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() In-Reply-To: <9eArO7YV2P2mV2W7JNtZNhYMHPwDaipfS9mYGWcnNmk=.7d05178d-f45b-4132-9a57-dd0750ba0b90@github.com> References: <9eArO7YV2P2mV2W7JNtZNhYMHPwDaipfS9mYGWcnNmk=.7d05178d-f45b-4132-9a57-dd0750ba0b90@github.com> Message-ID: On Wed, 23 Dec 2020 12:17:03 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8234011 to 13u for parity with 11u. > The patch applies cleanly. > Tested with tier1 and jdk/nio/zipfs tests. This pull request has now been integrated. Changeset: 576cf039 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/576cf039 Stats: 97 lines in 2 files changed: 96 ins; 0 del; 1 mod 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() Backport-of: a6fd1b4c4bad720a4fde0d51ace7f1cd56c8878c ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/71 From yan at azul.com Thu Dec 24 11:58:12 2020 From: yan at azul.com (Yuri Nesterenko) Date: Thu, 24 Dec 2020 14:58:12 +0300 Subject: [13u notice] last 13u-dev merge for 13.0.6 Message-ID: Hi, presently jdk13u-dev is closed. It will reopen for 13.0.7 (April release) as soon as we have that release value available and 13.0.7+0 tag set there. Last update of master jdk13u repo from jdk13u-dev is finished. Further changes to 13.0.6, if any, will go directly to the master and should be requested with jdk13u-critical-request label. Thank you! --yan From robm at openjdk.java.net Thu Dec 24 13:42:57 2020 From: robm at openjdk.java.net (Rob McKenna) Date: Thu, 24 Dec 2020 13:42:57 GMT Subject: [jdk16u] Integrated: 8258909: update jdk16u jcheck conf In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 19:23:03 GMT, Rob McKenna wrote: > The jdk16u repository is forked from the jdk16 stabilization repository. The jcheck configuration should be updated post-fork to indicate that this repository is part of the jdk-updates project. This pull request has now been integrated. Changeset: be345a2c Author: Rob McKenna URL: https://git.openjdk.java.net/jdk16u/commit/be345a2c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8258909: update jdk16u jcheck conf Reviewed-by: kcr, coffeys ------------- PR: https://git.openjdk.java.net/jdk16u/pull/1 From coffeys at openjdk.java.net Thu Dec 24 14:20:05 2020 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 24 Dec 2020 14:20:05 GMT Subject: [jdk16u] Integrated: 8253368: TLS connection always receives close_notify exception Message-ID: 8253368: TLS connection always receives close_notify exception ------------- Commit messages: - 8253368 backport a4e082e9857d6acd126fb0734583b4a1e211f9f7 Changes: https://git.openjdk.java.net/jdk16u/pull/2/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=2&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253368 Stats: 37 lines in 2 files changed: 25 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk16u/pull/2.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/2/head:pull/2 PR: https://git.openjdk.java.net/jdk16u/pull/2 From coffeys at openjdk.java.net Thu Dec 24 14:20:05 2020 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 24 Dec 2020 14:20:05 GMT Subject: [jdk16u] Integrated: 8253368: TLS connection always receives close_notify exception In-Reply-To: References: Message-ID: <6W8Y0Ts03TmtOkoRPnKWex26c6n1kvStNMM6sjmlZrY=.45bf3efb-6d03-4f73-ad35-f3d54ff9e2ed@github.com> On Thu, 24 Dec 2020 14:12:59 GMT, Sean Coffey wrote: > 8253368: TLS connection always receives close_notify exception backporting 8253368 to jdk16u ------------- PR: https://git.openjdk.java.net/jdk16u/pull/2 From coffeys at openjdk.java.net Thu Dec 24 14:20:06 2020 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 24 Dec 2020 14:20:06 GMT Subject: [jdk16u] Integrated: 8253368: TLS connection always receives close_notify exception In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 14:12:59 GMT, Sean Coffey wrote: > 8253368: TLS connection always receives close_notify exception This pull request has now been integrated. Changeset: 43f4ae2d Author: Sean Coffey URL: https://git.openjdk.java.net/jdk16u/commit/43f4ae2d Stats: 37 lines in 2 files changed: 25 ins; 0 del; 12 mod 8253368: TLS connection always receives close_notify exception Backport-of: a4e082e9857d6acd126fb0734583b4a1e211f9f7 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/2 From martin.doerr at sap.com Mon Dec 28 13:17:47 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 28 Dec 2020 13:17:47 +0000 Subject: [11u] RFR: 8255544: Create a checked cast Message-ID: Hi, JDK-8255544 is backported to 11.0.11-oracle. I'd like to backport it for parity. And it's required by other backports. Change doesn't apply cleanly: globalDefinitions.hpp: I had to apply the hunk manually because of unrelated context changes. heap.cpp: Doesn't apply because JDK-8231460 is not in 11u. I suggest to skip it. Bug: https://bugs.openjdk.java.net/browse/JDK-8255544 Original change: https://github.com/openjdk/jdk/commit/3302d3ad 11u backport: http://cr.openjdk.java.net/~mdoerr/8255544_checked_cast_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Mon Dec 28 15:29:43 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 28 Dec 2020 15:29:43 +0000 Subject: [11u] RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches Message-ID: Hi, I'd like to backport the following PPC64 fixes to 11u together: https://bugs.openjdk.java.net/browse/JDK-8257423 https://bugs.openjdk.java.net/browse/JDK-8257798 (2nd one is a follow-up fix for some builds) Both changes don't apply cleanly, but are trivial to resolve: 1st one didn't apply because Universe::narrow_klass_base() was moved to CompressedKlassPointers::base() which is used in old version of MacroAssembler::instr_size_for_decode_klass_not_null. 2nd one didn't apply because of unrelated context changes. I just had to apply the hunks manually. Original changes: https://github.com/openjdk/jdk/commit/1d2d9815 https://github.com/openjdk/jdk/commit/46b35acf 11u backports: http://cr.openjdk.java.net/~mdoerr/8257423_PPC_UseInlineCaches_11u/webrev.00/ http://cr.openjdk.java.net/~mdoerr/8257798_PPC_build_11u/webrev.00/ Please review. Best regards, Martin From goetz.lindenmaier at sap.com Tue Dec 29 15:29:24 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Dec 2020 15:29:24 +0000 Subject: [11u] RFR: 8248901: Signed immediate support in .../share/assembler.hpp is broken.memory chain In-Reply-To: References: <85B150E5-4134-4B31-A4F2-6F7CDB9922CC@amazon.com> Message-ID: Hi Martin, Webrev 01 still looks good. Thanks, Goetz > -----Original Message----- > From: Doerr, Martin > Sent: Wednesday, December 23, 2020 10:25 PM > To: Hohensee, Paul ; 'hotspot-compiler- > dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net > Cc: Langer, Christoph ; Lindenmaier, Goetz > > Subject: RE: [11u] RFR: 8248901: Signed immediate support > in .../share/assembler.hpp is broken.memory chain > > Hi, > > I noticed that I need additional fixes for PPC64 and SPARC (see below). > I've taken the fix for the wrong assertion on PPC64 from upstream and added > the missing functions to assembler_sparc.hpp. > > New webrev: > http://cr.openjdk.java.net/~mdoerr/8248901_assembler_11u/webrev.01/ > > Best regards, > Martin > > > diff -r d8d8bd39cbbe src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Mon Jul 06 21:29:51 > 2020 +0200 > +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Wed Dec 23 > 22:08:52 2020 +0100 > @@ -2302,7 +2302,7 @@ > ) { > // make sure arguments make sense > assert_different_registers(obj, var_size_in_bytes, t1); > - assert(0 <= con_size_in_bytes && is_simm13(con_size_in_bytes), "illegal > object size"); > + assert(0 <= con_size_in_bytes && is_simm16(con_size_in_bytes), "illegal > object size"); > assert((con_size_in_bytes & MinObjAlignmentInBytesMask) == 0, "object > size is not multiple of alignment"); > > const Register new_top = t1; > diff -r d8d8bd39cbbe src/hotspot/cpu/sparc/assembler_sparc.hpp > --- a/src/hotspot/cpu/sparc/assembler_sparc.hpp Mon Jul 06 21:29:51 2020 > +0200 > +++ b/src/hotspot/cpu/sparc/assembler_sparc.hpp Wed Dec 23 22:08:52 > 2020 +0100 > @@ -358,6 +358,13 @@ > return is_in_wdisp_range(a, b, 30); > } > > + static bool is_simm5(intptr_t x) { return is_simm(x, 5); } > + static bool is_simm11(intptr_t x) { return is_simm(x, 11); } > + static bool is_simm12(intptr_t x) { return is_simm(x, 12); } > + static bool is_simm13(intptr_t x) { return is_simm(x, 13); } > + > + static int min_simm13() { return -4096; } > + > enum ASIs { // page 72, v9 > ASI_PRIMARY = 0x80, > ASI_PRIMARY_NOFAULT = 0x82, > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Montag, 21. Dezember 2020 18:32 > > To: Hohensee, Paul ; 'hotspot-compiler- > > dev at openjdk.java.net' ; jdk- > > updates-dev at openjdk.java.net > > Cc: Langer, Christoph ; Lindenmaier, Goetz > > > > Subject: RE: [11u] RFR: 8248901: Signed immediate support in > > .../share/assembler.hpp is broken.memory chain > > > > Hi Paul, > > > > thanks for the review! I'll have to backport it together with JDK-8247766 > > which doesn't apply cleanly in order to avoid breaking aarch64. > > > > Best regards, > > Martin > > > > > > > -----Original Message----- > > > From: Hohensee, Paul > > > Sent: Montag, 21. Dezember 2020 18:29 > > > To: Doerr, Martin ; 'hotspot-compiler- > > > dev at openjdk.java.net' ; jdk- > > > updates-dev at openjdk.java.net > > > Cc: Langer, Christoph ; Lindenmaier, Goetz > > > > > > Subject: RE: [11u] RFR: 8248901: Signed immediate support in > > > .../share/assembler.hpp is broken.memory chain > > > > > > Lgtm. > > > > > > Thanks, > > > Paul > > > > > > ?-----Original Message----- > > > From: jdk-updates-dev on > > > behalf of "Doerr, Martin" > > > Date: Monday, December 21, 2020 at 8:52 AM > > > To: "'hotspot-compiler-dev at openjdk.java.net'" > > dev at openjdk.java.net>, "jdk-updates-dev at openjdk.java.net" > > updates-dev at openjdk.java.net> > > > Cc: "Langer, Christoph" , "Lindenmaier, > > Goetz" > > > > > > Subject: [11u] RFR: 8248901: Signed immediate support in > > > .../share/assembler.hpp is broken.memory chain > > > > > > Hi, > > > > > > JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for > parity. > > > Change applies cleanly, but precond macro is missing in 11u. I've taken it > > from > > > JDK-8223140 (http://hg.openjdk.java.net/jdk/jdk/rev/6b77693eda6a). > > > > > > Bug: > > > https://bugs.openjdk.java.net/browse/JDK-8248901 > > > > > > Original change: > > > https://hg.openjdk.java.net/jdk/jdk/rev/ce8fb40c9174 > > > > > > Clean 11u backport with added precond and postcond macros: > > > > http://cr.openjdk.java.net/~mdoerr/8248901_assembler_11u/webrev.00/ > > > > > > Please review. > > > > > > Best regards, > > > Martin > > > From goetz.lindenmaier at sap.com Tue Dec 29 15:52:40 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Dec 2020 15:52:40 +0000 Subject: [11u] RFR: 8247766: [aarch64] guarantee(val < (1U << nbits)) failed: Field too big for insn In-Reply-To: References: Message-ID: Hi, Looks good to me, adaptions are trivial. Thanks, Goetz. From: Doerr, Martin Sent: Wednesday, December 23, 2020 10:28 PM To: 'hotspot-compiler-dev at openjdk.java.net' ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8247766: [aarch64] guarantee(val < (1U << nbits)) failed: Field too big for insn Hi, JDK-8247766 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly. I had to apply failing hunks manually which are listed here: http://cr.openjdk.java.net/~mdoerr/8247766_aarch64_11u/8247766_aarch64_failed_hunks.txt Note that there are minor differences regarding integer types. I've taken the new implementation. In addition, I have taken "legitimize_address" from upstream. It was missing in 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8247766 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/40c07de877ab 11u backport: http://cr.openjdk.java.net/~mdoerr/8247766_aarch64_11u/webrev.00/ Please review. Best regards, Martin From goetz.lindenmaier at sap.com Tue Dec 29 15:58:50 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Dec 2020 15:58:50 +0000 Subject: [11u] RFR: 8255544: Create a checked cast In-Reply-To: References: Message-ID: Hi, Ok, so there is only the definition of the checked_cast remaining. Looks good. Best regards, Goetz. From: Doerr, Martin Sent: Monday, December 28, 2020 2:18 PM To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8255544: Create a checked cast Hi, JDK-8255544 is backported to 11.0.11-oracle. I'd like to backport it for parity. And it's required by other backports. Change doesn't apply cleanly: globalDefinitions.hpp: I had to apply the hunk manually because of unrelated context changes. heap.cpp: Doesn't apply because JDK-8231460 is not in 11u. I suggest to skip it. Bug: https://bugs.openjdk.java.net/browse/JDK-8255544 Original change: https://github.com/openjdk/jdk/commit/3302d3ad 11u backport: http://cr.openjdk.java.net/~mdoerr/8255544_checked_cast_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Tue Dec 29 15:59:03 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 29 Dec 2020 15:59:03 +0000 Subject: [11u] RFR: 8248901: Signed immediate support in .../share/assembler.hpp is broken.memory chain In-Reply-To: References: <85B150E5-4134-4B31-A4F2-6F7CDB9922CC@amazon.com> Message-ID: Hi G?tz, thanks for the review! Best regards, Martin > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 29. Dezember 2020 16:29 > To: Doerr, Martin ; Hohensee, Paul > ; 'hotspot-compiler-dev at openjdk.java.net' > ; jdk-updates- > dev at openjdk.java.net > Cc: Langer, Christoph > Subject: RE: [11u] RFR: 8248901: Signed immediate support in > .../share/assembler.hpp is broken.memory chain > > Hi Martin, > > Webrev 01 still looks good. > > Thanks, > Goetz > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Wednesday, December 23, 2020 10:25 PM > > To: Hohensee, Paul ; 'hotspot-compiler- > > dev at openjdk.java.net' ; jdk- > > updates-dev at openjdk.java.net > > Cc: Langer, Christoph ; Lindenmaier, Goetz > > > > Subject: RE: [11u] RFR: 8248901: Signed immediate support > > in .../share/assembler.hpp is broken.memory chain > > > > Hi, > > > > I noticed that I need additional fixes for PPC64 and SPARC (see below). > > I've taken the fix for the wrong assertion on PPC64 from upstream and > added > > the missing functions to assembler_sparc.hpp. > > > > New webrev: > > http://cr.openjdk.java.net/~mdoerr/8248901_assembler_11u/webrev.01/ > > > > Best regards, > > Martin > > > > > > diff -r d8d8bd39cbbe src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > > --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Mon Jul 06 > 21:29:51 > > 2020 +0200 > > +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Wed Dec 23 > > 22:08:52 2020 +0100 > > @@ -2302,7 +2302,7 @@ > > ) { > > // make sure arguments make sense > > assert_different_registers(obj, var_size_in_bytes, t1); > > - assert(0 <= con_size_in_bytes && is_simm13(con_size_in_bytes), "illegal > > object size"); > > + assert(0 <= con_size_in_bytes && is_simm16(con_size_in_bytes), > "illegal > > object size"); > > assert((con_size_in_bytes & MinObjAlignmentInBytesMask) == 0, > "object > > size is not multiple of alignment"); > > > > const Register new_top = t1; > > diff -r d8d8bd39cbbe src/hotspot/cpu/sparc/assembler_sparc.hpp > > --- a/src/hotspot/cpu/sparc/assembler_sparc.hpp Mon Jul 06 21:29:51 2020 > > +0200 > > +++ b/src/hotspot/cpu/sparc/assembler_sparc.hpp Wed Dec 23 22:08:52 > > 2020 +0100 > > @@ -358,6 +358,13 @@ > > return is_in_wdisp_range(a, b, 30); > > } > > > > + static bool is_simm5(intptr_t x) { return is_simm(x, 5); } > > + static bool is_simm11(intptr_t x) { return is_simm(x, 11); } > > + static bool is_simm12(intptr_t x) { return is_simm(x, 12); } > > + static bool is_simm13(intptr_t x) { return is_simm(x, 13); } > > + > > + static int min_simm13() { return -4096; } > > + > > enum ASIs { // page 72, v9 > > ASI_PRIMARY = 0x80, > > ASI_PRIMARY_NOFAULT = 0x82, > > > > > > > -----Original Message----- > > > From: Doerr, Martin > > > Sent: Montag, 21. Dezember 2020 18:32 > > > To: Hohensee, Paul ; 'hotspot-compiler- > > > dev at openjdk.java.net' ; jdk- > > > updates-dev at openjdk.java.net > > > Cc: Langer, Christoph ; Lindenmaier, Goetz > > > > > > Subject: RE: [11u] RFR: 8248901: Signed immediate support in > > > .../share/assembler.hpp is broken.memory chain > > > > > > Hi Paul, > > > > > > thanks for the review! I'll have to backport it together with JDK-8247766 > > > which doesn't apply cleanly in order to avoid breaking aarch64. > > > > > > Best regards, > > > Martin > > > > > > > > > > -----Original Message----- > > > > From: Hohensee, Paul > > > > Sent: Montag, 21. Dezember 2020 18:29 > > > > To: Doerr, Martin ; 'hotspot-compiler- > > > > dev at openjdk.java.net' ; > jdk- > > > > updates-dev at openjdk.java.net > > > > Cc: Langer, Christoph ; Lindenmaier, Goetz > > > > > > > > Subject: RE: [11u] RFR: 8248901: Signed immediate support in > > > > .../share/assembler.hpp is broken.memory chain > > > > > > > > Lgtm. > > > > > > > > Thanks, > > > > Paul > > > > > > > > ?-----Original Message----- > > > > From: jdk-updates-dev on > > > > behalf of "Doerr, Martin" > > > > Date: Monday, December 21, 2020 at 8:52 AM > > > > To: "'hotspot-compiler-dev at openjdk.java.net'" > > > dev at openjdk.java.net>, "jdk-updates-dev at openjdk.java.net" > > > updates-dev at openjdk.java.net> > > > > Cc: "Langer, Christoph" , "Lindenmaier, > > > Goetz" > > > > > > > > Subject: [11u] RFR: 8248901: Signed immediate support in > > > > .../share/assembler.hpp is broken.memory chain > > > > > > > > Hi, > > > > > > > > JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for > > parity. > > > > Change applies cleanly, but precond macro is missing in 11u. I've taken it > > > from > > > > JDK-8223140 (http://hg.openjdk.java.net/jdk/jdk/rev/6b77693eda6a). > > > > > > > > Bug: > > > > https://bugs.openjdk.java.net/browse/JDK-8248901 > > > > > > > > Original change: > > > > https://hg.openjdk.java.net/jdk/jdk/rev/ce8fb40c9174 > > > > > > > > Clean 11u backport with added precond and postcond macros: > > > > > > http://cr.openjdk.java.net/~mdoerr/8248901_assembler_11u/webrev.00/ > > > > > > > > Please review. > > > > > > > > Best regards, > > > > Martin > > > > From martin.doerr at sap.com Tue Dec 29 15:59:28 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 29 Dec 2020 15:59:28 +0000 Subject: [11u] RFR: 8247766: [aarch64] guarantee(val < (1U << nbits)) failed: Field too big for insn In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Best regards, Martin From: Lindenmaier, Goetz Sent: Dienstag, 29. Dezember 2020 16:53 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8247766: [aarch64] guarantee(val < (1U << nbits)) failed: Field too big for insn Hi, Looks good to me, adaptions are trivial. Thanks, Goetz. From: Doerr, Martin > Sent: Wednesday, December 23, 2020 10:28 PM To: 'hotspot-compiler-dev at openjdk.java.net' >; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8247766: [aarch64] guarantee(val < (1U << nbits)) failed: Field too big for insn Hi, JDK-8247766 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly. I had to apply failing hunks manually which are listed here: http://cr.openjdk.java.net/~mdoerr/8247766_aarch64_11u/8247766_aarch64_failed_hunks.txt Note that there are minor differences regarding integer types. I've taken the new implementation. In addition, I have taken "legitimize_address" from upstream. It was missing in 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8247766 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/40c07de877ab 11u backport: http://cr.openjdk.java.net/~mdoerr/8247766_aarch64_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Tue Dec 29 16:00:12 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 29 Dec 2020 16:00:12 +0000 Subject: [11u] RFR: 8255544: Create a checked cast In-Reply-To: References: Message-ID: Hi G?tz, > Ok, so there is only the definition of the checked_cast remaining. Right. It's needed for future backports. Thanks for the review! Best regards, Martin From: Lindenmaier, Goetz Sent: Dienstag, 29. Dezember 2020 16:59 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8255544: Create a checked cast Hi, Ok, so there is only the definition of the checked_cast remaining. Looks good. Best regards, Goetz. From: Doerr, Martin > Sent: Monday, December 28, 2020 2:18 PM To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8255544: Create a checked cast Hi, JDK-8255544 is backported to 11.0.11-oracle. I'd like to backport it for parity. And it's required by other backports. Change doesn't apply cleanly: globalDefinitions.hpp: I had to apply the hunk manually because of unrelated context changes. heap.cpp: Doesn't apply because JDK-8231460 is not in 11u. I suggest to skip it. Bug: https://bugs.openjdk.java.net/browse/JDK-8255544 Original change: https://github.com/openjdk/jdk/commit/3302d3ad 11u backport: http://cr.openjdk.java.net/~mdoerr/8255544_checked_cast_11u/webrev.00/ Please review. Best regards, Martin From goetz.lindenmaier at sap.com Tue Dec 29 16:11:13 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Dec 2020 16:11:13 +0000 Subject: [11u] RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches In-Reply-To: References: Message-ID: Hi Martin, Both changes look good. They have only trivial adaptions. I'is a bit strange to have an #include in an ad file, But that was already introduced in the original file. So no issue for the downport. It should have gone to adlc/main.cpp. Best regards, Goetz. From: Doerr, Martin Sent: Monday, December 28, 2020 4:30 PM To: 'hotspot-compiler-dev at openjdk.java.net' ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches Hi, I'd like to backport the following PPC64 fixes to 11u together: https://bugs.openjdk.java.net/browse/JDK-8257423 https://bugs.openjdk.java.net/browse/JDK-8257798 (2nd one is a follow-up fix for some builds) Both changes don't apply cleanly, but are trivial to resolve: 1st one didn't apply because Universe::narrow_klass_base() was moved to CompressedKlassPointers::base() which is used in old version of MacroAssembler::instr_size_for_decode_klass_not_null. 2nd one didn't apply because of unrelated context changes. I just had to apply the hunks manually. Original changes: https://github.com/openjdk/jdk/commit/1d2d9815 https://github.com/openjdk/jdk/commit/46b35acf 11u backports: http://cr.openjdk.java.net/~mdoerr/8257423_PPC_UseInlineCaches_11u/webrev.00/ http://cr.openjdk.java.net/~mdoerr/8257798_PPC_build_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Tue Dec 29 16:19:15 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 29 Dec 2020 16:19:15 +0000 Subject: [11u] RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches In-Reply-To: References: Message-ID: Hi G?tz, > So no issue for the downport. It should have gone to adlc/main.cpp. Right, that would have been another option. But it seems like only PPC needs it. Thanks for the review! Best regards, Martin From: Lindenmaier, Goetz Sent: Dienstag, 29. Dezember 2020 17:11 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' ; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches Hi Martin, Both changes look good. They have only trivial adaptions. I'is a bit strange to have an #include in an ad file, But that was already introduced in the original file. So no issue for the downport. It should have gone to adlc/main.cpp. Best regards, Goetz. From: Doerr, Martin > Sent: Monday, December 28, 2020 4:30 PM To: 'hotspot-compiler-dev at openjdk.java.net' >; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches Hi, I'd like to backport the following PPC64 fixes to 11u together: https://bugs.openjdk.java.net/browse/JDK-8257423 https://bugs.openjdk.java.net/browse/JDK-8257798 (2nd one is a follow-up fix for some builds) Both changes don't apply cleanly, but are trivial to resolve: 1st one didn't apply because Universe::narrow_klass_base() was moved to CompressedKlassPointers::base() which is used in old version of MacroAssembler::instr_size_for_decode_klass_not_null. 2nd one didn't apply because of unrelated context changes. I just had to apply the hunks manually. Original changes: https://github.com/openjdk/jdk/commit/1d2d9815 https://github.com/openjdk/jdk/commit/46b35acf 11u backports: http://cr.openjdk.java.net/~mdoerr/8257423_PPC_UseInlineCaches_11u/webrev.00/ http://cr.openjdk.java.net/~mdoerr/8257798_PPC_build_11u/webrev.00/ Please review. Best regards, Martin From akashche at redhat.com Tue Dec 29 19:34:17 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 29 Dec 2020 19:34:17 +0000 Subject: [11u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources In-Reply-To: References: Message-ID: On 12/22/20, Langer, Christoph wrote: > Hi Alex, > > thanks for doing this backport. It looks good to me. As you mention, it > should be pushed together with these follow up items which are all part of > 11.0.11-oracle as well: > https://bugs.openjdk.java.net/browse/JDK-8257670 > https://bugs.openjdk.java.net/browse/JDK-8257884 > https://bugs.openjdk.java.net/browse/JDK-8257997 Thanks for the review! I've flagged all 4 issues for approval. > > [...] > -- -Alex From goetz.lindenmaier at sap.com Wed Dec 30 06:55:51 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 30 Dec 2020 06:55:51 +0000 Subject: [11u notice]: jdk11u containing 11.0.10 is closed now Message-ID: Hi, The jdk11u repository is closed now for preparation of the embargoed security changes. As there were no new changes in the past week, I will not push another tag. jdk-11.0.10+8 is the last tag. Best regards, Goetz See also https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u From goetz.lindenmaier at sap.com Wed Dec 30 10:14:03 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 30 Dec 2020 10:14:03 +0000 Subject: [11u] RFR: 8234742: Improve handshake logging In-Reply-To: References: Message-ID: Hi Martin, I had a look at your change. I also compared it with the original version that has both involved changes. You might want to adapt the comment: - // hence it is skipped in handshake_process_by_vmthread. + // hence it is skipped in handshake_try_process_by_vmthread. I don't need a new webrev. Looks good. Best regards, Goetz. From: Doerr, Martin Sent: Wednesday, December 23, 2020 4:11 PM To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8234742: Improve handshake logging Hi, JDK-8234742 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly at all, mainly because JDK-8244340 was integrated before this one which was in the wrong order. (Failing hunks are listed here: http://cr.openjdk.java.net/~mdoerr/8234742_handshake_11u/8234742_handshake_failing_hunks.txt) So my 11u backport is supposed to reflect the state of both changes integrated. Bug: https://bugs.openjdk.java.net/browse/JDK-8234742 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/c2ce3849c62f Other change which was backported in the wrong order and from which I've taken small parts: https://hg.openjdk.java.net/jdk/jdk/rev/67a435ce2dc2 11u backport: http://cr.openjdk.java.net/~mdoerr/8234742_handshake_11u/webrev.00/ Please review. Best regards, Martin From christoph.langer at sap.com Wed Dec 30 10:29:43 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Dec 2020 10:29:43 +0000 Subject: [11u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources In-Reply-To: References: Message-ID: Hi Alex, I've approved all items. You wrote in some comments that you had jcheck issues due to different author naming in the original git changes vs. mercurial. Did you use git hg-export [1]? Are you aware of it? I usually use it for every backport and it seemed to work fine for me every time so far. (Although I heard of issues with it with larger commit messages or something like that.) Best regards Christoph https://wiki.openjdk.java.net/display/SKARA/git-hg-export > -----Original Message----- > From: Alex Kashchenko > Sent: Dienstag, 29. Dezember 2020 20:34 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8256818: SSLSocket that is never bound or connected > leaks socket resources > > On 12/22/20, Langer, Christoph wrote: > > Hi Alex, > > > > thanks for doing this backport. It looks good to me. As you mention, it > > should be pushed together with these follow up items which are all part of > > 11.0.11-oracle as well: > > https://bugs.openjdk.java.net/browse/JDK-8257670 > > https://bugs.openjdk.java.net/browse/JDK-8257884 > > https://bugs.openjdk.java.net/browse/JDK-8257997 > > Thanks for the review! I've flagged all 4 issues for approval. > > > > > [...] > > > > -- > -Alex From martin.doerr at sap.com Wed Dec 30 10:57:01 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 30 Dec 2020 10:57:01 +0000 Subject: [11u] RFR: 8234742: Improve handshake logging In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Pushed with your suggestion. Best regards, Martin From: Lindenmaier, Goetz Sent: Mittwoch, 30. Dezember 2020 11:14 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8234742: Improve handshake logging Hi Martin, I had a look at your change. I also compared it with the original version that has both involved changes. You might want to adapt the comment: - // hence it is skipped in handshake_process_by_vmthread. + // hence it is skipped in handshake_try_process_by_vmthread. I don't need a new webrev. Looks good. Best regards, Goetz. From: Doerr, Martin > Sent: Wednesday, December 23, 2020 4:11 PM To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8234742: Improve handshake logging Hi, JDK-8234742 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly at all, mainly because JDK-8244340 was integrated before this one which was in the wrong order. (Failing hunks are listed here: http://cr.openjdk.java.net/~mdoerr/8234742_handshake_11u/8234742_handshake_failing_hunks.txt) So my 11u backport is supposed to reflect the state of both changes integrated. Bug: https://bugs.openjdk.java.net/browse/JDK-8234742 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/c2ce3849c62f Other change which was backported in the wrong order and from which I've taken small parts: https://hg.openjdk.java.net/jdk/jdk/rev/67a435ce2dc2 11u backport: http://cr.openjdk.java.net/~mdoerr/8234742_handshake_11u/webrev.00/ Please review. Best regards, Martin From akashche at redhat.com Wed Dec 30 15:30:10 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 30 Dec 2020 15:30:10 +0000 Subject: [11u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources In-Reply-To: References: Message-ID: On 12/30/20, Langer, Christoph wrote: > Hi Alex, > > I've approved all items. Thanks! Pushed. > > You wrote in some comments that you had jcheck issues due to different > author naming in the original git changes vs. mercurial. > > Did you use git hg-export [1]? Are you aware of it? I usually use it for > every backport and it seemed to work fine for me every time so far. > (Although I heard of issues with it with larger commit messages or something > like that.) Thanks for the pointer, no I haven't used Skara and was not aware of hg-export, this was my first backport from git to hg. Will use Skara for such backports in future. > > Best regards > Christoph > > https://wiki.openjdk.java.net/display/SKARA/git-hg-export > > [...] > -- -Alex