From yan at azul.com Mon Mar 1 08:07:35 2021 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 1 Mar 2021 11:07:35 +0300 Subject: [15u] RFR: 8262541: Bump update version for OpenJDK: jdk-15.0.3 Message-ID: Hi, we have several fixes presumably targeted to April release of jdk15u which should be 15.0.3, so I need to bump the version. Release value 15.0.3 is defined in JBS. Expected release date is 2021-04-20 I'll push the change after hgupdater is switched to it for http://hg.openjdk.java.net/jdk-updates/jdk15u/. Webrev: http://cr.openjdk.java.net/~yan/8262541/webrev.0/ Thanks, --yan From shade at openjdk.java.net Mon Mar 1 10:28:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 1 Mar 2021 10:28:59 GMT Subject: [jdk16u] RFR: 8261912: Code IfNode::fold_compares_helper more defensively Message-ID: This fixes C2 miscompilation. Risk is low, as it limits the optimization where it would have miscompiled. ------------- Commit messages: - Backport e9f3aab7f483818944faf8638f421c6960fafbd2 Changes: https://git.openjdk.java.net/jdk16u/pull/48/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=48&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261912 Stats: 23 lines in 1 file changed: 15 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk16u/pull/48.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/48/head:pull/48 PR: https://git.openjdk.java.net/jdk16u/pull/48 From shade at openjdk.java.net Mon Mar 1 10:50:05 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 1 Mar 2021 10:50:05 GMT Subject: [jdk16u] RFR: 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp Message-ID: This improves Shenandoah tests reliability. Affected tests fail with -Xcomp before the patch, and pass after. ------------- Commit messages: - Backport c3c6662528311d3fd3f29bb0131fc5cfd832183c Changes: https://git.openjdk.java.net/jdk16u/pull/49/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=49&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259954 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/49/head:pull/49 PR: https://git.openjdk.java.net/jdk16u/pull/49 From shade at openjdk.java.net Mon Mar 1 11:03:01 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 1 Mar 2021 11:03:01 GMT Subject: [jdk16u] RFR: 8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java Message-ID: This improves coverage for Shenandoah. This test fails without JDK-8255401 and passes with it. ------------- Commit messages: - Backport db6f39302b972a468452e2c2b7200039b2c23556 Changes: https://git.openjdk.java.net/jdk16u/pull/50/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=50&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251944 Stats: 24 lines in 1 file changed: 22 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/50/head:pull/50 PR: https://git.openjdk.java.net/jdk16u/pull/50 From shade at openjdk.java.net Mon Mar 1 11:08:05 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 1 Mar 2021 11:08:05 GMT Subject: [jdk16u] RFR: 8259580: Shenandoah: uninitialized label in VerifyThreadGCState Message-ID: Stabilizes Shenandoah verification. "label" is passed, but never hooked into the field. So instead of reporting a GC bug, Verifier would probably crash itself trying to read garbage memory. ------------- Commit messages: - Backport 2e124544e6feafe925ada70dc37e82656fd8beee Changes: https://git.openjdk.java.net/jdk16u/pull/51/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=51&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259580 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk16u/pull/51.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/51/head:pull/51 PR: https://git.openjdk.java.net/jdk16u/pull/51 From shade at openjdk.java.net Mon Mar 1 11:40:01 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 1 Mar 2021 11:40:01 GMT Subject: [jdk16u] RFR: 8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers Message-ID: <-TNQUBQGMdBbQXN1FnuK44yvBDcewjQ-czVcEzAiVCY=.6fee78e0-98b4-410b-b532-337c4f158515@github.com> This fixes a minor Shenandoah inefficiency and allows clean backports of other fixes. ------------- Commit messages: - Backport f80c63b38035f6b6969cca08cfc534d0476105af Changes: https://git.openjdk.java.net/jdk16u/pull/52/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=52&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258490 Stats: 44 lines in 1 file changed: 21 ins; 15 del; 8 mod Patch: https://git.openjdk.java.net/jdk16u/pull/52.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/52/head:pull/52 PR: https://git.openjdk.java.net/jdk16u/pull/52 From shade at openjdk.java.net Mon Mar 1 12:17:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 1 Mar 2021 12:17:00 GMT Subject: [jdk16u] RFR: 8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary Message-ID: <4QNyjHFfZUmmJOLLuRT9D88_1POmH3xslznARsCwg7U=.329aa9e4-2973-4f7e-b386-63574c974f3e@github.com> This trivial backport simplifies the fastpath in fastdebug builds. Additional testing: - [x] hotspot_gc_shenandoah ------------- Commit messages: - Backport 5940287b9fa494cf8ddff634a698b0f4891b6f7b Changes: https://git.openjdk.java.net/jdk16u/pull/53/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=53&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260048 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/53.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/53/head:pull/53 PR: https://git.openjdk.java.net/jdk16u/pull/53 From shade at openjdk.java.net Mon Mar 1 12:35:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 1 Mar 2021 12:35:59 GMT Subject: [jdk16u] RFR: 8261413: Shenandoah: Disable class-unloading in I-U mode Message-ID: This workarounds the bug in non-default Shenandoah mode. The risk is low, as it only affects Shenandoah code. Additional testing: - [x] hotspot_gc_shenandoah ------------- Commit messages: - Backport e2d52ae2656deab98229a4701810334e9cc8519a Changes: https://git.openjdk.java.net/jdk16u/pull/54/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=54&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261413 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16u/pull/54.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/54/head:pull/54 PR: https://git.openjdk.java.net/jdk16u/pull/54 From shade at openjdk.java.net Mon Mar 1 12:58:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 1 Mar 2021 12:58:58 GMT Subject: [jdk16u] RFR: 8261251: Shenandoah: Use object size for full GC humongous compaction Message-ID: This fixes a minor performance issue in Shenandoah (which becomes asserted in later projects, i.e. Loom). Additional testing: - [x] hotspot_gc_shenandoah ------------- Commit messages: - Backport deb0544ff330fadc5aac0378766bcd36c220d7e2 Changes: https://git.openjdk.java.net/jdk16u/pull/55/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=55&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261251 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/55.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/55/head:pull/55 PR: https://git.openjdk.java.net/jdk16u/pull/55 From zgu at openjdk.java.net Mon Mar 1 13:40:47 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 1 Mar 2021 13:40:47 GMT Subject: [jdk16u] RFR: 8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers In-Reply-To: <-TNQUBQGMdBbQXN1FnuK44yvBDcewjQ-czVcEzAiVCY=.6fee78e0-98b4-410b-b532-337c4f158515@github.com> References: <-TNQUBQGMdBbQXN1FnuK44yvBDcewjQ-czVcEzAiVCY=.6fee78e0-98b4-410b-b532-337c4f158515@github.com> Message-ID: <_Nh-Gw2tk85Vk6LUJOTmu5TodDlKFGXdpfB_m3qtB3o=.e7356a70-38b9-4423-9823-54d1ab1b8b51@github.com> On Mon, 1 Mar 2021 11:35:08 GMT, Aleksey Shipilev wrote: > This fixes a minor Shenandoah inefficiency and allows clean backports of other fixes. Marked as reviewed by zgu (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16u/pull/52 From zgu at openjdk.java.net Mon Mar 1 13:42:46 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 1 Mar 2021 13:42:46 GMT Subject: [jdk16u] RFR: 8261251: Shenandoah: Use object size for full GC humongous compaction In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 12:53:04 GMT, Aleksey Shipilev wrote: > This fixes a minor performance issue in Shenandoah (which becomes asserted in later projects, i.e. Loom). > > Additional testing: > - [x] hotspot_gc_shenandoah Marked as reviewed by zgu (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16u/pull/55 From zgu at openjdk.java.net Mon Mar 1 13:43:49 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 1 Mar 2021 13:43:49 GMT Subject: [jdk16u] RFR: 8261413: Shenandoah: Disable class-unloading in I-U mode In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 12:29:47 GMT, Aleksey Shipilev wrote: > This workarounds the bug in non-default Shenandoah mode. The risk is low, as it only affects Shenandoah code. > > Additional testing: > - [x] hotspot_gc_shenandoah Marked as reviewed by zgu (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16u/pull/54 From ewhelan at openjdk.java.net Mon Mar 1 15:54:05 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Mon, 1 Mar 2021 15:54:05 GMT Subject: [jdk16u] RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows Message-ID: 8252883: AccessDeniedException caused by delayed file deletion on Windows ------------- Commit messages: - 8252883: AccessDeniedException caused by delayed file deletion on Windows Changes: https://git.openjdk.java.net/jdk16u/pull/56/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=56&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252883 Stats: 73 lines in 2 files changed: 72 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/56.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/56/head:pull/56 PR: https://git.openjdk.java.net/jdk16u/pull/56 From rob.mckenna at oracle.com Mon Mar 1 17:20:46 2021 From: rob.mckenna at oracle.com (Robert Mckenna) Date: Mon, 1 Mar 2021 17:20:46 +0000 Subject: [16u Communication] Heads up: Final few days for 16.0.1 fixes Message-ID: Hi folks, Just a heads up: we expect to stop accepting fixes for 16.0.1 by the end of this week. If you need something in 16.0.1 please file a fix request ASAP. -Rob From evergizova at openjdk.java.net Mon Mar 1 18:28:10 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Mon, 1 Mar 2021 18:28:10 GMT Subject: [jdk13u-dev] RFR: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines Message-ID: <2WQudEYkgI_0bXHY12Sk7QWJST0iHdIok0cJLGD-0E8=.ac7ad753-4c9b-4385-a2d5-8e801d02fe90@github.com> I'd like to backport JDK-8257746 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 similar places in cgroupv1/Metrics.java. Tested with tier1 and container tests. ------------- Commit messages: - Backport abc4300de9c7a298c359fb585d3b0570a98df5cb Changes: https://git.openjdk.java.net/jdk13u-dev/pull/133/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=133&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257746 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/133.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/133/head:pull/133 PR: https://git.openjdk.java.net/jdk13u-dev/pull/133 From sgehwolf at openjdk.java.net Mon Mar 1 18:49:50 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 1 Mar 2021 18:49:50 GMT Subject: [jdk13u-dev] RFR: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines In-Reply-To: <2WQudEYkgI_0bXHY12Sk7QWJST0iHdIok0cJLGD-0E8=.ac7ad753-4c9b-4385-a2d5-8e801d02fe90@github.com> References: <2WQudEYkgI_0bXHY12Sk7QWJST0iHdIok0cJLGD-0E8=.ac7ad753-4c9b-4385-a2d5-8e801d02fe90@github.com> Message-ID: On Mon, 1 Mar 2021 18:22:40 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8257746 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 similar places in cgroupv1/Metrics.java. > Tested with tier1 and container tests. Looks fine. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/133 From sgehwolf at redhat.com Mon Mar 1 18:57:25 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 01 Mar 2021 19:57:25 +0100 Subject: [11u] RFR: 8255086: Update the root locale display names Message-ID: <4184f178de22039c60e82cae52535ab9249f75f0.camel@redhat.com> Hi, Please review this 11u backport. It's the same patch as for head, modulo the @bug line in LocaleDataTest.java as some of the other changes which touched that test in jdk/jdk[1] aren't in 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8255086 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8255086/jdk11/01/webrev/ Testing: Linux x86_64 tier1 tests and changed tests which fail before and pass after the patch. Thoughts? Thanks, Severin [1] These bugs: 8221432 8230284 8231273 8233579 From prr at openjdk.java.net Mon Mar 1 20:32:19 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 1 Mar 2021 20:32:19 GMT Subject: [jdk16u] Integrated: 8261170: Upgrade to freetype 2.10.4 Message-ID: backport ------------- Commit messages: - 8261170: Upgrade to freetype 2.10.4 Changes: https://git.openjdk.java.net/jdk16u/pull/58/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=58&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261170 Stats: 4253 lines in 265 files changed: 1642 ins; 1368 del; 1243 mod Patch: https://git.openjdk.java.net/jdk16u/pull/58.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/58/head:pull/58 PR: https://git.openjdk.java.net/jdk16u/pull/58 From prr at openjdk.java.net Mon Mar 1 20:32:20 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 1 Mar 2021 20:32:20 GMT Subject: [jdk16u] Integrated: 8261170: Upgrade to freetype 2.10.4 In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 20:24:58 GMT, Phil Race wrote: > backport This pull request has now been integrated. Changeset: f36b10ac Author: Phil Race URL: https://git.openjdk.java.net/jdk16u/commit/f36b10ac Stats: 4253 lines in 265 files changed: 1642 ins; 1368 del; 1243 mod 8261170: Upgrade to freetype 2.10.4 Backport-of: 228c2857154cd6208cfbbe024a65ef31016e2ec4 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/58 From hohensee at amazon.com Mon Mar 1 22:50:07 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 1 Mar 2021 22:50:07 +0000 Subject: [11u] RFR: 8255086: Update the root locale display names Message-ID: <9B2B5761-061D-4F50-B83A-8B4EC7337FB1@amazon.com> Lgtm. A cursory look at the four issues in [1] says they might worth backporting too. But, I don't know what our policy on updating CLDR versions is for 11u. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Severin Gehwolf Date: Monday, March 1, 2021 at 10:58 AM To: jdk-updates-dev Subject: [11u] RFR: 8255086: Update the root locale display names Hi, Please review this 11u backport. It's the same patch as for head, modulo the @bug line in LocaleDataTest.java as some of the other changes which touched that test in jdk/jdk[1] aren't in 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8255086 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8255086/jdk11/01/webrev/ Testing: Linux x86_64 tier1 tests and changed tests which fail before and pass after the patch. Thoughts? Thanks, Severin [1] These bugs: 8221432 8230284 8231273 8233579 From erik.gahlin at oracle.com Tue Mar 2 05:10:52 2021 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 2 Mar 2021 05:10:52 +0000 Subject: [External] : Re: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization In-Reply-To: <81cf7fbc-db6a-4bed-8014-22762c9baa5c.qingfeng.yy@alibaba-inc.com> References: <80fd05f0-9a1c-4e50-a3fb-e855f626bd43.qingfeng.yy@alibaba-inc.com> <3f2288be-bd71-48be-93c6-73b9214150b8.qingfeng.yy@alibaba-inc.com>, , <74d45cb0-9779-40c0-921f-917159b424c9.qingfeng.yy@alibaba-inc.com>, , <81cf7fbc-db6a-4bed-8014-22762c9baa5c.qingfeng.yy@alibaba-inc.com> Message-ID: Hi Yang, > I mean, deoptimization is an important mechanism of VM, so deoptimization is also an important event. However, there are no quantitative indicators to measure what is "important". Given some JFR events like GCReferenceStatistics, G1MMU, G1GarbageCollection, OldGarbageCollection, I would like to say that G1GarbageCollection and OldGarbageCollection are more important than GCReferenceStatistics and G1MMU . About 15 events have been added between JDK 11 and JDK 17, several of them more important than the Deoptimization event (in my opinion). If we start adding events/features, it's likely to lead to issues at some point. > Our customer has an application that uses code generation, the generated code contains many if statements that might cause unstable_if deoptimization, and the generated code shows a significant performance degradation. They hope to continuously monitor what is causing the performance degradation of the generated code, so they need to monitor some indicators like full gc, deoptimize, etc. It doesn't seem like a very common use case. It has to weighted against all the people who will not benefit from the event. You can always run on a more recent JDK release if you want to get the information. It's important to build confidence in the technology, so users are not hesitant to use JFR on production servers. If a bug is introduced in a security upgrade, users may decide to remove -XX:StartFlightRecording going forward. It would be unfortunate. Thanks Erik ________________________________ From: Yang Yi Sent: Wednesday, February 24, 2021 3:45 AM To: Erik Gahlin ; Langer, Christoph ; jdk-updates-dev at openjdk.java.net ; Mario Torre ; Andrew Haley Subject: [External] : Re: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization Hi Erik, Let me clarify the previous response and add some content. > I'm not sure I understand what you mean with an essential JFR event, I mean, deoptimization is an important mechanism of VM, so deoptimization is also an important event. However, there are no quantitative indicators to measure what is "important". Given some JFR events like GCReferenceStatistics, G1MMU, G1GarbageCollection, OldGarbageCollection, I would like to say that G1GarbageCollection and OldGarbageCollection are more important than GCReferenceStatistics and G1MMU . > how customer can use this event to "estimate their code" in a new architecture that they can't do with a later release Our customer has an application that uses code generation, the generated code contains many if statements that might cause unstable_if deoptimization, and the generated code shows a significant performance degradation. They hope to continuously monitor what is causing the performance degradation of the generated code, so they need to monitor some indicators like full gc, deoptimize, etc. There are advantages and disadvantages to introducing a new event. Whether we are worth backporting is a question that needs broad consideration. If the community believes that the benefits of this backport are less than the risk, I will only backport it in the internal fork. Thanks, Yang ------------------------------------------------------------------ From:Erik Gahlin Send Time:2021 Feb. 24 (Wed.) 01:14 To:"Langer, Christoph" ; jdk-updates-dev at openjdk.java.net ; Mario Torre ; Andrew Haley ; "YANG, Yi" Subject:Re: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization Hi Yang, I'm not sure I understand what you mean with an essential JFR event, or how customer can use this event to "estimate their code" in a new architecture that they can't do with a later release, but we like to avoid backporting of events. Besides bugs introduced by the event itself, it can also lead to unexpected problems in tools/libraries that consume the data. Thanks Erik ________________________________ From: jdk-updates-dev on behalf of Yang Yi Sent: Tuesday, February 23, 2021 3:20 AM To: Langer, Christoph ; jdk-updates-dev at openjdk.java.net ; Mario Torre ; Andrew Haley Subject: Re: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization Hi Christoph, Thanks for sharing the information, it's really useful, I will withdraw other JFR feature backports. However, as for Deoptimization event, the reason why deoptimization event probably could be considered are as follows: 1. It's actually an essential JFR event rather than a feature/enhancement event 2. There are customers who really need this event to estimate their code on the new architecture.(That's why I did this backport) Just IMHO, please let me know more inputs :-) Cheers, Yang Yi , I think we could carefully consider it. ,????????????? ------------------------------------------------------------------ From:Langer, Christoph Send Time:2021 Feb. 23 (Tue.) 06:28 To:"YANG, Yi" ; jdk-updates-dev at openjdk.java.net ; Mario Torre ; Andrew Haley Subject:RE: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization Hi Yang Yi, thanks for proposing this backport. I don't have a review, rather a maintainers comment. There was an earlier discussion regarding JFR feature backports, e.g. additional events. See [0] and its predecessor mails. At the time we were reluctant to accept a proposed JFR event backport and I think it hasn't changed until today. There was a list compiled by Azul about potentially interesting JFR backports [1] which also contains the Deoptimization event but afterwards nothing happened. Since then I believe only bug fixes for JFR were accepted. I don't know whether we should change that for the Deoptimization event. Any thoughts by people involved with JFR? Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-December/002276.html [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002427.html > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Yang Yi > Sent: Donnerstag, 18. Februar 2021 06:27 > To: Yang Yi ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: Backport of 8216041: [Event Request] - > Deoptimization > > Gentle Ping :-) > ------------------Original Mail ------------------ > Sender:Yang Yi > Send Date:Sun Feb 7 16:54:52 2021 > Recipients:jdk-updates-dev at openjdk.java.net dev at openjdk.java.net> > Subject:[11u] RFR: Backport of 8216041: [Event Request] - Deoptimization > > Hi, > > Please can I request a review of this webrev for the backport of > https://bugs.openjdk.java.net/browse/JDK-8216041 ? > > Webrev: http://cr.openjdk.java.net/~ddong/yiyang/11u- > 8216041/webrev.00/ > > This patch doesn't apply cleanly but is fairly trivial. The signature of > method `Atomic::cmpxchg` and `register_static_type(jfrTypeManager.cpp)` > is > not different comparing to upstream and jdk11u. Simply adjusting the > argument position and adding extra parameters can solve this problem. > > Best,Yang Yi From shade at openjdk.java.net Tue Mar 2 08:09:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 08:09:48 GMT Subject: [jdk16u] Integrated: 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 10:44:57 GMT, Aleksey Shipilev wrote: > This improves Shenandoah tests reliability. Affected tests fail with -Xcomp before the patch, and pass after. This pull request has now been integrated. Changeset: cec58167 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/cec58167 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp Backport-of: c3c6662528311d3fd3f29bb0131fc5cfd832183c ------------- PR: https://git.openjdk.java.net/jdk16u/pull/49 From shade at openjdk.java.net Tue Mar 2 08:19:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 08:19:48 GMT Subject: [jdk16u] Integrated: 8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers In-Reply-To: <-TNQUBQGMdBbQXN1FnuK44yvBDcewjQ-czVcEzAiVCY=.6fee78e0-98b4-410b-b532-337c4f158515@github.com> References: <-TNQUBQGMdBbQXN1FnuK44yvBDcewjQ-czVcEzAiVCY=.6fee78e0-98b4-410b-b532-337c4f158515@github.com> Message-ID: On Mon, 1 Mar 2021 11:35:08 GMT, Aleksey Shipilev wrote: > This fixes a minor Shenandoah inefficiency and allows clean backports of other fixes. This pull request has now been integrated. Changeset: 395ab591 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/395ab591 Stats: 44 lines in 1 file changed: 21 ins; 15 del; 8 mod 8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers Reviewed-by: zgu Backport-of: f80c63b38035f6b6969cca08cfc534d0476105af ------------- PR: https://git.openjdk.java.net/jdk16u/pull/52 From shade at openjdk.java.net Tue Mar 2 08:19:51 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 08:19:51 GMT Subject: [jdk16u] Integrated: 8259580: Shenandoah: uninitialized label in VerifyThreadGCState In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 11:03:16 GMT, Aleksey Shipilev wrote: > Stabilizes Shenandoah verification. "label" is passed, but never hooked into the field. So instead of reporting a GC bug, Verifier would probably crash itself trying to read garbage memory. This pull request has now been integrated. Changeset: f0815541 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/f0815541 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8259580: Shenandoah: uninitialized label in VerifyThreadGCState Backport-of: 2e124544e6feafe925ada70dc37e82656fd8beee ------------- PR: https://git.openjdk.java.net/jdk16u/pull/51 From shade at openjdk.java.net Tue Mar 2 08:20:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 08:20:47 GMT Subject: [jdk16u] Integrated: 8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary In-Reply-To: <4QNyjHFfZUmmJOLLuRT9D88_1POmH3xslznARsCwg7U=.329aa9e4-2973-4f7e-b386-63574c974f3e@github.com> References: <4QNyjHFfZUmmJOLLuRT9D88_1POmH3xslznARsCwg7U=.329aa9e4-2973-4f7e-b386-63574c974f3e@github.com> Message-ID: On Mon, 1 Mar 2021 12:11:15 GMT, Aleksey Shipilev wrote: > This trivial backport simplifies the fastpath in fastdebug builds. > > Additional testing: > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: b9582bfc Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/b9582bfc Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod 8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary Backport-of: 5940287b9fa494cf8ddff634a698b0f4891b6f7b ------------- PR: https://git.openjdk.java.net/jdk16u/pull/53 From shade at openjdk.java.net Tue Mar 2 08:21:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 08:21:43 GMT Subject: [jdk16u] Integrated: 8261413: Shenandoah: Disable class-unloading in I-U mode In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 12:29:47 GMT, Aleksey Shipilev wrote: > This workarounds the bug in non-default Shenandoah mode. The risk is low, as it only affects Shenandoah code. > > Additional testing: > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: 39fb8e5a Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/39fb8e5a Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8261413: Shenandoah: Disable class-unloading in I-U mode Reviewed-by: zgu Backport-of: e2d52ae2656deab98229a4701810334e9cc8519a ------------- PR: https://git.openjdk.java.net/jdk16u/pull/54 From shade at openjdk.java.net Tue Mar 2 08:21:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 08:21:52 GMT Subject: [jdk16u] Integrated: 8261251: Shenandoah: Use object size for full GC humongous compaction In-Reply-To: References: Message-ID: <6yk9xVo8hsZRDLghEJu2bAEln0EJHmyl5bZyZsYRWCc=.0e88ee58-cfc1-4e63-af28-0cf040d70986@github.com> On Mon, 1 Mar 2021 12:53:04 GMT, Aleksey Shipilev wrote: > This fixes a minor performance issue in Shenandoah (which becomes asserted in later projects, i.e. Loom). > > Additional testing: > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: 101e7429 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/101e7429 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8261251: Shenandoah: Use object size for full GC humongous compaction Reviewed-by: zgu Backport-of: deb0544ff330fadc5aac0378766bcd36c220d7e2 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/55 From abrygin at azul.com Tue Mar 2 09:16:56 2021 From: abrygin at azul.com (Andrew Brygin) Date: Tue, 2 Mar 2021 12:16:56 +0300 Subject: [15u] RFR: 8262541: Bump update version for OpenJDK: jdk-15.0.3 In-Reply-To: References: Message-ID: Hello Yuri, the change looks fine. Thanks, Andrew On 01/03/2021 11:07, Yuri Nesterenko wrote: > Hi, > > we have several fixes presumably targeted to April release of jdk15u > which should be 15.0.3, so I need to bump the version. > Release value 15.0.3 is defined in JBS. > Expected release date is 2021-04-20 > > I'll push the change after hgupdater is switched to it for > http://hg.openjdk.java.net/jdk-updates/jdk15u/. > > Webrev: http://cr.openjdk.java.net/~yan/8262541/webrev.0/ > > Thanks, > --yan > From evergizova at openjdk.java.net Tue Mar 2 09:29:10 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 2 Mar 2021 09:29:10 GMT Subject: [jdk13u-dev] RFR: 8232905: JFR fails with assertion: assert(t->unflushed_size() == 0) failed: invariant Message-ID: I'd like to backport JDK-8232905 to 13u for parity with 11u. The patch applies cleanly. Tested with tier1 and jdk/jfr tests. ------------- Commit messages: - Backport 24bff84cb3516cb0ae46b3b8773eba205e1eb8ab Changes: https://git.openjdk.java.net/jdk13u-dev/pull/134/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=134&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232905 Stats: 12 lines in 1 file changed: 5 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/134.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/134/head:pull/134 PR: https://git.openjdk.java.net/jdk13u-dev/pull/134 From shade at openjdk.java.net Tue Mar 2 09:35:04 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 09:35:04 GMT Subject: [jdk16u] RFR: 8259849: Shenandoah: Rename store-val to IU-barrier Message-ID: <5Ja5zQmGkafXJbHpGAM6LRnpO6AndD6saniGWs1nrxs=.53f8fb73-9922-4d74-ac83-65d8f9022bf0@github.com> This improves Shenandoah UX and prepares ground for future backports. Additional testing: - [x] hotspot_gc_shenandoah ------------- Commit messages: - Backport e60c9926993d530fabf92d22b1e92b89bd850c51 Changes: https://git.openjdk.java.net/jdk16u/pull/59/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=59&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259849 Stats: 131 lines in 26 files changed: 0 ins; 5 del; 126 mod Patch: https://git.openjdk.java.net/jdk16u/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/59/head:pull/59 PR: https://git.openjdk.java.net/jdk16u/pull/59 From shade at openjdk.java.net Tue Mar 2 10:06:07 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 10:06:07 GMT Subject: [jdk16u] RFR: 8260933: runtime/cds/serviceability/ReplaceCriticalClassesForSubgraphs.java fails without CompactStrings Message-ID: This stabilizes the test. Additional testing: - [x] Linux x86_64 fastdebug, affected tests with/without `-XX:-CompactStrings` ------------- Commit messages: - Backport 9f0f0c9870b9e09aff4dca20bd1404a1872ac566 Changes: https://git.openjdk.java.net/jdk16u/pull/60/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=60&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260933 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/60/head:pull/60 PR: https://git.openjdk.java.net/jdk16u/pull/60 From shade at openjdk.java.net Tue Mar 2 10:13:01 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 10:13:01 GMT Subject: [jdk16u] RFR: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings Message-ID: <9HhEQaZSa6GtTTwhr55SCSy-T6Yx161jbLr-K3LPHeI=.62dbd96c-d018-4e49-87be-d01072ede9c2@github.com> This stabilizes the test. Additional testing: - [x] Linux x86_64 fastdebug, affected test, `-XX:-CompactStrings` - [x] Linux x86_64 fastdebug, affected test, `-XX:+CompactStrings` ------------- Commit messages: - Backport ad54d8dd832b22485d7ac45958cc4c9bfd70fbd2 Changes: https://git.openjdk.java.net/jdk16u/pull/61/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=61&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260934 Stats: 12 lines in 1 file changed: 7 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk16u/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk16u/pull/61 From shade at openjdk.java.net Tue Mar 2 10:35:02 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 10:35:02 GMT Subject: [jdk16u] RFR: 8259392: Zero error reporting is broken after JDK-8255711 Message-ID: This fixes the JDK 16 regression in Zero. Additional testing: - [x] Linux x86_64 zero fastdebug, affected tests now pass ------------- Commit messages: - Backport bb247b02c82b5b74a3b3a1ce76075e5d109829e1 Changes: https://git.openjdk.java.net/jdk16u/pull/62/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=62&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259392 Stats: 22 lines in 1 file changed: 6 ins; 10 del; 6 mod Patch: https://git.openjdk.java.net/jdk16u/pull/62.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/62/head:pull/62 PR: https://git.openjdk.java.net/jdk16u/pull/62 From shade at openjdk.java.net Tue Mar 2 10:46:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 10:46:58 GMT Subject: [jdk16u] RFR: 8259451: Zero: skip serviceability/sa tests, set vm.hasSA to false Message-ID: This cleans up test runs with Zero. Additional testing: - [x] Linux x86_64 zero, `serviceability/sa` (now skipped) - [x] Linux x86_64 server, `serviceability/sa` (still pass) ------------- Commit messages: - Backport 3974fd4f33fb7156e31a76bc039f493a86246988 Changes: https://git.openjdk.java.net/jdk16u/pull/63/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=63&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259451 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16u/pull/63.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/63/head:pull/63 PR: https://git.openjdk.java.net/jdk16u/pull/63 From shade at openjdk.java.net Tue Mar 2 11:19:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 11:19:52 GMT Subject: [jdk16u] RFR: 8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp Message-ID: This improves hs_errs after JDK 16 change, which might be confusing (compress klass ptrs are enabled, when hs_err is pointing out in only one place in heap info). Additional testing: - [x] Linux x86_64 fastdebug `tier1` ------------- Commit messages: - Backport a03e22bb14e0873a599320676fc9d2128a1e23cb Changes: https://git.openjdk.java.net/jdk16u/pull/64/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=64&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253910 Stats: 19 lines in 1 file changed: 8 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk16u/pull/64.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/64/head:pull/64 PR: https://git.openjdk.java.net/jdk16u/pull/64 From shade at openjdk.java.net Tue Mar 2 11:32:01 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 11:32:01 GMT Subject: [jdk16u] RFR: 8258534: Epsilon: clean up unused includes Message-ID: This simplifies the build and keeps codebases in sync. Additional testing: - [x] Linux x86_64 fastdebug `gc/epsilon` - [x] Linux x86_64 release `gc/epsilon` ------------- Commit messages: - Backport 3817c32fd1dba46ff1ee1831aa5efb03c6546ace Changes: https://git.openjdk.java.net/jdk16u/pull/65/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=65&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258534 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk16u/pull/65.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/65/head:pull/65 PR: https://git.openjdk.java.net/jdk16u/pull/65 From stuefe at openjdk.java.net Tue Mar 2 11:43:46 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 2 Mar 2021 11:43:46 GMT Subject: [jdk16u] RFR: 8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 11:14:38 GMT, Aleksey Shipilev wrote: > This improves hs_errs after JDK 16 change, which might be confusing (compress klass ptrs are enabled, when hs_err is pointing out in only one place in heap info). > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` LGTM. May be just me but it was not immediately clear that this is a backport to 16. I wondered why the issue was already marked as resolved. ..Thomas ------------- PR: https://git.openjdk.java.net/jdk16u/pull/64 From shade at openjdk.java.net Tue Mar 2 11:48:05 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 11:48:05 GMT Subject: [jdk16u] RFR: 8259231: Epsilon: improve performance under contention during virtual space expansion Message-ID: This improves Epsilon performance under heavy contention. Additional testing: - [x] Linux x86_64 fastdebug `gc/epsilon` - [x] Linux x86_64 release `gc/epsilon` ------------- Commit messages: - Backport 722f23610e128991e21ba1b56ddf2b7eec99e5c2 Changes: https://git.openjdk.java.net/jdk16u/pull/66/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=66&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259231 Stats: 39 lines in 1 file changed: 17 ins; 4 del; 18 mod Patch: https://git.openjdk.java.net/jdk16u/pull/66.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/66/head:pull/66 PR: https://git.openjdk.java.net/jdk16u/pull/66 From evergizova at openjdk.java.net Tue Mar 2 12:35:47 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 2 Mar 2021 12:35:47 GMT Subject: [jdk13u-dev] Integrated: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines In-Reply-To: <2WQudEYkgI_0bXHY12Sk7QWJST0iHdIok0cJLGD-0E8=.ac7ad753-4c9b-4385-a2d5-8e801d02fe90@github.com> References: <2WQudEYkgI_0bXHY12Sk7QWJST0iHdIok0cJLGD-0E8=.ac7ad753-4c9b-4385-a2d5-8e801d02fe90@github.com> Message-ID: On Mon, 1 Mar 2021 18:22:40 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8257746 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 similar places in cgroupv1/Metrics.java. > Tested with tier1 and container tests. This pull request has now been integrated. Changeset: c668a0c5 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk13u-dev/commit/c668a0c5 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines Reviewed-by: sgehwolf Backport-of: abc4300de9c7a298c359fb585d3b0570a98df5cb ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/133 From evergizova at openjdk.java.net Tue Mar 2 12:35:49 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 2 Mar 2021 12:35:49 GMT Subject: [jdk13u-dev] Integrated: 8232905: JFR fails with assertion: assert(t->unflushed_size() == 0) failed: invariant In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 09:19:39 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8232905 to 13u for parity with 11u. > The patch applies cleanly. > Tested with tier1 and jdk/jfr tests. This pull request has now been integrated. Changeset: 64f6dfa3 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk13u-dev/commit/64f6dfa3 Stats: 12 lines in 1 file changed: 5 ins; 6 del; 1 mod 8232905: JFR fails with assertion: assert(t->unflushed_size() == 0) failed: invariant Backport-of: 24bff84cb3516cb0ae46b3b8773eba205e1eb8ab ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/134 From shade at openjdk.java.net Tue Mar 2 15:39:49 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 15:39:49 GMT Subject: [jdk16u] Integrated: 8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 10:56:24 GMT, Aleksey Shipilev wrote: > This improves coverage for Shenandoah. This test fails without JDK-8255401 and passes with it. This pull request has now been integrated. Changeset: 09855d7d Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/09855d7d Stats: 24 lines in 1 file changed: 22 ins; 0 del; 2 mod 8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java Backport-of: db6f39302b972a468452e2c2b7200039b2c23556 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/50 From shade at openjdk.java.net Tue Mar 2 15:40:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 15:40:48 GMT Subject: [jdk16u] Integrated: 8259849: Shenandoah: Rename store-val to IU-barrier In-Reply-To: <5Ja5zQmGkafXJbHpGAM6LRnpO6AndD6saniGWs1nrxs=.53f8fb73-9922-4d74-ac83-65d8f9022bf0@github.com> References: <5Ja5zQmGkafXJbHpGAM6LRnpO6AndD6saniGWs1nrxs=.53f8fb73-9922-4d74-ac83-65d8f9022bf0@github.com> Message-ID: On Tue, 2 Mar 2021 09:29:02 GMT, Aleksey Shipilev wrote: > This improves Shenandoah UX and prepares ground for future backports. > > Additional testing: > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: 466eff33 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/466eff33 Stats: 131 lines in 26 files changed: 0 ins; 5 del; 126 mod 8259849: Shenandoah: Rename store-val to IU-barrier Backport-of: e60c9926993d530fabf92d22b1e92b89bd850c51 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/59 From shade at openjdk.java.net Tue Mar 2 15:40:49 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 15:40:49 GMT Subject: [jdk16u] Integrated: 8260933: runtime/cds/serviceability/ReplaceCriticalClassesForSubgraphs.java fails without CompactStrings In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 09:59:43 GMT, Aleksey Shipilev wrote: > This stabilizes the test. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected tests with/without `-XX:-CompactStrings` This pull request has now been integrated. Changeset: 6de0fae7 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/6de0fae7 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8260933: runtime/cds/serviceability/ReplaceCriticalClassesForSubgraphs.java fails without CompactStrings Backport-of: 9f0f0c9870b9e09aff4dca20bd1404a1872ac566 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/60 From shade at openjdk.java.net Tue Mar 2 15:41:50 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 15:41:50 GMT Subject: [jdk16u] Integrated: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings In-Reply-To: <9HhEQaZSa6GtTTwhr55SCSy-T6Yx161jbLr-K3LPHeI=.62dbd96c-d018-4e49-87be-d01072ede9c2@github.com> References: <9HhEQaZSa6GtTTwhr55SCSy-T6Yx161jbLr-K3LPHeI=.62dbd96c-d018-4e49-87be-d01072ede9c2@github.com> Message-ID: On Tue, 2 Mar 2021 10:07:32 GMT, Aleksey Shipilev wrote: > This stabilizes the test. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test, `-XX:-CompactStrings` > - [x] Linux x86_64 fastdebug, affected test, `-XX:+CompactStrings` This pull request has now been integrated. Changeset: 802c6ad9 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/802c6ad9 Stats: 12 lines in 1 file changed: 7 ins; 0 del; 5 mod 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings Backport-of: ad54d8dd832b22485d7ac45958cc4c9bfd70fbd2 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/61 From shade at openjdk.java.net Tue Mar 2 15:42:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 15:42:45 GMT Subject: [jdk16u] Integrated: 8259451: Zero: skip serviceability/sa tests, set vm.hasSA to false In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 10:40:20 GMT, Aleksey Shipilev wrote: > This cleans up test runs with Zero. > > Additional testing: > - [x] Linux x86_64 zero, `serviceability/sa` (now skipped) > - [x] Linux x86_64 server, `serviceability/sa` (still pass) This pull request has now been integrated. Changeset: 6198e0cb Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/6198e0cb Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8259451: Zero: skip serviceability/sa tests, set vm.hasSA to false Backport-of: 3974fd4f33fb7156e31a76bc039f493a86246988 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/63 From shade at openjdk.java.net Tue Mar 2 15:42:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 15:42:48 GMT Subject: [jdk16u] Integrated: 8259392: Zero error reporting is broken after JDK-8255711 In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 10:28:22 GMT, Aleksey Shipilev wrote: > This fixes the JDK 16 regression in Zero. > > Additional testing: > - [x] Linux x86_64 zero fastdebug, affected tests now pass This pull request has now been integrated. Changeset: bb285ce5 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/bb285ce5 Stats: 22 lines in 1 file changed: 6 ins; 10 del; 6 mod 8259392: Zero error reporting is broken after JDK-8255711 Backport-of: bb247b02c82b5b74a3b3a1ce76075e5d109829e1 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/62 From shade at openjdk.java.net Tue Mar 2 15:43:46 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 15:43:46 GMT Subject: [jdk16u] Integrated: 8259231: Epsilon: improve performance under contention during virtual space expansion In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 11:43:15 GMT, Aleksey Shipilev wrote: > This improves Epsilon performance under heavy contention. > > Additional testing: > - [x] Linux x86_64 fastdebug `gc/epsilon` > - [x] Linux x86_64 release `gc/epsilon` This pull request has now been integrated. Changeset: 81395c4f Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/81395c4f Stats: 39 lines in 1 file changed: 17 ins; 4 del; 18 mod 8259231: Epsilon: improve performance under contention during virtual space expansion Backport-of: 722f23610e128991e21ba1b56ddf2b7eec99e5c2 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/66 From ewhelan at openjdk.java.net Tue Mar 2 17:13:52 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 2 Mar 2021 17:13:52 GMT Subject: [jdk16u] Integrated: 8252883: AccessDeniedException caused by delayed file deletion on Windows In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 15:47:32 GMT, Evan Whelan wrote: > 8252883: AccessDeniedException caused by delayed file deletion on Windows This pull request has now been integrated. Changeset: 37544901 Author: Evan Whelan Committer: Rob McKenna URL: https://git.openjdk.java.net/jdk16u/commit/37544901 Stats: 73 lines in 2 files changed: 72 ins; 0 del; 1 mod 8252883: AccessDeniedException caused by delayed file deletion on Windows Backport-of: ebdc80ead9b2ffd5f0d1e16ca6b8bab94b5ae6f3 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/56 From ccheung at openjdk.java.net Tue Mar 2 17:23:17 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 2 Mar 2021 17:23:17 GMT Subject: [jdk16u] RFR: 8261860: Crash caused by lambda proxy class loaded in Shutdown hook Message-ID: <5iTbQvM7ATe66rVwXWfBSH0CkJl8DIjaUYQheT-ylMo=.0b1e3f79-8241-46fa-ac41-65273b767565@github.com> Backport ------------- Commit messages: - 8261860: Crash caused by lambda proxy class loaded in Shutdown hook Changes: https://git.openjdk.java.net/jdk16u/pull/67/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=67&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261860 Stats: 138 lines in 3 files changed: 137 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/67.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/67/head:pull/67 PR: https://git.openjdk.java.net/jdk16u/pull/67 From minqi at openjdk.java.net Tue Mar 2 17:36:44 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 2 Mar 2021 17:36:44 GMT Subject: [jdk16u] RFR: 8261860: Crash caused by lambda proxy class loaded in Shutdown hook In-Reply-To: <5iTbQvM7ATe66rVwXWfBSH0CkJl8DIjaUYQheT-ylMo=.0b1e3f79-8241-46fa-ac41-65273b767565@github.com> References: <5iTbQvM7ATe66rVwXWfBSH0CkJl8DIjaUYQheT-ylMo=.0b1e3f79-8241-46fa-ac41-65273b767565@github.com> Message-ID: On Tue, 2 Mar 2021 17:18:11 GMT, Calvin Cheung wrote: > Backport LGTM. ------------- Marked as reviewed by minqi (Committer). PR: https://git.openjdk.java.net/jdk16u/pull/67 From attila at openjdk.java.net Tue Mar 2 17:46:48 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Tue, 2 Mar 2021 17:46:48 GMT Subject: [jdk16u] RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" Message-ID: Backporting this to eliminate flakiness of tests ------------- Commit messages: - 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" Changes: https://git.openjdk.java.net/jdk16u/pull/68/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=68&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261483 Stats: 92 lines in 2 files changed: 71 ins; 8 del; 13 mod Patch: https://git.openjdk.java.net/jdk16u/pull/68.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/68/head:pull/68 PR: https://git.openjdk.java.net/jdk16u/pull/68 From attila at openjdk.java.net Tue Mar 2 17:46:48 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Tue, 2 Mar 2021 17:46:48 GMT Subject: [jdk16u] RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 17:38:12 GMT, Attila Szegedi wrote: > Backporting this to eliminate flakiness of tests The only reason this didn't get the "clean" label is that in 16u these tests were never put on the `test/jdk/ProblemList.txt` so the changes to that file don't apply here. ------------- PR: https://git.openjdk.java.net/jdk16u/pull/68 From shade at openjdk.java.net Tue Mar 2 18:55:50 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 18:55:50 GMT Subject: [jdk16u] RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 17:38:12 GMT, Attila Szegedi wrote: > Backporting this to eliminate flakiness of tests Looks fine. You still need to wait for `jdk16u-fix-yes` in JIRA. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk16u/pull/68 From cgo at openjdk.java.net Tue Mar 2 18:59:46 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Tue, 2 Mar 2021 18:59:46 GMT Subject: [jdk16u] Integrated: 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java fails if ergonomics detect too small InitialHeapSize In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 09:46:23 GMT, Christoph G?ttschkes wrote: > 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java fails if ergonomics detect too small InitialHeapSize This pull request has now been integrated. Changeset: b5ea9083 Author: Christoph G?ttschkes Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/b5ea9083 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java fails if ergonomics detect too small InitialHeapSize Backport-of: c7885eb1c5a8b44394780d749f602e175a0360a9 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/32 From shade at openjdk.java.net Tue Mar 2 19:00:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 19:00:45 GMT Subject: [jdk16u] RFR: 8261752: Multiple GC test are missing memory requirements In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 09:51:18 GMT, Christoph G?ttschkes wrote: > 8261752: Multiple GC test are missing memory requirements The backport looks good. You still need to wait for `jdk16u-fix-yes` in JIRA. Note: you have requested `jdk16-fix-request`, not "u". I changed it for you. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk16u/pull/33 From shade at openjdk.java.net Tue Mar 2 19:36:06 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 19:36:06 GMT Subject: [jdk16u] RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code Message-ID: <6vryfZFG9FkuPbtFfhtHD4K2Irqq1Pyy20qI64ke9So=.e7584f3e-350f-44bb-b806-cf59247aadeb@github.com> This unbreaks x86_32 tests with Shenandoah. Additional testing: - [x] Linux x86_64 fastdebug tier1,2 - [x] Linux x86_32 fastdebug tier1,2 `-XX:+UseShenandoahGC -XX:+UseSSE=1` - [x] Linux x86_32 fastdebug tier1,2 `-XX:+UseShenandoahGC -XX:+UseSSE=2` ------------- Commit messages: - Backport a97aedff9f622ba6816b7550588f1d429bff2483 Changes: https://git.openjdk.java.net/jdk16u/pull/69/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=69&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256215 Stats: 118 lines in 2 files changed: 69 ins; 13 del; 36 mod Patch: https://git.openjdk.java.net/jdk16u/pull/69.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/69/head:pull/69 PR: https://git.openjdk.java.net/jdk16u/pull/69 From shade at openjdk.java.net Tue Mar 2 19:45:55 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Mar 2021 19:45:55 GMT Subject: [jdk16u] RFR: 8260592: jpackage tests fail when Desktop is not supported Message-ID: This unbreaks jpackage tests on x86_32 cross-compiled builds. Additional testing: - [x] Linux x86_32 `tools/jpackage` (pass cleanly) ------------- Commit messages: - Backport 24a262124f507759d72cddc0d1371b31ef1661cf Changes: https://git.openjdk.java.net/jdk16u/pull/70/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=70&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260592 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16u/pull/70.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/70/head:pull/70 PR: https://git.openjdk.java.net/jdk16u/pull/70 From asemenyuk at openjdk.java.net Wed Mar 3 00:23:50 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 3 Mar 2021 00:23:50 GMT Subject: [jdk16u] RFR: 8260592: jpackage tests fail when Desktop is not supported In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 19:40:30 GMT, Aleksey Shipilev wrote: > This unbreaks jpackage tests on x86_32 cross-compiled builds. > > Additional testing: > - [x] Linux x86_32 `tools/jpackage` (pass cleanly) Marked as reviewed by asemenyuk (Author). ------------- PR: https://git.openjdk.java.net/jdk16u/pull/70 From iklam at openjdk.java.net Wed Mar 3 03:08:45 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 3 Mar 2021 03:08:45 GMT Subject: [jdk16u] RFR: 8261860: Crash caused by lambda proxy class loaded in Shutdown hook In-Reply-To: <5iTbQvM7ATe66rVwXWfBSH0CkJl8DIjaUYQheT-ylMo=.0b1e3f79-8241-46fa-ac41-65273b767565@github.com> References: <5iTbQvM7ATe66rVwXWfBSH0CkJl8DIjaUYQheT-ylMo=.0b1e3f79-8241-46fa-ac41-65273b767565@github.com> Message-ID: On Tue, 2 Mar 2021 17:18:11 GMT, Calvin Cheung wrote: > Backport Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16u/pull/67 From ccheung at openjdk.java.net Wed Mar 3 04:09:50 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 3 Mar 2021 04:09:50 GMT Subject: [jdk16u] Integrated: 8261860: Crash caused by lambda proxy class loaded in Shutdown hook In-Reply-To: <5iTbQvM7ATe66rVwXWfBSH0CkJl8DIjaUYQheT-ylMo=.0b1e3f79-8241-46fa-ac41-65273b767565@github.com> References: <5iTbQvM7ATe66rVwXWfBSH0CkJl8DIjaUYQheT-ylMo=.0b1e3f79-8241-46fa-ac41-65273b767565@github.com> Message-ID: On Tue, 2 Mar 2021 17:18:11 GMT, Calvin Cheung wrote: > Backport This pull request has now been integrated. Changeset: b5c5079a Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk16u/commit/b5c5079a Stats: 138 lines in 3 files changed: 137 ins; 0 del; 1 mod 8261860: Crash caused by lambda proxy class loaded in Shutdown hook Reviewed-by: minqi, iklam ------------- PR: https://git.openjdk.java.net/jdk16u/pull/67 From hohensee at amazon.com Wed Mar 3 04:48:38 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 03 Mar 2021 04:48:38 -0000 Subject: [11u] RFR: 8222518: Remove unnecessary caching of Parker object in java.lang.Thread In-Reply-To: References: Message-ID: Ping once more. Andrew, you haven't objected, so I'm hoping that's approval? :) Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Hohensee, Paul" Date: Wednesday, January 20, 2021 at 3:44 PM To: "Langer, Christoph" , Andrew Haley Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker object in java.lang.Thread Ping. :) -----Original Message----- From: "Langer, Christoph" Date: Monday, January 18, 2021 at 7:23 AM To: Andrew Haley Cc: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker object in java.lang.Thread Hi Andrew, with all evaluation and discussion of this item, I would be ready to approve it. Or would you object? Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Freitag, 15. Januar 2021 20:58 > To: Andrew Haley ; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker > object in java.lang.Thread > > As Richard noted, it's a useful cleanup and "reduces footprint without > performance cost." > > Amazon has a number of small performance/footprint backports we've been > running internally in 11.0.9 for the last 3 months that we?d like to upstream. > This is one of them. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on > behalf of Andrew Haley > Date: Thursday, January 14, 2021 at 2:51 AM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker > object in java.lang.Thread > > Can someone please explain why this P4 Enhancement is proposed for > backporting? > > -- > 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 tvoniadka at openjdk.java.net Wed Mar 3 05:28:07 2021 From: tvoniadka at openjdk.java.net (Thejasvi Voniadka) Date: Wed, 3 Mar 2021 05:28:07 GMT Subject: [jdk16u] RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset Message-ID: This is a clean backport of: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset The patch applies clean. All tests have been run and verified to pass with the patch. ------------- Commit messages: - Backport 0a50688dec6a91e4f12ab4f7d2bea965611525c6 Changes: https://git.openjdk.java.net/jdk16u/pull/71/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=71&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241372 Stats: 58 lines in 4 files changed: 42 ins; 7 del; 9 mod Patch: https://git.openjdk.java.net/jdk16u/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/71/head:pull/71 PR: https://git.openjdk.java.net/jdk16u/pull/71 From shade at openjdk.java.net Wed Mar 3 06:53:11 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 3 Mar 2021 06:53:11 GMT Subject: [jdk16u] RFR: 8259679: GitHub actions should use MSVC 14.28 Message-ID: Some GH action testing is failing in jdk16u now, for example: https://github.com/shipilev/jdk16u/runs/2016544577?check_suite_focus=true This should make GH actions more resilient. ------------- Commit messages: - Backport 6b4732fe519a502d88b977fe293299998cc1fadc Changes: https://git.openjdk.java.net/jdk16u/pull/72/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=72&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259679 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/72.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/72/head:pull/72 PR: https://git.openjdk.java.net/jdk16u/pull/72 From evergizova at openjdk.java.net Wed Mar 3 08:34:13 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 3 Mar 2021 08:34:13 GMT Subject: [jdk13u-dev] RFR: 8260308: Update LogCompilation junit to 4.13.1 Message-ID: I'd like to backport JDK-8260308 to 13u for parity with 11u. The patch applies cleanly. Tested with tier1 and compiler/compilercontrol/logcompilation tests. ------------- Commit messages: - Backport ef247ab276b6f687a2ac0e0700d0de91bd3df8a8 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/135/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=135&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260308 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/135.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/135/head:pull/135 PR: https://git.openjdk.java.net/jdk13u-dev/pull/135 From cgo at openjdk.java.net Wed Mar 3 08:39:50 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Wed, 3 Mar 2021 08:39:50 GMT Subject: [jdk16u] RFR: 8261752: Multiple GC test are missing memory requirements In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 18:57:35 GMT, Aleksey Shipilev wrote: >> 8261752: Multiple GC test are missing memory requirements > > The backport looks good. You still need to wait for `jdk16u-fix-yes` in JIRA. Oh, thanks a lot for looking into this and fixing the tag, didn't notice this. ------------- PR: https://git.openjdk.java.net/jdk16u/pull/33 From evergizova at openjdk.java.net Wed Mar 3 09:38:02 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 3 Mar 2021 09:38:02 GMT Subject: [jdk13u-dev] Integrated: 8260308: Update LogCompilation junit to 4.13.1 In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 08:28:55 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8260308 to 13u for parity with 11u. > The patch applies cleanly. > Tested with tier1 and compiler/compilercontrol/logcompilation tests. This pull request has now been integrated. Changeset: 335890fc Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk13u-dev/commit/335890fc Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8260308: Update LogCompilation junit to 4.13.1 Backport-of: ef247ab276b6f687a2ac0e0700d0de91bd3df8a8 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/135 From shade at redhat.com Wed Mar 3 10:21:31 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 3 Mar 2021 11:21:31 +0100 Subject: [15u] RFR (S) 8247676: vcruntime140_1.dll is not needed on 32-bit Windows Message-ID: <4e5eb7a0-175c-fa60-cc29-35eb5ad9922b@redhat.com> Configure fails on --with-target-bits=32 for Windows since it tries to locate the non-existing 32-bit version of vcruntime140_1.dll. This is not needed on 32 bit and should be skipped. In JDK 16+, this seems to be implicitly fixed with JDK-8248238: https://github.com/openjdk/jdk/commit/9604ee82#diff-faa23e14e93e8ccffb102d4696b367b75f88ae8dcc91b02b473bdc69b4a7b786R734 ...and followup in JDK-8257679: https://github.com/openjdk/jdk/commit/d29c78da#diff-9ae6a9495d0da7dfc02e8d804de187641e8dd59c7ae671ac2170c21d4c6204e2R607 JDK 15 Windows 32 builds still fail, and need a point fix like this: https://cr.openjdk.java.net/~shade/8247676/webrev.15u.01/ With the patch above, JDK 15 Windows 32 builds work. Testing: Windows {x86_32, x86_64} builds with MSVC 2019 -- Thanks, -Aleksey From christoph.goettschkes at microdoc.com Wed Mar 3 10:27:28 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Wed, 3 Mar 2021 11:27:28 +0100 Subject: [11u] RFR: 8248411: [aarch64] Insufficient error handling when CodeBuffer is exhausted Message-ID: <371pt05ckk-1@aserp2020.oracle.com> Hi, please review this backport of JDK-8248411 from 15u to 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8248411 Original commit: https://github.com/openjdk/jdk/commit/f279ddfa 15u backport webrev: https://cr.openjdk.java.net/~phedlin/tr8248411.15u/webrev/index.html Webrev: https://cr.openjdk.java.net/~cgo/8248411/backport-11u.00/ we are seeing intermittent test failure in jdk11u on aarch64 for the hotspot tier1 jtreg tests "compiler/codecache/TestStressCodeBuffers.java". I backported JDK-8248411, which resolves the issues. I executed the test case several times. Without the patch, 10 of 25 runs failed. With the patch applied, 0 of 25 runs failed. I chose the 15u backport as a basis for this 11u backport. Everything except the changes to "src/hotspot/share/opto/output.cpp" applies cleanly. The changes in output.cpp are only the addition of one assert call and some formatting. Tests executed: * Hotspot tier1 on linux aarch64 * Tier1 on linux x86_64 Thanks, Christoph From martin.doerr at sap.com Wed Mar 3 10:49:21 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 3 Mar 2021 10:49:21 +0000 Subject: [11u] RFR: 8249867: xml declaration is not followed by a newline Message-ID: Hi, JDK-8249867 is backported to 11.0.11-oracle. I'd like to backport it for parity. It applies almost cleanly and resolution is trivial. Manual resolution steps: PrettyPrintTest.java: - Update copyright year. - Add bug id to the @bug line. ToStream.java: - Update copyright year. - Update time stamp in @LastModified line. LSSerializerImpl.java: - Skip Copyright year and time stamp update because the Copyright header is missing in 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8249867 Original change: https://git.openjdk.java.net/jdk/commit/69ee314b 11u backport: http://cr.openjdk.java.net/~mdoerr/8249867_xml_11u/webrev.00/ Please review. Best regards, Martin From tvoniadka at openjdk.java.net Wed Mar 3 16:04:48 2021 From: tvoniadka at openjdk.java.net (Thejasvi Voniadka) Date: Wed, 3 Mar 2021 16:04:48 GMT Subject: [jdk16u] Integrated: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 05:23:08 GMT, Thejasvi Voniadka wrote: > This is a clean backport of: > > 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset > > The patch applies clean. All tests have been run and verified to pass with the patch. This pull request has now been integrated. Changeset: d89a8cda Author: Thejasvi Voniadka Committer: Rob McKenna URL: https://git.openjdk.java.net/jdk16u/commit/d89a8cda Stats: 58 lines in 4 files changed: 42 ins; 7 del; 9 mod 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset Backport-of: 0a50688dec6a91e4f12ab4f7d2bea965611525c6 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/71 From christoph.langer at sap.com Wed Mar 3 16:25:55 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 3 Mar 2021 16:25:55 +0000 Subject: [11u] RFR: 8248411: [aarch64] Insufficient error handling when CodeBuffer is exhausted In-Reply-To: <371pt05ckk-1@aserp2020.oracle.com> References: <371pt05ckk-1@aserp2020.oracle.com> Message-ID: Hi Christoph, that's cool, thanks for tackling this backport. We're seeing the same issue with test compiler/codecache/TestStressCodeBuffers.java and once in a while the same pattern also for compiler/startup/SmallCodeCacheStartup.java and we also think that this should be fixed by JDK- 8248411. I'll run it through our tests tonight and if nothing breaks and you don't hear from me by tomorrow you can consider this reviewed. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Christoph G?ttschkes > Sent: Mittwoch, 3. M?rz 2021 11:27 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8248411: [aarch64] Insufficient error handling when > CodeBuffer is exhausted > > Hi, > > please review this backport of JDK-8248411 from 15u to 11u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248411 > Original commit: https://github.com/openjdk/jdk/commit/f279ddfa > 15u backport webrev: > https://cr.openjdk.java.net/~phedlin/tr8248411.15u/webrev/index.html > > Webrev: https://cr.openjdk.java.net/~cgo/8248411/backport-11u.00/ > > we are seeing intermittent test failure in jdk11u on aarch64 for the > hotspot tier1 jtreg tests > "compiler/codecache/TestStressCodeBuffers.java". I backported > JDK-8248411, which resolves the issues. > I executed the test case several times. Without the patch, 10 of 25 runs > failed. With the patch applied, 0 of 25 runs failed. > > I chose the 15u backport as a basis for this 11u backport. Everything > except the changes to "src/hotspot/share/opto/output.cpp" applies > cleanly. The changes in output.cpp are only the addition of one assert > call and some formatting. > > Tests executed: > * Hotspot tier1 on linux aarch64 > * Tier1 on linux x86_64 > > Thanks, > Christoph From dcherepanov at azul.com Wed Mar 3 16:48:43 2021 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Wed, 3 Mar 2021 19:48:43 +0300 Subject: [15u] RFR (S) 8247676: vcruntime140_1.dll is not needed on 32-bit Windows In-Reply-To: <4e5eb7a0-175c-fa60-cc29-35eb5ad9922b@redhat.com> References: <4e5eb7a0-175c-fa60-cc29-35eb5ad9922b@redhat.com> Message-ID: Hi Aleksey, Looks good, thanks! Dmitry On 03.03.2021 13:21, Aleksey Shipilev wrote: > Configure fails on --with-target-bits=32 for Windows since it tries to locate the non-existing 32-bit version of vcruntime140_1.dll. This is not needed on 32 bit and should be skipped. > > In JDK 16+, this seems to be implicitly fixed with JDK-8248238: > > https://github.com/openjdk/jdk/commit/9604ee82#diff-faa23e14e93e8ccffb102d4696b367b75f88ae8dcc91b02b473bdc69b4a7b786R734 > > ...and followup in JDK-8257679: > > https://github.com/openjdk/jdk/commit/d29c78da#diff-9ae6a9495d0da7dfc02e8d804de187641e8dd59c7ae671ac2170c21d4c6204e2R607 > > JDK 15 Windows 32 builds still fail, and need a point fix like this: > ? https://cr.openjdk.java.net/~shade/8247676/webrev.15u.01/ > > With the patch above, JDK 15 Windows 32 builds work. > > Testing: Windows {x86_32, x86_64} builds with MSVC 2019 > From sgehwolf at redhat.com Wed Mar 3 17:31:26 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 03 Mar 2021 18:31:26 +0100 Subject: [11u] RFR: 8249867: xml declaration is not followed by a newline In-Reply-To: References: Message-ID: On Wed, 2021-03-03 at 10:49 +0000, Doerr, Martin wrote: > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8249867_xml_11u/webrev.00/ This seems fine to me. Thanks, Severin From shade at openjdk.java.net Wed Mar 3 17:54:51 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 3 Mar 2021 17:54:51 GMT Subject: [jdk16u] RFR: 8261752: Multiple GC test are missing memory requirements In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 08:36:35 GMT, Christoph G?ttschkes wrote: >> The backport looks good. You still need to wait for `jdk16u-fix-yes` in JIRA. > > Oh, thanks a lot for looking into this and fixing the tag, didn't notice this. Please check you have the approval tag on the issue (I think you have), and if so, say `/integrate`, and I shall sponsor. ------------- PR: https://git.openjdk.java.net/jdk16u/pull/33 From shade at openjdk.java.net Wed Mar 3 17:54:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 3 Mar 2021 17:54:52 GMT Subject: [jdk16u] Integrated: 8258534: Epsilon: clean up unused includes In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 11:26:42 GMT, Aleksey Shipilev wrote: > This simplifies the build and keeps codebases in sync. > > Additional testing: > - [x] Linux x86_64 fastdebug `gc/epsilon` > - [x] Linux x86_64 release `gc/epsilon` This pull request has now been integrated. Changeset: 247fea2d Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/247fea2d Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod 8258534: Epsilon: clean up unused includes Backport-of: 3817c32fd1dba46ff1ee1831aa5efb03c6546ace ------------- PR: https://git.openjdk.java.net/jdk16u/pull/65 From shade at openjdk.java.net Wed Mar 3 17:54:54 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 3 Mar 2021 17:54:54 GMT Subject: [jdk16u] Integrated: 8259679: GitHub actions should use MSVC 14.28 In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 06:48:51 GMT, Aleksey Shipilev wrote: > Some GH action testing is failing in jdk16u now, for example: > https://github.com/shipilev/jdk16u/runs/2016544577?check_suite_focus=true > > This should make GH actions more resilient. This pull request has now been integrated. Changeset: 90ac9a72 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/90ac9a72 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8259679: GitHub actions should use MSVC 14.28 Backport-of: 6b4732fe519a502d88b977fe293299998cc1fadc ------------- PR: https://git.openjdk.java.net/jdk16u/pull/72 From shade at openjdk.java.net Wed Mar 3 17:55:13 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 3 Mar 2021 17:55:13 GMT Subject: [jdk16u] RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code [v2] In-Reply-To: <6vryfZFG9FkuPbtFfhtHD4K2Irqq1Pyy20qI64ke9So=.e7584f3e-350f-44bb-b806-cf59247aadeb@github.com> References: <6vryfZFG9FkuPbtFfhtHD4K2Irqq1Pyy20qI64ke9So=.e7584f3e-350f-44bb-b806-cf59247aadeb@github.com> Message-ID: > This unbreaks x86_32 tests with Shenandoah. > > Additional testing: > - [x] Linux x86_64 fastdebug tier1,2 > - [x] Linux x86_32 fastdebug tier1,2 `-XX:+UseShenandoahGC -XX:+UseSSE=1` > - [x] Linux x86_32 fastdebug tier1,2 `-XX:+UseShenandoahGC -XX:+UseSSE=2` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8256215-sh-regsaves - Backport a97aedff9f622ba6816b7550588f1d429bff2483 ------------- Changes: - all: https://git.openjdk.java.net/jdk16u/pull/69/files - new: https://git.openjdk.java.net/jdk16u/pull/69/files/1a010fed..5f827070 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=69&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=69&range=00-01 Stats: 326 lines in 17 files changed: 281 ins; 13 del; 32 mod Patch: https://git.openjdk.java.net/jdk16u/pull/69.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/69/head:pull/69 PR: https://git.openjdk.java.net/jdk16u/pull/69 From shade at openjdk.java.net Wed Mar 3 17:55:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 3 Mar 2021 17:55:59 GMT Subject: [jdk16u] Integrated: 8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 11:14:38 GMT, Aleksey Shipilev wrote: > This improves hs_errs after JDK 16 change, which might be confusing (compress klass ptrs are enabled, when hs_err is pointing out in only one place in heap info). > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` This pull request has now been integrated. Changeset: 3266d0bc Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/3266d0bc Stats: 19 lines in 1 file changed: 8 ins; 0 del; 11 mod 8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp Backport-of: a03e22bb14e0873a599320676fc9d2128a1e23cb ------------- PR: https://git.openjdk.java.net/jdk16u/pull/64 From shade at openjdk.java.net Wed Mar 3 17:55:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 3 Mar 2021 17:55:59 GMT Subject: [jdk16u] Integrated: 8260592: jpackage tests fail when Desktop is not supported In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 19:40:30 GMT, Aleksey Shipilev wrote: > This unbreaks jpackage tests on x86_32 cross-compiled builds. > > Additional testing: > - [x] Linux x86_32 `tools/jpackage` (pass cleanly) This pull request has now been integrated. Changeset: e19759ba Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/e19759ba Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8260592: jpackage tests fail when Desktop is not supported Reviewed-by: asemenyuk Backport-of: 24a262124f507759d72cddc0d1371b31ef1661cf ------------- PR: https://git.openjdk.java.net/jdk16u/pull/70 From shade at openjdk.java.net Wed Mar 3 17:56:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 3 Mar 2021 17:56:00 GMT Subject: [jdk16u] Integrated: 8261912: Code IfNode::fold_compares_helper more defensively In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 10:24:29 GMT, Aleksey Shipilev wrote: > This fixes C2 miscompilation. Risk is low, as it limits the optimization where it would have miscompiled. This pull request has now been integrated. Changeset: 6be71baf Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/6be71baf Stats: 23 lines in 1 file changed: 15 ins; 4 del; 4 mod 8261912: Code IfNode::fold_compares_helper more defensively Backport-of: e9f3aab7f483818944faf8638f421c6960fafbd2 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/48 From hseigel at openjdk.java.net Wed Mar 3 17:56:54 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 3 Mar 2021 17:56:54 GMT Subject: [jdk16u] Integrated: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines Message-ID: The patch for this fix applied cleanly. The change was regression tested with tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. ------------- Commit messages: - Backport abc4300de9c7a298c359fb585d3b0570a98df5cb Changes: https://git.openjdk.java.net/jdk16u/pull/73/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=73&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257746 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk16u/pull/73.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/73/head:pull/73 PR: https://git.openjdk.java.net/jdk16u/pull/73 From hseigel at openjdk.java.net Wed Mar 3 17:56:55 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 3 Mar 2021 17:56:55 GMT Subject: [jdk16u] Integrated: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 16:43:30 GMT, Harold Seigel wrote: > The patch for this fix applied cleanly. The change was regression tested with tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. This pull request has now been integrated. Changeset: 692b2bf4 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk16u/commit/692b2bf4 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines Backport-of: abc4300de9c7a298c359fb585d3b0570a98df5cb ------------- PR: https://git.openjdk.java.net/jdk16u/pull/73 From shade at redhat.com Wed Mar 3 18:02:10 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 3 Mar 2021 19:02:10 +0100 Subject: [15u] RFR (S) 8247676: vcruntime140_1.dll is not needed on 32-bit Windows In-Reply-To: References: <4e5eb7a0-175c-fa60-cc29-35eb5ad9922b@redhat.com> Message-ID: <6cf5522b-6e8b-e424-5055-d7cd33ce8103@redhat.com> On 3/3/21 5:48 PM, Dmitry Cherepanov wrote: > Looks good, thanks! Thank you, I tagged it for 15u approval. -- -Aleksey From martin.doerr at sap.com Wed Mar 3 18:44:08 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 3 Mar 2021 18:44:08 +0000 Subject: [11u] RFR: 8249867: xml declaration is not followed by a newline In-Reply-To: References: Message-ID: Hi Severin, thank you for the review! Best regards, Martin > -----Original Message----- > From: Severin Gehwolf > Sent: Mittwoch, 3. M?rz 2021 18:31 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8249867: xml declaration is not followed by a newline > > On Wed, 2021-03-03 at 10:49 +0000, Doerr, Martin wrote: > > 11u backport: > > http://cr.openjdk.java.net/~mdoerr/8249867_xml_11u/webrev.00/ > > This seems fine to me. > > Thanks, > Severin From shade at openjdk.java.net Wed Mar 3 21:26:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 3 Mar 2021 21:26:47 GMT Subject: [jdk16u] RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 18:53:04 GMT, Aleksey Shipilev wrote: >> Backporting this to eliminate flakiness of tests > > Looks fine. You still need to wait for `jdk16u-fix-yes` in JIRA. I think you are good to go? There seems to be `jdk16u-fix-yes` in JIRA. `16.0.1` integration window closes this week. ------------- PR: https://git.openjdk.java.net/jdk16u/pull/68 From shade at openjdk.java.net Wed Mar 3 21:26:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 3 Mar 2021 21:26:48 GMT Subject: [jdk16u] Integrated: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code In-Reply-To: <6vryfZFG9FkuPbtFfhtHD4K2Irqq1Pyy20qI64ke9So=.e7584f3e-350f-44bb-b806-cf59247aadeb@github.com> References: <6vryfZFG9FkuPbtFfhtHD4K2Irqq1Pyy20qI64ke9So=.e7584f3e-350f-44bb-b806-cf59247aadeb@github.com> Message-ID: <1t1cRO0_-3RTnpK5XxEd7-R8_TsFKOtPqeaP1zJybE0=.2077bc05-6741-44f8-9ea1-eb8a62590db3@github.com> On Tue, 2 Mar 2021 19:27:46 GMT, Aleksey Shipilev wrote: > This unbreaks x86_32 tests with Shenandoah. > > Additional testing: > - [x] Linux x86_64 fastdebug tier1,2 > - [x] Linux x86_32 fastdebug tier1,2 `-XX:+UseShenandoahGC -XX:+UseSSE=1` > - [x] Linux x86_32 fastdebug tier1,2 `-XX:+UseShenandoahGC -XX:+UseSSE=2` This pull request has now been integrated. Changeset: 12f505ad Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/12f505ad Stats: 118 lines in 2 files changed: 69 ins; 13 del; 36 mod 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code Backport-of: a97aedff9f622ba6816b7550588f1d429bff2483 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/69 From cgo at openjdk.java.net Thu Mar 4 08:24:44 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Thu, 4 Mar 2021 08:24:44 GMT Subject: [jdk16u] RFR: 8261752: Multiple GC test are missing memory requirements In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 17:46:49 GMT, Aleksey Shipilev wrote: >> Oh, thanks a lot for looking into this and fixing the tag, didn't notice this. > > Please check you have the approval tag on the issue (I think you have), and if so, say `/integrate`, and I shall sponsor. Yes, you are right, it got approved. Thanks for sponsoring. ------------- PR: https://git.openjdk.java.net/jdk16u/pull/33 From cgo at openjdk.java.net Thu Mar 4 08:42:47 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Thu, 4 Mar 2021 08:42:47 GMT Subject: [jdk16u] Integrated: 8261752: Multiple GC test are missing memory requirements In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 09:51:18 GMT, Christoph G?ttschkes wrote: > 8261752: Multiple GC test are missing memory requirements This pull request has now been integrated. Changeset: 558a05ed Author: Christoph G?ttschkes Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/558a05ed Stats: 7 lines in 7 files changed: 2 ins; 0 del; 5 mod 8261752: Multiple GC test are missing memory requirements Reviewed-by: shade Backport-of: 2e18b52aed00abc18fbb1198c3818b5e0aad3ff7 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/33 From yan at openjdk.java.net Thu Mar 4 09:09:54 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 4 Mar 2021 09:09:54 GMT Subject: [jdk13u-dev] RFR: 8198540: Dynalink leaks memory when generating type converters In-Reply-To: <_Z_ZptjCVPeGWZiroRUtGHybFKT2KvHOnTQ-Y-PXG7A=.d539c7b2-6654-4922-812e-1e9a735b0db0@github.com> References: <_Z_ZptjCVPeGWZiroRUtGHybFKT2KvHOnTQ-Y-PXG7A=.d539c7b2-6654-4922-812e-1e9a735b0db0@github.com> Message-ID: On Sat, 13 Feb 2021 17:47:08 GMT, Attila Szegedi wrote: > I would like to backport JDK-8198540 to 13u. > > The patch doesn't apply cleanly due to minor context differences, namely that [JDK-8251538](https://github.com/openjdk/jdk/commit/4b1b547020effb72ba9ef92807fec39a0db99973) is not in 13u. This was a purely code refactoring task, which among other things refactored some anonymous inner classes in `TypeConverterFactory.java` and `ClassMap.java` to lambdas. All the lines that failed to apply cleanly were deletes, so after this change these differences no longer even exist. > > Additionally, 13u did not have running of tests in `test/jdk/jdk/dynalink` enabled as part of the `jdk_other` test group, so a relevant single line of [JDK-8252124](https://github.com/openjdk/jdk/commit/97f8261e4190b8edf83c1d8f11ea57f6c8338284#diff-687d4f32a29eeafbc88c0807e48388ea3e3b16dee622db0fef1473cb387f22ac) was also added to `test/jdk/TEST.groups` to enable the two tests that are part of this change to run. There should be a better reviewer but time is nigh: ship it! ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/127 From attila at openjdk.java.net Thu Mar 4 10:36:49 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Thu, 4 Mar 2021 10:36:49 GMT Subject: [jdk16u] Integrated: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 17:38:12 GMT, Attila Szegedi wrote: > Backporting this to eliminate flakiness of tests This pull request has now been integrated. Changeset: 1a3eda9f Author: Attila Szegedi URL: https://git.openjdk.java.net/jdk16u/commit/1a3eda9f Stats: 92 lines in 2 files changed: 71 ins; 8 del; 13 mod 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" Reviewed-by: shade Backport-of: b6db9a502cffc3f1a67d5a078010347fea805306 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/68 From attila at openjdk.java.net Thu Mar 4 10:59:45 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Thu, 4 Mar 2021 10:59:45 GMT Subject: [jdk13u-dev] RFR: 8198540: Dynalink leaks memory when generating type converters In-Reply-To: References: <_Z_ZptjCVPeGWZiroRUtGHybFKT2KvHOnTQ-Y-PXG7A=.d539c7b2-6654-4922-812e-1e9a735b0db0@github.com> Message-ID: On Thu, 4 Mar 2021 09:06:52 GMT, Yuri Nesterenko wrote: >> I would like to backport JDK-8198540 to 13u. >> >> The patch doesn't apply cleanly due to minor context differences, namely that [JDK-8251538](https://github.com/openjdk/jdk/commit/4b1b547020effb72ba9ef92807fec39a0db99973) is not in 13u. This was a purely code refactoring task, which among other things refactored some anonymous inner classes in `TypeConverterFactory.java` and `ClassMap.java` to lambdas. All the lines that failed to apply cleanly were deletes, so after this change these differences no longer even exist. >> >> Additionally, 13u did not have running of tests in `test/jdk/jdk/dynalink` enabled as part of the `jdk_other` test group, so a relevant single line of [JDK-8252124](https://github.com/openjdk/jdk/commit/97f8261e4190b8edf83c1d8f11ea57f6c8338284#diff-687d4f32a29eeafbc88c0807e48388ea3e3b16dee622db0fef1473cb387f22ac) was also added to `test/jdk/TEST.groups` to enable the two tests that are part of this change to run. > > There should be a better reviewer but time is nigh: ship it! Thank you @yan-too ! I'll shortly follow it up with a backport of the change that makes the tests in this PR more reliable. ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/127 From attila at openjdk.java.net Thu Mar 4 10:59:46 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Thu, 4 Mar 2021 10:59:46 GMT Subject: [jdk13u-dev] Integrated: 8198540: Dynalink leaks memory when generating type converters In-Reply-To: <_Z_ZptjCVPeGWZiroRUtGHybFKT2KvHOnTQ-Y-PXG7A=.d539c7b2-6654-4922-812e-1e9a735b0db0@github.com> References: <_Z_ZptjCVPeGWZiroRUtGHybFKT2KvHOnTQ-Y-PXG7A=.d539c7b2-6654-4922-812e-1e9a735b0db0@github.com> Message-ID: On Sat, 13 Feb 2021 17:47:08 GMT, Attila Szegedi wrote: > I would like to backport JDK-8198540 to 13u. > > The patch doesn't apply cleanly due to minor context differences, namely that [JDK-8251538](https://github.com/openjdk/jdk/commit/4b1b547020effb72ba9ef92807fec39a0db99973) is not in 13u. This was a purely code refactoring task, which among other things refactored some anonymous inner classes in `TypeConverterFactory.java` and `ClassMap.java` to lambdas. All the lines that failed to apply cleanly were deletes, so after this change these differences no longer even exist. > > Additionally, 13u did not have running of tests in `test/jdk/jdk/dynalink` enabled as part of the `jdk_other` test group, so a relevant single line of [JDK-8252124](https://github.com/openjdk/jdk/commit/97f8261e4190b8edf83c1d8f11ea57f6c8338284#diff-687d4f32a29eeafbc88c0807e48388ea3e3b16dee622db0fef1473cb387f22ac) was also added to `test/jdk/TEST.groups` to enable the two tests that are part of this change to run. This pull request has now been integrated. Changeset: 26f7e6fd Author: Attila Szegedi URL: https://git.openjdk.java.net/jdk13u-dev/commit/26f7e6fd Stats: 781 lines in 6 files changed: 539 ins; 228 del; 14 mod 8198540: Dynalink leaks memory when generating type converters Reviewed-by: yan Backport-of: 8f4c15f6417e471b372f74460fa94b9d84c4811d ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/127 From attila at openjdk.java.net Thu Mar 4 13:03:01 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Thu, 4 Mar 2021 13:03:01 GMT Subject: [jdk13u-dev] RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" Message-ID: Backporting this to eliminate flakiness of tests. This backport differs in the following ways from the original issue: * There's no changes to `test/jdk/ProblemList.txt` since the flaky tests were never put on the problem list in this repo. * Tests with Shenandoah also contain the `-XX:+UnlockExperimentalVMOptions` JVM flag which is still necessary with JDK 13. * Added the `vm.gc.Serial`, `vm.gc.Parallel`, and `vm.gc.G1` properties to `test/jdk/TEST.ROOT` (in addition to already existing `vm.gc.Z` and `vm.gc.Shenandoah`.) It seems it's the right call to add them, it might help further backported tests in the future. ------------- Commit messages: - 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" Changes: https://git.openjdk.java.net/jdk13u-dev/pull/136/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=136&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261483 Stats: 95 lines in 3 files changed: 74 ins; 8 del; 13 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/136.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/136/head:pull/136 PR: https://git.openjdk.java.net/jdk13u-dev/pull/136 From omikhaltcova at openjdk.java.net Thu Mar 4 14:22:56 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 4 Mar 2021 14:22:56 GMT Subject: [jdk13u-dev] RFR: 8233880: Support compilers with multi-digit major version numbers Message-ID: I'd like to backport JDK-8233880 to jdk13u for parity with jdk11u. The original patch applied cleanly. Checked this configure warning fix manually on Ubuntu 20.04 with gcc 10.2.0. ------------- Commit messages: - Backport 7dafe378d3b4fbbb39d1bbfdb50cc655ebf633bd Changes: https://git.openjdk.java.net/jdk13u-dev/pull/137/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=137&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233880 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/137.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/137/head:pull/137 PR: https://git.openjdk.java.net/jdk13u-dev/pull/137 From yan at openjdk.java.net Thu Mar 4 14:26:50 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 4 Mar 2021 14:26:50 GMT Subject: [jdk13u-dev] RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" In-Reply-To: References: Message-ID: On Thu, 4 Mar 2021 12:58:20 GMT, Attila Szegedi wrote: > Backporting this to eliminate flakiness of tests. This backport differs in the following ways from the original issue: > * There's no changes to `test/jdk/ProblemList.txt` since the flaky tests were never put on the problem list in this repo. > * Tests with Shenandoah also contain the `-XX:+UnlockExperimentalVMOptions` JVM flag which is still necessary with JDK 13. > * Added the `vm.gc.Serial`, `vm.gc.Parallel`, and `vm.gc.G1` properties to `test/jdk/TEST.ROOT` (in addition to already existing `vm.gc.Z` and `vm.gc.Shenandoah`.) It seems it's the right call to add them, it might help further backported tests in the future. Looks good to me, thank you! ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/136 From omikhaltcova at openjdk.java.net Thu Mar 4 14:41:51 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 4 Mar 2021 14:41:51 GMT Subject: [jdk13u-dev] Integrated: 8233880: Support compilers with multi-digit major version numbers In-Reply-To: References: Message-ID: On Thu, 4 Mar 2021 14:16:19 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8233880 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Checked this configure warning fix manually on Ubuntu 20.04 with gcc 10.2.0. This pull request has now been integrated. Changeset: 2f2f2deb Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/2f2f2deb Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8233880: Support compilers with multi-digit major version numbers Backport-of: 7dafe378d3b4fbbb39d1bbfdb50cc655ebf633bd ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/137 From dcherepanov at openjdk.java.net Thu Mar 4 15:35:56 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 4 Mar 2021 15:35:56 GMT Subject: [jdk13u-dev] RFR: 8260356: (tz) Upgrade time-zone data to tzdata2021a Message-ID: request to backport upgrade to tzdata2021a to 13u. Applies cleanly, relevant tests passed. ------------- Commit messages: - Backport d9aefa36ac1d4b711a3082e3ce6c442d4cb8e718 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/138/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=138&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260356 Stats: 12 lines in 3 files changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/138.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/138/head:pull/138 PR: https://git.openjdk.java.net/jdk13u-dev/pull/138 From dcherepanov at openjdk.java.net Thu Mar 4 15:44:56 2021 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Thu, 4 Mar 2021 15:44:56 GMT Subject: [jdk13u-dev] Integrated: 8260356: (tz) Upgrade time-zone data to tzdata2021a In-Reply-To: References: Message-ID: On Thu, 4 Mar 2021 15:30:35 GMT, Dmitry Cherepanov wrote: > request to backport upgrade to tzdata2021a to 13u. Applies cleanly, relevant tests passed. This pull request has now been integrated. Changeset: fd2aac7e Author: Dmitry Cherepanov URL: https://git.openjdk.java.net/jdk13u-dev/commit/fd2aac7e Stats: 12 lines in 3 files changed: 6 ins; 0 del; 6 mod 8260356: (tz) Upgrade time-zone data to tzdata2021a Backport-of: d9aefa36ac1d4b711a3082e3ce6c442d4cb8e718 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/138 From evergizova at openjdk.java.net Thu Mar 4 17:30:56 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 4 Mar 2021 17:30:56 GMT Subject: [jdk13u-dev] RFR: 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities Message-ID: I'd like to backport JDK-8253476 to 13u. The patch applies cleanly. It is test-only change, the affected test passes after applying the patch. ------------- Commit messages: - Backport 2fe0a5d75ee9434017b3df5cfa713ef895a19866 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/139/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=139&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253476 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/139.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/139/head:pull/139 PR: https://git.openjdk.java.net/jdk13u-dev/pull/139 From volker.simonis at gmail.com Thu Mar 4 18:07:44 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Mar 2021 19:07:44 +0100 Subject: [11u] RFR (XS): 8223504: improve performance of forall loops by better inlining of "iterator()" methods. In-Reply-To: References: Message-ID: Looks good to me. Notice that this has already been review by Paul on February 4th [1]. unfortunately that was the week when not all jdk-updates-dev mails were forwarded to all subscribers [2], so you may have missed that mail. Best regards, Volker [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/004873.html [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/004883.html ---------- Forwarded message --------- From: Dmitry Chuyko Date: Thu, Jan 28, 2021 at 12:22 PM Subject: [11u] RFR (XS): 8223504: improve performance of forall loops by better inlining of "iterator()" methods. To: jdk-updates-dev at openjdk.java.net Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8223504 Original patch mostly applies cleanly except do_klass() addition in systemDictionary.hpp which was mechanically reproduced with an extra parameter. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8223504/webrev.11u.00/ Testing: tier1, tier2. -- Thanks, -Dmitry From andrew at openjdk.java.net Thu Mar 4 19:29:00 2021 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Thu, 4 Mar 2021 19:29:00 GMT Subject: [jdk13u-dev] Integrated: 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags Message-ID: 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags ------------- Commit messages: - Backport 0785147460934ee2aa413ab7872837094824bd3d Changes: https://git.openjdk.java.net/jdk13u-dev/pull/140/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=140&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259949 Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/140.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/140/head:pull/140 PR: https://git.openjdk.java.net/jdk13u-dev/pull/140 From andrew at openjdk.java.net Thu Mar 4 19:29:01 2021 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Thu, 4 Mar 2021 19:29:01 GMT Subject: [jdk13u-dev] Integrated: 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags In-Reply-To: References: Message-ID: On Thu, 4 Mar 2021 19:21:34 GMT, Andrew John Hughes wrote: > 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags This pull request has now been integrated. Changeset: b8d5fcbe Author: Andrew John Hughes URL: https://git.openjdk.java.net/jdk13u-dev/commit/b8d5fcbe Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags Use -march=i686 instead of -march=i586 if -fcf-protection is passed to the build as CMOV is required Backport-of: 0785147460934ee2aa413ab7872837094824bd3d ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/140 From andrew at openjdk.java.net Thu Mar 4 19:40:59 2021 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Thu, 4 Mar 2021 19:40:59 GMT Subject: [jdk16u] RFR: 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags Message-ID: 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags ------------- Commit messages: - Backport 0785147460934ee2aa413ab7872837094824bd3d Changes: https://git.openjdk.java.net/jdk16u/pull/74/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=74&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259949 Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/74.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/74/head:pull/74 PR: https://git.openjdk.java.net/jdk16u/pull/74 From andrew at openjdk.java.net Thu Mar 4 19:53:51 2021 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Thu, 4 Mar 2021 19:53:51 GMT Subject: [jdk16u] Integrated: 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags In-Reply-To: References: Message-ID: On Thu, 4 Mar 2021 19:35:12 GMT, Andrew John Hughes wrote: > 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags This pull request has now been integrated. Changeset: 189fe433 Author: Andrew John Hughes URL: https://git.openjdk.java.net/jdk16u/commit/189fe433 Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags Use -march=i686 instead of -march=i586 if -fcf-protection is passed to the build as CMOV is required Backport-of: 0785147460934ee2aa413ab7872837094824bd3d ------------- PR: https://git.openjdk.java.net/jdk16u/pull/74 From rwestrel at redhat.com Fri Mar 5 07:55:16 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 05 Mar 2021 08:55:16 +0100 Subject: [11u] RFR 8253923: C2 doesn't always run loop opts for compilations that include loops Message-ID: <87r1kuvxuj.fsf@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8253923 https://github.com/openjdk/jdk/commit/a6c23b77 Original patch does not apply cleanly to 11u because code around a couple changes is different. Patch is otherwise identical. See below for hunks that failed to apply. 11u webrev: https://cr.openjdk.java.net/~roland/8253923.11u/webrev.00/ Testing: x86_64 build, tier1, some complile the world testing Roland. --- callGenerator.cpp +++ callGenerator.cpp @@ -456,7 +456,6 @@ void LateInlineCallGenerator::do_late_inline() { result = (result_size == 1) ? kit.pop() : kit.pop_pair(); } - C->set_has_loops(C->has_loops() || _inline_cg->method()->has_loops()); C->env()->notice_inlined_method(_inline_cg->method()); C->set_inlining_progress(true); C->set_do_cleanup(kit.stopped()); // path is dead; needs cleanup --- compile.cpp +++ compile.cpp @@ -1022,6 +1022,7 @@ void Compile::Init(int aliaslevel) { #ifdef ASSERT _type_verify_symmetry = true; _phase_optimize_finished = false; + _exception_backedge = false; #endif } From adinn at redhat.com Fri Mar 5 10:05:20 2021 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 5 Mar 2021 10:05:20 +0000 Subject: [11u] RFR 8253923: C2 doesn't always run loop opts for compilations that include loops In-Reply-To: <87r1kuvxuj.fsf@redhat.com> References: <87r1kuvxuj.fsf@redhat.com> Message-ID: <668b2f3a-94b7-4765-3af5-e0048b243e8f@redhat.com> On 05/03/2021 07:55, Roland Westrelin wrote: > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8253923 > https://github.com/openjdk/jdk/commit/a6c23b77 > > Original patch does not apply cleanly to 11u because code around a > couple changes is different. Patch is otherwise identical. See below for > hunks that failed to apply. > > 11u webrev: > https://cr.openjdk.java.net/~roland/8253923.11u/webrev.00/ > > Testing: x86_64 build, tier1, some complile the world testing This the backport looks fine. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From rwestrel at redhat.com Fri Mar 5 10:07:56 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 05 Mar 2021 11:07:56 +0100 Subject: [11u] RFR 8253923: C2 doesn't always run loop opts for compilations that include loops In-Reply-To: <668b2f3a-94b7-4765-3af5-e0048b243e8f@redhat.com> References: <87r1kuvxuj.fsf@redhat.com> <668b2f3a-94b7-4765-3af5-e0048b243e8f@redhat.com> Message-ID: <87lfb1x69v.fsf@redhat.com> Thanks for reviewing the change! Roland. From evergizova at openjdk.java.net Fri Mar 5 10:29:53 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 5 Mar 2021 10:29:53 GMT Subject: [jdk13u-dev] Integrated: 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities In-Reply-To: References: Message-ID: On Thu, 4 Mar 2021 17:25:00 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8253476 to 13u. > The patch applies cleanly. > It is test-only change, the affected test passes after applying the patch. This pull request has now been integrated. Changeset: 54a8465c Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk13u-dev/commit/54a8465c Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities Backport-of: 2fe0a5d75ee9434017b3df5cfa713ef895a19866 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/139 From matthias.baesken at sap.com Fri Mar 5 15:24:18 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 5 Mar 2021 15:24:18 +0000 Subject: RFR : [jdk11] 8259786: initialize last parameter of getpwuid_r Message-ID: Hi, please review the jdk11 backport of 8259786: initialize last parameter of getpwuid_r The jdk11 version is similar to jdk/jdk , but instead of changing perfMemory_posix.cpp , the separate OS/platform related files have to be changed . Jdk11 backport webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8259786_0_jdk11/ Bug / jdk link : https://bugs.openjdk.java.net/browse/JDK-8259786 https://git.openjdk.java.net/jdk/commit/52ed2aab Thanks, Matthias From martin.doerr at sap.com Fri Mar 5 15:31:29 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 5 Mar 2021 15:31:29 +0000 Subject: RFR : [jdk11] 8259786: initialize last parameter of getpwuid_r Message-ID: Hi Matthias, looks good. Solaris already has the fix. Thanks for backporting. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Baesken, Matthias > Sent: Freitag, 5. M?rz 2021 16:24 > To: jdk-updates-dev at openjdk.java.net > Subject: RFR : [jdk11] 8259786: initialize last parameter of > getpwuid_r > > Hi, please review the jdk11 backport of > > 8259786: initialize last > parameter of getpwuid_r > > The jdk11 version is similar to jdk/jdk , but instead of changing > perfMemory_posix.cpp , the separate OS/platform related files have to be > changed . > > > > > Jdk11 backport webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8259786_0_jdk11/ > > > Bug / jdk link : > > https://bugs.openjdk.java.net/browse/JDK-8259786 > > https://git.openjdk.java.net/jdk/commit/52ed2aab > > > > Thanks, Matthias From matthias.baesken at sap.com Fri Mar 5 15:46:46 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 5 Mar 2021 15:46:46 +0000 Subject: RFR : [jdk11] 8259786: initialize last parameter of getpwuid_r In-Reply-To: References: Message-ID: Hi Martin, thanks for the review ! -----Original Message----- From: Doerr, Martin Sent: Freitag, 5. M?rz 2021 16:31 To: Baesken, Matthias ; jdk-updates-dev at openjdk.java.net Subject: RE: RFR : [jdk11] 8259786: initialize last parameter of getpwuid_r Hi Matthias, looks good. Solaris already has the fix. Thanks for backporting. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Baesken, Matthias > Sent: Freitag, 5. M?rz 2021 16:24 > To: jdk-updates-dev at openjdk.java.net > Subject: RFR : [jdk11] 8259786: initialize last parameter of > getpwuid_r > > Hi, please review the jdk11 backport of > > 8259786: initialize last > parameter of getpwuid_r > > The jdk11 version is similar to jdk/jdk , but instead of changing > perfMemory_posix.cpp , the separate OS/platform related files have to be > changed . > > > > > Jdk11 backport webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8259786_0_jdk11/ > > > Bug / jdk link : > > https://bugs.openjdk.java.net/browse/JDK-8259786 > > https://git.openjdk.java.net/jdk/commit/52ed2aab > > > > Thanks, Matthias From attila at openjdk.java.net Fri Mar 5 16:06:02 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Fri, 5 Mar 2021 16:06:02 GMT Subject: [jdk13u-dev] Integrated: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" In-Reply-To: References: Message-ID: On Thu, 4 Mar 2021 12:58:20 GMT, Attila Szegedi wrote: > Backporting this to eliminate flakiness of tests. This backport differs in the following ways from the original issue: > * There's no changes to `test/jdk/ProblemList.txt` since the flaky tests were never put on the problem list in this repo. > * Tests with Shenandoah also contain the `-XX:+UnlockExperimentalVMOptions` JVM flag which is still necessary with JDK 13. > * Added the `vm.gc.Serial`, `vm.gc.Parallel`, and `vm.gc.G1` properties to `test/jdk/TEST.ROOT` (in addition to already existing `vm.gc.Z` and `vm.gc.Shenandoah`.) It seems it's the right call to add them, it might help further backported tests in the future. This pull request has now been integrated. Changeset: 71ed1cd8 Author: Attila Szegedi URL: https://git.openjdk.java.net/jdk13u-dev/commit/71ed1cd8 Stats: 95 lines in 3 files changed: 74 ins; 8 del; 13 mod 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" Reviewed-by: yan Backport-of: d185a6c53e2a1dbf7aca47c431baa8df6ee1ca8b ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/136 From omikhaltcova at openjdk.java.net Fri Mar 5 16:06:15 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 5 Mar 2021 16:06:15 GMT Subject: [jdk13u-dev] RFR: 8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:" Message-ID: I'd like to backport JDK-8240711 to jdk13u for parity with jdk11u. The original patch applied cleanly. sun/tools/jstatd tests passed. ------------- Commit messages: - Backport b70ef0d2e256085b48f8d5b0f131bca89b699609 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/141/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=141&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240711 Stats: 20 lines in 1 file changed: 7 ins; 10 del; 3 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/141.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/141/head:pull/141 PR: https://git.openjdk.java.net/jdk13u-dev/pull/141 From omikhaltcova at openjdk.java.net Fri Mar 5 16:12:34 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 5 Mar 2021 16:12:34 GMT Subject: [jdk13u-dev] Integrated: 8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:" In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 15:59:45 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8240711 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > sun/tools/jstatd tests passed. This pull request has now been integrated. Changeset: 7d0aaf18 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/7d0aaf18 Stats: 20 lines in 1 file changed: 7 ins; 10 del; 3 mod 8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:" Backport-of: b70ef0d2e256085b48f8d5b0f131bca89b699609 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/141 From vladimir.kozlov at oracle.com Fri Mar 5 17:28:19 2021 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 5 Mar 2021 09:28:19 -0800 Subject: [11u] RFR 8253923: C2 doesn't always run loop opts for compilations that include loops In-Reply-To: <87r1kuvxuj.fsf@redhat.com> References: <87r1kuvxuj.fsf@redhat.com> Message-ID: <35643adc-b04f-3e7d-ec41-37b5119fa5ce@oracle.com> Looks good. Thanks, Vladimir K On 3/4/21 11:55 PM, Roland Westrelin wrote: > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8253923 > https://github.com/openjdk/jdk/commit/a6c23b77 > > Original patch does not apply cleanly to 11u because code around a > couple changes is different. Patch is otherwise identical. See below for > hunks that failed to apply. > > 11u webrev: > https://cr.openjdk.java.net/~roland/8253923.11u/webrev.00/ > > Testing: x86_64 build, tier1, some complile the world testing > > Roland. > > --- callGenerator.cpp > +++ callGenerator.cpp > @@ -456,7 +456,6 @@ void LateInlineCallGenerator::do_late_inline() { > result = (result_size == 1) ? kit.pop() : kit.pop_pair(); > } > > - C->set_has_loops(C->has_loops() || _inline_cg->method()->has_loops()); > C->env()->notice_inlined_method(_inline_cg->method()); > C->set_inlining_progress(true); > C->set_do_cleanup(kit.stopped()); // path is dead; needs cleanup > > --- compile.cpp > +++ compile.cpp > @@ -1022,6 +1022,7 @@ void Compile::Init(int aliaslevel) { > #ifdef ASSERT > _type_verify_symmetry = true; > _phase_optimize_finished = false; > + _exception_backedge = false; > #endif > } > > From rwestrel at redhat.com Mon Mar 8 08:45:41 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 08 Mar 2021 09:45:41 +0100 Subject: [11u] RFR 8253923: C2 doesn't always run loop opts for compilations that include loops In-Reply-To: <35643adc-b04f-3e7d-ec41-37b5119fa5ce@oracle.com> References: <87r1kuvxuj.fsf@redhat.com> <35643adc-b04f-3e7d-ec41-37b5119fa5ce@oracle.com> Message-ID: <87czwavxsa.fsf@redhat.com> > Looks good. Thanks, Vladimir. Roland. From volker.simonis at gmail.com Mon Mar 8 12:15:23 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Mar 2021 13:15:23 +0100 Subject: [11u] RFR (S) 8214922: Aarch64: Add vectorization support for fmin/fmax In-Reply-To: <9d0af7aa-b4df-2774-f099-cc55de1890e0@bell-sw.com> References: <9d0af7aa-b4df-2774-f099-cc55de1890e0@bell-sw.com> Message-ID: Hi Dmitry, in general, the downport looks good to me. I only wonder if we shouldn't integrate the format changes from 8241911 which were skipped in December when 8241911 was downported [1,2] because at that time this change wasn't in 11u. I'm fine either way and leave the final decision to the 11u maintainers. Thank you and best regards, Volker [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004474.html [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004498.html On Thu, Feb 18, 2021 at 9:27 AM Dmitry Chuyko wrote: > > Hello, > > Original RFE: https://bugs.openjdk.java.net/browse/JDK-8214922 > > Original patch applies almost cleanly except 2 added lines in > src/hotspot/share/opto/vectornode.cpp because of missing part of context > (JDK-8214751 not ported), they are added manually. > > 11u webrev: http://cr.openjdk.java.net/~dchuyko/8214922/webrev.11u.00/ > > Testing: tier1, tier2, TestFpMinMaxIntrinsics. > > -- > Thanks, > -Dmitry > From christoph.goettschkes at microdoc.com Mon Mar 8 12:22:35 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Mon, 8 Mar 2021 13:22:35 +0100 Subject: [11u] RFR: 8248411: [aarch64] Insufficient error handling when CodeBuffer is exhausted In-Reply-To: References: <371pt05ckk-1@aserp2020.oracle.com> Message-ID: <373yhtyjba-1@userp2060.oracle.com> Thanks for the review and the testing, Christoph. The backport got approved and I updated the webrev: https://cr.openjdk.java.net/~cgo/8248411/backport-11u.01/ Could you please sponsor this changeset for me? Thanks, Christoph On 3/3/21 5:25 PM, Langer, Christoph wrote: > Hi Christoph, > > that's cool, thanks for tackling this backport. > > We're seeing the same issue with test compiler/codecache/TestStressCodeBuffers.java and once in a while the same pattern also for compiler/startup/SmallCodeCacheStartup.java and we also think that this should be fixed by JDK- 8248411. I'll run it through our tests tonight and if nothing breaks and you don't hear from me by tomorrow you can consider this reviewed. > > Best regards > Christoph > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Christoph G?ttschkes >> Sent: Mittwoch, 3. M?rz 2021 11:27 >> To: jdk-updates-dev at openjdk.java.net >> Subject: [11u] RFR: 8248411: [aarch64] Insufficient error handling when >> CodeBuffer is exhausted >> >> Hi, >> >> please review this backport of JDK-8248411 from 15u to 11u. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8248411 >> Original commit: https://github.com/openjdk/jdk/commit/f279ddfa >> 15u backport webrev: >> https://cr.openjdk.java.net/~phedlin/tr8248411.15u/webrev/index.html >> >> Webrev: https://cr.openjdk.java.net/~cgo/8248411/backport-11u.00/ >> >> we are seeing intermittent test failure in jdk11u on aarch64 for the >> hotspot tier1 jtreg tests >> "compiler/codecache/TestStressCodeBuffers.java". I backported >> JDK-8248411, which resolves the issues. >> I executed the test case several times. Without the patch, 10 of 25 runs >> failed. With the patch applied, 0 of 25 runs failed. >> >> I chose the 15u backport as a basis for this 11u backport. Everything >> except the changes to "src/hotspot/share/opto/output.cpp" applies >> cleanly. The changes in output.cpp are only the addition of one assert >> call and some formatting. >> >> Tests executed: >> * Hotspot tier1 on linux aarch64 >> * Tier1 on linux x86_64 >> >> Thanks, >> Christoph > -- ------------------------------------------------------------------- Christoph G?ttschkes MicroDoc Software GmbH Tel: +49-89-551 969 43 Mail: christoph.goettschkes at microdoc.com ------------------------------------------------------------------- MicroDoc Software GmbH Elektrastrasse 6 A, 81925 M?nchen, Germany Tel: +49 89 551 969-0 | Fax: +49 89 551 969-11 http://www.microdoc.com Registergericht M?nchen, HRB 214239, USt.Id.: DE 296 807 578 Gesch?ftsf?hrer: Dr. Christian Kuka, Florian ?hlschlegel Unsere Datenschutzerkl?rung finden Sie hier: https://www.microdoc.com/datenschutzerklaerung ------------------------------------------------------------------- From christoph.langer at sap.com Mon Mar 8 12:37:14 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 8 Mar 2021 12:37:14 +0000 Subject: [11u] RFR: 8248411: [aarch64] Insufficient error handling when CodeBuffer is exhausted In-Reply-To: References: <371pt05ckk-1@aserp2020.oracle.com> Message-ID: Hi Christoph, sure, will do. Best regards Christoph > -----Original Message----- > From: Christoph G?ttschkes > Sent: Montag, 8. M?rz 2021 13:23 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8248411: [aarch64] Insufficient error handling when > CodeBuffer is exhausted > > Thanks for the review and the testing, Christoph. > > The backport got approved and I updated the webrev: > https://cr.openjdk.java.net/~cgo/8248411/backport-11u.01/ > > Could you please sponsor this changeset for me? > > Thanks, > Christoph > > On 3/3/21 5:25 PM, Langer, Christoph wrote: > > Hi Christoph, > > > > that's cool, thanks for tackling this backport. > > > > We're seeing the same issue with test > compiler/codecache/TestStressCodeBuffers.java and once in a while the > same pattern also for compiler/startup/SmallCodeCacheStartup.java and we > also think that this should be fixed by JDK- 8248411. I'll run it through our > tests tonight and if nothing breaks and you don't hear from me by tomorrow > you can consider this reviewed. > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: jdk-updates-dev On > >> Behalf Of Christoph G?ttschkes > >> Sent: Mittwoch, 3. M?rz 2021 11:27 > >> To: jdk-updates-dev at openjdk.java.net > >> Subject: [11u] RFR: 8248411: [aarch64] Insufficient error handling when > >> CodeBuffer is exhausted > >> > >> Hi, > >> > >> please review this backport of JDK-8248411 from 15u to 11u. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8248411 > >> Original commit: https://github.com/openjdk/jdk/commit/f279ddfa > >> 15u backport webrev: > >> https://cr.openjdk.java.net/~phedlin/tr8248411.15u/webrev/index.html > >> > >> Webrev: https://cr.openjdk.java.net/~cgo/8248411/backport-11u.00/ > >> > >> we are seeing intermittent test failure in jdk11u on aarch64 for the > >> hotspot tier1 jtreg tests > >> "compiler/codecache/TestStressCodeBuffers.java". I backported > >> JDK-8248411, which resolves the issues. > >> I executed the test case several times. Without the patch, 10 of 25 runs > >> failed. With the patch applied, 0 of 25 runs failed. > >> > >> I chose the 15u backport as a basis for this 11u backport. Everything > >> except the changes to "src/hotspot/share/opto/output.cpp" applies > >> cleanly. The changes in output.cpp are only the addition of one assert > >> call and some formatting. > >> > >> Tests executed: > >> * Hotspot tier1 on linux aarch64 > >> * Tier1 on linux x86_64 > >> > >> Thanks, > >> Christoph > > > > -- > ------------------------------------------------------------------- > Christoph G?ttschkes > MicroDoc Software GmbH > Tel: +49-89-551 969 43 > Mail: christoph.goettschkes at microdoc.com > ------------------------------------------------------------------- > MicroDoc Software GmbH > Elektrastrasse 6 A, 81925 M?nchen, Germany > Tel: +49 89 551 969-0 | Fax: +49 89 551 969-11 > http://www.microdoc.com > Registergericht M?nchen, HRB 214239, USt.Id.: DE 296 807 578 > Gesch?ftsf?hrer: Dr. Christian Kuka, Florian ?hlschlegel > > Unsere Datenschutzerkl?rung finden Sie hier: > https://www.microdoc.com/datenschutzerklaerung > ------------------------------------------------------------------- From hseigel at openjdk.java.net Mon Mar 8 16:32:26 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 8 Mar 2021 16:32:26 GMT Subject: [jdk16u] Integrated: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 Message-ID: The patch for the JDK-16u backport of the fix for JDK-8261397 applied cleanly. It was regression tested on 16u with Mach5 tiers 1 and 2 on Linux, Mac OS, and Solaris, and Mach5 tiers 3-5 on Mac OS. ------------- Commit messages: - Backport 0257caad38b4358bd151e993b708603fce2056f2 Changes: https://git.openjdk.java.net/jdk16u/pull/75/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=75&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261397 Stats: 30 lines in 3 files changed: 29 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/75.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/75/head:pull/75 PR: https://git.openjdk.java.net/jdk16u/pull/75 From hseigel at openjdk.java.net Mon Mar 8 16:32:27 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 8 Mar 2021 16:32:27 GMT Subject: [jdk16u] Integrated: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 16:25:34 GMT, Harold Seigel wrote: > The patch for the JDK-16u backport of the fix for JDK-8261397 applied cleanly. It was regression tested on 16u with Mach5 tiers 1 and 2 on Linux, Mac OS, and Solaris, and Mach5 tiers 3-5 on Mac OS. This pull request has now been integrated. Changeset: e3e74008 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk16u/commit/e3e74008 Stats: 30 lines in 3 files changed: 29 ins; 0 del; 1 mod 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 Backport-of: 0257caad38b4358bd151e993b708603fce2056f2 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/75 From cgo at openjdk.java.net Tue Mar 9 11:00:26 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Tue, 9 Mar 2021 11:00:26 GMT Subject: [jdk16u] RFR: 8261505: Test test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java killed by Linux OOM Killer Message-ID: <4Adf31Uo0cKyM4qI83znp3cWbuIrT0hhH0Uo0fVyVX0=.630da4a9-ea43-43b9-b504-637dbce88687@github.com> 8261505: Test test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java killed by Linux OOM Killer ------------- Commit messages: - Clean backport of JDK-8261505. Changes: https://git.openjdk.java.net/jdk16u/pull/76/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=76&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261505 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/76.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/76/head:pull/76 PR: https://git.openjdk.java.net/jdk16u/pull/76 From shade at redhat.com Tue Mar 9 11:19:47 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 9 Mar 2021 12:19:47 +0100 Subject: [jdk16u] JDK 16 RC tags? Message-ID: Hi, Look here in JDK 16 RC/EA tree, ends with jdk-16+36: https://github.com/openjdk/jdk16/tags ...and then here in JDK 16u tree, ends with jdk-16+29: https://github.com/openjdk/jdk16u/tags I think merges happen normally: https://github.com/openjdk/jdk16u/commit/ad5d4e9073d0738a7e9f92f4f221c3b6fc575757 ...but the tags are not replicated? Git requires handling the tags specially, e.g. with "git push --tags". Rob, can you check if this omission was intentional or just a process hiccup? -- Thanks, -Aleksey From christoph.goettschkes at microdoc.com Tue Mar 9 11:57:12 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Tue, 9 Mar 2021 12:57:12 +0100 Subject: [11u] RFR: 8261752: Multiple GC test are missing memory requirements Message-ID: <37426036ev-1@userp2050.oracle.com> Hello, please review the following backport to 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8261752 Original commit: https://git.openjdk.java.net/jdk/commit/2e18b52a Webrev: https://cr.openjdk.java.net/~cgo/8261752/backport-11u.00/ The patch doesn't apply cleanly, because 8249000 [1] and 8244614 [2] have not been backported yet and changed a lot of test cases. Applying the changes manually was trivial, since it only changes @requires tags of some tests. One of the test cases (TestMetaSpaceLog.java) doesn't exist in 11u. [1] https://bugs.openjdk.java.net/browse/JDK-8249000 [2] https://bugs.openjdk.java.net/browse/JDK-8244614 From neugens at redhat.com Tue Mar 9 12:45:57 2021 From: neugens at redhat.com (Mario Torre) Date: Tue, 9 Mar 2021 13:45:57 +0100 Subject: [11u] RFR: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default) In-Reply-To: References: Message-ID: Hi Christoph, Jaroslav, Sorry for the late reply, I missed this conversation back in December :/ I went through the changes and although they seem to be mostly self contained in the allocation tracer, I still tend to agree with Christoph and Erik that there's a risk involved in changing the configurations and metadata and I too think we should have this change in upstream for a bit longer before considering it for a backport. With another LTS expected soon I don't think it's a big loss and in fact, it may be a good reason to update in the first place. Cheers, Mario On Wed, Dec 23, 2020 at 12:34 PM Langer, Christoph wrote: > > 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- -- Mario Torre Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at openjdk.java.net Tue Mar 9 13:21:25 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Mar 2021 13:21:25 GMT Subject: [jdk16u] RFR: 8261914: IfNode::fold_compares_helper faces non-canonicalized bool when running JRuby JSON workload Message-ID: JDK-8261912 provided the release-mode bailout, and this issue is supposed to fix the corner case in debug-mode. ------------- Commit messages: - Backport 20c93b3b901806cd9d691d75c8f30398c41fec34 Changes: https://git.openjdk.java.net/jdk16u/pull/77/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=77&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261914 Stats: 10 lines in 1 file changed: 4 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/77/head:pull/77 PR: https://git.openjdk.java.net/jdk16u/pull/77 From rob.mckenna at oracle.com Tue Mar 9 16:16:29 2021 From: rob.mckenna at oracle.com (Robert Mckenna) Date: Tue, 9 Mar 2021 16:16:29 +0000 Subject: [External] : [jdk16u] JDK 16 RC tags? In-Reply-To: References: Message-ID: Yep - apologies. I've added the tags to the weekly sync. -Rob ________________________________________ From: Aleksey Shipilev Sent: Tuesday 9 March 2021 11:19 To: jdk-updates-dev at openjdk.java.net Cc: Robert Mckenna Subject: [External] : [jdk16u] JDK 16 RC tags? Hi, Look here in JDK 16 RC/EA tree, ends with jdk-16+36: https://urldefense.com/v3/__https://github.com/openjdk/jdk16/tags__;!!GqivPVa7Brio!O7H4-7_a0pBr44rtNfy5AAopnaPh3ObBQpZTrqnEFHoFS00j5CXPJah_VdqYe3NU$ ...and then here in JDK 16u tree, ends with jdk-16+29: https://urldefense.com/v3/__https://github.com/openjdk/jdk16u/tags__;!!GqivPVa7Brio!O7H4-7_a0pBr44rtNfy5AAopnaPh3ObBQpZTrqnEFHoFS00j5CXPJah_VSgCWclu$ I think merges happen normally: https://urldefense.com/v3/__https://github.com/openjdk/jdk16u/commit/ad5d4e9073d0738a7e9f92f4f221c3b6fc575757__;!!GqivPVa7Brio!O7H4-7_a0pBr44rtNfy5AAopnaPh3ObBQpZTrqnEFHoFS00j5CXPJah_VUYJiyJy$ ...but the tags are not replicated? Git requires handling the tags specially, e.g. with "git push --tags". Rob, can you check if this omission was intentional or just a process hiccup? -- Thanks, -Aleksey From hohensee at amazon.com Tue Mar 9 17:31:29 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 9 Mar 2021 17:31:29 +0000 Subject: [11u] RFR: 8261752: Multiple GC test are missing memory requirements Message-ID: <6DBA2AB2-797C-4FD9-AD04-D84DEE18CA3F@amazon.com> Lgtm. To help keep track of tests that haven't been backported, please include in your fix request comment that TestMetaSpaceLog.java is missing from the backport, link 8261752 to 8211123 (the issue that introduced it), and add a comment to 8211123 that the test was excluded from the 8261752 backport. There are 12 patches that affect that missing test, so it's a difficult backport candidate, but someone may want to tackle it sometime. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Christoph G?ttschkes Date: Tuesday, March 9, 2021 at 3:59 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR: 8261752: Multiple GC test are missing memory requirements Hello, please review the following backport to 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8261752 Original commit: https://git.openjdk.java.net/jdk/commit/2e18b52a Webrev: https://cr.openjdk.java.net/~cgo/8261752/backport-11u.00/ The patch doesn't apply cleanly, because 8249000 [1] and 8244614 [2] have not been backported yet and changed a lot of test cases. Applying the changes manually was trivial, since it only changes @requires tags of some tests. One of the test cases (TestMetaSpaceLog.java) doesn't exist in 11u. [1] https://bugs.openjdk.java.net/browse/JDK-8249000 [2] https://bugs.openjdk.java.net/browse/JDK-8244614 From djelinski1 at gmail.com Tue Mar 9 23:36:47 2021 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 10 Mar 2021 00:36:47 +0100 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Message-ID: Hi, Please review this 11u backport; this is the same patch as for head, except for microbenchmark makefile changes that did not apply because the file doesn't exist in 11u, and the actual microbenchmark, which would only add weight for no benefit. Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 webrev: https://djelinski.github.io/8259886-11u/webrev/index.html Testing: Linux x86_64 tier1 and tier2. Thanks, Daniel From vladimir.kozlov at oracle.com Wed Mar 10 01:32:41 2021 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 9 Mar 2021 17:32:41 -0800 Subject: [jdk16u] RFR: 8261914: IfNode::fold_compares_helper faces non-canonicalized bool when running JRuby JSON workload In-Reply-To: References: Message-ID: It looks like backport was applied cleanly. Reviewed. Thanks, Vladimir K On 3/9/21 5:21 AM, Aleksey Shipilev wrote: > JDK-8261912 provided the release-mode bailout, and this issue is supposed to fix the corner case in debug-mode. > > ------------- > > Commit messages: > - Backport 20c93b3b901806cd9d691d75c8f30398c41fec34 > > Changes: https://git.openjdk.java.net/jdk16u/pull/77/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=77&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8261914 > Stats: 10 lines in 1 file changed: 4 ins; 4 del; 2 mod > Patch: https://git.openjdk.java.net/jdk16u/pull/77.diff > Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/77/head:pull/77 > > PR: https://git.openjdk.java.net/jdk16u/pull/77 > From shade at redhat.com Wed Mar 10 08:00:54 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 10 Mar 2021 09:00:54 +0100 Subject: [External] : [jdk16u] JDK 16 RC tags? In-Reply-To: References: Message-ID: <2e4df19d-ec77-34e1-0060-87c8755ff1e8@redhat.com> On 3/9/21 5:16 PM, Robert Mckenna wrote: > Yep - apologies. I've added the tags to the weekly sync. Excellent, thanks. I see the new tags in jdk16u tree now. -- Thanks, -Aleksey From christoph.goettschkes at microdoc.com Wed Mar 10 09:42:35 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Wed, 10 Mar 2021 10:42:35 +0100 Subject: [11u] RFR: 8261752: Multiple GC test are missing memory requirements In-Reply-To: <6DBA2AB2-797C-4FD9-AD04-D84DEE18CA3F@amazon.com> References: <6DBA2AB2-797C-4FD9-AD04-D84DEE18CA3F@amazon.com> Message-ID: <373yskr50t-1@userp2030.oracle.com> Hi Paul, On 3/9/21 6:31 PM, Hohensee, Paul wrote: > Lgtm. > > To help keep track of tests that haven't been backported, please include in your fix request comment that TestMetaSpaceLog.java is missing from the backport, link 8261752 to 8211123 (the issue that introduced it), and add a comment to 8211123 that the test was excluded from the 8261752 backport. There are 12 patches that affect that missing test, so it's a difficult backport candidate, but someone may want to tackle it sometime. > thanks for the review and the details on how to handle this. I linked the two issues already and will mentioned the missing test in the request. I will add a comment to 8211123 as soon as the backport issue is created. -- Christoph From christoph.langer at sap.com Wed Mar 10 10:57:39 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 10 Mar 2021 10:57:39 +0000 Subject: [11u] RFR (S) 8214922: Aarch64: Add vectorization support for fmin/fmax In-Reply-To: References: <9d0af7aa-b4df-2774-f099-cc55de1890e0@bell-sw.com> Message-ID: Hi, I agree, the format changes from 8241911 should be added to this backport. Best regards Christoph > -----Original Message----- > From: Volker Simonis > Sent: Montag, 8. M?rz 2021 13:15 > To: Dmitry Chuyko > Cc: jdk-updates-dev at openjdk.java.net; aarch64-port- > dev at openjdk.java.net; Langer, Christoph > Subject: Re: [11u] RFR (S) 8214922: Aarch64: Add vectorization support for > fmin/fmax > > Hi Dmitry, > > in general, the downport looks good to me. > > I only wonder if we shouldn't integrate the format changes from > 8241911 which were skipped in December when 8241911 was downported > [1,2] because at that time this change wasn't in 11u. I'm fine either > way and leave the final decision to the 11u maintainers. > > Thank you and best regards, > Volker > > [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > December/004474.html > [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > December/004498.html > > On Thu, Feb 18, 2021 at 9:27 AM Dmitry Chuyko sw.com> wrote: > > > > Hello, > > > > Original RFE: https://bugs.openjdk.java.net/browse/JDK-8214922 > > > > Original patch applies almost cleanly except 2 added lines in > > src/hotspot/share/opto/vectornode.cpp because of missing part of > context > > (JDK-8214751 not ported), they are added manually. > > > > 11u webrev: > http://cr.openjdk.java.net/~dchuyko/8214922/webrev.11u.00/ > > > > Testing: tier1, tier2, TestFpMinMaxIntrinsics. > > > > -- > > Thanks, > > -Dmitry > > From christoph.goettschkes at microdoc.com Wed Mar 10 11:26:35 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Wed, 10 Mar 2021 12:26:35 +0100 Subject: [11u] RFR: 8261752: Multiple GC test are missing memory requirements In-Reply-To: <6DBA2AB2-797C-4FD9-AD04-D84DEE18CA3F@amazon.com> References: <6DBA2AB2-797C-4FD9-AD04-D84DEE18CA3F@amazon.com> Message-ID: <373ysksnfc-1@userp2030.oracle.com> Hi Paul, the backport got already approved. I updated the webrev and added you as a reviewer: https://cr.openjdk.java.net/~cgo/8261752/backport-11u.01/ https://bugs.openjdk.java.net/browse/JDK-8261752 Would you mind sponsoring this changset? I already added a comment to 8211123. Thanks, Christoph On 3/9/21 6:31 PM, Hohensee, Paul wrote: > Lgtm. > > To help keep track of tests that haven't been backported, please include in your fix request comment that TestMetaSpaceLog.java is missing from the backport, link 8261752 to 8211123 (the issue that introduced it), and add a comment to 8211123 that the test was excluded from the 8261752 backport. There are 12 patches that affect that missing test, so it's a difficult backport candidate, but someone may want to tackle it sometime. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf of Christoph G?ttschkes > Date: Tuesday, March 9, 2021 at 3:59 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [11u] RFR: 8261752: Multiple GC test are missing memory requirements > > Hello, > > please review the following backport to 11u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8261752 > Original commit: https://git.openjdk.java.net/jdk/commit/2e18b52a > Webrev: https://cr.openjdk.java.net/~cgo/8261752/backport-11u.00/ > > The patch doesn't apply cleanly, because 8249000 [1] and 8244614 [2] > have not been backported yet and changed a lot of test cases. Applying > the changes manually was trivial, since it only changes @requires tags > of some tests. > One of the test cases (TestMetaSpaceLog.java) doesn't exist in 11u. > > [1] https://bugs.openjdk.java.net/browse/JDK-8249000 > [2] https://bugs.openjdk.java.net/browse/JDK-8244614 > > From verghese at amazon.com Wed Mar 10 20:56:12 2021 From: verghese at amazon.com (Verghese, Clive) Date: Wed, 10 Mar 2021 20:56:12 +0000 Subject: [11u] RFR: Backport of 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl Message-ID: <2125893A-DF20-44A8-9F98-235BED2ADFBD@amazon.com> Hi, I would like to request a review for the backport of JDK-8259662 Webrev : http://cr.openjdk.java.net/~cverghese/webrevs/8259662/ The patch applied cleanly expect for the hunks at src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java, Line : 1329-1333 and 1394-1398. Have validated that the associated tests and tests in test/jdk/javax/net/ssl/SSLSession/ and test/jdk/sun/security/ssl are passing. Regards, Clive Verghese From ewhelan at openjdk.java.net Thu Mar 11 11:47:24 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Thu, 11 Mar 2021 11:47:24 GMT Subject: [jdk16u] RFR: 8260401: StackOverflowError on open WindowsPreferences Message-ID: Hi, Please review this backport which prevents StackOverflowError occurring on Windows. This occurs when users have incorrect registry access. Regards, Evan ------------- Commit messages: - 8260401: StackOverflowError on open WindowsPreferences Changes: https://git.openjdk.java.net/jdk16u/pull/78/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=78&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260401 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk16u/pull/78.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/78/head:pull/78 PR: https://git.openjdk.java.net/jdk16u/pull/78 From snazarki at openjdk.java.net Thu Mar 11 12:02:16 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Thu, 11 Mar 2021 12:02:16 GMT Subject: [jdk13u-dev] RFR: 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect Message-ID: I'd like to backport JDK-8259619 to jdk13u for parity with jdk11u. The original patch applied cleanly. ------------- Commit messages: - Backport ce9451208772 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/142/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=142&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259619 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/142.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/142/head:pull/142 PR: https://git.openjdk.java.net/jdk13u-dev/pull/142 From dmitry.chuyko at bell-sw.com Thu Mar 11 15:21:30 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 11 Mar 2021 18:21:30 +0300 Subject: [11u] RFR (S) 8223444: Improve CodeHeap Free Space Management Message-ID: <14b2a6b4-615c-efb9-ba57-4a05ac3a02b3@bell-sw.com> Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8223444 Original post-fix: https://bugs.openjdk.java.net/browse/JDK-8231460 Original patch applies almost cleanly except 4 changes in CodeHeap::add_to_freelist because JDK-8238356 is already backported, they were applied manually. Original post-fix (for performance issue) applies cleanly. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8223444/webrev.11u.00/ Testing: tier1, tier2. -- Thanks, -Dmitry From alvdavi at amazon.com Thu Mar 11 15:56:02 2021 From: alvdavi at amazon.com (Alvarez, David) Date: Thu, 11 Mar 2021 07:56:02 -0800 Subject: [15u] RFR 8202343: Disable TLS 1.0 and 1.1 Message-ID: <2bccd95a-5a7a-7cb2-4037-97d520bf7087@amazon.com> Hi, I would like to request a review for JDK-8202343 Bug: https://bugs.openjdk.java.net/browse/JDK-8202343 Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8202343/webrev.8202343.15u.00/ Patch applies almost cleanly, only minor changes were needed to the java.security and DisabledCurve.java files to account for JDK-8235710 [1] missing in 15u. Patch passes the tests under sun/security/ssl. I intend to mark this patch as critical request to make sure 15u is aligned with other versions, so I would appreciate if the patch gets reviewed soon. 13u also needs this backport. Thanks, David ------ [1] https://bugs.openjdk.java.net/browse/JDK-8235710 From clanger at openjdk.java.net Thu Mar 11 15:57:22 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 11 Mar 2021 15:57:22 GMT Subject: [jdk16u] RFR: 8263069: Exclude some failing tests from security/infra/java/security/cert/CertPathValidator Message-ID: 8263069: Exclude some failing tests from security/infra/java/security/cert/CertPathValidator ------------- Commit messages: - Backport a9b4f033ddfb2e7ea36ecdf2f076fc374fe54cac Changes: https://git.openjdk.java.net/jdk16u/pull/79/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=79&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263069 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16u/pull/79.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/79/head:pull/79 PR: https://git.openjdk.java.net/jdk16u/pull/79 From clanger at openjdk.java.net Thu Mar 11 16:02:13 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 11 Mar 2021 16:02:13 GMT Subject: [jdk16u] RFR: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 Message-ID: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 ------------- Commit messages: - Backport 8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81 Changes: https://git.openjdk.java.net/jdk16u/pull/80/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=80&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262844 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/80.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/80/head:pull/80 PR: https://git.openjdk.java.net/jdk16u/pull/80 From christoph.langer at sap.com Thu Mar 11 16:25:21 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 11 Mar 2021 16:25:21 +0000 Subject: [DMARC FAILURE] [15u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: <2bccd95a-5a7a-7cb2-4037-97d520bf7087@amazon.com> References: <2bccd95a-5a7a-7cb2-4037-97d520bf7087@amazon.com> Message-ID: Hi David, for 15u you should do the request as git/skara backport and get it reviewed in a PR, I guess. Please find some documentation for the backport process here: https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-CLI I guess the documentation is not current at the moment, you might as well use "git skara backport" when you have the latest skara tools installed. You could refer to this Skara PR for some documentation: https://github.com/openjdk/skara/pull/1025#issue-576471401 Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Alvarez, David > Sent: Donnerstag, 11. M?rz 2021 16:56 > To: jdk-updates-dev at openjdk.java.net > Subject: [DMARC FAILURE] [15u] RFR 8202343: Disable TLS 1.0 and 1.1 > > Hi, > > I would like to request a review for JDK-8202343 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202343 > Webrev: > http://cr.openjdk.java.net/~alvdavi/webrevs/8202343/webrev.8202343.15u. > 00/ > > Patch applies almost cleanly, only minor changes were needed to the > java.security and DisabledCurve.java files to account for JDK-8235710 > [1] missing in 15u. > > Patch passes the tests under sun/security/ssl. > > I intend to mark this patch as critical request to make sure 15u is > aligned with other versions, so I would appreciate if the patch gets > reviewed soon. 13u also needs this backport. > > Thanks, > > David > > ------ > [1] https://bugs.openjdk.java.net/browse/JDK-8235710 From hohensee at amazon.com Thu Mar 11 16:32:46 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Mar 2021 16:32:46 +0000 Subject: [11u] RFR: 8261752: Multiple GC test are missing memory requirements Message-ID: <3BEE6EFA-BC50-43CA-BE06-6A0BADBD37E5@amazon.com> No problem. I added your name to the changeset as a contributor. Pushed. Paul ?-----Original Message----- From: Christoph G?ttschkes Date: Wednesday, March 10, 2021 at 3:28 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: 8261752: Multiple GC test are missing memory requirements Hi Paul, the backport got already approved. I updated the webrev and added you as a reviewer: https://cr.openjdk.java.net/~cgo/8261752/backport-11u.01/ https://bugs.openjdk.java.net/browse/JDK-8261752 Would you mind sponsoring this changset? I already added a comment to 8211123. Thanks, Christoph On 3/9/21 6:31 PM, Hohensee, Paul wrote: > Lgtm. > > To help keep track of tests that haven't been backported, please include in your fix request comment that TestMetaSpaceLog.java is missing from the backport, link 8261752 to 8211123 (the issue that introduced it), and add a comment to 8211123 that the test was excluded from the 8261752 backport. There are 12 patches that affect that missing test, so it's a difficult backport candidate, but someone may want to tackle it sometime. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on behalf of Christoph G?ttschkes > Date: Tuesday, March 9, 2021 at 3:59 AM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [11u] RFR: 8261752: Multiple GC test are missing memory requirements > > Hello, > > please review the following backport to 11u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8261752 > Original commit: https://git.openjdk.java.net/jdk/commit/2e18b52a > Webrev: https://cr.openjdk.java.net/~cgo/8261752/backport-11u.00/ > > The patch doesn't apply cleanly, because 8249000 [1] and 8244614 [2] > have not been backported yet and changed a lot of test cases. Applying > the changes manually was trivial, since it only changes @requires tags > of some tests. > One of the test cases (TestMetaSpaceLog.java) doesn't exist in 11u. > > [1] https://bugs.openjdk.java.net/browse/JDK-8249000 > [2] https://bugs.openjdk.java.net/browse/JDK-8244614 > > From yan at azul.com Thu Mar 11 16:37:10 2021 From: yan at azul.com (Yuri Nesterenko) Date: Thu, 11 Mar 2021 19:37:10 +0300 Subject: [15u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: <2bccd95a-5a7a-7cb2-4037-97d520bf7087@amazon.com> References: <2bccd95a-5a7a-7cb2-4037-97d520bf7087@amazon.com> Message-ID: <64eaec56-4f64-b82c-e5f5-d9257207c3d8@azul.com> Hi David, do you plan also to backport JDK-8257083 and JDK-8256682 (that on the surface)? I hope we have a week or so for that. This patch looks OK to me. And as there was no clear rampdown declared, a simple jdk15u-fix-request should be enough. Thank you! --yan On 11.03.2021 18:56, Alvarez, David wrote: > Hi, > > I would like to request a review for JDK-8202343 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202343 > Webrev: > http://cr.openjdk.java.net/~alvdavi/webrevs/8202343/webrev.8202343.15u.00/ > > Patch applies almost cleanly, only minor changes were needed to the > java.security and DisabledCurve.java files to account for JDK-8235710 > [1] missing in 15u. > > Patch passes the tests under sun/security/ssl. > > I intend to mark this patch as critical request to make sure 15u is > aligned with other versions, so I would appreciate if the patch gets > reviewed soon. 13u also needs this backport. > > Thanks, > > David > > ------ > [1] https://bugs.openjdk.java.net/browse/JDK-8235710 > From yan at azul.com Thu Mar 11 16:39:44 2021 From: yan at azul.com (Yuri Nesterenko) Date: Thu, 11 Mar 2021 19:39:44 +0300 Subject: [DMARC FAILURE] [15u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: References: <2bccd95a-5a7a-7cb2-4037-97d520bf7087@amazon.com> Message-ID: <78b3ee12-a5b7-9283-42c1-036df0d4828b@azul.com> Hi Christoph, not yet:-) https://bugs.openjdk.java.net/browse/SKARA-920 is still in New state. --yan On 11.03.2021 19:25, Langer, Christoph wrote: > Hi David, > > for 15u you should do the request as git/skara backport and get it reviewed in a PR, I guess. > > Please find some documentation for the backport process here: https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-CLI > > I guess the documentation is not current at the moment, you might as well use "git skara backport" when you have the latest skara tools installed. You could refer to this Skara PR for some documentation: https://github.com/openjdk/skara/pull/1025#issue-576471401 > > Best regards > Christoph > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Alvarez, David >> Sent: Donnerstag, 11. M?rz 2021 16:56 >> To: jdk-updates-dev at openjdk.java.net >> Subject: [DMARC FAILURE] [15u] RFR 8202343: Disable TLS 1.0 and 1.1 >> >> Hi, >> >> I would like to request a review for JDK-8202343 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202343 >> Webrev: >> http://cr.openjdk.java.net/~alvdavi/webrevs/8202343/webrev.8202343.15u. >> 00/ >> >> Patch applies almost cleanly, only minor changes were needed to the >> java.security and DisabledCurve.java files to account for JDK-8235710 >> [1] missing in 15u. >> >> Patch passes the tests under sun/security/ssl. >> >> I intend to mark this patch as critical request to make sure 15u is >> aligned with other versions, so I would appreciate if the patch gets >> reviewed soon. 13u also needs this backport. >> >> Thanks, >> >> David >> >> ------ >> [1] https://bugs.openjdk.java.net/browse/JDK-8235710 > From alvdavi at amazon.com Thu Mar 11 16:45:27 2021 From: alvdavi at amazon.com (Alvarez, David) Date: Thu, 11 Mar 2021 08:45:27 -0800 Subject: [15u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: <64eaec56-4f64-b82c-e5f5-d9257207c3d8@azul.com> References: <2bccd95a-5a7a-7cb2-4037-97d520bf7087@amazon.com> <64eaec56-4f64-b82c-e5f5-d9257207c3d8@azul.com> Message-ID: Hi Yan, I did consider JDK-8257083 and JDK-8256682, but I didn't backport them because I thought this would need to go as critical (and I was not sure those two would). I'll try to grab them, but if you don't see the request in the next few days, feel free to pick this for the release (if JDK-8257083 and JDK-8256682 are picked, I expect this one to apply cleanly). David On 3/11/21 8:37 AM, Yuri Nesterenko wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi David, > > do you plan also to backport JDK-8257083 and JDK-8256682 (that on the surface)? > I hope we have a week or so for that. > This patch looks OK to me. > And as there was no clear rampdown declared, a simple jdk15u-fix-request should be enough. > > Thank you! > > --yan > > On 11.03.2021 18:56, Alvarez, David wrote: >> Hi, >> >> I would like to request a review for JDK-8202343 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202343 >> Webrev: >> http://cr.openjdk.java.net/~alvdavi/webrevs/8202343/webrev.8202343.15u.00/ >> >> Patch applies almost cleanly, only minor changes were needed to the >> java.security and DisabledCurve.java files to account for JDK-8235710 >> [1] missing in 15u. >> >> Patch passes the tests under sun/security/ssl. >> >> I intend to mark this patch as critical request to make sure 15u is >> aligned with other versions, so I would appreciate if the patch gets >> reviewed soon. 13u also needs this backport. >> >> Thanks, >> >> David >> >> ------ >> [1] https://bugs.openjdk.java.net/browse/JDK-8235710 >> > From alvdavi at amazon.com Thu Mar 11 16:47:04 2021 From: alvdavi at amazon.com (Alvarez, David) Date: Thu, 11 Mar 2021 08:47:04 -0800 Subject: [DMARC FAILURE] [15u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: <78b3ee12-a5b7-9283-42c1-036df0d4828b@azul.com> References: <2bccd95a-5a7a-7cb2-4037-97d520bf7087@amazon.com> <78b3ee12-a5b7-9283-42c1-036df0d4828b@azul.com> Message-ID: Thanks for the clarification. I did use skara for the 13u [1], but I did not see a 15u repo. Cristoph had me wondering. David ---- [1] https://github.com/openjdk/jdk13u-dev/pull/143 On 3/11/21 8:39 AM, Yuri Nesterenko wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi Christoph, > > not yet:-) > > https://bugs.openjdk.java.net/browse/SKARA-920 > > is still in New state. > > --yan > > On 11.03.2021 19:25, Langer, Christoph wrote: >> Hi David, >> >> for 15u you should do the request as git/skara backport and get it reviewed in a PR, I guess. >> >> Please find some documentation for the backport process here: https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-CLI >> >> I guess the documentation is not current at the moment, you might as well use "git skara backport" when you have the latest skara tools installed. You could refer to this Skara PR for some documentation: https://github.com/openjdk/skara/pull/1025#issue-576471401 >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: jdk-updates-dev On >>> Behalf Of Alvarez, David >>> Sent: Donnerstag, 11. M?rz 2021 16:56 >>> To: jdk-updates-dev at openjdk.java.net >>> Subject: [DMARC FAILURE] [15u] RFR 8202343: Disable TLS 1.0 and 1.1 >>> >>> Hi, >>> >>> I would like to request a review for JDK-8202343 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202343 >>> Webrev: >>> http://cr.openjdk.java.net/~alvdavi/webrevs/8202343/webrev.8202343.15u. >>> 00/ >>> >>> Patch applies almost cleanly, only minor changes were needed to the >>> java.security and DisabledCurve.java files to account for JDK-8235710 >>> [1] missing in 15u. >>> >>> Patch passes the tests under sun/security/ssl. >>> >>> I intend to mark this patch as critical request to make sure 15u is >>> aligned with other versions, so I would appreciate if the patch gets >>> reviewed soon. 13u also needs this backport. >>> >>> Thanks, >>> >>> David >>> >>> ------ >>> [1] https://bugs.openjdk.java.net/browse/JDK-8235710 >> > From alvdavi at amazon.com Thu Mar 11 16:50:03 2021 From: alvdavi at amazon.com (Alvarez, David) Date: Thu, 11 Mar 2021 08:50:03 -0800 Subject: [15u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: References: <2bccd95a-5a7a-7cb2-4037-97d520bf7087@amazon.com> <64eaec56-4f64-b82c-e5f5-d9257207c3d8@azul.com> Message-ID: <08c7bee2-9291-3948-1c1d-0ef8ef5327f9@amazon.com> Sorry, my bad, I though you were talking about the prerrequisites that made the patch not apply cleanly, but you were talking about the follow ups. Yes, I absolutely intend to backport those follow ups David On 3/11/21 8:45 AM, Alvarez, David wrote: > Hi Yan, > > I did consider JDK-8257083 and JDK-8256682, but I didn't backport them > because I thought this would need to go as critical (and I was not sure > those two would). I'll try to grab them, but if you don't see the > request in the next few days, feel free to pick this for the release (if > JDK-8257083 and JDK-8256682 are picked, I expect this one to apply cleanly). > > David > > On 3/11/21 8:37 AM, Yuri Nesterenko wrote: >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. >> >> >> >> Hi David, >> >> do you plan also to backport JDK-8257083 and JDK-8256682 (that on the surface)? >> I hope we have a week or so for that. >> This patch looks OK to me. >> And as there was no clear rampdown declared, a simple jdk15u-fix-request should be enough. >> >> Thank you! >> >> --yan >> >> On 11.03.2021 18:56, Alvarez, David wrote: >>> Hi, >>> >>> I would like to request a review for JDK-8202343 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202343 >>> Webrev: >>> http://cr.openjdk.java.net/~alvdavi/webrevs/8202343/webrev.8202343.15u.00/ >>> >>> Patch applies almost cleanly, only minor changes were needed to the >>> java.security and DisabledCurve.java files to account for JDK-8235710 >>> [1] missing in 15u. >>> >>> Patch passes the tests under sun/security/ssl. >>> >>> I intend to mark this patch as critical request to make sure 15u is >>> aligned with other versions, so I would appreciate if the patch gets >>> reviewed soon. 13u also needs this backport. >>> >>> Thanks, >>> >>> David >>> >>> ------ >>> [1] https://bugs.openjdk.java.net/browse/JDK-8235710 >>> >> > From martin.doerr at sap.com Thu Mar 11 16:50:12 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 11 Mar 2021 16:50:12 +0000 Subject: [11u] RFR: 8261209: isStandalone property: remove dependency on pretty-print Message-ID: Hi, JDK-8261209 is backported to 11.0.11-oracle. I'd like to backport it for parity. The actual fix is trivial, but the remainder of the original patch doesn't apply to 11u. So I suggest the following: - Only take the real fix which is in ToXMLStream.java (LastModified timestamp doesn't exist in 11u). - Skip module-info.java: The modified comments don't exist in 11u. - Skip PrettyPrintTest.java: The modified parts of the test don't exist in 11u. The existing tests are still passing with the fix. Original bug: https://bugs.openjdk.java.net/browse/JDK-8261209 Original change: https://github.com/openjdk/jdk/commit/7c565f8b 11u backport: http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.00/ Please review. Best regards, Martin From christoph.langer at sap.com Thu Mar 11 16:56:52 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 11 Mar 2021 16:56:52 +0000 Subject: [DMARC FAILURE] [15u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: <78b3ee12-a5b7-9283-42c1-036df0d4828b@azul.com> References: <2bccd95a-5a7a-7cb2-4037-97d520bf7087@amazon.com> <78b3ee12-a5b7-9283-42c1-036df0d4828b@azul.com> Message-ID: Hi Yuri, ah, I didn't know that. But sure, 15u was run with mercurial so far, so it's not yet converted ?? My bad... Sorry David for the confusion. Cheers Christoph > -----Original Message----- > From: Yuri Nesterenko > Sent: Donnerstag, 11. M?rz 2021 17:40 > To: Langer, Christoph ; Alvarez, David > ; jdk-updates-dev at openjdk.java.net > Subject: Re: [DMARC FAILURE] [15u] RFR 8202343: Disable TLS 1.0 and 1.1 > > Hi Christoph, > > not yet:-) > > https://bugs.openjdk.java.net/browse/SKARA-920 > > is still in New state. > > --yan > > On 11.03.2021 19:25, Langer, Christoph wrote: > > Hi David, > > > > for 15u you should do the request as git/skara backport and get it reviewed > in a PR, I guess. > > > > Please find some documentation for the backport process here: > https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-CLI > > > > I guess the documentation is not current at the moment, you might as well > use "git skara backport" when you have the latest skara tools installed. You > could refer to this Skara PR for some documentation: > https://github.com/openjdk/skara/pull/1025#issue-576471401 > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: jdk-updates-dev On > >> Behalf Of Alvarez, David > >> Sent: Donnerstag, 11. M?rz 2021 16:56 > >> To: jdk-updates-dev at openjdk.java.net > >> Subject: [DMARC FAILURE] [15u] RFR 8202343: Disable TLS 1.0 and 1.1 > >> > >> Hi, > >> > >> I would like to request a review for JDK-8202343 > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202343 > >> Webrev: > >> > http://cr.openjdk.java.net/~alvdavi/webrevs/8202343/webrev.8202343.15u. > >> 00/ > >> > >> Patch applies almost cleanly, only minor changes were needed to the > >> java.security and DisabledCurve.java files to account for JDK-8235710 > >> [1] missing in 15u. > >> > >> Patch passes the tests under sun/security/ssl. > >> > >> I intend to mark this patch as critical request to make sure 15u is > >> aligned with other versions, so I would appreciate if the patch gets > >> reviewed soon. 13u also needs this backport. > >> > >> Thanks, > >> > >> David > >> > >> ------ > >> [1] https://bugs.openjdk.java.net/browse/JDK-8235710 > > From hohensee at amazon.com Thu Mar 11 17:19:13 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Mar 2021 17:19:13 +0000 Subject: [11u] RFR (S) 8223444: Improve CodeHeap Free Space Management Message-ID: <89EDF166-607B-4112-9EA1-3CF79585A881@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Dmitry Chuyko Date: Thursday, March 11, 2021 at 7:22 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR (S) 8223444: Improve CodeHeap Free Space Management Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8223444 Original post-fix: https://bugs.openjdk.java.net/browse/JDK-8231460 Original patch applies almost cleanly except 4 changes in CodeHeap::add_to_freelist because JDK-8238356 is already backported, they were applied manually. Original post-fix (for performance issue) applies cleanly. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8223444/webrev.11u.00/ Testing: tier1, tier2. -- Thanks, -Dmitry From stuefe at openjdk.java.net Thu Mar 11 17:25:10 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 11 Mar 2021 17:25:10 GMT Subject: [jdk16u] RFR: 8263069: Exclude some failing tests from security/infra/java/security/cert/CertPathValidator In-Reply-To: References: Message-ID: <_X-peBE_Slp1osTQXK98sRlFxbp1eaA_-R4ZWuEDE2k=.8d274518-68e3-415a-a6b8-05bc762589b0@github.com> On Thu, 11 Mar 2021 15:51:01 GMT, Christoph Langer wrote: > 8263069: Exclude some failing tests from security/infra/java/security/cert/CertPathValidator LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk16u/pull/79 From hohensee at amazon.com Thu Mar 11 18:02:20 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Mar 2021 18:02:20 +0000 Subject: [11u] RFR: 8261209: isStandalone property: remove dependency on pretty-print Message-ID: Hi, Goetz, Looking at the latest 11u version of PrettyPrintTest.java (pushed 6 days ago), it does contain the modified parts. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Doerr, Martin" Date: Thursday, March 11, 2021 at 8:51 AM To: "jdk-updates-dev at openjdk.java.net" Cc: "Lindenmaier, Goetz" , "Langer, Christoph" Subject: [11u] RFR: 8261209: isStandalone property: remove dependency on pretty-print Hi, JDK-8261209 is backported to 11.0.11-oracle. I'd like to backport it for parity. The actual fix is trivial, but the remainder of the original patch doesn't apply to 11u. So I suggest the following: - Only take the real fix which is in ToXMLStream.java (LastModified timestamp doesn't exist in 11u). - Skip module-info.java: The modified comments don't exist in 11u. - Skip PrettyPrintTest.java: The modified parts of the test don't exist in 11u. The existing tests are still passing with the fix. Original bug: https://bugs.openjdk.java.net/browse/JDK-8261209 Original change: https://github.com/openjdk/jdk/commit/7c565f8b 11u backport: http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Thu Mar 11 19:20:10 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 11 Mar 2021 19:20:10 +0000 Subject: [11u] RFR: 8261209: isStandalone property: remove dependency on pretty-print In-Reply-To: References: Message-ID: Hi Paul, good catch! I should use jdk11u-critical-request and try to get approval for 11.0.11 which is in jdk11u, not in jdk11u-dev. It fits much better on top of the other jdk11u change: http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.01/ I only had to add the bug id 8261209 manually to PrettyPrintTest.java. Please take a look! Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 11. M?rz 2021 19:02 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: RE: [11u] RFR: 8261209: isStandalone property: remove dependency > on pretty-print > > Hi, Goetz, > > Looking at the latest 11u version of PrettyPrintTest.java (pushed 6 days ago), > it does contain the modified parts. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of "Doerr, Martin" > Date: Thursday, March 11, 2021 at 8:51 AM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Cc: "Lindenmaier, Goetz" , "Langer, > Christoph" > Subject: [11u] RFR: 8261209: isStandalone property: remove dependency on > pretty-print > > Hi, > > JDK-8261209 is backported to 11.0.11-oracle. I'd like to backport it for parity. > The actual fix is trivial, but the remainder of the original patch doesn't apply > to 11u. > > So I suggest the following: > - Only take the real fix which is in ToXMLStream.java (LastModified > timestamp doesn't exist in 11u). > - Skip module-info.java: The modified comments don't exist in 11u. > - Skip PrettyPrintTest.java: The modified parts of the test don't exist in 11u. > > The existing tests are still passing with the fix. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8261209 > > Original change: > https://github.com/openjdk/jdk/commit/7c565f8b > > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.00/ > > Please review. > > Best regards, > Martin > From hohensee at amazon.com Thu Mar 11 19:36:33 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Mar 2021 19:36:33 +0000 Subject: [11u] RFR: 8261209: isStandalone property: remove dependency on pretty-print Message-ID: Hi, Martin (I read Goetz in the cc as the sender!), Looks good now. Thanks, Paul ?-----Original Message----- From: "Doerr, Martin" Date: Thursday, March 11, 2021 at 11:21 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Cc: "Lindenmaier, Goetz" , "Langer, Christoph" Subject: RE: [11u] RFR: 8261209: isStandalone property: remove dependency on pretty-print Hi Paul, good catch! I should use jdk11u-critical-request and try to get approval for 11.0.11 which is in jdk11u, not in jdk11u-dev. It fits much better on top of the other jdk11u change: http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.01/ I only had to add the bug id 8261209 manually to PrettyPrintTest.java. Please take a look! Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 11. M?rz 2021 19:02 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: RE: [11u] RFR: 8261209: isStandalone property: remove dependency > on pretty-print > > Hi, Goetz, > > Looking at the latest 11u version of PrettyPrintTest.java (pushed 6 days ago), > it does contain the modified parts. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on > behalf of "Doerr, Martin" > Date: Thursday, March 11, 2021 at 8:51 AM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Cc: "Lindenmaier, Goetz" , "Langer, > Christoph" > Subject: [11u] RFR: 8261209: isStandalone property: remove dependency on > pretty-print > > Hi, > > JDK-8261209 is backported to 11.0.11-oracle. I'd like to backport it for parity. > The actual fix is trivial, but the remainder of the original patch doesn't apply > to 11u. > > So I suggest the following: > - Only take the real fix which is in ToXMLStream.java (LastModified > timestamp doesn't exist in 11u). > - Skip module-info.java: The modified comments don't exist in 11u. > - Skip PrettyPrintTest.java: The modified parts of the test don't exist in 11u. > > The existing tests are still passing with the fix. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8261209 > > Original change: > https://github.com/openjdk/jdk/commit/7c565f8b > > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.00/ > > Please review. > > Best regards, > Martin > From omikhaltcova at openjdk.java.net Fri Mar 12 08:08:23 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 12 Mar 2021 08:08:23 GMT Subject: [jdk13u-dev] RFR: 7185258: [macosx] Deadlock in SunToolKit.realSync() Message-ID: I'd like to backport JDK-7185258 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested manually with test/jdk/java/awt/dnd/DragWaitForIdle/DragWaitForIdle.java added in this patch. No regression in tests. ------------- Commit messages: - Backport 14b7dd40905f649f68bbe0c1e0faadd1dfabea84 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/144/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=144&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-7185258 Stats: 137 lines in 6 files changed: 125 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/144.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/144/head:pull/144 PR: https://git.openjdk.java.net/jdk13u-dev/pull/144 From snazarki at openjdk.java.net Fri Mar 12 08:16:11 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Fri, 12 Mar 2021 08:16:11 GMT Subject: [jdk13u-dev] Integrated: 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 10:10:11 GMT, Sergey Nazarkin wrote: > I'd like to backport JDK-8259619 to jdk13u for parity with jdk11u. > The original patch applied cleanly. This pull request has now been integrated. Changeset: e0aac4a5 Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/e0aac4a5 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect Backport-of: ce9451208772534efd532a6bc44c226a419f570d ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/142 From yan at openjdk.java.net Fri Mar 12 08:23:11 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 12 Mar 2021 08:23:11 GMT Subject: [jdk13u-dev] RFR: 7185258: [macosx] Deadlock in SunToolKit.realSync() In-Reply-To: References: Message-ID: <1-XZ6ZapntwCoTQ2eUiTn_DlZReKrIcYN0gMSxBPEE0=.53565ad2-4380-4ba9-97fb-da5184256455@github.com> On Fri, 12 Mar 2021 08:02:27 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-7185258 to jdk13u for parity with jdk11u. > The original patch applied quite cleanly (slight merge was needed in LWCToolkit.m due to year changed in copyright). > Tested manually with test/jdk/java/awt/dnd/DragWaitForIdle/DragWaitForIdle.java added in this patch. > No regression in tests. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/144 From omikhaltcova at openjdk.java.net Fri Mar 12 08:28:08 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 12 Mar 2021 08:28:08 GMT Subject: [jdk13u-dev] Integrated: 7185258: [macosx] Deadlock in SunToolKit.realSync() In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 08:02:27 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-7185258 to jdk13u for parity with jdk11u. > The original patch applied quite cleanly (slight merge was needed in LWCToolkit.m due to year changed in copyright). > Tested manually with test/jdk/java/awt/dnd/DragWaitForIdle/DragWaitForIdle.java added in this patch. > No regression in tests. This pull request has now been integrated. Changeset: 55f25d11 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/55f25d11 Stats: 137 lines in 6 files changed: 125 ins; 2 del; 10 mod 7185258: [macosx] Deadlock in SunToolKit.realSync() Reviewed-by: yan Backport-of: 14b7dd40905f649f68bbe0c1e0faadd1dfabea84 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/144 From snazarki at openjdk.java.net Fri Mar 12 08:34:20 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Fri, 12 Mar 2021 08:34:20 GMT Subject: [jdk13u-dev] RFR: 8262726: AArch64: C1 StubAssembler::call_RT can corrupt stack Message-ID: 8262726: AArch64: C1 StubAssembler::call_RT can corrupt stack ------------- Commit messages: - Backport be67aaabe63a4440c64bf79b9fa0d1394ac87ddf Changes: https://git.openjdk.java.net/jdk13u-dev/pull/145/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=145&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262726 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/145.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/145/head:pull/145 PR: https://git.openjdk.java.net/jdk13u-dev/pull/145 From snazarki at openjdk.java.net Fri Mar 12 08:58:10 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Fri, 12 Mar 2021 08:58:10 GMT Subject: [jdk13u-dev] Integrated: 8262726: AArch64: C1 StubAssembler::call_RT can corrupt stack In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 08:28:53 GMT, Sergey Nazarkin wrote: > 8262726: AArch64: C1 StubAssembler::call_RT can corrupt stack This pull request has now been integrated. Changeset: 5de1b465 Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/5de1b465 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8262726: AArch64: C1 StubAssembler::call_RT can corrupt stack Backport-of: be67aaabe63a4440c64bf79b9fa0d1394ac87ddf ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/145 From martin.doerr at sap.com Fri Mar 12 09:40:17 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 12 Mar 2021 09:40:17 +0000 Subject: [11u] RFR: 8261209: isStandalone property: remove dependency on pretty-print In-Reply-To: References: Message-ID: Hi Paul, thank you for the review! Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 11. M?rz 2021 20:37 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: RE: [11u] RFR: 8261209: isStandalone property: remove dependency > on pretty-print > > Hi, Martin (I read Goetz in the cc as the sender!), > > Looks good now. > > Thanks, > Paul > > ?-----Original Message----- > From: "Doerr, Martin" > Date: Thursday, March 11, 2021 at 11:21 AM > To: "Hohensee, Paul" , "jdk-updates- > dev at openjdk.java.net" > Cc: "Lindenmaier, Goetz" , "Langer, > Christoph" > Subject: RE: [11u] RFR: 8261209: isStandalone property: remove dependency > on pretty-print > > Hi Paul, > > good catch! > > I should use jdk11u-critical-request and try to get approval for 11.0.11 which > is in jdk11u, not in jdk11u-dev. > > It fits much better on top of the other jdk11u change: > http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.01/ > > I only had to add the bug id 8261209 manually to PrettyPrintTest.java. > > Please take a look! > > Best regards, > Martin > > > > -----Original Message----- > > From: Hohensee, Paul > > Sent: Donnerstag, 11. M?rz 2021 19:02 > > To: Doerr, Martin ; jdk-updates- > > dev at openjdk.java.net > > Cc: Lindenmaier, Goetz ; Langer, Christoph > > > > Subject: RE: [11u] RFR: 8261209: isStandalone property: remove > dependency > > on pretty-print > > > > Hi, Goetz, > > > > Looking at the latest 11u version of PrettyPrintTest.java (pushed 6 days > ago), > > it does contain the modified parts. > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: jdk-updates-dev on > > behalf of "Doerr, Martin" > > Date: Thursday, March 11, 2021 at 8:51 AM > > To: "jdk-updates-dev at openjdk.java.net" > dev at openjdk.java.net> > > Cc: "Lindenmaier, Goetz" , "Langer, > > Christoph" > > Subject: [11u] RFR: 8261209: isStandalone property: remove dependency > on > > pretty-print > > > > Hi, > > > > JDK-8261209 is backported to 11.0.11-oracle. I'd like to backport it for parity. > > The actual fix is trivial, but the remainder of the original patch doesn't apply > > to 11u. > > > > So I suggest the following: > > - Only take the real fix which is in ToXMLStream.java (LastModified > > timestamp doesn't exist in 11u). > > - Skip module-info.java: The modified comments don't exist in 11u. > > - Skip PrettyPrintTest.java: The modified parts of the test don't exist in 11u. > > > > The existing tests are still passing with the fix. > > > > Original bug: > > https://bugs.openjdk.java.net/browse/JDK-8261209 > > > > Original change: > > https://github.com/openjdk/jdk/commit/7c565f8b > > > > 11u backport: > > http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.00/ > > > > Please review. > > > > Best regards, > > Martin > > > From goetz.lindenmaier at sap.com Fri Mar 12 10:40:37 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 12 Mar 2021 10:40:37 +0000 Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: Hi, We had seen sporadic test failures in the test added with this change. Jaroslav proposed a fix. Thanks! Since applying that fix I did not see the problem any more. This new webrev contains the fix by Jaroslav: http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287-JFR_line_no_0-jdk11/02/ Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Monday, February 22, 2021 2:18 PM > To: jdk-updates-dev > Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have > line number 0 > > Hi, > > We tried to backport "8244287: JFR: Methods samples have line number 0" > to 11.0.9 [1]. The first downport had to be backed out, though [2]. > > I now propose this change for the issue. Please review. > http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287- > JFR_line_no_0-jdk11/01/ > I have verified that we do not see the crashes we saw with the > original change. > > New Issue: > https://bugs.openjdk.java.net/browse/JDK-8262121 > > Original Change: > https://bugs.openjdk.java.net/browse/JDK-8244287 > Previous downport: > https://bugs.openjdk.java.net/browse/JDK-8253576 > Backout: > https://bugs.openjdk.java.net/browse/JDK-8253813 > > I don't understand why the previous backport is > flagged as 11.010. It was pushed on 2020-09-23, > which was in the 11.0.9 time frame. But we had > issues with the automatic tagging in the past, probably > this is the reason. > > I will only push this to 11.0.12. > I would also adapt the backport information so that > JBS shows that this is only fixed in 11.0.12. > > Best regards, > Goetz > > [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > June/003312.html > [2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > September/003886.html From rwestrel at redhat.com Fri Mar 12 10:41:05 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 12 Mar 2021 11:41:05 +0100 Subject: [11u] RFR 8259710: Inlining trace leaks memory Message-ID: <87mtv8vem6.fsf@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8259710 https://github.com/openjdk/jdk/commit/ca20c63c The patch doesn't apply cleanly. Failed hunk is below but patch is otherwise largely unchanged. 11u webrev: https://cr.openjdk.java.net/~roland/8259710.11u/webrev.00/ Testing: x86_64 build, executing non trivial app with -XX:+PrintInlining Roland. --- compile.cpp +++ compile.cpp @@ -4209,32 +4204,32 @@ void Compile::print_inlining_commit() { assert(print_inlining() || print_intrinsics(), "PrintInlining off?"); // Transfer the message from _print_inlining_stream to the current // _print_inlining_list buffer and clear _print_inlining_stream. - _print_inlining_list->at(_print_inlining_idx).ss()->write(_print_inlining_stream->base(), _print_inlining_stream->size()); + _print_inlining_list->at(_print_inlining_idx)->ss()->write(_print_inlining_stream->base(), _print_inlining_stream->size()); print_inlining_reset(); } void Compile::print_inlining_push() { // Add new buffer to the _print_inlining_list at current position _print_inlining_idx++; - _print_inlining_list->insert_before(_print_inlining_idx, PrintInliningBuffer()); + _print_inlining_list->insert_before(_print_inlining_idx, new PrintInliningBuffer()); } -Compile::PrintInliningBuffer& Compile::print_inlining_current() { +Compile::PrintInliningBuffer* Compile::print_inlining_current() { return _print_inlining_list->at(_print_inlining_idx); } void Compile::print_inlining_update(CallGenerator* cg) { if (print_inlining() || print_intrinsics()) { if (cg->is_late_inline()) { - if (print_inlining_current().cg() != cg && - (print_inlining_current().cg() != NULL || - print_inlining_current().ss()->size() != 0)) { + if (print_inlining_current()->cg() != cg && + (print_inlining_current()->cg() != NULL || + print_inlining_current()->ss()->size() != 0)) { print_inlining_push(); } print_inlining_commit(); - print_inlining_current().set_cg(cg); + print_inlining_current()->set_cg(cg); } else { - if (print_inlining_current().cg() != NULL) { + if (print_inlining_current()->cg() != NULL) { print_inlining_push(); } print_inlining_commit(); From evergizova at openjdk.java.net Fri Mar 12 10:58:35 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 12 Mar 2021 10:58:35 GMT Subject: [jdk13u-dev] RFR: 8246707: (sc) SocketChannel.read/write throws AsynchronousCloseException on closed channel Message-ID: I'd like to backport JDK-8246707 to 13u for parity with 11u. The patch applies cleanly. Tested with tier1; new test fails without the patch, passes with it. ------------- Commit messages: - Backport 831f23ee86a158524dbf607428beb94f9c2a1552 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/146/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=146&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246707 Stats: 150 lines in 2 files changed: 137 ins; 8 del; 5 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/146.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/146/head:pull/146 PR: https://git.openjdk.java.net/jdk13u-dev/pull/146 From thomas.stuefe at gmail.com Fri Mar 12 11:31:51 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 12 Mar 2021 12:31:51 +0100 Subject: [11u] RFR 8259710: Inlining trace leaks memory In-Reply-To: <87mtv8vem6.fsf@redhat.com> References: <87mtv8vem6.fsf@redhat.com> Message-ID: Looks good. I wondered about the difference in print_inlining_update(), but saw that it had been changed with JDK-8257211, which I assume you don't want to backport. Cheers, Thomas On Fri, Mar 12, 2021 at 11:41 AM Roland Westrelin wrote: > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8259710 > https://github.com/openjdk/jdk/commit/ca20c63c > > The patch doesn't apply cleanly. Failed hunk is below but patch is > otherwise largely unchanged. > > 11u webrev: > https://cr.openjdk.java.net/~roland/8259710.11u/webrev.00/ > > Testing: x86_64 build, executing non trivial app with -XX:+PrintInlining > > Roland. > > --- compile.cpp > +++ compile.cpp > @@ -4209,32 +4204,32 @@ void Compile::print_inlining_commit() { > assert(print_inlining() || print_intrinsics(), "PrintInlining off?"); > // Transfer the message from _print_inlining_stream to the current > // _print_inlining_list buffer and clear _print_inlining_stream. > - > _print_inlining_list->at(_print_inlining_idx).ss()->write(_print_inlining_stream->base(), > _print_inlining_stream->size()); > + > _print_inlining_list->at(_print_inlining_idx)->ss()->write(_print_inlining_stream->base(), > _print_inlining_stream->size()); > print_inlining_reset(); > } > > void Compile::print_inlining_push() { > // Add new buffer to the _print_inlining_list at current position > _print_inlining_idx++; > - _print_inlining_list->insert_before(_print_inlining_idx, > PrintInliningBuffer()); > + _print_inlining_list->insert_before(_print_inlining_idx, new > PrintInliningBuffer()); > } > > -Compile::PrintInliningBuffer& Compile::print_inlining_current() { > +Compile::PrintInliningBuffer* Compile::print_inlining_current() { > return _print_inlining_list->at(_print_inlining_idx); > } > > void Compile::print_inlining_update(CallGenerator* cg) { > if (print_inlining() || print_intrinsics()) { > if (cg->is_late_inline()) { > - if (print_inlining_current().cg() != cg && > - (print_inlining_current().cg() != NULL || > - print_inlining_current().ss()->size() != 0)) { > + if (print_inlining_current()->cg() != cg && > + (print_inlining_current()->cg() != NULL || > + print_inlining_current()->ss()->size() != 0)) { > print_inlining_push(); > } > print_inlining_commit(); > - print_inlining_current().set_cg(cg); > + print_inlining_current()->set_cg(cg); > } else { > - if (print_inlining_current().cg() != NULL) { > + if (print_inlining_current()->cg() != NULL) { > print_inlining_push(); > } > print_inlining_commit(); > > From rwestrel at redhat.com Fri Mar 12 12:15:27 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 12 Mar 2021 13:15:27 +0100 Subject: [11u] RFR 8259710: Inlining trace leaks memory In-Reply-To: References: <87mtv8vem6.fsf@redhat.com> Message-ID: <87k0qcva8w.fsf@redhat.com> Hi Thomas, > Looks good. Thanks for the review. > I wondered about the difference in print_inlining_update(), but saw that it > had been changed with JDK-8257211, which I assume you don't want to > backport. Indeed. Roland. From dmitry.chuyko at bell-sw.com Fri Mar 12 13:14:07 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 12 Mar 2021 16:14:07 +0300 Subject: [11u] RFR (S) 8214922: Aarch64: Add vectorization support for fmin/fmax In-Reply-To: References: <9d0af7aa-b4df-2774-f099-cc55de1890e0@bell-sw.com> Message-ID: <972812d1-cd69-2194-bf88-0a7d8c65061f@bell-sw.com> Hi, Volker, Christoph, thanks for the catch. I included formatting changes into the patch. webrev: http://cr.openjdk.java.net/~dchuyko/8214922/webrev.11u.01/ Combined changes were re-tested and re-measured. -Dmitry On 3/10/21 1:57 PM, Langer, Christoph wrote: > Hi, > > I agree, the format changes from 8241911 should be added to this backport. > > Best regards > Christoph > >> -----Original Message----- >> From: Volker Simonis >> Sent: Montag, 8. M?rz 2021 13:15 >> To: Dmitry Chuyko >> Cc: jdk-updates-dev at openjdk.java.net; aarch64-port- >> dev at openjdk.java.net; Langer, Christoph >> Subject: Re: [11u] RFR (S) 8214922: Aarch64: Add vectorization support for >> fmin/fmax >> >> Hi Dmitry, >> >> in general, the downport looks good to me. >> >> I only wonder if we shouldn't integrate the format changes from >> 8241911 which were skipped in December when 8241911 was downported >> [1,2] because at that time this change wasn't in 11u. I'm fine either >> way and leave the final decision to the 11u maintainers. >> >> Thank you and best regards, >> Volker >> >> [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- >> December/004474.html >> [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- >> December/004498.html >> >> On Thu, Feb 18, 2021 at 9:27 AM Dmitry Chuyko > sw.com> wrote: >>> Hello, >>> >>> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8214922 >>> >>> Original patch applies almost cleanly except 2 added lines in >>> src/hotspot/share/opto/vectornode.cpp because of missing part of >> context >>> (JDK-8214751 not ported), they are added manually. >>> >>> 11u webrev: >> http://cr.openjdk.java.net/~dchuyko/8214922/webrev.11u.00/ >>> Testing: tier1, tier2, TestFpMinMaxIntrinsics. >>> >>> -- >>> Thanks, >>> -Dmitry >>> From evergizova at openjdk.java.net Fri Mar 12 14:47:12 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 12 Mar 2021 14:47:12 GMT Subject: [jdk13u-dev] Integrated: 8246707: (sc) SocketChannel.read/write throws AsynchronousCloseException on closed channel In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 10:52:54 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8246707 to 13u for parity with 11u. > The patch applies cleanly. > Tested with tier1; new test fails without the patch, passes with it. This pull request has now been integrated. Changeset: 325657a6 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk13u-dev/commit/325657a6 Stats: 150 lines in 2 files changed: 137 ins; 8 del; 5 mod 8246707: (sc) SocketChannel.read/write throws AsynchronousCloseException on closed channel This fix addresses an issue where an AsynchronousCloseException was being thrown instead of a ChannelClosedException when SocketChannel.write() is called on a closed SocketChannel. Backport-of: 831f23ee86a158524dbf607428beb94f9c2a1552 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/146 From evergizova at openjdk.java.net Fri Mar 12 19:04:20 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 12 Mar 2021 19:04:20 GMT Subject: [jdk13u-dev] RFR: 8250911: [windows] os::pd_map_memory error detection broken Message-ID: I'd like to backport JDK-8250911 to 13u for parity with 11u. The patch applies cleanly. Tested with tier1. ------------- Commit messages: - Backport aab365f7463014be658dd55626f1628048642a13 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/147/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=147&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250911 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/147.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/147/head:pull/147 PR: https://git.openjdk.java.net/jdk13u-dev/pull/147 From dmitry.chuyko at bell-sw.com Fri Mar 12 19:06:27 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 12 Mar 2021 22:06:27 +0300 Subject: [11u] RFR 8222412: AARCH64: multiple instructions encoding issues Message-ID: <9d506869-8b97-a9f6-03ca-7f19f22c4c04@bell-sw.com> Hello, Original bug: https://bugs.openjdk.java.net/browse/JDK-8222412 Original patch applies almost cleanly except 1 change in assembler_aarch64.hpp. In jdk/jdk the fix is based on JDK-8214961 [1]. In jdk11u first half of JDK-8214961 is already backported in JDK-8216350 [2]. The second half of JDK-8214961 is overridden by that single line change which is manually recreated to change the current code. I.e. -??? rf(Rs, 16), f(op1, 15), f(op2, 14, 12), f(0, 11, 10), rf(Rn, 5), zrf(Rt, 0); instead of -??? rf(Rs, 16), f(op1, 15), f(op2, 14, 12), f(0, 11, 10), srf(Rn, 5), zrf(Rt, 0); No need to backport JDK-8214961 as it is completely overridden by JDK-8222412 + JDK-8216350 backports. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8222412/webrev.11u.00/ Testing: aarch64 build, tier1, tier2; asm_check in fastdebug build. [1] https://bugs.openjdk.java.net/browse/JDK-8214961 [2] https://bugs.openjdk.java.net/browse/JDK-8216350 -- Thanks, -Dmitry From hohensee at amazon.com Fri Mar 12 23:14:04 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 12 Mar 2021 23:14:04 +0000 Subject: [11u] RFR 8222412: AARCH64: multiple instructions encoding issues Message-ID: <816421DD-1164-49D7-BC84-5DB40584EA6F@amazon.com> Looks like you're missing part of the assembler_aarch64.cpp patch in the sections "// AbsOp", "// CondBranchOp", "// Op", "// LoadStoreOp" with "__ prfm(back)", and "// FloatImmediateOp". Other than those hunks, looks good. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Dmitry Chuyko Date: Friday, March 12, 2021 at 12:58 PM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8222412: AARCH64: multiple instructions encoding issues Hello, Original bug: https://bugs.openjdk.java.net/browse/JDK-8222412 Original patch applies almost cleanly except 1 change in assembler_aarch64.hpp. In jdk/jdk the fix is based on JDK-8214961 [1]. In jdk11u first half of JDK-8214961 is already backported in JDK-8216350 [2]. The second half of JDK-8214961 is overridden by that single line change which is manually recreated to change the current code. I.e. - rf(Rs, 16), f(op1, 15), f(op2, 14, 12), f(0, 11, 10), rf(Rn, 5), zrf(Rt, 0); instead of - rf(Rs, 16), f(op1, 15), f(op2, 14, 12), f(0, 11, 10), srf(Rn, 5), zrf(Rt, 0); No need to backport JDK-8214961 as it is completely overridden by JDK-8222412 + JDK-8216350 backports. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8222412/webrev.11u.00/ Testing: aarch64 build, tier1, tier2; asm_check in fastdebug build. [1] https://bugs.openjdk.java.net/browse/JDK-8214961 [2] https://bugs.openjdk.java.net/browse/JDK-8216350 -- Thanks, -Dmitry From shade at openjdk.java.net Mon Mar 15 09:47:13 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 15 Mar 2021 09:47:13 GMT Subject: [jdk16u] Integrated: 8261914: IfNode::fold_compares_helper faces non-canonicalized bool when running JRuby JSON workload In-Reply-To: References: Message-ID: <7ap56hZgQEsSD240JLZuEXINlvfCkbhq8hfF9Iftu_s=.99218feb-4941-462a-9ecb-67667976df5d@github.com> On Tue, 9 Mar 2021 13:15:03 GMT, Aleksey Shipilev wrote: > JDK-8261912 provided the release-mode bailout, and this issue is supposed to fix the corner case in debug-mode. This pull request has now been integrated. Changeset: 69055914 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/69055914 Stats: 10 lines in 1 file changed: 4 ins; 4 del; 2 mod 8261914: IfNode::fold_compares_helper faces non-canonicalized bool when running JRuby JSON workload Backport-of: 20c93b3b901806cd9d691d75c8f30398c41fec34 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/77 From lutz.schmidt at sap.com Mon Mar 15 09:55:41 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 15 Mar 2021 09:55:41 +0000 Subject: [11u] RFR (S) 8223444: Improve CodeHeap Free Space Management In-Reply-To: References: <14b2a6b4-615c-efb9-ba57-4a05ac3a02b3@bell-sw.com> Message-ID: <5ECE130B-245D-419D-AF79-BC31958CDF3E@sap.com> Hi Dmitry, the changes look good to me. Thank you for bringing this one and the follow-up fix to jdk11. Please note that I'm not a reviewer for the jdk-updates project. But as author of the original change I dare to approve it. Regards, Lutz -----Original Message----- From: jdk-updates-dev On Behalf Of Dmitry Chuyko Sent: Donnerstag, 11. M?rz 2021 16:22 To: jdk-updates-dev at openjdk.java.net Subject: [11u] RFR (S) 8223444: Improve CodeHeap Free Space Management Hello, Original RFE: https://bugs.openjdk.java.net/browse/JDK-8223444 Original post-fix: https://bugs.openjdk.java.net/browse/JDK-8231460 Original patch applies almost cleanly except 4 changes in CodeHeap::add_to_freelist because JDK-8238356 is already backported, they were applied manually. Original post-fix (for performance issue) applies cleanly. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8223444/webrev.11u.00/ Testing: tier1, tier2. -- Thanks, -Dmitry From shade at openjdk.java.net Mon Mar 15 11:03:30 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 15 Mar 2021 11:03:30 GMT Subject: [jdk16u] RFR: 8263030: Remove Shenandoah leftovers from ReferenceProcessor Message-ID: Shenandoah is no longer using the shared ReferenceProcessor. We can remove remaining Shenandoah leftovers there. Additional testing: - [x] Linux x86_64 fastdebug, `hotspot_gc_shenandoah` ------------- Commit messages: - Backport ef5e13d263b6d4aaa50e777f7a3fc818293126c8 Changes: https://git.openjdk.java.net/jdk16u/pull/81/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=81&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263030 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/81/head:pull/81 PR: https://git.openjdk.java.net/jdk16u/pull/81 From evergizova at openjdk.java.net Mon Mar 15 13:07:20 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Mon, 15 Mar 2021 13:07:20 GMT Subject: [jdk13u-dev] Integrated: 8250911: [windows] os::pd_map_memory error detection broken In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 18:57:41 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8250911 to 13u for parity with 11u. > The patch applies cleanly. > Tested with tier1. This pull request has now been integrated. Changeset: d7a63fc9 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk13u-dev/commit/d7a63fc9 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8250911: [windows] os::pd_map_memory error detection broken Backport-of: aab365f7463014be658dd55626f1628048642a13 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/147 From dmarkov at openjdk.java.net Mon Mar 15 13:42:37 2021 From: dmarkov at openjdk.java.net (Dmitry Markov) Date: Mon, 15 Mar 2021 13:42:37 GMT Subject: [jdk16u] RFR: 8262446: DragAndDrop hangs on Windows Message-ID: Clean back port of bf9b74d18767619f0765ed1435e35e28077a4220 ------------- Commit messages: - 8262446: DragAndDrop hangs on Windows Changes: https://git.openjdk.java.net/jdk16u/pull/82/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=82&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262446 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk16u/pull/82 From dmarkov at openjdk.java.net Mon Mar 15 13:48:21 2021 From: dmarkov at openjdk.java.net (Dmitry Markov) Date: Mon, 15 Mar 2021 13:48:21 GMT Subject: [jdk16u] Integrated: 8262446: DragAndDrop hangs on Windows In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 12:56:31 GMT, Dmitry Markov wrote: > Clean back port of bf9b74d18767619f0765ed1435e35e28077a4220 This pull request has now been integrated. Changeset: 86a970d6 Author: Dmitry Markov URL: https://git.openjdk.java.net/jdk16u/commit/86a970d6 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod 8262446: DragAndDrop hangs on Windows Backport-of: bf9b74d18767619f0765ed1435e35e28077a4220 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/82 From christoph.langer at sap.com Mon Mar 15 15:45:44 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 15 Mar 2021 15:45:44 +0000 Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: Hi Goetz, it would have been nice if there was an incremental webrev compared to the previous version. But I think I've figured out that the increment was a fix in the test. ?? So, it seems that the update has indeed fixed the test failures that we observed before, hence it should be ok. The indentation in line 82 of TestStackFrameLineNumbers looks a bit awkward, you should fix that. But no need for a further webrev. 82 System.out.println("=== Frame: " + frame); Question to Jaroslav: It seems like the test is a valuable regression test. Shouldn't tit be added to jdk/jdk head as well? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 12. M?rz 2021 11:41 > To: jdk-updates-dev > Cc: 'Jaroslav Bachor?k' > Subject: RE: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have > line number 0 > > Hi, > > We had seen sporadic test failures in the test added with this > change. > Jaroslav proposed a fix. Thanks! Since applying that fix I did not see > the problem any more. > > This new webrev contains the fix by Jaroslav: > http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287- > JFR_line_no_0-jdk11/02/ > > Best regards, > Goetz. > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Monday, February 22, 2021 2:18 PM > > To: jdk-updates-dev > > Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have > > line number 0 > > > > Hi, > > > > We tried to backport "8244287: JFR: Methods samples have line number 0" > > to 11.0.9 [1]. The first downport had to be backed out, though [2]. > > > > I now propose this change for the issue. Please review. > > http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287- > > JFR_line_no_0-jdk11/01/ > > I have verified that we do not see the crashes we saw with the > > original change. > > > > New Issue: > > https://bugs.openjdk.java.net/browse/JDK-8262121 > > > > Original Change: > > https://bugs.openjdk.java.net/browse/JDK-8244287 > > Previous downport: > > https://bugs.openjdk.java.net/browse/JDK-8253576 > > Backout: > > https://bugs.openjdk.java.net/browse/JDK-8253813 > > > > I don't understand why the previous backport is > > flagged as 11.010. It was pushed on 2020-09-23, > > which was in the 11.0.9 time frame. But we had > > issues with the automatic tagging in the past, probably > > this is the reason. > > > > I will only push this to 11.0.12. > > I would also adapt the backport information so that > > JBS shows that this is only fixed in 11.0.12. > > > > Best regards, > > Goetz > > > > [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > > June/003312.html > > [2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > > September/003886.html From jaroslav.bachorik at datadoghq.com Mon Mar 15 16:21:17 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 15 Mar 2021 17:21:17 +0100 Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: Hi Christop, On Mon, Mar 15, 2021 at 4:45 PM Langer, Christoph wrote: > Hi Goetz, > > it would have been nice if there was an incremental webrev compared to the > previous version. But I think I've figured out that the increment was a fix > in the test. ?? > > So, it seems that the update has indeed fixed the test failures that we > observed before, hence it should be ok. > > The indentation in line 82 of TestStackFrameLineNumbers looks a bit > awkward, you should fix that. But no need for a further webrev. > > 82 System.out.println("=== Frame: " + frame); > > Question to Jaroslav: It seems like the test is a valuable regression > test. Shouldn't tit be added to jdk/jdk head as well? > Goetz is the original author of the test - I just fixed the corner case where no samples were generated due to low activity. But yes, it would definitely make sense to have this test in jdk/jdk head too. -JB- > > Best regards > Christoph > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Freitag, 12. M?rz 2021 11:41 > > To: jdk-updates-dev > > Cc: 'Jaroslav Bachor?k' > > Subject: RE: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples > have > > line number 0 > > > > Hi, > > > > We had seen sporadic test failures in the test added with this > > change. > > Jaroslav proposed a fix. Thanks! Since applying that fix I did not see > > the problem any more. > > > > This new webrev contains the fix by Jaroslav: > > http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287- > > JFR_line_no_0-jdk11/02/ > > > > Best regards, > > Goetz. > > > > > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz > > > Sent: Monday, February 22, 2021 2:18 PM > > > To: jdk-updates-dev > > > Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have > > > line number 0 > > > > > > Hi, > > > > > > We tried to backport "8244287: JFR: Methods samples have line number 0" > > > to 11.0.9 [1]. The first downport had to be backed out, though [2]. > > > > > > I now propose this change for the issue. Please review. > > > http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287- > > > JFR_line_no_0-jdk11/01/ > > > I have verified that we do not see the crashes we saw with the > > > original change. > > > > > > New Issue: > > > https://bugs.openjdk.java.net/browse/JDK-8262121 > > > > > > Original Change: > > > https://bugs.openjdk.java.net/browse/JDK-8244287 > > > Previous downport: > > > https://bugs.openjdk.java.net/browse/JDK-8253576 > > > Backout: > > > https://bugs.openjdk.java.net/browse/JDK-8253813 > > > > > > I don't understand why the previous backport is > > > flagged as 11.010. It was pushed on 2020-09-23, > > > which was in the 11.0.9 time frame. But we had > > > issues with the automatic tagging in the past, probably > > > this is the reason. > > > > > > I will only push this to 11.0.12. > > > I would also adapt the backport information so that > > > JBS shows that this is only fixed in 11.0.12. > > > > > > Best regards, > > > Goetz > > > > > > [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > > > June/003312.html > > > [2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > > > September/003886.html > From goetz.lindenmaier at sap.com Mon Mar 15 16:28:43 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 15 Mar 2021 16:28:43 +0000 Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: Hi, Jaroslav, the test is by you. I just fixed the change by you that was backed out in 11.0.9. That change already contained the test. But at that time there was a real error in the fix. https://bugs.openjdk.java.net/browse/JDK-8244287 https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-June/003312.html History ?? Should I count you as reviewer too, Jaroslav? Best regards Goetz. From: Jaroslav Bachor?k Sent: Monday, March 15, 2021 5:21 PM To: Langer, Christoph Cc: Lindenmaier, Goetz ; jdk-updates-dev Subject: Re: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have line number 0 Hi Christop, On Mon, Mar 15, 2021 at 4:45 PM Langer, Christoph > wrote: Hi Goetz, it would have been nice if there was an incremental webrev compared to the previous version. But I think I've figured out that the increment was a fix in the test. ?? So, it seems that the update has indeed fixed the test failures that we observed before, hence it should be ok. The indentation in line 82 of TestStackFrameLineNumbers looks a bit awkward, you should fix that. But no need for a further webrev. 82 System.out.println("=== Frame: " + frame); Question to Jaroslav: It seems like the test is a valuable regression test. Shouldn't tit be added to jdk/jdk head as well? Goetz is the original author of the test - I just fixed the corner case where no samples were generated due to low activity. But yes, it would definitely make sense to have this test in jdk/jdk head too. -JB- Best regards Christoph > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 12. M?rz 2021 11:41 > To: jdk-updates-dev > > Cc: 'Jaroslav Bachor?k' > > Subject: RE: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have > line number 0 > > Hi, > > We had seen sporadic test failures in the test added with this > change. > Jaroslav proposed a fix. Thanks! Since applying that fix I did not see > the problem any more. > > This new webrev contains the fix by Jaroslav: > http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287- > JFR_line_no_0-jdk11/02/ > > Best regards, > Goetz. > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Monday, February 22, 2021 2:18 PM > > To: jdk-updates-dev > > > Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have > > line number 0 > > > > Hi, > > > > We tried to backport "8244287: JFR: Methods samples have line number 0" > > to 11.0.9 [1]. The first downport had to be backed out, though [2]. > > > > I now propose this change for the issue. Please review. > > http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287- > > JFR_line_no_0-jdk11/01/ > > I have verified that we do not see the crashes we saw with the > > original change. > > > > New Issue: > > https://bugs.openjdk.java.net/browse/JDK-8262121 > > > > Original Change: > > https://bugs.openjdk.java.net/browse/JDK-8244287 > > Previous downport: > > https://bugs.openjdk.java.net/browse/JDK-8253576 > > Backout: > > https://bugs.openjdk.java.net/browse/JDK-8253813 > > > > I don't understand why the previous backport is > > flagged as 11.010. It was pushed on 2020-09-23, > > which was in the 11.0.9 time frame. But we had > > issues with the automatic tagging in the past, probably > > this is the reason. > > > > I will only push this to 11.0.12. > > I would also adapt the backport information so that > > JBS shows that this is only fixed in 11.0.12. > > > > Best regards, > > Goetz > > > > [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > > June/003312.html > > [2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > > September/003886.html From j.bachorik at gmail.com Mon Mar 15 16:53:50 2021 From: j.bachorik at gmail.com (Jaroslav Bachorik) Date: Mon, 15 Mar 2021 17:53:50 +0100 Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: On Mon, Mar 15, 2021 at 5:29 PM Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi, > > Jaroslav, the test is by you. > Ouch. And I thought I was lazy to provide the test in the first place :) Ok. I will file a JIRA ticket to get it to jdk/jdk. > I just fixed the change by you that was backed out in 11.0.9. > That change already contained the test. > But at that time there was a real error in the fix. > https://bugs.openjdk.java.net/browse/JDK-8244287 > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-June/003312.html > > History ?? > > Should I count you as reviewer too, Jaroslav? > Not necessary. I didn't do any real reviewing. Cheers, -JB- > > Best regards > Goetz. > > > From: Jaroslav Bachor?k > Sent: Monday, March 15, 2021 5:21 PM > To: Langer, Christoph > Cc: Lindenmaier, Goetz ; jdk-updates-dev < > jdk-updates-dev at openjdk.java.net> > Subject: Re: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have > line number 0 > > Hi Christop, > > On Mon, Mar 15, 2021 at 4:45 PM Langer, Christoph < > christoph.langer at sap.com> wrote: > Hi Goetz, > > it would have been nice if there was an incremental webrev compared to the > previous version. But I think I've figured out that the increment was a fix > in the test. ?? > > So, it seems that the update has indeed fixed the test failures that we > observed before, hence it should be ok. > > The indentation in line 82 of TestStackFrameLineNumbers looks a bit > awkward, you should fix that. But no need for a further webrev. > > 82 System.out.println("=== Frame: " + frame); > > Question to Jaroslav: It seems like the test is a valuable regression > test. Shouldn't tit be added to jdk/jdk head as well? > > Goetz is the original author of the test - I just fixed the corner case > where no samples were generated due to low activity. But yes, it would > definitely make sense to have this test in jdk/jdk head too. > > -JB- > > > Best regards > Christoph > > > > -----Original Message----- > > From: jdk-updates-dev jdk-updates-dev-retn at openjdk.java.net>> On > > Behalf Of Lindenmaier, Goetz > > Sent: Freitag, 12. M?rz 2021 11:41 > > To: jdk-updates-dev jdk-updates-dev at openjdk.java.net>> > > Cc: 'Jaroslav Bachor?k' jaroslav.bachorik at datadoghq.com>> > > Subject: RE: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples > have > > line number 0 > > > > Hi, > > > > We had seen sporadic test failures in the test added with this > > change. > > Jaroslav proposed a fix. Thanks! Since applying that fix I did not see > > the problem any more. > > > > This new webrev contains the fix by Jaroslav: > > http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287- > > JFR_line_no_0-jdk11/02/ > > > > Best regards, > > Goetz. > > > > > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz > > > Sent: Monday, February 22, 2021 2:18 PM > > > To: jdk-updates-dev jdk-updates-dev at openjdk.java.net>> > > > Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have > > > line number 0 > > > > > > Hi, > > > > > > We tried to backport "8244287: JFR: Methods samples have line number 0" > > > to 11.0.9 [1]. The first downport had to be backed out, though [2]. > > > > > > I now propose this change for the issue. Please review. > > > http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287- > > > JFR_line_no_0-jdk11/01/ > > > I have verified that we do not see the crashes we saw with the > > > original change. > > > > > > New Issue: > > > https://bugs.openjdk.java.net/browse/JDK-8262121 > > > > > > Original Change: > > > https://bugs.openjdk.java.net/browse/JDK-8244287 > > > Previous downport: > > > https://bugs.openjdk.java.net/browse/JDK-8253576 > > > Backout: > > > https://bugs.openjdk.java.net/browse/JDK-8253813 > > > > > > I don't understand why the previous backport is > > > flagged as 11.010. It was pushed on 2020-09-23, > > > which was in the 11.0.9 time frame. But we had > > > issues with the automatic tagging in the past, probably > > > this is the reason. > > > > > > I will only push this to 11.0.12. > > > I would also adapt the backport information so that > > > JBS shows that this is only fixed in 11.0.12. > > > > > > Best regards, > > > Goetz > > > > > > [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > > > June/003312.html > > > [2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > > > September/003886.html > From hohensee at amazon.com Mon Mar 15 17:09:54 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 15 Mar 2021 17:09:54 +0000 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Message-ID: <739B2CF5-1C67-46A8-8C91-3642CD6C9818@amazon.com> The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. Thanks, Paul ?-----Original Message----- From: security-dev on behalf of Daniel Jeli?ski Date: Tuesday, March 9, 2021 at 3:37 PM To: "jdk-updates-dev at openjdk.java.net" Cc: "security-dev at openjdk.java.net" Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Hi, Please review this 11u backport; this is the same patch as for head, except for microbenchmark makefile changes that did not apply because the file doesn't exist in 11u, and the actual microbenchmark, which would only add weight for no benefit. Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 webrev: https://djelinski.github.io/8259886-11u/webrev/index.html Testing: Linux x86_64 tier1 and tier2. Thanks, Daniel From martin.doerr at sap.com Mon Mar 15 17:10:14 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 15 Mar 2021 17:10:14 +0000 Subject: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys Message-ID: Hi, JDK-8243559 is backported to 11.0.12-oracle. I'd like to backport it for parity. I had to integrate changes to the test VerifyCACerts.java manually: - Add bug ID. - Adapt COUNT. - Compute new CHECKSUM. - Remove verisigntsaca and thawtepremiumserverca in the last hunk. Bug: https://bugs.openjdk.java.net/browse/JDK-8243559 Original change: https://github.com/openjdk/jdk/commit/dbfeb90d 11u backport: http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Mon Mar 15 17:38:33 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 15 Mar 2021 17:38:33 +0000 Subject: [11u] RFR: 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux Message-ID: Hi, JDK-8171303 is backported to 11.0.12-oracle. I'd like to backport it for parity. I had to remove the test from the problem list manually. Bug: https://bugs.openjdk.java.net/browse/JDK-8171303 Original change: https://git.openjdk.java.net/jdk/commit/48802268 11u backport: http://cr.openjdk.java.net/~mdoerr/8171303_2d_test_11u/webrev.00/ Please review. Best regards, Martin From volker.simonis at gmail.com Mon Mar 15 17:56:27 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 15 Mar 2021 18:56:27 +0100 Subject: [11u] RFR (S) 8214922: Aarch64: Add vectorization support for fmin/fmax In-Reply-To: <972812d1-cd69-2194-bf88-0a7d8c65061f@bell-sw.com> References: <9d0af7aa-b4df-2774-f099-cc55de1890e0@bell-sw.com> <972812d1-cd69-2194-bf88-0a7d8c65061f@bell-sw.com> Message-ID: Hi Dmitry, thanks for applying the extra formatting changes. Looks good to me now. Regards, Volker On Fri, Mar 12, 2021 at 2:14 PM Dmitry Chuyko wrote: > > Hi, > > Volker, Christoph, thanks for the catch. I included formatting changes > into the patch. > > webrev: http://cr.openjdk.java.net/~dchuyko/8214922/webrev.11u.01/ > > Combined changes were re-tested and re-measured. > > -Dmitry > > On 3/10/21 1:57 PM, Langer, Christoph wrote: > > Hi, > > > > I agree, the format changes from 8241911 should be added to this backport. > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: Volker Simonis > >> Sent: Montag, 8. M?rz 2021 13:15 > >> To: Dmitry Chuyko > >> Cc: jdk-updates-dev at openjdk.java.net; aarch64-port- > >> dev at openjdk.java.net; Langer, Christoph > >> Subject: Re: [11u] RFR (S) 8214922: Aarch64: Add vectorization support for > >> fmin/fmax > >> > >> Hi Dmitry, > >> > >> in general, the downport looks good to me. > >> > >> I only wonder if we shouldn't integrate the format changes from > >> 8241911 which were skipped in December when 8241911 was downported > >> [1,2] because at that time this change wasn't in 11u. I'm fine either > >> way and leave the final decision to the 11u maintainers. > >> > >> Thank you and best regards, > >> Volker > >> > >> [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > >> December/004474.html > >> [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > >> December/004498.html > >> > >> On Thu, Feb 18, 2021 at 9:27 AM Dmitry Chuyko >> sw.com> wrote: > >>> Hello, > >>> > >>> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8214922 > >>> > >>> Original patch applies almost cleanly except 2 added lines in > >>> src/hotspot/share/opto/vectornode.cpp because of missing part of > >> context > >>> (JDK-8214751 not ported), they are added manually. > >>> > >>> 11u webrev: > >> http://cr.openjdk.java.net/~dchuyko/8214922/webrev.11u.00/ > >>> Testing: tier1, tier2, TestFpMinMaxIntrinsics. > >>> > >>> -- > >>> Thanks, > >>> -Dmitry > >>> From shade at openjdk.java.net Mon Mar 15 17:57:19 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 15 Mar 2021 17:57:19 GMT Subject: [jdk16u] RFR: 8260236: better init AnnotationCollector _contended_group Message-ID: This eliminates a potential source of bugs, and keeps codebases in sync (I see 11.0.12-oracle). Patch apples to 11u cleanly, passes tier{1,2}. ------------- Commit messages: - Backport fd2641ed36c8cdb59c33675bd9ed909b47cd002e Changes: https://git.openjdk.java.net/jdk16u/pull/83/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=83&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260236 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/83.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/83/head:pull/83 PR: https://git.openjdk.java.net/jdk16u/pull/83 From hohensee at amazon.com Mon Mar 15 17:58:12 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 15 Mar 2021 17:58:12 +0000 Subject: [11u] RFR: 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux Message-ID: <7205A435-12E3-4E1D-93EC-BAD8074FB1A1@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Doerr, Martin" Date: Monday, March 15, 2021 at 10:44 AM To: "jdk-updates-dev at openjdk.java.net" Cc: "Lindenmaier, Goetz" , "Langer, Christoph" Subject: [11u] RFR: 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux Hi, JDK-8171303 is backported to 11.0.12-oracle. I'd like to backport it for parity. I had to remove the test from the problem list manually. Bug: https://bugs.openjdk.java.net/browse/JDK-8171303 Original change: https://git.openjdk.java.net/jdk/commit/48802268 11u backport: http://cr.openjdk.java.net/~mdoerr/8171303_2d_test_11u/webrev.00/ Please review. Best regards, Martin From hseigel at openjdk.java.net Mon Mar 15 18:02:07 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 15 Mar 2021 18:02:07 GMT Subject: [jdk16u] RFR: 8260236: better init AnnotationCollector _contended_group In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 17:50:51 GMT, Aleksey Shipilev wrote: > This eliminates a potential source of bugs, and keeps codebases in sync (I see 11.0.12-oracle). Patch apples to 11u cleanly, passes tier{1,2}. LGTM ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk16u/pull/83 From martin.doerr at sap.com Mon Mar 15 18:03:46 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 15 Mar 2021 18:03:46 +0000 Subject: [11u] RFR: 8171303: sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux In-Reply-To: <7205A435-12E3-4E1D-93EC-BAD8074FB1A1@amazon.com> References: <7205A435-12E3-4E1D-93EC-BAD8074FB1A1@amazon.com> Message-ID: Hi Paul, thanks for the prompt review! Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Montag, 15. M?rz 2021 18:58 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: Re: [11u] RFR: 8171303: > sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux > > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of "Doerr, Martin" > Date: Monday, March 15, 2021 at 10:44 AM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Cc: "Lindenmaier, Goetz" , "Langer, > Christoph" > Subject: [11u] RFR: 8171303: sun/java2d/pipe/InterpolationQualityTest.java > fails on Windows & Linux > > Hi, > > JDK-8171303 is backported to 11.0.12-oracle. I'd like to backport it for parity. > I had to remove the test from the problem list manually. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8171303 > > Original change: > https://git.openjdk.java.net/jdk/commit/48802268 > > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8171303_2d_test_11u/webrev.00/ > > Please review. > > Best regards, > Martin > From shade at redhat.com Mon Mar 15 18:31:22 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 15 Mar 2021 19:31:22 +0100 Subject: [11u] RFR (XS) 8239536: Can't use `java.util.List` object after importing `java.awt.List` Message-ID: <0b9dd71e-9205-469e-c7e9-eac2d22c7c22@redhat.com> Original bugfix: https://bugs.openjdk.java.net/browse/JDK-8239536 https://hg.openjdk.java.net/jdk/jdk/rev/38319837aeec The patch applies to 11u almost exactly, except for @bug line in ToolSimpleTest, which in 14u includes the mentions of the fixes that could not be backported (i.e. Raw String Literal support). Therefore, I had to add the bug ID for this bug by hand. 11u variant: https://cr.openjdk.java.net/~shade/8239536/webrev.11u.01/ Testing: jdk/shell, tier{1,2} -- Thanks, -Aleksey From hohensee at amazon.com Mon Mar 15 18:51:06 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 15 Mar 2021 18:51:06 +0000 Subject: [11u] RFR (XS) 8239536: Can't use `java.util.List` object after importing `java.awt.List` Message-ID: <350CA6AE-8244-49DD-89D7-A37E3165A476@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Aleksey Shipilev Date: Monday, March 15, 2021 at 11:34 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR (XS) 8239536: Can't use `java.util.List` object after importing `java.awt.List` Original bugfix: https://bugs.openjdk.java.net/browse/JDK-8239536 https://hg.openjdk.java.net/jdk/jdk/rev/38319837aeec The patch applies to 11u almost exactly, except for @bug line in ToolSimpleTest, which in 14u includes the mentions of the fixes that could not be backported (i.e. Raw String Literal support). Therefore, I had to add the bug ID for this bug by hand. 11u variant: https://cr.openjdk.java.net/~shade/8239536/webrev.11u.01/ Testing: jdk/shell, tier{1,2} -- Thanks, -Aleksey From omikhaltcova at openjdk.java.net Mon Mar 15 20:50:23 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 15 Mar 2021 20:50:23 GMT Subject: [jdk13u-dev] RFR: 8257414: Drag n Drop target area is wrong on high DPI systems Message-ID: I'd like to backport JDK-8257414 to jdk13u for parity with jdk11u. The original patch applied cleanly. Tested manually. ------------- Commit messages: - Backport d3398324e9c3944d2f1558ff1becea9ed1d4e8a2 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/148/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=148&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257414 Stats: 31 lines in 2 files changed: 26 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/148.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/148/head:pull/148 PR: https://git.openjdk.java.net/jdk13u-dev/pull/148 From omikhaltcova at openjdk.java.net Tue Mar 16 07:02:17 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Tue, 16 Mar 2021 07:02:17 GMT Subject: [jdk13u-dev] Integrated: 8257414: Drag n Drop target area is wrong on high DPI systems In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 20:42:09 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8257414 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > Tested manually. This pull request has now been integrated. Changeset: 5850c58e Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/5850c58e Stats: 31 lines in 2 files changed: 26 ins; 0 del; 5 mod 8257414: Drag n Drop target area is wrong on high DPI systems Backport-of: d3398324e9c3944d2f1558ff1becea9ed1d4e8a2 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/148 From shade at redhat.com Tue Mar 16 08:25:23 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 16 Mar 2021 09:25:23 +0100 Subject: [11u] RFR (XS) 8239536: Can't use `java.util.List` object after importing `java.awt.List` In-Reply-To: <350CA6AE-8244-49DD-89D7-A37E3165A476@amazon.com> References: <350CA6AE-8244-49DD-89D7-A37E3165A476@amazon.com> Message-ID: On 3/15/21 7:51 PM, Hohensee, Paul wrote: > Lgtm. Thanks, tagged. -- -Aleksey From shade at openjdk.java.net Tue Mar 16 09:52:24 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 16 Mar 2021 09:52:24 GMT Subject: [jdk16u] RFR: 8263136: C4530 was reported from VS 2019 at access bridge Message-ID: Seeing the similar failure in JDK 16u GHA testing. Backport this one should help. ------------- Commit messages: - Backport d339320e0b648e28bcc0c07801ae9376a33fc975 Changes: https://git.openjdk.java.net/jdk16u/pull/84/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=84&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263136 Stats: 9 lines in 1 file changed: 2 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk16u/pull/84.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/84/head:pull/84 PR: https://git.openjdk.java.net/jdk16u/pull/84 From sgehwolf at redhat.com Tue Mar 16 10:20:37 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 16 Mar 2021 11:20:37 +0100 Subject: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys In-Reply-To: References: Message-ID: <31912d26dddcc09b0084e88826b0dabd740e921c.camel@redhat.com> Hi Martin, On Mon, 2021-03-15 at 17:10 +0000, Doerr, Martin wrote: > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.00/ This doesn't look like the right webrev to me. Could you please double- check? Thanks, Severin From aivanov at openjdk.java.net Tue Mar 16 11:54:29 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 16 Mar 2021 11:54:29 GMT Subject: [jdk16u] Integrated: 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames() In-Reply-To: References: Message-ID: On Tue, 16 Mar 2021 11:47:11 GMT, Alexey Ivanov wrote: > Backporting [JDK-8262829](https://bugs.openjdk.java.net/browse/JDK-8262829) to jdk16u. This pull request has now been integrated. Changeset: 7ba457ab Author: Alexey Ivanov URL: https://git.openjdk.java.net/jdk16u/commit/7ba457ab Stats: 20 lines in 1 file changed: 13 ins; 0 del; 7 mod 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames() Backport-of: a6e34b3d1c6e2e278fe2d26d7e9028898a1c01b6 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/85 From aivanov at openjdk.java.net Tue Mar 16 11:54:28 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 16 Mar 2021 11:54:28 GMT Subject: [jdk16u] Integrated: 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames() Message-ID: Backporting [JDK-8262829](https://bugs.openjdk.java.net/browse/JDK-8262829) to jdk16u. ------------- Commit messages: - 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames() Changes: https://git.openjdk.java.net/jdk16u/pull/85/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=85&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262829 Stats: 20 lines in 1 file changed: 13 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk16u/pull/85.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/85/head:pull/85 PR: https://git.openjdk.java.net/jdk16u/pull/85 From martin.doerr at sap.com Tue Mar 16 10:39:29 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 16 Mar 2021 10:39:29 +0000 Subject: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys In-Reply-To: <31912d26dddcc09b0084e88826b0dabd740e921c.camel@redhat.com> References: <31912d26dddcc09b0084e88826b0dabd740e921c.camel@redhat.com> Message-ID: Hi Severin, sorry, seems like I had pasted the wrong one. Here's the correct one: http://cr.openjdk.java.net/~mdoerr/8243559_root_ca_11u/webrev.00/ Best regards, Martin > -----Original Message----- > From: Severin Gehwolf > Sent: Dienstag, 16. M?rz 2021 11:21 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net; security-dev > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: Re: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys > > Hi Martin, > > On Mon, 2021-03-15 at 17:10 +0000, Doerr, Martin wrote: > > 11u backport: > > http://cr.openjdk.java.net/~mdoerr/8261209_xml_11u/webrev.00/ > > This doesn't look like the right webrev to me. Could you please double- > check? > > Thanks, > Severin From sgehwolf at redhat.com Tue Mar 16 14:11:59 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 16 Mar 2021 15:11:59 +0100 Subject: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys In-Reply-To: References: <31912d26dddcc09b0084e88826b0dabd740e921c.camel@redhat.com> Message-ID: On Tue, 2021-03-16 at 10:39 +0000, Doerr, Martin wrote: > http://cr.openjdk.java.net/~mdoerr/8243559_root_ca_11u/webrev.00/ This looks good to me. Thanks, Severin From martin.doerr at sap.com Tue Mar 16 14:20:50 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 16 Mar 2021 14:20:50 +0000 Subject: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys In-Reply-To: References: <31912d26dddcc09b0084e88826b0dabd740e921c.camel@redhat.com> Message-ID: Hi Severin, thank you for the review! Best regards, Martin > -----Original Message----- > From: Severin Gehwolf > Sent: Dienstag, 16. M?rz 2021 15:12 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net; security-dev > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: Re: [11u] RFR: 8243559: Remove root certificates with 1024-bit keys > > On Tue, 2021-03-16 at 10:39 +0000, Doerr, Martin wrote: > > http://cr.openjdk.java.net/~mdoerr/8243559_root_ca_11u/webrev.00/ > > This looks good to me. > > Thanks, > Severin From rkennke at redhat.com Tue Mar 16 15:18:50 2021 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 16 Mar 2021 16:18:50 +0100 Subject: RFR(11u): 8257621: JFR StringPool misses cached items across consecutive recordings In-Reply-To: References: Message-ID: Any takers? This is becoming relevant for some Graal work... :-) Cheers, Roman > Can I please get a review of the following backport: > > Original issue: > https://bugs.openjdk.java.net/browse/JDK-8257621 > > The original fix: > https://github.com/openjdk/jdk16/commit/7aac4dc1 > > JDK11u webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8257621-jdk11/webrev.00/ > > None of the code that has been changed to use jfrSignal in jdk16 seems > to exist in jdk11, so I left those parts out. I am not totally sure if > JfrStringPool::add() is correct. > > I successfully ran JFR tests, including TestReEnableName.java. > > Thanks, > Roman From djelinski1 at gmail.com Tue Mar 16 16:49:03 2021 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Tue, 16 Mar 2021 17:49:03 +0100 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability In-Reply-To: <739B2CF5-1C67-46A8-8C91-3642CD6C9818@amazon.com> References: <739B2CF5-1C67-46A8-8C91-3642CD6C9818@amazon.com> Message-ID: Thanks Paul for your review and for the hint. Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html compared to original, changes to make/test/BuildMicrobenchmark.gmk were dropped because file does not exist in jdk11 compared to previous webrev, CacheBench was re-added. Testing: Linux x86_64 tier1 and tier2. Thanks, Daniel pon., 15 mar 2021 o 18:09 Hohensee, Paul napisa?(a): > > The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. > > Thanks, > Paul > > ?-----Original Message----- > From: security-dev on behalf of Daniel Jeli?ski > Date: Tuesday, March 9, 2021 at 3:37 PM > To: "jdk-updates-dev at openjdk.java.net" > Cc: "security-dev at openjdk.java.net" > Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > Hi, > Please review this 11u backport; this is the same patch as for head, > except for microbenchmark makefile changes that did not apply because > the file doesn't exist in 11u, and the actual microbenchmark, which > would only add weight for no benefit. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > Testing: Linux x86_64 tier1 and tier2. > > Thanks, > Daniel > From jaroslav.bachorik at datadoghq.com Tue Mar 16 17:16:11 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 16 Mar 2021 18:16:11 +0100 Subject: RFR(11u): 8257621: JFR StringPool misses cached items across consecutive recordings In-Reply-To: References: Message-ID: Hi Roman, AFAICT, this looks good. The changes related to jfrSignal usage seem to be only cosmetic (encapsulating a common logic) and not required for this backport. I checked the diffs and everything else in JDK 11 backport fully corresponds to the original patch. Looks good! -JB- -JB- On Tue, Mar 16, 2021 at 4:19 PM Roman Kennke wrote: > > Any takers? This is becoming relevant for some Graal work... :-) > > Cheers, > Roman > > > Can I please get a review of the following backport: > > > > Original issue: > > https://bugs.openjdk.java.net/browse/JDK-8257621 > > > > The original fix: > > https://github.com/openjdk/jdk16/commit/7aac4dc1 > > > > JDK11u webrev: > > http://cr.openjdk.java.net/~rkennke/JDK-8257621-jdk11/webrev.00/ > > > > None of the code that has been changed to use jfrSignal in jdk16 seems > > to exist in jdk11, so I left those parts out. I am not totally sure if > > JfrStringPool::add() is correct. > > > > I successfully ran JFR tests, including TestReEnableName.java. > > > > Thanks, > > Roman > From hohensee at amazon.com Tue Mar 16 17:59:53 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 16 Mar 2021 17:59:53 +0000 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Message-ID: <00A0F08F-FB4C-49BB-9FCC-B52F10466EA2@amazon.com> Looks good! :) ?-----Original Message----- From: Daniel Jeli?ski Date: Tuesday, March 16, 2021 at 9:49 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Thanks Paul for your review and for the hint. Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html compared to original, changes to make/test/BuildMicrobenchmark.gmk were dropped because file does not exist in jdk11 compared to previous webrev, CacheBench was re-added. Testing: Linux x86_64 tier1 and tier2. Thanks, Daniel pon., 15 mar 2021 o 18:09 Hohensee, Paul napisa?(a): > > The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. > > Thanks, > Paul > > -----Original Message----- > From: security-dev on behalf of Daniel Jeli?ski > Date: Tuesday, March 9, 2021 at 3:37 PM > To: "jdk-updates-dev at openjdk.java.net" > Cc: "security-dev at openjdk.java.net" > Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > Hi, > Please review this 11u backport; this is the same patch as for head, > except for microbenchmark makefile changes that did not apply because > the file doesn't exist in 11u, and the actual microbenchmark, which > would only add weight for no benefit. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > Testing: Linux x86_64 tier1 and tier2. > > Thanks, > Daniel > From hohensee at amazon.com Tue Mar 16 19:46:37 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 16 Mar 2021 19:46:37 +0000 Subject: [11u] RFR: 8217561: X86: Add floating-point Math.min/max intrinsics Message-ID: Please review this follow up to the ARM64 11u backport of JDK-8212043: AArch64: Add floating-point Math.in/max intrinsics. See https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-January/004734.html for details. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8212043 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a 11u webrev: https://cr.openjdk.java.net/~phh/8217561/webrev.11u.00/ The second hunk of x86.ad required a context modification, and the first hunk of library_call.cpp was removed due to a later copyright date update. This is the first of three backports that will be pushed together. The other two apply cleanly after 8217561. JDK-8227222: vmTestbase/jit/FloatingPoint/gen_math/Loops04/Loops04.java hits assert(((!attributes->uses_vl()) || (attributes->get_vector_len() == AVX_512bit) || (!_legacy_mode_vl) || (attributes->is_legacy_mode()))) failed: XMM register should be 0-15 JDK-8220407: compiler/intrinsics/math/TestFpMinMaxIntrinsics.java timedout Thanks, Paul From hohensee at amazon.com Tue Mar 16 20:06:01 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 16 Mar 2021 20:06:01 +0000 Subject: [11u] RFR: 8217561: X86: Add floating-point Math.min/max intrinsics In-Reply-To: References: Message-ID: <29A5F044-8828-4462-8531-12AEE36FDEE8@amazon.com> Forgot to mention testing. Passes tier1 and tier2 on Linux x64. From: "Hohensee, Paul" Date: Tuesday, March 16, 2021 at 12:46 PM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR: 8217561: X86: Add floating-point Math.min/max intrinsics Please review this follow up to the ARM64 11u backport of JDK-8212043: AArch64: Add floating-point Math.in/max intrinsics. See https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-January/004734.html for details. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8212043 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a 11u webrev: https://cr.openjdk.java.net/~phh/8217561/webrev.11u.00/ The second hunk of x86.ad required a context modification, and the first hunk of library_call.cpp was removed due to a later copyright date update. This is the first of three backports that will be pushed together. The other two apply cleanly after 8217561. JDK-8227222: vmTestbase/jit/FloatingPoint/gen_math/Loops04/Loops04.java hits assert(((!attributes->uses_vl()) || (attributes->get_vector_len() == AVX_512bit) || (!_legacy_mode_vl) || (attributes->is_legacy_mode()))) failed: XMM register should be 0-15 JDK-8220407: compiler/intrinsics/math/TestFpMinMaxIntrinsics.java timedout Thanks, Paul From akashche at redhat.com Tue Mar 16 20:56:23 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 16 Mar 2021 20:56:23 +0000 Subject: [11u] RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows Message-ID: Hi, Please review the backport of JDK-8252883 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8252883 Original change: https://github.com/openjdk/jdk/commit/ebdc80ea 11u webrev: https://cr.openjdk.java.net/~akasko/jdk11u/8252883/webrev.00/ Patch applies almost cleanly, the only change is a copyright year, that was changed by JDK-8252265 that is not in 11u. Testing: I was unable to reproduce the issue locally with the test included - tried it with higher number of threads with both 11u and mainline openjd/jdk (with change reverted) with no luck; ran jtreg:java/util/logging and jck:api/java_util/logging . -- -Alex From hohensee at amazon.com Wed Mar 17 02:02:13 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Mar 2021 02:02:13 +0000 Subject: [11u] RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows Message-ID: <0F0D7EAC-B743-4FB9-8A0B-FD9E370A724F@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Alex Kashchenko Date: Tuesday, March 16, 2021 at 1:56 PM To: jdk-updates-dev Subject: [11u] RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows Hi, Please review the backport of JDK-8252883 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8252883 Original change: https://github.com/openjdk/jdk/commit/ebdc80ea 11u webrev: https://cr.openjdk.java.net/~akasko/jdk11u/8252883/webrev.00/ Patch applies almost cleanly, the only change is a copyright year, that was changed by JDK-8252265 that is not in 11u. Testing: I was unable to reproduce the issue locally with the test included - tried it with higher number of threads with both 11u and mainline openjd/jdk (with change reverted) with no luck; ran jtreg:java/util/logging and jck:api/java_util/logging . -- -Alex From djelinski1 at gmail.com Wed Mar 17 06:39:13 2021 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 17 Mar 2021 07:39:13 +0100 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability In-Reply-To: <00A0F08F-FB4C-49BB-9FCC-B52F10466EA2@amazon.com> References: <00A0F08F-FB4C-49BB-9FCC-B52F10466EA2@amazon.com> Message-ID: Thanks again Paul. Could you sponsor the change? As far as I can tell, I'd need to add a fix request now, but I don't have access to issue tracker. Thanks, Daniel wt., 16 mar 2021 o 18:59 Hohensee, Paul napisa?(a): > > Looks good! :) > > ?-----Original Message----- > From: Daniel Jeli?ski > Date: Tuesday, March 16, 2021 at 9:49 AM > To: "Hohensee, Paul" > Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > Thanks Paul for your review and for the hint. > > Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html > > compared to original, changes to make/test/BuildMicrobenchmark.gmk > were dropped because file does not exist in jdk11 > compared to previous webrev, CacheBench was re-added. > > Testing: Linux x86_64 tier1 and tier2. > Thanks, > Daniel > > pon., 15 mar 2021 o 18:09 Hohensee, Paul napisa?(a): > > > > The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: security-dev on behalf of Daniel Jeli?ski > > Date: Tuesday, March 9, 2021 at 3:37 PM > > To: "jdk-updates-dev at openjdk.java.net" > > Cc: "security-dev at openjdk.java.net" > > Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > > > Hi, > > Please review this 11u backport; this is the same patch as for head, > > except for microbenchmark makefile changes that did not apply because > > the file doesn't exist in 11u, and the actual microbenchmark, which > > would only add weight for no benefit. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > > > Testing: Linux x86_64 tier1 and tier2. > > > > Thanks, > > Daniel > > > From mdoerr at openjdk.java.net Wed Mar 17 10:28:04 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 17 Mar 2021 10:28:04 GMT Subject: [jdk16u] RFR: 8263587: C2: JVMS not cloned when needs_clone_jvms() is true Message-ID: 8263587: C2: JVMS not cloned when needs_clone_jvms() is true ------------- Commit messages: - Backport 9c50b8e66a87eb3f27a0cbb573b22a9d9a73a114 Changes: https://git.openjdk.java.net/jdk16u/pull/86/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=86&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263587 Stats: 25 lines in 1 file changed: 1 ins; 16 del; 8 mod Patch: https://git.openjdk.java.net/jdk16u/pull/86.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/86/head:pull/86 PR: https://git.openjdk.java.net/jdk16u/pull/86 From snazarki at openjdk.java.net Wed Mar 17 14:00:07 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 17 Mar 2021 14:00:07 GMT Subject: [jdk13u-dev] RFR: 8255625: AArch64: Implement Base64.encodeBlock accelerator/intrinsic Message-ID: I'd like to backport JDK-8257414 to jdk13u for performance improvement. The patch is not applied cleanly due to miss of JDK-8224974. The following block need to be applied manually if (UseBASE64Intrinsics) { StubRoutines::_base64_encodeBlock = generate_base64_encodeBlock(); } Passed tier1 and verify performance change with new test. ------------- Commit messages: - Backport 8638cd9acf5c33612eaf82ae3219f68456ea9621 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/149/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=149&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255625 Stats: 226 lines in 3 files changed: 226 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/149.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/149/head:pull/149 PR: https://git.openjdk.java.net/jdk13u-dev/pull/149 From martin.doerr at sap.com Wed Mar 17 14:02:29 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 17 Mar 2021 14:02:29 +0000 Subject: [11u] RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset Message-ID: Hi, JDK-8241372 is backported to 11.0.12-oracle. I'd like to backport it for parity. It applies cleanly, but I had to remove the code which sets "serverAddress" which was introduced by https://bugs.openjdk.java.net/browse/JDK-8230435 and is not in 11u (see below). Bug: https://bugs.openjdk.java.net/browse/JDK-8241372 Original change: https://git.openjdk.java.net/jdk/commit/0a50688d 11u backport: http://cr.openjdk.java.net/~mdoerr/8241372_SSL_testfix_11u/webrev.00/ Please review. Best regards, Martin diff -r fbb7b445880e test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java --- a/test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java Tue Feb 16 18:54:39 2021 +0000 +++ b/test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java Wed Mar 17 14:37:24 2021 +0100 @@ -65,7 +65,6 @@ this.clientProtocols = clientProtocols; this.exceptionExpected = exceptionExpected; this.selectedProtocol = selectedProtocol; - this.serverAddress = InetAddress.getLoopbackAddress(); } @Override diff -r fbb7b445880e test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java --- a/test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java Tue Feb 16 18:54:39 2021 +0000 +++ b/test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java Wed Mar 17 14:37:24 2021 +0100 @@ -52,10 +52,6 @@ {{"TLSv1.2"}, {"TLSv1.2"}} }; - public SupportedGroups() { - this.serverAddress = InetAddress.getLoopbackAddress(); - } - // Servers are configured before clients, increment test case after. @Override protected void configureClientSocket(SSLSocket socket) { From snazarki at openjdk.java.net Wed Mar 17 15:06:00 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 17 Mar 2021 15:06:00 GMT Subject: [jdk13u-dev] Integrated: 8255625: AArch64: Implement Base64.encodeBlock accelerator/intrinsic In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 13:55:25 GMT, Sergey Nazarkin wrote: > I'd like to backport JDK-8257414 to jdk13u for performance improvement. The patch is not applied cleanly due to miss of JDK-8224974. The following block need to be applied manually > if (UseBASE64Intrinsics) { > StubRoutines::_base64_encodeBlock = generate_base64_encodeBlock(); > } > > Passed tier1 and verify performance change with new test. This pull request has now been integrated. Changeset: ebea17d0 Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/ebea17d0 Stats: 226 lines in 3 files changed: 226 ins; 0 del; 0 mod 8255625: AArch64: Implement Base64.encodeBlock accelerator/intrinsic Backport-of: 8638cd9acf5c33612eaf82ae3219f68456ea9621 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/149 From snazarki at openjdk.java.net Wed Mar 17 15:39:59 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Wed, 17 Mar 2021 15:39:59 GMT Subject: [jdk13u-dev] RFR: 8263425: AArch64: two potential bugs in C1 LIRGenerator::generate_address() Message-ID: Hi! I'd like to backport JDK-8263425 to 13u to fix obvious bugs. The patch applies cleanly. Pass basic tests ------------- Commit messages: - Backport f7e0a09802f74e6432d170e6a00dc75cd053047b Changes: https://git.openjdk.java.net/jdk13u-dev/pull/150/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=150&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263425 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/150.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/150/head:pull/150 PR: https://git.openjdk.java.net/jdk13u-dev/pull/150 From volker.simonis at gmail.com Wed Mar 17 17:12:10 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 17 Mar 2021 18:12:10 +0100 Subject: [11u] RFR: 8217561: X86: Add floating-point Math.min/max intrinsics In-Reply-To: <29A5F044-8828-4462-8531-12AEE36FDEE8@amazon.com> References: <29A5F044-8828-4462-8531-12AEE36FDEE8@amazon.com> Message-ID: On Tue, Mar 16, 2021 at 9:06 PM Hohensee, Paul wrote: > > Forgot to mention testing. Passes tier1 and tier2 on Linux x64. > > From: "Hohensee, Paul" > Date: Tuesday, March 16, 2021 at 12:46 PM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [11u] RFR: 8217561: X86: Add floating-point Math.min/max intrinsics > > Please review this follow up to the ARM64 11u backport of JDK-8212043: AArch64: Add floating-point Math.in/max intrinsics. See https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-January/004734.html for details. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8212043 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a > 11u webrev: https://cr.openjdk.java.net/~phh/8217561/webrev.11u.00/ > > The second hunk of x86.ad required a context modification, and the first hunk of library_call.cpp was removed due to a later copyright date update. > Hi Paul, thanks for doing this. Downport looks good to me. Best regards, Volker > This is the first of three backports that will be pushed together. The other two apply cleanly after 8217561. > > JDK-8227222: vmTestbase/jit/FloatingPoint/gen_math/Loops04/Loops04.java hits assert(((!attributes->uses_vl()) || (attributes->get_vector_len() == AVX_512bit) || (!_legacy_mode_vl) || (attributes->is_legacy_mode()))) failed: XMM register should be 0-15 > JDK-8220407: compiler/intrinsics/math/TestFpMinMaxIntrinsics.java timedout > > Thanks, > Paul > > From hohensee at amazon.com Wed Mar 17 17:30:34 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Mar 2021 17:30:34 +0000 Subject: [11u] RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset Message-ID: <08D34C16-BB25-469F-AC15-BEB8969DDE5E@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Doerr, Martin" Date: Wednesday, March 17, 2021 at 7:04 AM To: "jdk-updates-dev at openjdk.java.net" Cc: "Langer, Christoph" , "Lindenmaier, Goetz" Subject: [11u] RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset Hi, JDK-8241372 is backported to 11.0.12-oracle. I'd like to backport it for parity. It applies cleanly, but I had to remove the code which sets "serverAddress" which was introduced by https://bugs.openjdk.java.net/browse/JDK-8230435 and is not in 11u (see below). Bug: https://bugs.openjdk.java.net/browse/JDK-8241372 Original change: https://git.openjdk.java.net/jdk/commit/0a50688d 11u backport: http://cr.openjdk.java.net/~mdoerr/8241372_SSL_testfix_11u/webrev.00/ Please review. Best regards, Martin diff -r fbb7b445880e test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java --- a/test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java Tue Feb 16 18:54:39 2021 +0000 +++ b/test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java Wed Mar 17 14:37:24 2021 +0100 @@ -65,7 +65,6 @@ this.clientProtocols = clientProtocols; this.exceptionExpected = exceptionExpected; this.selectedProtocol = selectedProtocol; - this.serverAddress = InetAddress.getLoopbackAddress(); } @Override diff -r fbb7b445880e test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java --- a/test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java Tue Feb 16 18:54:39 2021 +0000 +++ b/test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java Wed Mar 17 14:37:24 2021 +0100 @@ -52,10 +52,6 @@ {{"TLSv1.2"}, {"TLSv1.2"}} }; - public SupportedGroups() { - this.serverAddress = InetAddress.getLoopbackAddress(); - } - // Servers are configured before clients, increment test case after. @Override protected void configureClientSocket(SSLSocket socket) { From martin.doerr at sap.com Wed Mar 17 17:47:07 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 17 Mar 2021 17:47:07 +0000 Subject: [11u] RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset In-Reply-To: <08D34C16-BB25-469F-AC15-BEB8969DDE5E@amazon.com> References: <08D34C16-BB25-469F-AC15-BEB8969DDE5E@amazon.com> Message-ID: Hi Paul, thanks for the review! Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Mittwoch, 17. M?rz 2021 18:31 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net > Cc: Langer, Christoph ; Lindenmaier, Goetz > > Subject: Re: [11u] RFR: 8241372: Several test failures due to > javax.net.ssl.SSLException: Connection reset > > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of "Doerr, Martin" > Date: Wednesday, March 17, 2021 at 7:04 AM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Cc: "Langer, Christoph" , "Lindenmaier, Goetz" > > Subject: [11u] RFR: 8241372: Several test failures due to > javax.net.ssl.SSLException: Connection reset > > Hi, > > JDK-8241372 is backported to 11.0.12-oracle. I'd like to backport it for parity. > It applies cleanly, but I had to remove the code which sets "serverAddress" > which was introduced by https://bugs.openjdk.java.net/browse/JDK- > 8230435 and is not in 11u (see below). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8241372 > > Original change: > https://git.openjdk.java.net/jdk/commit/0a50688d > > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8241372_SSL_testfix_11u/webrev.00/ > > Please review. > > Best regards, > Martin > > > diff -r fbb7b445880e > test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java > --- a/test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java Tue > Feb 16 18:54:39 2021 +0000 > +++ b/test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java Wed > Mar 17 14:37:24 2021 +0100 > @@ -65,7 +65,6 @@ > this.clientProtocols = clientProtocols; > this.exceptionExpected = exceptionExpected; > this.selectedProtocol = selectedProtocol; > - this.serverAddress = InetAddress.getLoopbackAddress(); > } > > @Override > diff -r fbb7b445880e > test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java > --- a/test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java Tue > Feb 16 18:54:39 2021 +0000 > +++ b/test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java Wed > Mar 17 14:37:24 2021 +0100 > @@ -52,10 +52,6 @@ > {{"TLSv1.2"}, {"TLSv1.2"}} > }; > > - public SupportedGroups() { > - this.serverAddress = InetAddress.getLoopbackAddress(); > - } > - > // Servers are configured before clients, increment test case after. > @Override > protected void configureClientSocket(SSLSocket socket) { > From hohensee at amazon.com Wed Mar 17 18:37:06 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Mar 2021 18:37:06 +0000 Subject: [11u] RFR: 8217561: X86: Add floating-point Math.min/max intrinsics Message-ID: <3B5AA392-3BC4-42BA-891F-4DE9030CD327@amazon.com> Thanks, Volker! ?-----Original Message----- From: Volker Simonis Date: Wednesday, March 17, 2021 at 10:20 AM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR: 8217561: X86: Add floating-point Math.min/max intrinsics On Tue, Mar 16, 2021 at 9:06 PM Hohensee, Paul wrote: > > Forgot to mention testing. Passes tier1 and tier2 on Linux x64. > > From: "Hohensee, Paul" > Date: Tuesday, March 16, 2021 at 12:46 PM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [11u] RFR: 8217561: X86: Add floating-point Math.min/max intrinsics > > Please review this follow up to the ARM64 11u backport of JDK-8212043: AArch64: Add floating-point Math.in/max intrinsics. See https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-January/004734.html for details. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8212043 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a > 11u webrev: https://cr.openjdk.java.net/~phh/8217561/webrev.11u.00/ > > The second hunk of x86.ad required a context modification, and the first hunk of library_call.cpp was removed due to a later copyright date update. > Hi Paul, thanks for doing this. Downport looks good to me. Best regards, Volker > This is the first of three backports that will be pushed together. The other two apply cleanly after 8217561. > > JDK-8227222: vmTestbase/jit/FloatingPoint/gen_math/Loops04/Loops04.java hits assert(((!attributes->uses_vl()) || (attributes->get_vector_len() == AVX_512bit) || (!_legacy_mode_vl) || (attributes->is_legacy_mode()))) failed: XMM register should be 0-15 > JDK-8220407: compiler/intrinsics/math/TestFpMinMaxIntrinsics.java timedout > > Thanks, > Paul > > From hohensee at amazon.com Wed Mar 17 20:00:37 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Mar 2021 20:00:37 +0000 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Message-ID: Np, tagged. ?-----Original Message----- From: Daniel Jeli?ski Date: Tuesday, March 16, 2021 at 11:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Thanks again Paul. Could you sponsor the change? As far as I can tell, I'd need to add a fix request now, but I don't have access to issue tracker. Thanks, Daniel wt., 16 mar 2021 o 18:59 Hohensee, Paul napisa?(a): > > Looks good! :) > > -----Original Message----- > From: Daniel Jeli?ski > Date: Tuesday, March 16, 2021 at 9:49 AM > To: "Hohensee, Paul" > Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > Thanks Paul for your review and for the hint. > > Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html > > compared to original, changes to make/test/BuildMicrobenchmark.gmk > were dropped because file does not exist in jdk11 > compared to previous webrev, CacheBench was re-added. > > Testing: Linux x86_64 tier1 and tier2. > Thanks, > Daniel > > pon., 15 mar 2021 o 18:09 Hohensee, Paul napisa?(a): > > > > The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: security-dev on behalf of Daniel Jeli?ski > > Date: Tuesday, March 9, 2021 at 3:37 PM > > To: "jdk-updates-dev at openjdk.java.net" > > Cc: "security-dev at openjdk.java.net" > > Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > > > Hi, > > Please review this 11u backport; this is the same patch as for head, > > except for microbenchmark makefile changes that did not apply because > > the file doesn't exist in 11u, and the actual microbenchmark, which > > would only add weight for no benefit. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > > > Testing: Linux x86_64 tier1 and tier2. > > > > Thanks, > > Daniel > > > From dmitry.chuyko at bell-sw.com Wed Mar 17 20:38:37 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 17 Mar 2021 23:38:37 +0300 Subject: [11u] RFR 8222412: AARCH64: multiple instructions encoding issues In-Reply-To: <816421DD-1164-49D7-BC84-5DB40584EA6F@amazon.com> References: <816421DD-1164-49D7-BC84-5DB40584EA6F@amazon.com> Message-ID: <65351ce9-99a1-7bd2-6fe4-6085a7710794@bell-sw.com> Hi Paul, Thanks for taking a look. I don't get what parts exactly are missing. You mentioned chunks from the generated section of assembler_aarch64.cpp. I compared generated sections from multiple sources: A. Current jdk11u-dev B. Patched jdk11u-dev C. JDK 15 D. Script output My observations: 1. B == C. After the patch the code is like 15. 2. B ~= D. The section in patched .cpp corresponds to the script output. Unfortunately in previous work with the script we didn't make the random seed fixed by default. So generated section in the file contains same instruction sequence up to register renaming and other randomized stuff. 3. A ~< B. The patch makes additions in "// ThreeRegOp" and adds "// LdStSIMDOp", "// SpecialCases" and "// LSEOp"-s. Other parts are equivalent up to random stuff. -Dmitry On 3/13/21 2:14 AM, Hohensee, Paul wrote: > Looks like you're missing part of the assembler_aarch64.cpp patch in the sections "// AbsOp", "// CondBranchOp", "// Op", "// LoadStoreOp" with "__ prfm(back)", and "// FloatImmediateOp". > > Other than those hunks, looks good. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on behalf of Dmitry Chuyko > Date: Friday, March 12, 2021 at 12:58 PM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [11u] RFR 8222412: AARCH64: multiple instructions encoding issues > > Hello, > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8222412 > > Original patch applies almost cleanly except 1 change in > assembler_aarch64.hpp. In jdk/jdk the fix is based on JDK-8214961 [1]. > In jdk11u first half of JDK-8214961 is already backported in JDK-8216350 > [2]. The second half of JDK-8214961 is overridden by that single line > change which is manually recreated to change the current code. I.e. > > - rf(Rs, 16), f(op1, 15), f(op2, 14, 12), f(0, 11, 10), rf(Rn, 5), > zrf(Rt, 0); > instead of > - rf(Rs, 16), f(op1, 15), f(op2, 14, 12), f(0, 11, 10), srf(Rn, 5), > zrf(Rt, 0); > > No need to backport JDK-8214961 as it is completely overridden by > JDK-8222412 + JDK-8216350 backports. > > 11u webrev: http://cr.openjdk.java.net/~dchuyko/8222412/webrev.11u.00/ > > Testing: aarch64 build, tier1, tier2; asm_check in fastdebug build. > > [1] https://bugs.openjdk.java.net/browse/JDK-8214961 > [2] https://bugs.openjdk.java.net/browse/JDK-8216350 > > -- > Thanks, > -Dmitry > > From dmitry.chuyko at bell-sw.com Wed Mar 17 20:45:09 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 17 Mar 2021 23:45:09 +0300 Subject: [11u] RFR (S) 8223444: Improve CodeHeap Free Space Management In-Reply-To: <5ECE130B-245D-419D-AF79-BC31958CDF3E@sap.com> References: <14b2a6b4-615c-efb9-ba57-4a05ac3a02b3@bell-sw.com> <5ECE130B-245D-419D-AF79-BC31958CDF3E@sap.com> Message-ID: <363bbecc-6ec4-7a58-bc54-305f3854e071@bell-sw.com> Hi Lutz, Thank you and Paul for the review. The backport will be pushed by one of my jdk-updates committer/reviewer colleagues right after the 16 release rush is over. -Dmitry On 3/15/21 12:55 PM, Schmidt, Lutz wrote: > Hi Dmitry, > > the changes look good to me. Thank you for bringing this one and the follow-up fix to jdk11. > > Please note that I'm not a reviewer for the jdk-updates project. But as author of the original change I dare to approve it. > > Regards, > Lutz > > -----Original Message----- > From: jdk-updates-dev On Behalf Of Dmitry Chuyko > Sent: Donnerstag, 11. M?rz 2021 16:22 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR (S) 8223444: Improve CodeHeap Free Space Management > > Hello, > > Original RFE: https://bugs.openjdk.java.net/browse/JDK-8223444 > Original post-fix: https://bugs.openjdk.java.net/browse/JDK-8231460 > > Original patch applies almost cleanly except 4 changes in > CodeHeap::add_to_freelist because JDK-8238356 is already backported, > they were applied manually. > Original post-fix (for performance issue) applies cleanly. > > 11u webrev: http://cr.openjdk.java.net/~dchuyko/8223444/webrev.11u.00/ > > Testing: tier1, tier2. > > -- > Thanks, > -Dmitry > > From snazarki at openjdk.java.net Thu Mar 18 08:41:52 2021 From: snazarki at openjdk.java.net (Sergey Nazarkin) Date: Thu, 18 Mar 2021 08:41:52 GMT Subject: [jdk13u-dev] Integrated: 8263425: AArch64: two potential bugs in C1 LIRGenerator::generate_address() In-Reply-To: References: Message-ID: <190_spPosOjdCyJ7RmJ3IdJqvSsSOXF3o2utWrf5sdo=.69a6568d-39f9-4d5f-8739-ce5a00ffd2d8@github.com> On Wed, 17 Mar 2021 15:33:49 GMT, Sergey Nazarkin wrote: > Hi! > I'd like to backport JDK-8263425 to 13u to fix obvious bugs. The patch applies cleanly. Pass basic tests This pull request has now been integrated. Changeset: a117b8b5 Author: Sergey Nazarkin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/a117b8b5 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8263425: AArch64: two potential bugs in C1 LIRGenerator::generate_address() Backport-of: f7e0a09802f74e6432d170e6a00dc75cd053047b ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/150 From evergizova at openjdk.java.net Thu Mar 18 09:18:14 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 18 Mar 2021 09:18:14 GMT Subject: [jdk13u-dev] RFR: 8261022: Fix incorrect result of Math.abs() with char type Message-ID: <4NYNcVYvCdacHb3i8sSFCWMQIeNjadzwUzSIH4M-22o=.9bffabbe-fc0f-4a91-9809-19064538f466@github.com> I'd like to backport JDK-8261022 to 13u for parity with 11u. The patch applies cleanly, but requires some modification due to absence of VectorNode::is_shift_opcode in 13u (JDK-8257625 is not in 13u), replaced by similar VectorNode::is_shift. Tested with tier1; new test fails without the patch, passes with it. ------------- Commit messages: - Backport 7a2db858e0e81f2ba17c3554386bb6a833318b3d Changes: https://git.openjdk.java.net/jdk13u-dev/pull/152/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=152&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261022 Stats: 77 lines in 2 files changed: 66 ins; 1 del; 10 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/152.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/152/head:pull/152 PR: https://git.openjdk.java.net/jdk13u-dev/pull/152 From yan at openjdk.java.net Thu Mar 18 09:33:58 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 18 Mar 2021 09:33:58 GMT Subject: [jdk13u-dev] RFR: 8261022: Fix incorrect result of Math.abs() with char type In-Reply-To: <4NYNcVYvCdacHb3i8sSFCWMQIeNjadzwUzSIH4M-22o=.9bffabbe-fc0f-4a91-9809-19064538f466@github.com> References: <4NYNcVYvCdacHb3i8sSFCWMQIeNjadzwUzSIH4M-22o=.9bffabbe-fc0f-4a91-9809-19064538f466@github.com> Message-ID: On Thu, 18 Mar 2021 09:11:28 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8261022 to 13u for parity with 11u. > The patch applies cleanly, but requires some modification due to absence of VectorNode::is_shift_opcode in 13u (JDK-8257625 is not in 13u), replaced by similar VectorNode::is_shift. > Tested with tier1; new test fails without the patch, passes with it. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/152 From matthias.baesken at sap.com Thu Mar 18 10:06:27 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 18 Mar 2021 10:06:27 +0000 Subject: RFR [jdk11] 8259983: do not use uninitialized expand_ms value in G1CollectedHeap::expand_heap_after_young_collection Message-ID: Hello, please review the jdk11 backport of 8259983 . The backport fits in nicely, but does not apply cleanly because of changes in the stride ; that's why the separate RFR. Bug / webrev : https://bugs.openjdk.java.net/browse/JDK-8259983 http://cr.openjdk.java.net/~mbaesken/webrevs/8259983_jdk11/ Jdk/jdk : https://github.com/openjdk/jdk/commit/9f21bb6a Thanks, Matthias From evergizova at openjdk.java.net Thu Mar 18 11:16:42 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 18 Mar 2021 11:16:42 GMT Subject: [jdk13u-dev] Integrated: 8261022: Fix incorrect result of Math.abs() with char type In-Reply-To: <4NYNcVYvCdacHb3i8sSFCWMQIeNjadzwUzSIH4M-22o=.9bffabbe-fc0f-4a91-9809-19064538f466@github.com> References: <4NYNcVYvCdacHb3i8sSFCWMQIeNjadzwUzSIH4M-22o=.9bffabbe-fc0f-4a91-9809-19064538f466@github.com> Message-ID: <-6KwsLWTLsEo3kqXZyKEAysWMzEXC9WatfVam6pTSBU=.df9cfd22-0812-451c-b9db-1d772df7c772@github.com> On Thu, 18 Mar 2021 09:11:28 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8261022 to 13u for parity with 11u. > The patch applies cleanly, but requires some modification due to absence of VectorNode::is_shift_opcode in 13u (JDK-8257625 is not in 13u), replaced by similar VectorNode::is_shift. > Tested with tier1; new test fails without the patch, passes with it. This pull request has now been integrated. Changeset: ff29b0b8 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk13u-dev/commit/ff29b0b8 Stats: 77 lines in 2 files changed: 66 ins; 1 del; 10 mod 8261022: Fix incorrect result of Math.abs() with char type Reviewed-by: yan Backport-of: 7a2db858e0e81f2ba17c3554386bb6a833318b3d ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/152 From martin.doerr at sap.com Thu Mar 18 15:44:54 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 18 Mar 2021 15:44:54 +0000 Subject: [11u] RFR: 8257574: C2: "failed: parsing found no loops but there are some" assert failure Message-ID: Hi, JDK-8257574 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly because of a naming difference in the code which gets replaced: The patch wants to remove "is_innermost()", but it's called "is_inner()" in 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8257574 Original change: https://git.openjdk.java.net/jdk/commit/86b65756 11u backport: http://cr.openjdk.java.net/~mdoerr/8257574_C2_11u/webrev.00/ Please review. Best regards, Martin From hohensee at amazon.com Thu Mar 18 15:50:15 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 18 Mar 2021 15:50:15 +0000 Subject: [11u] RFR 8222412: AARCH64: multiple instructions encoding issues Message-ID: <6C507377-DE84-4F51-83E9-5FAA4A517A1B@amazon.com> You're right, it does seem to be somewhat random. Reviewed. Thanks, Paul ?-----Original Message----- From: Dmitry Chuyko Date: Wednesday, March 17, 2021 at 1:39 PM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR 8222412: AARCH64: multiple instructions encoding issues Hi Paul, Thanks for taking a look. I don't get what parts exactly are missing. You mentioned chunks from the generated section of assembler_aarch64.cpp. I compared generated sections from multiple sources: A. Current jdk11u-dev B. Patched jdk11u-dev C. JDK 15 D. Script output My observations: 1. B == C. After the patch the code is like 15. 2. B ~= D. The section in patched .cpp corresponds to the script output. Unfortunately in previous work with the script we didn't make the random seed fixed by default. So generated section in the file contains same instruction sequence up to register renaming and other randomized stuff. 3. A ~< B. The patch makes additions in "// ThreeRegOp" and adds "// LdStSIMDOp", "// SpecialCases" and "// LSEOp"-s. Other parts are equivalent up to random stuff. -Dmitry On 3/13/21 2:14 AM, Hohensee, Paul wrote: > Looks like you're missing part of the assembler_aarch64.cpp patch in the sections "// AbsOp", "// CondBranchOp", "// Op", "// LoadStoreOp" with "__ prfm(back)", and "// FloatImmediateOp". > > Other than those hunks, looks good. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on behalf of Dmitry Chuyko > Date: Friday, March 12, 2021 at 12:58 PM > To: "jdk-updates-dev at openjdk.java.net" > Subject: [11u] RFR 8222412: AARCH64: multiple instructions encoding issues > > Hello, > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8222412 > > Original patch applies almost cleanly except 1 change in > assembler_aarch64.hpp. In jdk/jdk the fix is based on JDK-8214961 [1]. > In jdk11u first half of JDK-8214961 is already backported in JDK-8216350 > [2]. The second half of JDK-8214961 is overridden by that single line > change which is manually recreated to change the current code. I.e. > > - rf(Rs, 16), f(op1, 15), f(op2, 14, 12), f(0, 11, 10), rf(Rn, 5), > zrf(Rt, 0); > instead of > - rf(Rs, 16), f(op1, 15), f(op2, 14, 12), f(0, 11, 10), srf(Rn, 5), > zrf(Rt, 0); > > No need to backport JDK-8214961 as it is completely overridden by > JDK-8222412 + JDK-8216350 backports. > > 11u webrev: http://cr.openjdk.java.net/~dchuyko/8222412/webrev.11u.00/ > > Testing: aarch64 build, tier1, tier2; asm_check in fastdebug build. > > [1] https://bugs.openjdk.java.net/browse/JDK-8214961 > [2] https://bugs.openjdk.java.net/browse/JDK-8216350 > > -- > Thanks, > -Dmitry > > From aph at redhat.com Thu Mar 18 16:10:26 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Mar 2021 16:10:26 +0000 Subject: [11u] AArch64: Support for LSE atomics C++ HotSpot code Message-ID: This is the first of two patches which allow C++ code in HotSpot to use Arm's Large System Extensions. This is necessary because some recent AArch64 hardware performs very badly, particularly under heavy contention, with the older way of doing atomic updates, using LDXR and STXR. Java code has been using these LSE instructions, where available, for several years. This first patch is mostly just scaffolding: the actual performance improvement is https://bugs.openjdk.java.net/browse/JDK-8261649. The original patch did not apply because the argument order of class Atomic functions changed with 8234740. Otherwise, it was fairly straightforward. http://cr.openjdk.java.net/~aph/8261027-jdk11u/ -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Mar 18 16:20:05 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Mar 2021 16:20:05 +0000 Subject: [11u] AArch64: Support for LSE atomics C++ HotSpot code In-Reply-To: References: Message-ID: This is the second part of a pair with JDK-8261027. It generates near-optimal LSE instruction sequences for C++ atomic functions. The patch from JDK head applied with no changes, but there's a webrev at http://cr.openjdk.java.net/~aph/8261649-jdk11u/. We need this in 11u for performance reasons on new AArch64 hardware, particularly chips like the Apple M1 and Arm's Neoverse N1. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Mar 18 16:20:59 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Mar 2021 16:20:59 +0000 Subject: 8261649: AArch64: Optimize LSE atomics in C++ code In-Reply-To: References: Message-ID: <0925a24a-0db5-bda6-afe5-9d548ee72a01@redhat.com> [Fix: subject line] This is the second part of a pair with JDK-8261027. It generates near-optimal LSE instruction sequences for C++ atomic functions. The patch from JDK head applied with no changes, but there's a webrev at http://cr.openjdk.java.net/~aph/8261649-jdk11u/. We need this in 11u for performance reasons on new AArch64 hardware, particularly chips like the Apple M1 and Arm's Neoverse N1. -- 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 Thu Mar 18 16:37:48 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 18 Mar 2021 16:37:48 GMT Subject: [jdk13u-dev] RFR: 8237977: Further update javax/net/ssl/compatibility/Compatibility.java Message-ID: I'd like to backport JDK-8237977 to jdk13u for parity with jdk11u. The original patch applied cleanly. All regular tests passed. ------------- Commit messages: - Backport 60fae7797438ea0e7d6e4354af0f8406fab2b16c Changes: https://git.openjdk.java.net/jdk13u-dev/pull/153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=153&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8237977 Stats: 365 lines in 9 files changed: 184 ins; 117 del; 64 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/153.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/153/head:pull/153 PR: https://git.openjdk.java.net/jdk13u-dev/pull/153 From hohensee at amazon.com Thu Mar 18 17:00:44 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 18 Mar 2021 17:00:44 +0000 Subject: [11u] AArch64: Support for LSE atomics C++ HotSpot code Message-ID: <0246E7C6-0900-49EE-8C0A-E9F89CB732FA@amazon.com> Looks fine, except that I see you've included the patch for https://bugs.openjdk.java.net/browse/JDK-8261660 as part of the webrev for 8261027. If at all possible, please backport 8261660 separately and push the two patches (for 8261027 and 8261660) together. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Andrew Haley Date: Thursday, March 18, 2021 at 9:11 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] AArch64: Support for LSE atomics C++ HotSpot code This is the first of two patches which allow C++ code in HotSpot to use Arm's Large System Extensions. This is necessary because some recent AArch64 hardware performs very badly, particularly under heavy contention, with the older way of doing atomic updates, using LDXR and STXR. Java code has been using these LSE instructions, where available, for several years. This first patch is mostly just scaffolding: the actual performance improvement is https://bugs.openjdk.java.net/browse/JDK-8261649. The original patch did not apply because the argument order of class Atomic functions changed with 8234740. Otherwise, it was fairly straightforward. http://cr.openjdk.java.net/~aph/8261027-jdk11u/ -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Mar 18 17:35:24 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Mar 2021 17:35:24 +0000 Subject: [11u] AArch64: Support for LSE atomics C++ HotSpot code In-Reply-To: <0246E7C6-0900-49EE-8C0A-E9F89CB732FA@amazon.com> References: <0246E7C6-0900-49EE-8C0A-E9F89CB732FA@amazon.com> Message-ID: On 3/18/21 5:00 PM, Hohensee, Paul wrote: > Looks fine, except that I see you've included the patch for https://bugs.openjdk.java.net/browse/JDK-8261660 as part of the webrev for 8261027. If at all possible, please backport 8261660 separately and push the two patches (for 8261027 and 8261660) together. That sounds like an abysmal waste of time. Of course it's possible, but 8261660 was reverted in its entirety a few days later. We don't usually back-port patches and their reversions, and I can see no point doing so in this case. -- 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 Thu Mar 18 18:56:42 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 18 Mar 2021 18:56:42 +0000 Subject: [11u] AArch64: Support for LSE atomics C++ HotSpot code Message-ID: <71AD5B10-350A-4371-B3CB-7EDE4833FD0C@amazon.com> Up to you. :) ?-----Original Message----- From: Andrew Haley Date: Thursday, March 18, 2021 at 10:35 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] AArch64: Support for LSE atomics C++ HotSpot code On 3/18/21 5:00 PM, Hohensee, Paul wrote: > Looks fine, except that I see you've included the patch for https://bugs.openjdk.java.net/browse/JDK-8261660 as part of the webrev for 8261027. If at all possible, please backport 8261660 separately and push the two patches (for 8261027 and 8261660) together. That sounds like an abysmal waste of time. Of course it's possible, but 8261660 was reverted in its entirety a few days later. We don't usually back-port patches and their reversions, and I can see no point doing so in this case. -- 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 Thu Mar 18 19:02:24 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 18 Mar 2021 19:02:24 +0000 Subject: 8261649: AArch64: Optimize LSE atomics in C++ code Message-ID: <474F75FB-6BA5-45D2-94DA-4E7484A43F6C@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Andrew Haley Date: Thursday, March 18, 2021 at 9:22 AM To: "jdk-updates-dev at openjdk.java.net" Subject: 8261649: AArch64: Optimize LSE atomics in C++ code [Fix: subject line] This is the second part of a pair with JDK-8261027. It generates near-optimal LSE instruction sequences for C++ atomic functions. The patch from JDK head applied with no changes, but there's a webrev at http://cr.openjdk.java.net/~aph/8261649-jdk11u/. We need this in 11u for performance reasons on new AArch64 hardware, particularly chips like the Apple M1 and Arm's Neoverse N1. -- 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 Thu Mar 18 20:02:54 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 18 Mar 2021 20:02:54 +0000 Subject: [11u] RFR: 8257574: C2: "failed: parsing found no loops but there are some" assert failure Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Doerr, Martin" Date: Thursday, March 18, 2021 at 8:45 AM To: "jdk-updates-dev at openjdk.java.net" Cc: "Lindenmaier, Goetz" , "Langer, Christoph" Subject: [11u] RFR: 8257574: C2: "failed: parsing found no loops but there are some" assert failure Hi, JDK-8257574 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly because of a naming difference in the code which gets replaced: The patch wants to remove "is_innermost()", but it's called "is_inner()" in 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8257574 Original change: https://git.openjdk.java.net/jdk/commit/86b65756 11u backport: http://cr.openjdk.java.net/~mdoerr/8257574_C2_11u/webrev.00/ Please review. Best regards, Martin From aph at redhat.com Fri Mar 19 10:09:29 2021 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Mar 2021 10:09:29 +0000 Subject: [11u] AArch64: Support for LSE atomics C++ HotSpot code In-Reply-To: <71AD5B10-350A-4371-B3CB-7EDE4833FD0C@amazon.com> References: <71AD5B10-350A-4371-B3CB-7EDE4833FD0C@amazon.com> Message-ID: <11e8fd56-35af-2d6a-5718-a6a5b37fb1df@redhat.com> On 3/18/21 6:56 PM, Hohensee, Paul wrote: > Up to you. :) Thanks, I won't! Doing so would have required you to *approve a patch you knew to be broken*, which I don't think I've ever done. And srsly, I don't want to start now. :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Fri Mar 19 10:46:12 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 19 Mar 2021 10:46:12 +0000 Subject: [11u] RFR: 8257574: C2: "failed: parsing found no loops but there are some" assert failure In-Reply-To: References: Message-ID: Hi Paul, thanks for the review! Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 18. M?rz 2021 21:03 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: Re: [11u] RFR: 8257574: C2: "failed: parsing found no loops but there > are some" assert failure > > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of "Doerr, Martin" > Date: Thursday, March 18, 2021 at 8:45 AM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Cc: "Lindenmaier, Goetz" , "Langer, > Christoph" > Subject: [11u] RFR: 8257574: C2: "failed: parsing found no loops but there are > some" assert failure > > Hi, > > JDK-8257574 is backported to 11.0.12-oracle. I'd like to backport it for parity. > It doesn't apply cleanly because of a naming difference in the code which > gets replaced: > The patch wants to remove "is_innermost()", but it's called "is_inner()" in > 11u. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8257574 > > Original change: > https://git.openjdk.java.net/jdk/commit/86b65756 > > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8257574_C2_11u/webrev.00/ > > Please review. > > Best regards, > Martin > From evergizova at openjdk.java.net Fri Mar 19 11:54:59 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 19 Mar 2021 11:54:59 GMT Subject: [jdk13u-dev] RFR: 8253409: Double-rounding possibility in float fma Message-ID: I'd like to backport JDK-8253409 to 13u for parity with 11u. The patch applies cleanly. Tested with tier1; new test fails without the patch, passes with it. ------------- Commit messages: - Backport e5304b3a994b1e291e4ac5258f473dd7874f163f Changes: https://git.openjdk.java.net/jdk13u-dev/pull/154/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=154&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253409 Stats: 32 lines in 2 files changed: 4 ins; 11 del; 17 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/154.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/154/head:pull/154 PR: https://git.openjdk.java.net/jdk13u-dev/pull/154 From evergizova at openjdk.java.net Fri Mar 19 11:55:12 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 19 Mar 2021 11:55:12 GMT Subject: [jdk13u-dev] RFR: 8244573: java.lang.ArrayIndexOutOfBoundsException thrown for malformed class file Message-ID: I'd like to backport JDK-8244573 to 13u for parity with 11u. The patch applies cleanly. Tested with tier1; new test fails without the patch, passes with it. ------------- Commit messages: - Backport 4eeb61299f27a7db7049cb47e56563a1eaf8bd69 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/155/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=155&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244573 Stats: 94 lines in 3 files changed: 93 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/155.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/155/head:pull/155 PR: https://git.openjdk.java.net/jdk13u-dev/pull/155 From evergizova at openjdk.java.net Fri Mar 19 12:20:45 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 19 Mar 2021 12:20:45 GMT Subject: [jdk13u-dev] Integrated: 8244573: java.lang.ArrayIndexOutOfBoundsException thrown for malformed class file In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 11:48:55 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8244573 to 13u for parity with 11u. > The patch applies cleanly. > Tested with tier1; new test fails without the patch, passes with it. This pull request has now been integrated. Changeset: 3519e532 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk13u-dev/commit/3519e532 Stats: 94 lines in 3 files changed: 93 ins; 0 del; 1 mod 8244573: java.lang.ArrayIndexOutOfBoundsException thrown for malformed class file Fixed java.lang.ArrayIndexOutOfBoundsException in com.sun.tools.classfile.Code_attribute.getInstructions() for methods with no instructions Backport-of: 4eeb61299f27a7db7049cb47e56563a1eaf8bd69 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/155 From evergizova at openjdk.java.net Fri Mar 19 12:20:54 2021 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 19 Mar 2021 12:20:54 GMT Subject: [jdk13u-dev] Integrated: 8253409: Double-rounding possibility in float fma In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 11:47:03 GMT, Ekaterina Vergizova wrote: > I'd like to backport JDK-8253409 to 13u for parity with 11u. > The patch applies cleanly. > Tested with tier1; new test fails without the patch, passes with it. This pull request has now been integrated. Changeset: 17c982e3 Author: Ekaterina Vergizova URL: https://git.openjdk.java.net/jdk13u-dev/commit/17c982e3 Stats: 32 lines in 2 files changed: 4 ins; 11 del; 17 mod 8253409: Double-rounding possibility in float fma Backport-of: e5304b3a994b1e291e4ac5258f473dd7874f163f ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/154 From christoph.langer at sap.com Fri Mar 19 12:22:10 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 19 Mar 2021 12:22:10 +0000 Subject: RFR [jdk11] 8259983: do not use uninitialized expand_ms value in G1CollectedHeap::expand_heap_after_young_collection In-Reply-To: References: Message-ID: Hi Matthias, looks good and trivial. Reviewed. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Baesken, Matthias > Sent: Donnerstag, 18. M?rz 2021 11:06 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] RFR [jdk11] 8259983: do not use uninitialized expand_ms > value in G1CollectedHeap::expand_heap_after_young_collection > > Hello, please review the jdk11 backport of 8259983 . > The backport fits in nicely, but does not apply cleanly because of changes in > the stride ; that's why the separate RFR. > > > Bug / webrev : > > https://bugs.openjdk.java.net/browse/JDK-8259983 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8259983_jdk11/ > > Jdk/jdk : > > https://github.com/openjdk/jdk/commit/9f21bb6a > > > > Thanks, Matthias > From matthias.baesken at sap.com Fri Mar 19 12:47:40 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 19 Mar 2021 12:47:40 +0000 Subject: RFR [jdk11] 8259983: do not use uninitialized expand_ms value in G1CollectedHeap::expand_heap_after_young_collection In-Reply-To: References: Message-ID: Thanks for the review ! Best regards, Matthias > >Hi Matthias, > >looks good and trivial. Reviewed. > >Best regards >Christoph From github.com+75672469+larry-n at openjdk.java.net Fri Mar 19 12:50:01 2021 From: github.com+75672469+larry-n at openjdk.java.net (Larry-N) Date: Fri, 19 Mar 2021 12:50:01 GMT Subject: [jdk13u-dev] RFR: 8237950: C2 compilation fails with "Live Node limit exceeded limit" during ConvI2L::Ideal optimization Message-ID: 8237950: C2 compilation fails with "Live Node limit exceeded limit" during ConvI2L::Ideal optimization ------------- Commit messages: - Backport 326ba317872d377bee1ffcc6682e7bb5a85891d7 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/156/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=156&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8237950 Stats: 88 lines in 2 files changed: 88 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/156.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/156/head:pull/156 PR: https://git.openjdk.java.net/jdk13u-dev/pull/156 From github.com+75672469+larry-n at openjdk.java.net Fri Mar 19 13:06:51 2021 From: github.com+75672469+larry-n at openjdk.java.net (Larry-N) Date: Fri, 19 Mar 2021 13:06:51 GMT Subject: [jdk13u-dev] Integrated: 8237950: C2 compilation fails with "Live Node limit exceeded limit" during ConvI2L::Ideal optimization In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 12:43:18 GMT, Larry-N wrote: > 8237950: C2 compilation fails with "Live Node limit exceeded limit" during ConvI2L::Ideal optimization This pull request has now been integrated. Changeset: 6d32c410 Author: Ilarion Nakonechnyy Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/6d32c410 Stats: 88 lines in 2 files changed: 88 ins; 0 del; 0 mod 8237950: C2 compilation fails with "Live Node limit exceeded limit" during ConvI2L::Ideal optimization Postpone ConvI2L::Ideal optimization to IGVN. Backport-of: 326ba317872d377bee1ffcc6682e7bb5a85891d7 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/156 From github.com+75672469+larry-n at openjdk.java.net Fri Mar 19 13:40:00 2021 From: github.com+75672469+larry-n at openjdk.java.net (Larry-N) Date: Fri, 19 Mar 2021 13:40:00 GMT Subject: [jdk13u-dev] RFR: 8240295: hs_err elapsed time in seconds is not accurate enough Message-ID: 8237950: hs_err elapsed time in seconds is not accurate enough ------------- Commit messages: - Backport a11912ca0650e11c4b457c5e638d8a77d22e6659 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/157/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=157&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240295 Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/157.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/157/head:pull/157 PR: https://git.openjdk.java.net/jdk13u-dev/pull/157 From github.com+75672469+larry-n at openjdk.java.net Fri Mar 19 13:48:39 2021 From: github.com+75672469+larry-n at openjdk.java.net (Larry-N) Date: Fri, 19 Mar 2021 13:48:39 GMT Subject: [jdk13u-dev] Integrated: 8240295: hs_err elapsed time in seconds is not accurate enough In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 13:32:41 GMT, Larry-N wrote: > 8237950: hs_err elapsed time in seconds is not accurate enough This pull request has now been integrated. Changeset: e53c5601 Author: Ilarion Nakonechnyy Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/e53c5601 Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod 8240295: hs_err elapsed time in seconds is not accurate enough Backport-of: a11912ca0650e11c4b457c5e638d8a77d22e6659 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/157 From hseigel at openjdk.java.net Fri Mar 19 14:06:02 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 19 Mar 2021 14:06:02 GMT Subject: [jdk16u] Integrated: 8263557: Possible NULL dereference in Arena::destruct_contents() Message-ID: The patch for this JDK-16u backport of JDK-8263557 applied cleanly. The fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS. ------------- Commit messages: - Backport c484d8904285652246c3af212a4211b9a8955149 Changes: https://git.openjdk.java.net/jdk16u/pull/88/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=88&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263557 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/88.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/88/head:pull/88 PR: https://git.openjdk.java.net/jdk16u/pull/88 From hseigel at openjdk.java.net Fri Mar 19 14:06:02 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 19 Mar 2021 14:06:02 GMT Subject: [jdk16u] Integrated: 8263557: Possible NULL dereference in Arena::destruct_contents() In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 13:58:28 GMT, Harold Seigel wrote: > The patch for this JDK-16u backport of JDK-8263557 applied cleanly. The fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS. This pull request has now been integrated. Changeset: 0aeeebbf Author: Harold Seigel URL: https://git.openjdk.java.net/jdk16u/commit/0aeeebbf Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8263557: Possible NULL dereference in Arena::destruct_contents() Backport-of: c484d8904285652246c3af212a4211b9a8955149 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/88 From hseigel at openjdk.java.net Fri Mar 19 14:21:58 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 19 Mar 2021 14:21:58 GMT Subject: [jdk16u] Integrated: 8263430: Uninitialized Method* variables after JDK-8233913 Message-ID: The patch for this JDK-16u backport applied cleanly. It was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows. ------------- Commit messages: - Backport e25ad7309a5d8bf579b0f27f2f2a57228b9cec87 Changes: https://git.openjdk.java.net/jdk16u/pull/89/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=89&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263430 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk16u/pull/89.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/89/head:pull/89 PR: https://git.openjdk.java.net/jdk16u/pull/89 From hseigel at openjdk.java.net Fri Mar 19 14:21:58 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 19 Mar 2021 14:21:58 GMT Subject: [jdk16u] Integrated: 8263430: Uninitialized Method* variables after JDK-8233913 In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 14:11:27 GMT, Harold Seigel wrote: > The patch for this JDK-16u backport applied cleanly. It was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows. This pull request has now been integrated. Changeset: db7b1c9d Author: Harold Seigel URL: https://git.openjdk.java.net/jdk16u/commit/db7b1c9d Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8263430: Uninitialized Method* variables after JDK-8233913 Backport-of: e25ad7309a5d8bf579b0f27f2f2a57228b9cec87 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/89 From hohensee at amazon.com Fri Mar 19 15:21:27 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 19 Mar 2021 15:21:27 +0000 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability In-Reply-To: References: Message-ID: Pushed. In the future, it'd be great if you used "git hg-export" (one of the Skara tools) to generate the base changeset, because it includes the commit metadata we want to preserve in the 11u hg repo. Thanks, Paul ?-----Original Message----- From: security-dev on behalf of "Hohensee, Paul" Date: Wednesday, March 17, 2021 at 1:01 PM To: Daniel Jeli?ski Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Np, tagged. -----Original Message----- From: Daniel Jeli?ski Date: Tuesday, March 16, 2021 at 11:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Thanks again Paul. Could you sponsor the change? As far as I can tell, I'd need to add a fix request now, but I don't have access to issue tracker. Thanks, Daniel wt., 16 mar 2021 o 18:59 Hohensee, Paul napisa?(a): > > Looks good! :) > > -----Original Message----- > From: Daniel Jeli?ski > Date: Tuesday, March 16, 2021 at 9:49 AM > To: "Hohensee, Paul" > Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > Thanks Paul for your review and for the hint. > > Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html > > compared to original, changes to make/test/BuildMicrobenchmark.gmk > were dropped because file does not exist in jdk11 > compared to previous webrev, CacheBench was re-added. > > Testing: Linux x86_64 tier1 and tier2. > Thanks, > Daniel > > pon., 15 mar 2021 o 18:09 Hohensee, Paul napisa?(a): > > > > The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: security-dev on behalf of Daniel Jeli?ski > > Date: Tuesday, March 9, 2021 at 3:37 PM > > To: "jdk-updates-dev at openjdk.java.net" > > Cc: "security-dev at openjdk.java.net" > > Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > > > Hi, > > Please review this 11u backport; this is the same patch as for head, > > except for microbenchmark makefile changes that did not apply because > > the file doesn't exist in 11u, and the actual microbenchmark, which > > would only add weight for no benefit. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > > > Testing: Linux x86_64 tier1 and tier2. > > > > Thanks, > > Daniel > > > From hohensee at amazon.com Fri Mar 19 16:35:58 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 19 Mar 2021 16:35:58 +0000 Subject: [11u] AArch64: Support for LSE atomics C++ HotSpot code Message-ID: <4935F872-3D55-498E-A31F-38F6384BA8BB@amazon.com> By way of putting my money where my mouth is, I'd be happy to handle extra overhead of backporting 8261660 and of pushing the 8261649 and 8261660 backports together. 8261660 was reverted by 8261649, there's no separate reversion issue. ?-----Original Message----- From: Andrew Haley Date: Friday, March 19, 2021 at 3:10 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] AArch64: Support for LSE atomics C++ HotSpot code On 3/18/21 6:56 PM, Hohensee, Paul wrote: > Up to you. :) Thanks, I won't! Doing so would have required you to *approve a patch you knew to be broken*, which I don't think I've ever done. And srsly, I don't want to start now. :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Fri Mar 19 16:46:08 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 19 Mar 2021 16:46:08 +0000 Subject: [11u] RFR: 8257822: C2 crashes with SIGFPE due to a division that floats above its zero check Message-ID: Hi, JDK-8257822 is backported to 11.0.12-oracle. I'd like to backport it for parity and push it together with the follow-up fixes (which apply cleanly on top of this one): https://bugs.openjdk.java.net/browse/JDK-8258505 https://bugs.openjdk.java.net/browse/JDK-8259227 https://bugs.openjdk.java.net/browse/JDK-8260284 This one doesn't apply cleanly because of an unrelated context difference ("set_early_ctrl" has an additional parameter in 16). So it was trivial to resolve. Bug: https://bugs.openjdk.java.net/browse/JDK-8257822 Original change: https://git.openjdk.java.net/jdk16/commit/ce36aeaa 11u backport: http://cr.openjdk.java.net/~mdoerr/8257822_C2_SIGFPE_11u/webrev.00/ I couldn't get the new jtreg tests passing without removing the key "randomness" and the flag "-XX:StressSeed". I'd like to remove them from TestDivZeroWithSplitIf.java and TestDivZeroDominatedBy.java with JDK-8259227: http://cr.openjdk.java.net/~mdoerr/8259227_C2_SIGFPE2_11u/webrev.00/ That one has applied cleanly, but I've removed these parts (also see below). Reason for doing it in that change is that the first 3 patches modify the same tests. Please review. Best regards, Martin diff -r 2150c70198e1 test/hotspot/jtreg/compiler/loopopts/TestDivZeroDominatedBy.java --- a/test/hotspot/jtreg/compiler/loopopts/TestDivZeroDominatedBy.java Thu Jan 07 15:02:45 2021 +0000 +++ b/test/hotspot/jtreg/compiler/loopopts/TestDivZeroDominatedBy.java Fri Mar 19 17:24:00 2021 +0100 @@ -24,12 +24,12 @@ /* * @test - * @key stress randomness + * @key stress * @bug 8259227 * @summary Verify that zero check is executed before division/modulo operation. * @requires vm.compiler2.enabled * @run main/othervm -Xcomp -XX:-TieredCompilation -XX:CompileOnly=compiler/loopopts/TestDivZeroDominatedBy::test - * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM -XX:StressSeed=917280111 compiler.loopopts.TestDivZeroDominatedBy + * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM compiler.loopopts.TestDivZeroDominatedBy * @run main/othervm -Xcomp -XX:-TieredCompilation -XX:CompileOnly=compiler/loopopts/TestDivZeroDominatedBy::test * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM compiler.loopopts.TestDivZeroDominatedBy */ diff -r 2150c70198e1 test/hotspot/jtreg/compiler/loopopts/TestDivZeroWithSplitIf.java --- a/test/hotspot/jtreg/compiler/loopopts/TestDivZeroWithSplitIf.java Thu Jan 07 15:02:45 2021 +0000 +++ b/test/hotspot/jtreg/compiler/loopopts/TestDivZeroWithSplitIf.java Fri Mar 19 17:24:00 2021 +0100 @@ -24,12 +24,12 @@ /* * @test - * @key stress randomness + * @key stress * @bug 8257822 * @summary Verify that zero check is executed before division/modulo operation. * @requires vm.compiler2.enabled * @run main/othervm -Xcomp -XX:-TieredCompilation -XX:CompileOnly=compiler/loopopts/TestDivZeroWithSplitIf::test - * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM -XX:StressSeed=873732072 compiler.loopopts.TestDivZeroWithSplitIf + * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM compiler.loopopts.TestDivZeroWithSplitIf * @run main/othervm -Xcomp -XX:-TieredCompilation -XX:CompileOnly=compiler/loopopts/TestDivZeroWithSplitIf::test * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM compiler.loopopts.TestDivZeroWithSplitIf */ From djelinski1 at gmail.com Fri Mar 19 21:26:50 2021 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Fri, 19 Mar 2021 22:26:50 +0100 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability In-Reply-To: References: Message-ID: Great, thanks! I tried to follow the instructions here: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix The hg export recipe was not available, so I substituted git format-patch. I wasn't aware of git hg-export. I think it should be mentioned on that wiki. Thanks again, Daniel pt., 19 mar 2021, 16:21 u?ytkownik Hohensee, Paul napisa?: > Pushed. In the future, it'd be great if you used "git hg-export" (one of > the Skara tools) to generate the base changeset, because it includes the > commit metadata we want to preserve in the 11u hg repo. > > Thanks, > Paul > > ?-----Original Message----- > From: security-dev on behalf of > "Hohensee, Paul" > Date: Wednesday, March 17, 2021 at 1:01 PM > To: Daniel Jeli?ski > Cc: "jdk-updates-dev at openjdk.java.net" , > "security-dev at openjdk.java.net" > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and > scalability > > Np, tagged. > > -----Original Message----- > From: Daniel Jeli?ski > Date: Tuesday, March 16, 2021 at 11:40 PM > To: "Hohensee, Paul" > Cc: "jdk-updates-dev at openjdk.java.net" , > "security-dev at openjdk.java.net" > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and > scalability > > Thanks again Paul. > > Could you sponsor the change? As far as I can tell, I'd need to add a > fix request now, but I don't have access to issue tracker. > Thanks, > Daniel > > wt., 16 mar 2021 o 18:59 Hohensee, Paul napisa?(a): > > > > Looks good! :) > > > > -----Original Message----- > > From: Daniel Jeli?ski > > Date: Tuesday, March 16, 2021 at 9:49 AM > > To: "Hohensee, Paul" > > Cc: "jdk-updates-dev at openjdk.java.net" , > "security-dev at openjdk.java.net" > > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance > and scalability > > > > Thanks Paul for your review and for the hint. > > > > Updated webrev: > https://djelinski.github.io/8259886-11u/webrev2/index.html > > > > compared to original, changes to make/test/BuildMicrobenchmark.gmk > > were dropped because file does not exist in jdk11 > > compared to previous webrev, CacheBench was re-added. > > > > Testing: Linux x86_64 tier1 and tier2. > > Thanks, > > Daniel > > > > pon., 15 mar 2021 o 18:09 Hohensee, Paul > napisa?(a): > > > > > > The changes to Cache.java look fine, but please include > CacheBench.java. I'd like to see 11u to stand on its own without reference > to later releases, plus I believe the 11u maintainers prefer to backport as > much of a patch as possible. > > > > > > Thanks, > > > Paul > > > > > > -----Original Message----- > > > From: security-dev on behalf of > Daniel Jeli?ski > > > Date: Tuesday, March 9, 2021 at 3:37 PM > > > To: "jdk-updates-dev at openjdk.java.net" < > jdk-updates-dev at openjdk.java.net> > > > Cc: "security-dev at openjdk.java.net" > > > Subject: [11u] RFR 8259886: Improve SSL session cache performance and > scalability > > > > > > Hi, > > > Please review this 11u backport; this is the same patch as for head, > > > except for microbenchmark makefile changes that did not apply because > > > the file doesn't exist in 11u, and the actual microbenchmark, which > > > would only add weight for no benefit. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > > > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > > > > > Testing: Linux x86_64 tier1 and tier2. > > > > > > Thanks, > > > Daniel > > > > > > > > From dmitry.chuyko at bell-sw.com Fri Mar 19 21:51:01 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Sat, 20 Mar 2021 00:51:01 +0300 Subject: [11u] RFR 8233948: AArch64: Incorrect mapping between OptoReg and VMReg for high 64 bits of Vector Register Message-ID: Hello, Original bug: https://bugs.openjdk.java.net/browse/JDK-8233948 Original patch applies unmodified but with fuzz 1 (offset 0 lines) in vmreg_aarch64.inline.hpp (JDK-8216167 wasn't ported). 11u webrev without fuzz: http://cr.openjdk.java.net/~dchuyko/8233948/webrev.11u.00/ Testing: aarch64 build, tier1, tier2. -- Thanks, -Dmitry From jianglizhou at google.com Sun Mar 21 00:09:59 2021 From: jianglizhou at google.com (Jiangli Zhou) Date: Sat, 20 Mar 2021 17:09:59 -0700 Subject: [11u] RFR JDK-8213231 ThreadSnapshot::_threadObj can become stale Message-ID: Hello, We recently noticed JDK-8213231 related GC crashes in production environments when running on JDK 11. The crashes were always associated with a stale pointer from a java.lang.management.ThreadInfo object to a bad j.l.String object. Applying JDK-8213231's fix resolved the specific crashes. I'd like to backport JDK-8213231 to JDK 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8213231 Original commit: http://hg.openjdk.java.net/jdk/jdk/rev/391d671f222b Webrev: http://cr.openjdk.java.net/~jiangli/backport-8213231/webrev.00/ The patch did not apply cleanly. The following diff in threadService.hpp were hand merged: --- threadService.hpp +++ threadService.hpp @@ -213,12 +213,15 @@ ThreadConcurrentLocks* _concurrent_locks; ThreadSnapshot* _next; -public: - // Dummy snapshot + // ThreadSnapshot instances should only be created via + // ThreadDumpResult::add_thread_snapshot. + friend class ThreadDumpResult; ThreadSnapshot() : _thread(NULL), _threadObj(NULL), _blocker_object(NULL), _blocker_object_owner(NULL), _stack_trace(NULL), _concurrent_locks(NULL), _next(NULL) {}; - ThreadSnapshot(ThreadsList * t_list, JavaThread* thread); + void initialize(ThreadsList * t_list, JavaThread* thread); + +public: ~ThreadSnapshot(); Testing: Linux x86_64 tier1 tests Best, Jiangli From omikhaltcova at openjdk.java.net Mon Mar 22 07:13:44 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 22 Mar 2021 07:13:44 GMT Subject: [jdk13u-dev] Integrated: 8237977: Further update javax/net/ssl/compatibility/Compatibility.java In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 16:31:34 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8237977 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > All regular tests passed. This pull request has now been integrated. Changeset: 44dfa891 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/44dfa891 Stats: 365 lines in 9 files changed: 184 ins; 117 del; 64 mod 8237977: Further update javax/net/ssl/compatibility/Compatibility.java Backport-of: 60fae7797438ea0e7d6e4354af0f8406fab2b16c ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/153 From rwestrel at redhat.com Mon Mar 22 08:25:57 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 22 Mar 2021 09:25:57 +0100 Subject: [11u] RFR: 8257822: C2 crashes with SIGFPE due to a division that floats above its zero check In-Reply-To: References: Message-ID: <87y2efsiga.fsf@redhat.com> > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8257822_C2_SIGFPE_11u/webrev.00/ Looks good to me. Roland From shade at openjdk.java.net Mon Mar 22 08:33:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 22 Mar 2021 08:33:47 GMT Subject: [jdk16u] Integrated: 8263030: Remove Shenandoah leftovers from ReferenceProcessor In-Reply-To: References: Message-ID: <9j5VrkJqeNVUJSb2gRlbjwuXkbXJjt7JbXjT9T-RkG4=.330c0cec-fcc4-4e3a-b27d-4f7fbeb22b0c@github.com> On Mon, 15 Mar 2021 10:58:12 GMT, Aleksey Shipilev wrote: > Shenandoah is no longer using the shared ReferenceProcessor. We can remove remaining Shenandoah leftovers there. > > Additional testing: > - [x] Linux x86_64 fastdebug, `hotspot_gc_shenandoah` This pull request has now been integrated. Changeset: 2c6b47c6 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/2c6b47c6 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8263030: Remove Shenandoah leftovers from ReferenceProcessor Backport-of: ef5e13d263b6d4aaa50e777f7a3fc818293126c8 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/81 From shade at openjdk.java.net Mon Mar 22 08:33:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 22 Mar 2021 08:33:48 GMT Subject: [jdk16u] Integrated: 8260236: better init AnnotationCollector _contended_group In-Reply-To: References: Message-ID: <5pNyT7KPjiJsN4V-ESxBVXD0d_GefIVvTjO1mmzvV9k=.088a3e55-9544-4029-9ca5-abfbf2bda69d@github.com> On Mon, 15 Mar 2021 17:50:51 GMT, Aleksey Shipilev wrote: > This eliminates a potential source of bugs, and keeps codebases in sync (I see 11.0.12-oracle). Patch apples to 11u cleanly, passes tier{1,2}. This pull request has now been integrated. Changeset: c1ef3976 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/c1ef3976 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8260236: better init AnnotationCollector _contended_group Reviewed-by: hseigel Backport-of: fd2641ed36c8cdb59c33675bd9ed909b47cd002e ------------- PR: https://git.openjdk.java.net/jdk16u/pull/83 From shade at openjdk.java.net Mon Mar 22 08:33:49 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 22 Mar 2021 08:33:49 GMT Subject: [jdk16u] Integrated: 8263136: C4530 was reported from VS 2019 at access bridge In-Reply-To: References: Message-ID: On Tue, 16 Mar 2021 09:46:37 GMT, Aleksey Shipilev wrote: > Seeing the similar failure in JDK 16u GHA testing. Backport this one should help. This pull request has now been integrated. Changeset: 71102e79 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/71102e79 Stats: 9 lines in 1 file changed: 2 ins; 1 del; 6 mod 8263136: C4530 was reported from VS 2019 at access bridge Backport-of: d339320e0b648e28bcc0c07801ae9376a33fc975 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/84 From cgo at openjdk.java.net Mon Mar 22 08:35:48 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Mon, 22 Mar 2021 08:35:48 GMT Subject: [jdk16u] Integrated: 8261505: Test test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java killed by Linux OOM Killer In-Reply-To: <4Adf31Uo0cKyM4qI83znp3cWbuIrT0hhH0Uo0fVyVX0=.630da4a9-ea43-43b9-b504-637dbce88687@github.com> References: <4Adf31Uo0cKyM4qI83znp3cWbuIrT0hhH0Uo0fVyVX0=.630da4a9-ea43-43b9-b504-637dbce88687@github.com> Message-ID: <8fOqITlrJIEoWshQpPwAhnyxUfS-ql7xO_-29wzsOHM=.996ffe26-c9e4-4b4a-8dac-913a8dc21bf9@github.com> On Tue, 9 Mar 2021 10:54:17 GMT, Christoph G?ttschkes wrote: > 8261505: Test test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java killed by Linux OOM Killer This pull request has now been integrated. Changeset: b64af94b Author: Christoph G?ttschkes Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16u/commit/b64af94b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8261505: Test test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java killed by Linux OOM Killer Backport-of: ebaa58d9c07f1ac3846bbf8f3736b1b3a5e0a4fc ------------- PR: https://git.openjdk.java.net/jdk16u/pull/76 From clanger at openjdk.java.net Mon Mar 22 09:37:42 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 22 Mar 2021 09:37:42 GMT Subject: [jdk16u] Integrated: 8263069: Exclude some failing tests from security/infra/java/security/cert/CertPathValidator In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 15:51:01 GMT, Christoph Langer wrote: > 8263069: Exclude some failing tests from security/infra/java/security/cert/CertPathValidator This pull request has now been integrated. Changeset: 34ecf722 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk16u/commit/34ecf722 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8263069: Exclude some failing tests from security/infra/java/security/cert/CertPathValidator Reviewed-by: stuefe Backport-of: a9b4f033ddfb2e7ea36ecdf2f076fc374fe54cac ------------- PR: https://git.openjdk.java.net/jdk16u/pull/79 From clanger at openjdk.java.net Mon Mar 22 09:38:47 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 22 Mar 2021 09:38:47 GMT Subject: [jdk16u] Integrated: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 15:55:49 GMT, Christoph Langer wrote: > 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 This pull request has now been integrated. Changeset: 62adf831 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk16u/commit/62adf831 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 Backport-of: 8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/80 From omikhaltcova at openjdk.java.net Mon Mar 22 09:48:57 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 22 Mar 2021 09:48:57 GMT Subject: [jdk13u-dev] RFR: 8234779: Provide idiom for declaring classes noncopyable Message-ID: I'd like to backport JDK-8234779 to jdk13u for parity with jdk11u. The original patch applied not cleanly. The merge was required for the following 6 files: 1) due to the context changes in the includes of headers part: src/hotspot/share/utilities/bitMap.hpp src/hotspot/share/gc/z/zList.hpp 2) due to no definition of such a class (PlatformMutex): src/hotspot/os/windows/os_windows.hpp src/hotspot/os/solaris/os_solaris.hpp src/hotspot/os/posix/os_posix.hpp 3) due to the context changes: src/hotspot/share/gc/shared/ptrQueue.hpp All regular tests passed. ------------- Commit messages: - Backport 577e87e5b27a3f4c590258b370a42c511f724cbc Changes: https://git.openjdk.java.net/jdk13u-dev/pull/158/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=158&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234779 Stats: 161 lines in 37 files changed: 52 ins; 60 del; 49 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/158.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/158/head:pull/158 PR: https://git.openjdk.java.net/jdk13u-dev/pull/158 From yan at openjdk.java.net Mon Mar 22 10:10:46 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 22 Mar 2021 10:10:46 GMT Subject: [jdk13u-dev] RFR: 8234779: Provide idiom for declaring classes noncopyable In-Reply-To: References: Message-ID: On Mon, 22 Mar 2021 09:42:55 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8234779 to jdk13u for parity with jdk11u. > The original patch applied not cleanly. > > The merge was required for the following 6 files: > 1) due to the context changes in the includes of headers part: > src/hotspot/share/utilities/bitMap.hpp > src/hotspot/share/gc/z/zList.hpp > 2) due to no definition of such a class (PlatformMutex): > src/hotspot/os/windows/os_windows.hpp > src/hotspot/os/solaris/os_solaris.hpp > src/hotspot/os/posix/os_posix.hpp > 3) due to the context changes: > src/hotspot/share/gc/shared/ptrQueue.hpp > > All regular tests passed. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/158 From omikhaltcova at openjdk.java.net Mon Mar 22 11:15:49 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 22 Mar 2021 11:15:49 GMT Subject: [jdk13u-dev] Integrated: 8234779: Provide idiom for declaring classes noncopyable In-Reply-To: References: Message-ID: On Mon, 22 Mar 2021 09:42:55 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8234779 to jdk13u for parity with jdk11u. > The original patch applied not cleanly. > > The merge was required for the following 6 files: > 1) due to the context changes in the includes of headers part: > src/hotspot/share/utilities/bitMap.hpp > src/hotspot/share/gc/z/zList.hpp > 2) due to no definition of such a class (PlatformMutex): > src/hotspot/os/windows/os_windows.hpp > src/hotspot/os/solaris/os_solaris.hpp > src/hotspot/os/posix/os_posix.hpp > 3) due to the context changes: > src/hotspot/share/gc/shared/ptrQueue.hpp > > All regular tests passed. This pull request has now been integrated. Changeset: 3186873e Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/3186873e Stats: 161 lines in 37 files changed: 52 ins; 60 del; 49 mod 8234779: Provide idiom for declaring classes noncopyable Add NONCOPYABLE macro and uses. Reviewed-by: yan Backport-of: 577e87e5b27a3f4c590258b370a42c511f724cbc ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/158 From mdoerr at openjdk.java.net Mon Mar 22 11:53:52 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 22 Mar 2021 11:53:52 GMT Subject: [jdk16u] Integrated: 8263587: C2: JVMS not cloned when needs_clone_jvms() is true In-Reply-To: References: Message-ID: <-myjDBNdoG0QZFxZu-zCcCo-SIp8-XFSW3chmdKBRRg=.44a9733a-6243-4e4d-8946-291003fd7a49@github.com> On Tue, 16 Mar 2021 11:57:53 GMT, Martin Doerr wrote: > 8263587: C2: JVMS not cloned when needs_clone_jvms() is true This pull request has now been integrated. Changeset: 75ed0344 Author: Martin Doerr URL: https://git.openjdk.java.net/jdk16u/commit/75ed0344 Stats: 25 lines in 1 file changed: 1 ins; 16 del; 8 mod 8263587: C2: JVMS not cloned when needs_clone_jvms() is true Backport-of: 9c50b8e66a87eb3f27a0cbb573b22a9d9a73a114 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/86 From yan at azul.com Mon Mar 22 12:42:25 2021 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 22 Mar 2021 15:42:25 +0300 Subject: [13u notice] last 13u-dev merge for 13.0.7 Message-ID: Hi, presently jdk13u-dev is closed. It will reopen for 13.0.8 (July release) as soon as we have that release value available and 13.0.8+0 tag set there. Last update of master jdk13u repo from jdk13u-dev will be finished today. Further changes to 13.0.7, if any, will go directly to the master and should be requested with jdk13u-critical-request label. Thank you! --yan From martin.doerr at sap.com Mon Mar 22 13:15:13 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 22 Mar 2021 13:15:13 +0000 Subject: [11u] RFR: 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check Message-ID: Hi, thanks, Roland, for reviewing my JDK-8257822 backport! JDK-8259227 is a follow-up fix which applies cleanly, but I had to remove "randomness" and the flag "-XX:StressSeed" from 2 tests for jdk11u as mentioned in my previous RFR email which I included below. Please review http://cr.openjdk.java.net/~mdoerr/8259227_C2_SIGFPE2_11u/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8259227 Original change: https://git.openjdk.java.net/jdk16/commit/c1fb5216 Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Doerr, Martin > Sent: Freitag, 19. M?rz 2021 17:46 > To: jdk-updates-dev at openjdk.java.net > Cc: Langer, Christoph ; Lindenmaier, Goetz > > Subject: [CAUTION] [11u] RFR: 8257822: C2 crashes with SIGFPE due to a > division that floats above its zero check > > Hi, > > JDK-8257822 is backported to 11.0.12-oracle. I'd like to backport it for parity > and push it together with the follow-up fixes (which apply cleanly on top of > this one): > https://bugs.openjdk.java.net/browse/JDK-8258505 > https://bugs.openjdk.java.net/browse/JDK-8259227 > https://bugs.openjdk.java.net/browse/JDK-8260284 > This one doesn't apply cleanly because of an unrelated context difference > ("set_early_ctrl" has an additional parameter in 16). So it was trivial to > resolve. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8257822 > > Original change: > https://git.openjdk.java.net/jdk16/commit/ce36aeaa > > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8257822_C2_SIGFPE_11u/webrev.00/ > > I couldn't get the new jtreg tests passing without removing the key > "randomness" and the flag "-XX:StressSeed". I'd like to remove them from > TestDivZeroWithSplitIf.java and TestDivZeroDominatedBy.java with JDK- > 8259227: > http://cr.openjdk.java.net/~mdoerr/8259227_C2_SIGFPE2_11u/webrev.00/ > That one has applied cleanly, but I've removed these parts (also see below). > Reason for doing it in that change is that the first 3 patches modify the same > tests. > > Please review. > > Best regards, > Martin > > > diff -r 2150c70198e1 > test/hotspot/jtreg/compiler/loopopts/TestDivZeroDominatedBy.java > --- a/test/hotspot/jtreg/compiler/loopopts/TestDivZeroDominatedBy.java > Thu Jan 07 15:02:45 2021 +0000 > +++ b/test/hotspot/jtreg/compiler/loopopts/TestDivZeroDominatedBy.java > Fri Mar 19 17:24:00 2021 +0100 > @@ -24,12 +24,12 @@ > > /* > * @test > - * @key stress randomness > + * @key stress > * @bug 8259227 > * @summary Verify that zero check is executed before division/modulo > operation. > * @requires vm.compiler2.enabled > * @run main/othervm -Xcomp -XX:-TieredCompilation - > XX:CompileOnly=compiler/loopopts/TestDivZeroDominatedBy::test > - * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM - > XX:StressSeed=917280111 compiler.loopopts.TestDivZeroDominatedBy > + * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM > compiler.loopopts.TestDivZeroDominatedBy > * @run main/othervm -Xcomp -XX:-TieredCompilation - > XX:CompileOnly=compiler/loopopts/TestDivZeroDominatedBy::test > * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM > compiler.loopopts.TestDivZeroDominatedBy > */ > diff -r 2150c70198e1 > test/hotspot/jtreg/compiler/loopopts/TestDivZeroWithSplitIf.java > --- a/test/hotspot/jtreg/compiler/loopopts/TestDivZeroWithSplitIf.java Thu > Jan 07 15:02:45 2021 +0000 > +++ b/test/hotspot/jtreg/compiler/loopopts/TestDivZeroWithSplitIf.java Fri > Mar 19 17:24:00 2021 +0100 > @@ -24,12 +24,12 @@ > > /* > * @test > - * @key stress randomness > + * @key stress > * @bug 8257822 > * @summary Verify that zero check is executed before division/modulo > operation. > * @requires vm.compiler2.enabled > * @run main/othervm -Xcomp -XX:-TieredCompilation - > XX:CompileOnly=compiler/loopopts/TestDivZeroWithSplitIf::test > - * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM - > XX:StressSeed=873732072 compiler.loopopts.TestDivZeroWithSplitIf > + * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM > compiler.loopopts.TestDivZeroWithSplitIf > * @run main/othervm -Xcomp -XX:-TieredCompilation - > XX:CompileOnly=compiler/loopopts/TestDivZeroWithSplitIf::test > * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM > compiler.loopopts.TestDivZeroWithSplitIf > */ From dmitry.chuyko at bell-sw.com Mon Mar 22 15:08:19 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Mon, 22 Mar 2021 18:08:19 +0300 Subject: [11u] RFR 8206895: aarch64: rework error-prone cmp instuction Message-ID: <79ae48e6-22d4-856c-69f2-8b47f74b2590@bell-sw.com> Hello, Original bug: https://bugs.openjdk.java.net/browse/JDK-8206895 Original patch applies with minor fuzz and requires minor adjustments: few rejected changes in macroAssembler_aarch64.cpp and stubGenerator_aarch64.cpp were recreated -- all because of already ported stuff [1][2][3][4]. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8206895/webrev.11u.00/ Testing: tier1, tier2. [1] https://bugs.openjdk.java.net/browse/JDK-8239787 [2] https://bugs.openjdk.java.net/browse/JDK-8228400 [3] https://bugs.openjdk.java.net/browse/JDK-8205421 [4] https://bugs.openjdk.java.net/browse/JDK-8218966 -- Thanks, -Dmitry From hohensee at amazon.com Mon Mar 22 16:52:04 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 22 Mar 2021 16:52:04 +0000 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Message-ID: You?re right about that. Would someone with wiki access please update it? :) Thanks, Paul From: Daniel Jeli?ski Date: Friday, March 19, 2021 at 2:28 PM To: "Hohensee, Paul" Cc: "jdk-updates-dev at openjdk.java.net" , "security-dev at openjdk.java.net" Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Great, thanks! I tried to follow the instructions here: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix The hg export recipe was not available, so I substituted git format-patch. I wasn't aware of git hg-export. I think it should be mentioned on that wiki. Thanks again, Daniel pt., 19 mar 2021, 16:21 u?ytkownik Hohensee, Paul > napisa?: Pushed. In the future, it'd be great if you used "git hg-export" (one of the Skara tools) to generate the base changeset, because it includes the commit metadata we want to preserve in the 11u hg repo. Thanks, Paul -----Original Message----- From: security-dev > on behalf of "Hohensee, Paul" > Date: Wednesday, March 17, 2021 at 1:01 PM To: Daniel Jeli?ski > Cc: "jdk-updates-dev at openjdk.java.net" >, "security-dev at openjdk.java.net" > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Np, tagged. -----Original Message----- From: Daniel Jeli?ski > Date: Tuesday, March 16, 2021 at 11:40 PM To: "Hohensee, Paul" > Cc: "jdk-updates-dev at openjdk.java.net" >, "security-dev at openjdk.java.net" > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Thanks again Paul. Could you sponsor the change? As far as I can tell, I'd need to add a fix request now, but I don't have access to issue tracker. Thanks, Daniel wt., 16 mar 2021 o 18:59 Hohensee, Paul > napisa?(a): > > Looks good! :) > > -----Original Message----- > From: Daniel Jeli?ski > > Date: Tuesday, March 16, 2021 at 9:49 AM > To: "Hohensee, Paul" > > Cc: "jdk-updates-dev at openjdk.java.net" >, "security-dev at openjdk.java.net" > > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > Thanks Paul for your review and for the hint. > > Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html > > compared to original, changes to make/test/BuildMicrobenchmark.gmk > were dropped because file does not exist in jdk11 > compared to previous webrev, CacheBench was re-added. > > Testing: Linux x86_64 tier1 and tier2. > Thanks, > Daniel > > pon., 15 mar 2021 o 18:09 Hohensee, Paul > napisa?(a): > > > > The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: security-dev > on behalf of Daniel Jeli?ski > > > Date: Tuesday, March 9, 2021 at 3:37 PM > > To: "jdk-updates-dev at openjdk.java.net" > > > Cc: "security-dev at openjdk.java.net" > > > Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability > > > > Hi, > > Please review this 11u backport; this is the same patch as for head, > > except for microbenchmark makefile changes that did not apply because > > the file doesn't exist in 11u, and the actual microbenchmark, which > > would only add weight for no benefit. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > > > Testing: Linux x86_64 tier1 and tier2. > > > > Thanks, > > Daniel > > > From omikhaltcova at openjdk.java.net Mon Mar 22 19:04:48 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 22 Mar 2021 19:04:48 GMT Subject: [jdk13u-dev] RFR: 8263996: Fix build on 13u after JDK-8234779 backport Message-ID: I would like to partialy revert changes made by backport of JDK-8234779 to jdk13u: to remove restriction for copying objects from PlatformMonitor class due to the builds failure. ------------- Commit messages: - 8263996: Fix build on 13u after JDK-8234779 backport Changes: https://git.openjdk.java.net/jdk13u-dev/pull/160/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=160&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263996 Stats: 7 lines in 3 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/160.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/160/head:pull/160 PR: https://git.openjdk.java.net/jdk13u-dev/pull/160 From yan at openjdk.java.net Mon Mar 22 19:09:49 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 22 Mar 2021 19:09:49 GMT Subject: [jdk13u-dev] RFR: 8263996: Fix build on 13u after JDK-8234779 backport In-Reply-To: References: Message-ID: On Mon, 22 Mar 2021 19:00:08 GMT, Olga Mikhaltsova wrote: > I would like to partialy revert changes made by backport of JDK-8234779 to jdk13u: to remove restriction for copying objects from PlatformMonitor class due to the builds failure. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/160 From omikhaltcova at openjdk.java.net Mon Mar 22 19:21:45 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 22 Mar 2021 19:21:45 GMT Subject: [jdk13u-dev] Integrated: 8263996: Fix build on 13u after JDK-8234779 backport In-Reply-To: References: Message-ID: On Mon, 22 Mar 2021 19:00:08 GMT, Olga Mikhaltsova wrote: > I would like to partialy revert changes made by backport of JDK-8234779 to jdk13u: to remove restriction for copying objects from PlatformMonitor class due to the builds failure. This pull request has now been integrated. Changeset: c37cdb32 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/c37cdb32 Stats: 7 lines in 3 files changed: 0 ins; 7 del; 0 mod 8263996: Fix build on 13u after JDK-8234779 backport Reviewed-by: yan ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/160 From jdowland at redhat.com Mon Mar 22 20:02:32 2021 From: jdowland at redhat.com (Jonathan Dowland) Date: Mon, 22 Mar 2021 20:02:32 +0000 Subject: [11u] RFR: 8187450: JNI local refs exceeds capacity warning in NetworkInterface::getAll Message-ID: <20210322200232.jcnow3bpbjytn3k3@qusp> Hi, Please consider and review this backport for 11u. It does not apply clean from main, but the only hunk that doesn't is the Test metadata tagging. The patch substantially reduces the JNI local reference count when using NetworkInterface::getAll, which otherwise breaches the limit set by -Xcheck:jni very quickly. head patch: https://github.com/openjdk/jdk/commit/ba504fcee8ba9ca3e6c223effc46754444a9c49f Bug: https://bugs.openjdk.java.net/browse/JDK-8187450 Webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-8187450/webrev.00/ Testing: Linux x86_64 tier1 and test/jdk/java/net/NetworkInterface/Test.java, and by hand (see next paragraph) If you want to do a thorough check of the difference made, there are some shellscripts in the GitHub PR that make use of Linux network namespaces to control how many Network interfaces the Java process sees, that might be useful: https://github.com/openjdk/jdk/pull/2963 Best wishes, -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat From rrich at openjdk.java.net Tue Mar 23 08:16:59 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 23 Mar 2021 08:16:59 GMT Subject: [jdk16u] RFR: 8259627: Potential memory leaks in JVMTI after JDK-8227745 Message-ID: <7PrjnS9-HlTCguNRev561cNUcjRceS5ixiIcLe8Fpsc=.ad9588fe-8470-41c2-a679-3986c3a9e276@github.com> This is the jdk16u backport of the fix for JDK-8259627. The original patch applies cleanly without modification. The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms ------------- Commit messages: - Backport 6d4a593f8d139f633e4942518059f1e2c0ab0384 Changes: https://git.openjdk.java.net/jdk16u/pull/87/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=87&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259627 Stats: 16 lines in 1 file changed: 8 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk16u/pull/87.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/87/head:pull/87 PR: https://git.openjdk.java.net/jdk16u/pull/87 From rwestrel at redhat.com Tue Mar 23 08:23:16 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 23 Mar 2021 09:23:16 +0100 Subject: [11u] RFR: 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check In-Reply-To: References: Message-ID: <87ft0ms2h7.fsf@redhat.com> > http://cr.openjdk.java.net/~mdoerr/8259227_C2_SIGFPE2_11u/webrev.00/ Looks good to me. Roland. From christoph.goettschkes at microdoc.com Tue Mar 23 08:49:18 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Tue, 23 Mar 2021 09:49:18 +0100 Subject: [11u] RFR: 8213845: ARM32: Interpreter doesn't call result handler after native calls Message-ID: <37d6exsq9c-1@aserp2030.oracle.com> Hi, please review this backport of JDK-8213845 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8213845 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/2d795829f39f Webrev: https://cr.openjdk.java.net/~cgo/8213845/webrev.11u.00/ This patch fixes the conversion between C and Java boolean types, which value is not 0 or 1 in C on aarch32. This also fixes the test case "runtime/BoolReturn/JNIBooleanTest.java", which is testing this conversion. The backport is not clean, because in 11u, the arm64 CPU type is still present. Adjusting the backport was fairly straight forward. Because of the arm64 CPU type, there are some additional #ifdef present and the changes had to be incoporated into the arm64 port as well. No additional changes have been made, only slight adjustments. I am not able to test the arm64 port, since it doesn't compile anymore and I don't know if this CPU type is still supported, or if the code remains there because it is deemed to complicated to remove it. Tested: * Hotspot tier1 on linux aarch32 * Hotspot tier1 on linux aarch32 with -XX:+VerifyOops and -Xcheck:jni * Hotspot tier1 on linux ARMv7-A Thanks, Christoph From martin.doerr at sap.com Tue Mar 23 09:09:00 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 23 Mar 2021 09:09:00 +0000 Subject: [11u] RFR: 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check In-Reply-To: <87ft0ms2h7.fsf@redhat.com> References: <87ft0ms2h7.fsf@redhat.com> Message-ID: Hi Roland, thanks a lot for reviewing this one, too! Best regards, Martin > -----Original Message----- > From: Roland Westrelin > Sent: Dienstag, 23. M?rz 2021 09:23 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net > Cc: Langer, Christoph ; Lindenmaier, Goetz > > Subject: Re: [11u] RFR: 8259227: C2 crashes with SIGFPE due to a division that > floats above its zero check > > > > > http://cr.openjdk.java.net/~mdoerr/8259227_C2_SIGFPE2_11u/webrev.00/ > > Looks good to me. > > Roland. From sgehwolf at redhat.com Tue Mar 23 09:16:52 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 23 Mar 2021 10:16:52 +0100 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability In-Reply-To: References: Message-ID: On Mon, 2021-03-22 at 16:52 +0000, Hohensee, Paul wrote: > You?re right about that. Would someone with wiki access please update > it? :) Done. https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix Thanks, Severin From christoph.goettschkes at microdoc.com Tue Mar 23 11:21:51 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Tue, 23 Mar 2021 12:21:51 +0100 Subject: [11u] 8261505: Test test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java killed by Linux OOM Killer Message-ID: <37d6uu1ukk-1@userp2060.oracle.com> Hi, could someone please sponsor this clean and already approved backport of 8261505 to 11u? Bug: https://bugs.openjdk.java.net/browse/JDK-8261505 Webrev: https://cr.openjdk.java.net/~cgo/8261505/webrev.11u.00/ Thanks, Christoph From shade at redhat.com Tue Mar 23 11:25:15 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 23 Mar 2021 12:25:15 +0100 Subject: [11u] 8261505: Test test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java killed by Linux OOM Killer In-Reply-To: <37d6uu1ukk-1@userp2060.oracle.com> References: <37d6uu1ukk-1@userp2060.oracle.com> Message-ID: <92a5e1fc-ab09-07c2-05f4-d0dac776d482@redhat.com> On 3/23/21 12:21 PM, Christoph G?ttschkes wrote: > Hi, > > could someone please sponsor this clean and already approved backport of 8261505 to 11u? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8261505 > Webrev: https://cr.openjdk.java.net/~cgo/8261505/webrev.11u.00/ I will, hold on. -- Thanks, -Aleksey From shade at redhat.com Tue Mar 23 11:29:24 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 23 Mar 2021 12:29:24 +0100 Subject: [11u] 8261505: Test test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java killed by Linux OOM Killer In-Reply-To: <92a5e1fc-ab09-07c2-05f4-d0dac776d482@redhat.com> References: <37d6uu1ukk-1@userp2060.oracle.com> <92a5e1fc-ab09-07c2-05f4-d0dac776d482@redhat.com> Message-ID: <3a188fa4-f845-419b-0bc4-a74f6fc73e0f@redhat.com> On 3/23/21 12:25 PM, Aleksey Shipilev wrote: > On 3/23/21 12:21 PM, Christoph G?ttschkes wrote: >> Hi, >> >> could someone please sponsor this clean and already approved backport of 8261505 to 11u? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8261505 >> Webrev: https://cr.openjdk.java.net/~cgo/8261505/webrev.11u.00/ > > I will, hold on. There: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/db3531278ca5 -- Thanks, -Aleksey From christoph.goettschkes at microdoc.com Tue Mar 23 11:31:44 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Tue, 23 Mar 2021 12:31:44 +0100 Subject: [11u] 8261505: Test test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java killed by Linux OOM Killer In-Reply-To: <3a188fa4-f845-419b-0bc4-a74f6fc73e0f@redhat.com> References: <37d6uu1ukk-1@userp2060.oracle.com> <92a5e1fc-ab09-07c2-05f4-d0dac776d482@redhat.com> <3a188fa4-f845-419b-0bc4-a74f6fc73e0f@redhat.com> Message-ID: <37daew8kuu-1@userp2020.oracle.com> Thanks Aleksey, very much appreciated. On 3/23/21 12:29 PM, Aleksey Shipilev wrote: > On 3/23/21 12:25 PM, Aleksey Shipilev wrote: >> On 3/23/21 12:21 PM, Christoph G?ttschkes wrote: >>> Hi, >>> >>> could someone please sponsor this clean and already approved backport of 8261505 to 11u? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8261505 >>> Webrev: https://cr.openjdk.java.net/~cgo/8261505/webrev.11u.00/ >> >> I will, hold on. > > There: > ? https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/db3531278ca5 > From sgehwolf at redhat.com Tue Mar 23 12:56:15 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 23 Mar 2021 13:56:15 +0100 Subject: [11u] RFR: 8187450: JNI local refs exceeds capacity warning in NetworkInterface::getAll In-Reply-To: <20210322200232.jcnow3bpbjytn3k3@qusp> References: <20210322200232.jcnow3bpbjytn3k3@qusp> Message-ID: <100dbbc33b11e7912c3b3441fc1798824b2da074.camel@redhat.com> On Mon, 2021-03-22 at 20:02 +0000, Jonathan Dowland wrote: > Hi, > > Please consider and review this backport for 11u. It does not apply > clean from main, but the only hunk that doesn't is the Test metadata > tagging. The patch substantially reduces the JNI local reference > count when using NetworkInterface::getAll, which otherwise breaches > the limit set by -Xcheck:jni very quickly. > > head patch: > https://github.com/openjdk/jdk/commit/ba504fcee8ba9ca3e6c223effc46754444a9c49f > Bug: https://bugs.openjdk.java.net/browse/JDK-8187450 > Webrev: > https://cr.openjdk.java.net/~jdowland/webrevs/JDK-8187450/webrev.00/ > > Testing: Linux x86_64 tier1 and test/jdk/java/net/NetworkInterface/Test.java, > and by hand (see next paragraph) This looks good to me. Aside: For some reason the patch metadata looks different when doing a git hg-export from jdk/jdk. Both variants are fine, though. Thanks, Severin From hohensee at amazon.com Tue Mar 23 14:41:48 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 23 Mar 2021 14:41:48 +0000 Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Message-ID: Thanks, Severin. ?-----Original Message----- From: Severin Gehwolf Date: Tuesday, March 23, 2021 at 2:17 AM To: "Hohensee, Paul" , Daniel Jeli?ski Cc: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability On Mon, 2021-03-22 at 16:52 +0000, Hohensee, Paul wrote: > You?re right about that. Would someone with wiki access please update > it? :) Done. https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix Thanks, Severin From hohensee at amazon.com Tue Mar 23 14:43:07 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 23 Mar 2021 14:43:07 +0000 Subject: [11u] RFR 8206895: aarch64: rework error-prone cmp instuction Message-ID: <7DC2CC15-E9B0-4F74-8D00-912D89B84016@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Dmitry Chuyko Date: Monday, March 22, 2021 at 8:10 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8206895: aarch64: rework error-prone cmp instuction Hello, Original bug: https://bugs.openjdk.java.net/browse/JDK-8206895 Original patch applies with minor fuzz and requires minor adjustments: few rejected changes in macroAssembler_aarch64.cpp and stubGenerator_aarch64.cpp were recreated -- all because of already ported stuff [1][2][3][4]. 11u webrev: http://cr.openjdk.java.net/~dchuyko/8206895/webrev.11u.00/ Testing: tier1, tier2. [1] https://bugs.openjdk.java.net/browse/JDK-8239787 [2] https://bugs.openjdk.java.net/browse/JDK-8228400 [3] https://bugs.openjdk.java.net/browse/JDK-8205421 [4] https://bugs.openjdk.java.net/browse/JDK-8218966 -- Thanks, -Dmitry From hohensee at amazon.com Tue Mar 23 14:48:38 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 23 Mar 2021 14:48:38 +0000 Subject: [11u] RFR 8233948: AArch64: Incorrect mapping between OptoReg and VMReg for high 64 bits of Vector Register Message-ID: <23EF9E06-4C50-4DD9-802C-6D38FB124D4C@amazon.com> Lgtm, though I see the issue is already tagged, so this review is just a formal review record. :) Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Dmitry Chuyko Date: Friday, March 19, 2021 at 2:52 PM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8233948: AArch64: Incorrect mapping between OptoReg and VMReg for high 64 bits of Vector Register Hello, Original bug: https://bugs.openjdk.java.net/browse/JDK-8233948 Original patch applies unmodified but with fuzz 1 (offset 0 lines) in vmreg_aarch64.inline.hpp (JDK-8216167 wasn't ported). 11u webrev without fuzz: http://cr.openjdk.java.net/~dchuyko/8233948/webrev.11u.00/ Testing: aarch64 build, tier1, tier2. -- Thanks, -Dmitry From martin.doerr at sap.com Tue Mar 23 15:24:43 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 23 Mar 2021 15:24:43 +0000 Subject: [11u] RFR: 8206925: Support the certificate_authorities extension Message-ID: Hi, JDK-8206925 was backported to 11.0.10-oracle, but it's still missing in the Open Source version. I'd like to backport it for parity. It does apply cleanly, but I had to modify it, because the following change is not in 11u: https://bugs.openjdk.java.net/browse/JDK-8215712 Bug: https://bugs.openjdk.java.net/browse/JDK-8206925 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/827bac238aa0 11u backport: http://cr.openjdk.java.net/~mdoerr/8206925_ca_ext_11u/webrev.00/ Manual change to make it work without JDK-8215712 (SSLStringizer and derived classes don't take a HandshakeContext in 11u): http://cr.openjdk.java.net/~mdoerr/8206925_ca_ext_11u/8206925_ca_ext_diff.txt Please review. Best regards, Martin From aph at redhat.com Tue Mar 23 16:28:42 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 23 Mar 2021 16:28:42 +0000 Subject: [11u] RFR 8206895: aarch64: rework error-prone cmp instuction In-Reply-To: <79ae48e6-22d4-856c-69f2-8b47f74b2590@bell-sw.com> References: <79ae48e6-22d4-856c-69f2-8b47f74b2590@bell-sw.com> Message-ID: <996fc16c-a436-dd39-5c00-f4d4f298fed1@redhat.com> On 3/22/21 3:08 PM, Dmitry Chuyko wrote: > Hello, > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8206895 > > Original patch applies with minor fuzz and requires minor adjustments: > few rejected changes in macroAssembler_aarch64.cpp and > stubGenerator_aarch64.cpp were recreated -- all because of already > ported stuff [1][2][3][4]. I'm tempted to say no to this one, because it's too intrusive. If that means a ton of enhancements such as JDK-8229351 are more difficult to backport, is that a bad thing? Otherwise we're basically porting all of the AArch64 back end from head to 11u. -- 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 Tue Mar 23 18:29:34 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 23 Mar 2021 18:29:34 +0000 Subject: [11u] RFR 8206895: aarch64: rework error-prone cmp instuction In-Reply-To: <996fc16c-a436-dd39-5c00-f4d4f298fed1@redhat.com> References: <79ae48e6-22d4-856c-69f2-8b47f74b2590@bell-sw.com> <996fc16c-a436-dd39-5c00-f4d4f298fed1@redhat.com> Message-ID: <1C81B7EA-1A72-4558-8AAE-9BF3633535D6@amazon.com> I'd say this patch is worth doing on its own, since it catches actual argument size mismatches that would otherwise be silently accepted. Doesn't seem super intrusive either: all it does is add formal argument casts to "u1", and replace some cmp instructions with subs. Effectively syntax-only changes, so low risk. I don't think we've been backporting all of the aarch64 back end work to 11u, just some of it, and we've (well, I've, so far) done the equivalent x64 work where needed too. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Andrew Haley Date: Tuesday, March 23, 2021 at 9:30 AM To: "jdk-updates-dev at openjdk.java.net" Subject: RE: [11u] RFR 8206895: aarch64: rework error-prone cmp instuction On 3/22/21 3:08 PM, Dmitry Chuyko wrote: > Hello, > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8206895 > > Original patch applies with minor fuzz and requires minor adjustments: > few rejected changes in macroAssembler_aarch64.cpp and > stubGenerator_aarch64.cpp were recreated -- all because of already > ported stuff [1][2][3][4]. I'm tempted to say no to this one, because it's too intrusive. If that means a ton of enhancements such as JDK-8229351 are more difficult to backport, is that a bad thing? Otherwise we're basically porting all of the AArch64 back end from head to 11u. -- 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 Tue Mar 23 20:33:48 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 23 Mar 2021 20:33:48 +0000 Subject: [11u] RFR: Backport of 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl In-Reply-To: <2125893A-DF20-44A8-9F98-235BED2ADFBD@amazon.com> References: <2125893A-DF20-44A8-9F98-235BED2ADFBD@amazon.com> Message-ID: <5C163314-9990-4852-89D1-3D7E61238739@amazon.com> Lgtm. Please include a link to the original JBS issue next time. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Verghese, Clive" Date: Wednesday, March 10, 2021 at 12:58 PM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR: Backport of 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl Hi, I would like to request a review for the backport of JDK-8259662 Webrev : http://cr.openjdk.java.net/~cverghese/webrevs/8259662/ The patch applied cleanly expect for the hunks at src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java, Line : 1329-1333 and 1394-1398. Have validated that the associated tests and tests in test/jdk/javax/net/ssl/SSLSession/ and test/jdk/sun/security/ssl are passing. Regards, Clive Verghese From github.com+12403364+alvdavi at openjdk.java.net Wed Mar 24 00:43:02 2021 From: github.com+12403364+alvdavi at openjdk.java.net (David Alvarez) Date: Wed, 24 Mar 2021 00:43:02 GMT Subject: [jdk13u-dev] RFR: 8202343: Disable TLS 1.0 and 1.1 Message-ID: I'd like to backport 8202343 to jdk13u. All other jdk versions are disabling TLS 1.0 and TLS 1.1 in 2021 April CPU. The patch did not apply cleanly. I had to account for JDK-8235710 missing in 13u, affecting the java.security file. Additionally, JDK-8243029 is also missing, so some of the tests modified do not exist in 13u. ------------- Commit messages: - Backport 3a4b90f0863571dd372af6afab71862f3946a78f Changes: https://git.openjdk.java.net/jdk13u-dev/pull/143/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=143&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8202343 Stats: 381 lines in 18 files changed: 260 ins; 97 del; 24 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/143.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/143/head:pull/143 PR: https://git.openjdk.java.net/jdk13u-dev/pull/143 From yan at openjdk.java.net Wed Mar 24 00:43:02 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 24 Mar 2021 00:43:02 GMT Subject: [jdk13u-dev] RFR: 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 16:12:45 GMT, David Alvarez wrote: > I'd like to backport 8202343 to jdk13u. All other jdk versions are disabling TLS 1.0 and TLS 1.1 in 2021 April CPU. > > The patch did not apply cleanly. I had to account for JDK-8235710 missing in 13u, affecting the java.security file. Additionally, JDK-8243029 is also missing, so some of the tests modified do not exist in 13u. created https://bugs.openjdk.java.net/browse/SKARA-929 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/143 From github.com+12403364+alvdavi at openjdk.java.net Wed Mar 24 00:43:02 2021 From: github.com+12403364+alvdavi at openjdk.java.net (David Alvarez) Date: Wed, 24 Mar 2021 00:43:02 GMT Subject: [jdk13u-dev] RFR: 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 12:08:51 GMT, Yuri Nesterenko wrote: >> I'd like to backport 8202343 to jdk13u. All other jdk versions are disabling TLS 1.0 and TLS 1.1 in 2021 April CPU. >> >> The patch did not apply cleanly. I had to account for JDK-8235710 missing in 13u, affecting the java.security file. Additionally, JDK-8243029 is also missing, so some of the tests modified do not exist in 13u. > > created https://bugs.openjdk.java.net/browse/SKARA-929 @yan-too, as the 13.0.7 is getting closer, feel free to close this pull request and manually grab JDK-8202343 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/143 From yan at openjdk.java.net Wed Mar 24 00:43:02 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 24 Mar 2021 00:43:02 GMT Subject: [jdk13u-dev] RFR: 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: References: Message-ID: On Mon, 22 Mar 2021 17:49:23 GMT, David Alvarez wrote: >> created https://bugs.openjdk.java.net/browse/SKARA-929 > > @yan-too, as the 13.0.7 is getting closer, feel free to close this pull request and manually grab JDK-8202343 @alvdavi We have several days for critical, perhaps they will process the oca request, after all. If not, thank you, I'll grab it at the last moment ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/143 From robilad at openjdk.java.net Wed Mar 24 00:43:03 2021 From: robilad at openjdk.java.net (Dalibor Topic) Date: Wed, 24 Mar 2021 00:43:03 GMT Subject: [jdk13u-dev] RFR: 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: References: Message-ID: <8Bq8KkEoNCQXZDOmIx_gkaPMVvfXwHiWXxr6_xVS1Qc=.b73bf3a0-346b-4618-885a-77d62c9e3981@github.com> On Mon, 22 Mar 2021 18:24:26 GMT, Yuri Nesterenko wrote: >> @yan-too, as the 13.0.7 is getting closer, feel free to close this pull request and manually grab JDK-8202343 > > @alvdavi We have several days for critical, perhaps they will process the oca request, after all. If not, thank you, I'll grab it at the last moment Apologies for the delay. I re-pinged Yishai to verify your account @alvdavi. ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/143 From vkempik at azul.com Wed Mar 24 08:53:17 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 24 Mar 2021 08:53:17 +0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: References: Message-ID: <976AE11F-8213-4997-ABE2-8AE4562629A4@azul.com> Hello there are few caveats with backporting jep-391: 1) support for macos/aarch64 is not just jep-391, we split our jep into pieces, some of them were macos/aarch64 independent and were pushed to upstream as separate commits ( for example, macos MAP_JIT support). also some important pieces from community ( like JNF dependency removal by Phil Race). All these pieces need to be backported before jep-391. 2) we have a plan to go in a traditional way, ojdk17 -> ojdk15 -> ojdk13 -> ojdk11 If you don?t want to bother with jdk15/13 I would suggest you to go without waiting for jep-391. Regards , Vladimir > 24 ????? 2021 ?., ? 00:35, Bernhard Urban-Forster ???????(?): > > Hello, > > Spinning off the discussion from here: https://github.com/openjdk/jdk/pull/2200#issuecomment-804927150 > > And further context, there have been some discussions about it before: > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-October/009727.html > > > Open questions: > > 1. JEP 391 (macOS/AArch64) has a dependency on JEP 388, and I'm assuming we want both to be backported. Question: Is it preferred to do it one go (both together), or should we do it separately (that would be Windows first, then macOS)? > > 2. JEP 388 includes build changes to add cross compilation support for Windows in a hacky way. It's enough to get a build out of it [1], but it's not exactly clean. It was eventually cleaned up with the "WINENV" patch by Magnus [2], but imho it isn't trivial to backport that change. Thoughts? > > > Assuming the answer to question 1 is to split the backports: I think https://github.com/openjdk/aarch64-port/tree/jdk11-windows by Ludovic is in an okay shape, but I will take it for a spin tomorrow and then submit an initial PR against https://github.com/openjdk/jdk11u > > > Thank you, > -Bernhard > > > [1] with workarounds: https://github.com/openjdk/jdk/pull/212#issuecomment-695024586 > [2] https://github.com/openjdk/jdk/pull/1597 From christoph.goettschkes at microdoc.com Wed Mar 24 09:10:33 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Wed, 24 Mar 2021 10:10:33 +0100 Subject: [11u] 8213794: ARM32: disable TypeProfiling, CriticalJNINatives, Serviceablity tests for ARM32 Message-ID: <37d6uuh6s4-1@userp2060.oracle.com> Hi, could someone please sponsor this clean and already approved backport of 8213794 to 11u? Bug: https://bugs.openjdk.java.net/browse/JDK-8213794 Webrev: https://cr.openjdk.java.net/~cgo/8213794/webrev.11u.00/ Thanks, Christoph From yan at openjdk.java.net Wed Mar 24 09:19:52 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 24 Mar 2021 09:19:52 GMT Subject: [jdk13u-dev] RFR: 8264108: Update version .jcheck/conf in jdk13u-dev to be 13.0.8 Message-ID: I hope that with this change all subsequent fixes (until July 2021) will have fixVersion 13.0.8 ------------- Commit messages: - 8264108: Update version .jcheck/conf in jdk13u-dev to be 13.0.8 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/161/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=161&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264108 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/161.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/161/head:pull/161 PR: https://git.openjdk.java.net/jdk13u-dev/pull/161 From shade at redhat.com Wed Mar 24 09:20:00 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Mar 2021 10:20:00 +0100 Subject: [11u] 8213794: ARM32: disable TypeProfiling, CriticalJNINatives, Serviceablity tests for ARM32 In-Reply-To: <37d6uuh6s4-1@userp2060.oracle.com> References: <37d6uuh6s4-1@userp2060.oracle.com> Message-ID: On 3/24/21 10:10 AM, Christoph G?ttschkes wrote: > could someone please sponsor this clean and already approved backport of 8213794 to 11u? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213794 > Webrev: https://cr.openjdk.java.net/~cgo/8213794/webrev.11u.00/ I'll do it. -- Thanks, -Aleksey From shade at redhat.com Wed Mar 24 09:29:34 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Mar 2021 10:29:34 +0100 Subject: [11u] 8213794: ARM32: disable TypeProfiling, CriticalJNINatives, Serviceablity tests for ARM32 In-Reply-To: References: <37d6uuh6s4-1@userp2060.oracle.com> Message-ID: <4248918e-6442-848c-28f5-366ec1ac312a@redhat.com> On 3/24/21 10:20 AM, Aleksey Shipilev wrote: > On 3/24/21 10:10 AM, Christoph G?ttschkes wrote: >> could someone please sponsor this clean and already approved backport of 8213794 to 11u? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213794 >> Webrev: https://cr.openjdk.java.net/~cgo/8213794/webrev.11u.00/ > > I'll do it. There you go: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c13e2eae1bfc -- Thanks, -Aleksey From aph at redhat.com Wed Mar 24 10:06:41 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Mar 2021 10:06:41 +0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: References: Message-ID: On 3/23/21 9:35 PM, Bernhard Urban-Forster wrote: > Spinning off the discussion from here: https://github.com/openjdk/jdk/pull/2200#issuecomment-804927150 > > And further context, there have been some discussions about it before: > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-October/009727.html > > > Open questions: > > 1. JEP 391 (macOS/AArch64) has a dependency on JEP 388, and I'm assuming we want both to be backported. Question: Is it preferred to do it one go (both together), or should we do it separately (that would be Windows first, then macOS)? Separately. Let's have a look at the dependencies and figure out how (and perhaps whether) to do this. > 2. JEP 388 includes build changes to add cross compilation support for Windows in a hacky way. It's enough to get a build out of it [1], but it's not exactly clean. It was eventually cleaned up with the "WINENV" patch by Magnus [2], but imho it isn't trivial to backport that change. Thoughts? Cross compilation is not a requirement for a backport. -- 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 Wed Mar 24 10:07:01 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 24 Mar 2021 10:07:01 GMT Subject: [jdk13u-dev] RFR: 8264107: Bump update version for OpenJDK: jdk-13.0.8 Message-ID: <41a6O3flzcp2Cwjg95Fx7ZWRNnnyhdzdZt-MKGjto_A=.7b1c4b24-daca-4769-a44d-05f6355a3d70@github.com> Start the new version 13.0.8. ------------- Commit messages: - 8264107: Bump update version for OpenJDK: jdk-13.0.8 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/162/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=162&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264107 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/162.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/162/head:pull/162 PR: https://git.openjdk.java.net/jdk13u-dev/pull/162 From christoph.goettschkes at microdoc.com Wed Mar 24 10:06:44 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Wed, 24 Mar 2021 11:06:44 +0100 Subject: [11u] 8213794: ARM32: disable TypeProfiling, CriticalJNINatives, Serviceablity tests for ARM32 In-Reply-To: <4248918e-6442-848c-28f5-366ec1ac312a@redhat.com> References: <37d6uuh6s4-1@userp2060.oracle.com> <4248918e-6442-848c-28f5-366ec1ac312a@redhat.com> Message-ID: <37d85uakpp-1@aserp2020.oracle.com> On 3/24/21 10:29 AM, Aleksey Shipilev wrote: > On 3/24/21 10:20 AM, Aleksey Shipilev wrote: >> On 3/24/21 10:10 AM, Christoph G?ttschkes wrote: >>> could someone please sponsor this clean and already approved backport of 8213794 to 11u? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213794 >>> Webrev: https://cr.openjdk.java.net/~cgo/8213794/webrev.11u.00/ >> >> I'll do it. > > There you go: > ? https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c13e2eae1bfc > Thanks again. From bae at openjdk.java.net Wed Mar 24 10:15:43 2021 From: bae at openjdk.java.net (Andrew Brygin) Date: Wed, 24 Mar 2021 10:15:43 GMT Subject: [jdk13u-dev] RFR: 8264107: Bump update version for OpenJDK: jdk-13.0.8 In-Reply-To: <41a6O3flzcp2Cwjg95Fx7ZWRNnnyhdzdZt-MKGjto_A=.7b1c4b24-daca-4769-a44d-05f6355a3d70@github.com> References: <41a6O3flzcp2Cwjg95Fx7ZWRNnnyhdzdZt-MKGjto_A=.7b1c4b24-daca-4769-a44d-05f6355a3d70@github.com> Message-ID: On Wed, 24 Mar 2021 10:01:33 GMT, Yuri Nesterenko wrote: > Start the new version 13.0.8. The change looks fine to me. ------------- Marked as reviewed by bae (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/162 From aph at redhat.com Wed Mar 24 10:38:23 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Mar 2021 10:38:23 +0000 Subject: [11u] RFR 8206895: aarch64: rework error-prone cmp instuction In-Reply-To: <1C81B7EA-1A72-4558-8AAE-9BF3633535D6@amazon.com> References: <79ae48e6-22d4-856c-69f2-8b47f74b2590@bell-sw.com> <996fc16c-a436-dd39-5c00-f4d4f298fed1@redhat.com> <1C81B7EA-1A72-4558-8AAE-9BF3633535D6@amazon.com> Message-ID: .On 3/23/21 6:29 PM, Hohensee, Paul wrote: > I'd say this patch is worth doing on its own, since it catches actual argument size mismatches that would otherwise be silently accepted. Doesn't seem super intrusive either: all it does is add formal argument casts to "u1", and replace some cmp instructions with subs. Effectively syntax-only changes, so low risk. Hmm, interesting. But it's *not* syntax only, as I mention later. OK, but it's a lot of churn in an old maintenance release, especially where there's no actual bug. Isn't churn a bad thing of itself? > I don't think we've been backporting all of the aarch64 back end work to 11u, just some of it, and we've (well, I've, so far) done the equivalent x64 work where needed too. So what is the threshold for a backport? I'd think it should be a significant user-visible bug (or performance enhancement.) There are other possible criteria, such as misleading and error- prone code, which this perhaps qualifies for. It's still almost a thousand lines of patch, though. And this really is error-prone code: - cmp(rscratch1, is_virtual ? DataLayout::virtual_call_type_data_tag : DataLayout::call_type_data_tag); + cmp(rscratch1, u1(is_virtual ? DataLayout::virtual_call_type_data_tag : DataLayout::call_type_data_tag)); because it silently truncates its argument. It's what checked_cast was invented for, -- 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 bae at openjdk.java.net Wed Mar 24 13:56:48 2021 From: bae at openjdk.java.net (Andrew Brygin) Date: Wed, 24 Mar 2021 13:56:48 GMT Subject: [jdk13u-dev] RFR: 8264108: Update version .jcheck/conf in jdk13u-dev to be 13.0.8 In-Reply-To: References: Message-ID: <9bN_TORc9aLqnrOpyblitu6UwqEKZRACY0fSfAjfpck=.ee02625d-7b2d-44c8-b43e-13f013afdeb7@github.com> On Wed, 24 Mar 2021 09:16:01 GMT, Yuri Nesterenko wrote: > I hope that with this change all subsequent fixes (until July 2021) will have fixVersion 13.0.8 Looks fine. ------------- Marked as reviewed by bae (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/161 From yan at openjdk.java.net Wed Mar 24 14:00:56 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 24 Mar 2021 14:00:56 GMT Subject: [jdk13u-dev] Integrated: 8264108: Update version .jcheck/conf in jdk13u-dev to be 13.0.8 In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 09:16:01 GMT, Yuri Nesterenko wrote: > I hope that with this change all subsequent fixes (until July 2021) will have fixVersion 13.0.8 This pull request has now been integrated. Changeset: 4bbe7738 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/4bbe7738 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8264108: Update version .jcheck/conf in jdk13u-dev to be 13.0.8 Reviewed-by: bae ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/161 From yan at openjdk.java.net Wed Mar 24 14:09:45 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 24 Mar 2021 14:09:45 GMT Subject: [jdk13u-dev] Integrated: 8264107: Bump update version for OpenJDK: jdk-13.0.8 In-Reply-To: <41a6O3flzcp2Cwjg95Fx7ZWRNnnyhdzdZt-MKGjto_A=.7b1c4b24-daca-4769-a44d-05f6355a3d70@github.com> References: <41a6O3flzcp2Cwjg95Fx7ZWRNnnyhdzdZt-MKGjto_A=.7b1c4b24-daca-4769-a44d-05f6355a3d70@github.com> Message-ID: On Wed, 24 Mar 2021 10:01:33 GMT, Yuri Nesterenko wrote: > Start the new version 13.0.8. This pull request has now been integrated. Changeset: bda446b9 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/bda446b9 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8264107: Bump update version for OpenJDK: jdk-13.0.8 Reviewed-by: bae ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/162 From dmitry.chuyko at bell-sw.com Wed Mar 24 14:15:09 2021 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 24 Mar 2021 17:15:09 +0300 Subject: [11u] RFR 8206895: aarch64: rework error-prone cmp instuction In-Reply-To: References: <79ae48e6-22d4-856c-69f2-8b47f74b2590@bell-sw.com> <996fc16c-a436-dd39-5c00-f4d4f298fed1@redhat.com> <1C81B7EA-1A72-4558-8AAE-9BF3633535D6@amazon.com> Message-ID: Hi, On 3/24/21 1:38 PM, Andrew Haley wrote: > .On 3/23/21 6:29 PM, Hohensee, Paul wrote: >> I'd say this patch is worth doing on its own, since it catches actual argument size mismatches that would otherwise be silently accepted. Doesn't seem super intrusive either: all it does is add formal argument casts to "u1", and replace some cmp instructions with subs. Effectively syntax-only changes, so low risk. > Hmm, interesting. But it's *not* syntax only, as I mention later. > > OK, but it's a lot of churn in an old maintenance release, > especially where there's no actual bug. Isn't churn a bad thing > of itself? I listed few issues that were already backported touching same code areas. And I suppose the chance of getting more of them is high right because this is a distributed change for a widely used unstruction. There is no situation in currently backported code where we would rely on non-backported argument checks though but it is an annoying thing to track. > >> I don't think we've been backporting all of the aarch64 back end work to 11u, just some of it, and we've (well, I've, so far) done the equivalent x64 work where needed too. > So what is the threshold for a backport? I'd think it should be > a significant user-visible bug (or performance enhancement.) > There are other possible criteria, such as misleading and error- > prone code, which this perhaps qualifies for. It's still almost > a thousand lines of patch, though. > > And this really is error-prone code: > > - cmp(rscratch1, is_virtual ? DataLayout::virtual_call_type_data_tag : DataLayout::call_type_data_tag); > + cmp(rscratch1, u1(is_virtual ? DataLayout::virtual_call_type_data_tag : DataLayout::call_type_data_tag)); > > because it silently truncates its argument. > > It's what checked_cast was invented for, Looks like something to fix in the upstream too. -Dmitry From yan at openjdk.java.net Wed Mar 24 14:20:43 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 24 Mar 2021 14:20:43 GMT Subject: [jdk13u-dev] RFR: 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 16:12:45 GMT, David Alvarez wrote: > I'd like to backport 8202343 to jdk13u. All other jdk versions are disabling TLS 1.0 and TLS 1.1 in 2021 April CPU. > > The patch did not apply cleanly. I had to account for JDK-8235710 missing in 13u, affecting the java.security file. Additionally, JDK-8243029 is also missing, so some of the tests modified do not exist in 13u. Fine as far as I see. Will go to 13.0.8, first buid ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/143 From christoph.langer at sap.com Wed Mar 24 14:48:22 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Mar 2021 14:48:22 +0000 Subject: [11u] RFR: 8206925: Support the certificate_authorities extension In-Reply-To: References: Message-ID: Hi Martin, your backport looks good. I see the new tests pass and our testing does not unveil other regressions. Reviewed. Oracle has already included this item in 11.0.10 but it fell through the cracks for OpenJDK 11u due to an issue with the updates filter. However, it seems like an important item for TLS 1.3 usability. We have just received a customer request why this wasn?t included in 11u yet, they would need it for their product to move on to TLS 1.3. So I think we should strive for 11.0.11 with this backport. Please label accordingly. Adding @Andrew Haley and @Severin Gehwolf for their opinion on this decision ?? The CSR https://bugs.openjdk.java.net/browse/JDK-8248709 should apply to this backport, please link it to the JBS issue. Thanks & Best regards Christoph From: Doerr, Martin Sent: Dienstag, 23. M?rz 2021 16:25 To: jdk-updates-dev at openjdk.java.net; security-dev Cc: Lindenmaier, Goetz ; Langer, Christoph Subject: [11u] RFR: 8206925: Support the certificate_authorities extension Hi, JDK-8206925 was backported to 11.0.10-oracle, but it?s still missing in the Open Source version. I'd like to backport it for parity. It does apply cleanly, but I had to modify it, because the following change is not in 11u: https://bugs.openjdk.java.net/browse/JDK-8215712 Bug: https://bugs.openjdk.java.net/browse/JDK-8206925 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/827bac238aa0 11u backport: http://cr.openjdk.java.net/~mdoerr/8206925_ca_ext_11u/webrev.00/ Manual change to make it work without JDK-8215712 (SSLStringizer and derived classes don?t take a HandshakeContext in 11u): http://cr.openjdk.java.net/~mdoerr/8206925_ca_ext_11u/8206925_ca_ext_diff.txt Please review. Best regards, Martin From adinn at redhat.com Wed Mar 24 16:33:07 2021 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 24 Mar 2021 16:33:07 +0000 Subject: [11u] RFR 8206895: aarch64: rework error-prone cmp instuction In-Reply-To: References: <79ae48e6-22d4-856c-69f2-8b47f74b2590@bell-sw.com> <996fc16c-a436-dd39-5c00-f4d4f298fed1@redhat.com> <1C81B7EA-1A72-4558-8AAE-9BF3633535D6@amazon.com> Message-ID: <799d70ce-e17b-1dfd-0a80-63e284298b2f@redhat.com> On 24/03/2021 14:15, Dmitry Chuyko wrote: > Hi, > > On 3/24/21 1:38 PM, Andrew Haley wrote: >> .On 3/23/21 6:29 PM, Hohensee, Paul wrote: >>> I'd say this patch is worth doing on its own, since it catches actual >>> argument size mismatches that would otherwise be silently accepted. >>> Doesn't seem super intrusive either: all it does is add formal >>> argument casts to "u1", and replace some cmp instructions with subs. >>> Effectively syntax-only changes, so low risk. >> Hmm, interesting. But it's *not* syntax only, as I mention later. >> >> OK, but it's a lot of churn in an old maintenance release, >> especially where there's no actual bug. Isn't churn a bad thing >> of itself? > I listed few issues that were already backported touching same code > areas. And I suppose the chance of getting more of them is high right > because this is a distributed change for a widely used unstruction. > There is no situation in currently backported code where we would rely > on non-backported argument checks though but it is an annoying thing to > track. And in almost all of these cases sorting out the patch in the absence of this backport is pretty trivial. In a few cases it is not so trivial but those are *exactly* the cases where backporting this patch is also taking a risk. So, this patch is not actually reducing risk. It is just importing that risk into the backports repo before we need to. >> And this really is error-prone code: >> >> -??? cmp(rscratch1, is_virtual ? >> DataLayout::virtual_call_type_data_tag : DataLayout::call_type_data_tag); >> +??? cmp(rscratch1, u1(is_virtual ? >> DataLayout::virtual_call_type_data_tag : >> DataLayout::call_type_data_tag)); >> >> because it silently truncates its argument. >> >> It's what checked_cast was invented for, > > Looks like something to fix in the upstream too. Well, perhaps so. At which point we can then backport a worthwhile fix instead of reshuffling deck chairs like this patch does. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From martin.doerr at sap.com Wed Mar 24 16:41:29 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 24 Mar 2021 16:41:29 +0000 Subject: [11u] RFR: 8206925: Support the certificate_authorities extension In-Reply-To: References: Message-ID: Hi Christoph, thank you for the review and checking the tests! I agree. We should try to deliver it with 11.0.11 if possible. I?ve added the CSR to my backport comment and labeled the issue with jdk11u-critical-request. Best regards, Martin From: Langer, Christoph Sent: Mittwoch, 24. M?rz 2021 15:48 To: Doerr, Martin ; jdk-updates-dev at openjdk.java.net; security-dev ; Severin Gehwolf ; Andrew Haley Cc: Lindenmaier, Goetz Subject: RE: [11u] RFR: 8206925: Support the certificate_authorities extension Hi Martin, your backport looks good. I see the new tests pass and our testing does not unveil other regressions. Reviewed. Oracle has already included this item in 11.0.10 but it fell through the cracks for OpenJDK 11u due to an issue with the updates filter. However, it seems like an important item for TLS 1.3 usability. We have just received a customer request why this wasn?t included in 11u yet, they would need it for their product to move on to TLS 1.3. So I think we should strive for 11.0.11 with this backport. Please label accordingly. Adding @Andrew Haley and @Severin Gehwolf for their opinion on this decision ?? The CSR https://bugs.openjdk.java.net/browse/JDK-8248709 should apply to this backport, please link it to the JBS issue. Thanks & Best regards Christoph From: Doerr, Martin > Sent: Dienstag, 23. M?rz 2021 16:25 To: jdk-updates-dev at openjdk.java.net; security-dev > Cc: Lindenmaier, Goetz >; Langer, Christoph > Subject: [11u] RFR: 8206925: Support the certificate_authorities extension Hi, JDK-8206925 was backported to 11.0.10-oracle, but it?s still missing in the Open Source version. I'd like to backport it for parity. It does apply cleanly, but I had to modify it, because the following change is not in 11u: https://bugs.openjdk.java.net/browse/JDK-8215712 Bug: https://bugs.openjdk.java.net/browse/JDK-8206925 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/827bac238aa0 11u backport: http://cr.openjdk.java.net/~mdoerr/8206925_ca_ext_11u/webrev.00/ Manual change to make it work without JDK-8215712 (SSLStringizer and derived classes don?t take a HandshakeContext in 11u): http://cr.openjdk.java.net/~mdoerr/8206925_ca_ext_11u/8206925_ca_ext_diff.txt Please review. Best regards, Martin From florian.david at datadoghq.com Wed Mar 24 19:42:41 2021 From: florian.david at datadoghq.com (Florian David) Date: Wed, 24 Mar 2021 20:42:41 +0100 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive Message-ID: Hi, Please review this 11u backport. It's very similar to the original patch, except for the class loader data graph lock and JfrKlassUnloading::sort() method which are not available in 11u. The missing lock has been replaced by locking the module_lock instead, as it is done in jfrcheckpointManager.cpp:363. JfrKlassUnloading class does not exist and thus sort() method is not replaced, I added a TODO instead. Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.00/ Original PR: https://github.com/openjdk/jdk/pull/2780 Testing: - Linux x86_64 tier1 tests - SPECvm 2008 on a 96 cores/192 Gib server. JFR recording size is 75.12 MB before the patch and 3.08 MB after the patch. Let me know what you think. Thanks, Florian From beurba at microsoft.com Wed Mar 24 22:10:27 2021 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Wed, 24 Mar 2021 22:10:27 +0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u Message-ID: Thanks Vladimir and Andrew! > 1) support for macos/aarch64 is not just jep-391, we split our jep into pieces, > some of them were macos/aarch64 independent and were pushed to upstream > as separate commits ( for example, macos MAP_JIT support). also some > important pieces from community ( like JNF dependency removal by Phil Race). > All these pieces need to be backported before jep-391. For JEP 388 we have a similar situation, although those independent changes are at a smaller scale I would say. For example let's have a look at JDK-8248403 [1], does it need its own PR on the jdk11u repository or is it fine package it all together in one big PR? Here is a rebased jdk11u branch btw: https://github.com/lewurm/jdk11u/commits/jdk11u-windows > 2) we have a plan to go in a traditional way, ojdk17 -> ojdk15 -> ojdk13 > -> ojdk11 I would say jdk13u/jdk15u is low-priority for us, but I can have a look at them for JEP 388 once I've figured out the process for jdk11u (assuming it's the same). > Cross compilation is not a requirement for a backport. Cross compilation is the only way to build Windows+Arm64 today, so we need at least the hacky variant that I suggested. Thanks, -Bernhard [1] https://bugs.openjdk.java.net/browse/JDK-8248403 ________________________________________ From: Vladimir Kempik Sent: Wednesday, March 24, 2021 09:53 To: Bernhard Urban-Forster Cc: Andrew Haley; Anton Kozlov; aarch64-port-dev at openjdk.java.net; Monica Beckwith; jdk-updates-dev at openjdk.java.net; Magnus Ihse Bursie; openjdk-aarch64 Subject: Re: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u Hello there are few caveats with backporting jep-391: 1) support for macos/aarch64 is not just jep-391, we split our jep into pieces, some of them were macos/aarch64 independent and were pushed to upstream as separate commits ( for example, macos MAP_JIT support). also some important pieces from community ( like JNF dependency removal by Phil Race). All these pieces need to be backported before jep-391. 2) we have a plan to go in a traditional way, ojdk17 -> ojdk15 -> ojdk13 -> ojdk11 If you don?t want to bother with jdk15/13 I would suggest you to go without waiting for jep-391. Regards , Vladimir > 24 ????? 2021 ?., ? 00:35, Bernhard Urban-Forster ???????(?): > > Hello, > > Spinning off the discussion from here: https://github.com/openjdk/jdk/pull/2200#issuecomment-804927150 > > And further context, there have been some discussions about it before: > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-October/009727.html > > > Open questions: > > 1. JEP 391 (macOS/AArch64) has a dependency on JEP 388, and I'm assuming we want both to be backported.? Question: Is it preferred to do it one go (both together), or should we do it separately (that would be Windows first, then macOS)? > > 2. JEP 388 includes build changes to add cross compilation support for Windows in a hacky way. It's enough to get a build out of it [1], but it's not exactly clean. It was eventually cleaned up with the "WINENV" patch by Magnus [2], but imho it isn't trivial to backport that change.? Thoughts? > > > Assuming the answer to question 1 is to split the backports: I think https://github.com/openjdk/aarch64-port/tree/jdk11-windows by Ludovic is in an okay shape, but I will take it for a spin tomorrow and then submit an initial PR against https://github.com/openjdk/jdk11u > > > Thank you, > -Bernhard > > > [1] with workarounds: https://github.com/openjdk/jdk/pull/212#issuecomment-695024586 > [2] https://github.com/openjdk/jdk/pull/1597 From aph at redhat.com Thu Mar 25 09:27:44 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Mar 2021 09:27:44 +0000 Subject: [11u] RFR 8206895: aarch64: rework error-prone cmp instuction In-Reply-To: <799d70ce-e17b-1dfd-0a80-63e284298b2f@redhat.com> References: <79ae48e6-22d4-856c-69f2-8b47f74b2590@bell-sw.com> <996fc16c-a436-dd39-5c00-f4d4f298fed1@redhat.com> <1C81B7EA-1A72-4558-8AAE-9BF3633535D6@amazon.com> <799d70ce-e17b-1dfd-0a80-63e284298b2f@redhat.com> Message-ID: On 3/24/21 4:33 PM, Andrew Dinn wrote: > On 24/03/2021 14:15, Dmitry Chuyko wrote: >> Hi, >> >> On 3/24/21 1:38 PM, Andrew Haley wrote: >>> .On 3/23/21 6:29 PM, Hohensee, Paul wrote: >>>> I'd say this patch is worth doing on its own, since it catches actual >>>> argument size mismatches that would otherwise be silently accepted. >>>> Doesn't seem super intrusive either: all it does is add formal >>>> argument casts to "u1", and replace some cmp instructions with subs. >>>> Effectively syntax-only changes, so low risk. >>> Hmm, interesting. But it's *not* syntax only, as I mention later. >>> >>> OK, but it's a lot of churn in an old maintenance release, >>> especially where there's no actual bug. Isn't churn a bad thing >>> of itself? >> I listed few issues that were already backported touching same code >> areas. And I suppose the chance of getting more of them is high right >> because this is a distributed change for a widely used unstruction. >> There is no situation in currently backported code where we would rely >> on non-backported argument checks though but it is an annoying thing to >> track. > > And in almost all of these cases sorting out the patch in the absence of > this backport is pretty trivial. In a few cases it is not so trivial but > those are *exactly* the cases where backporting this patch is also > taking a risk. > > So, this patch is not actually reducing risk. It is just importing that > risk into the backports repo before we need to. We're going to have to import the MacOS and Windows AArch64 ports into 11u. (At least I think we are. I don't think we can leave those systems without an OpenJDK 11 port forever, can we?) So, let's hold off to see if we're going to need 8206895 for that. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Mar 25 09:33:52 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Mar 2021 09:33:52 +0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: References: Message-ID: <0964b92f-7a2d-8491-4be8-23112286bb46@redhat.com> On 3/24/21 10:10 PM, Bernhard Urban-Forster wrote: >> Cross compilation is not a requirement for a backport. > Cross compilation is the only way to build Windows+Arm64 today, so we need > at least the hacky variant that I suggested. Time to fix that, surely? A bootstrapping build should be a minimum. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Mar 25 15:11:49 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Mar 2021 15:11:49 +0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: References: Message-ID: <3dce3427-973d-7dbf-9534-2d4c829e5097@redhat.com> On 3/24/21 10:10 PM, Bernhard Urban-Forster wrote: > Here is a rebased jdk11u branch btw: > https://github.com/lewurm/jdk11u/commits/jdk11u-windows Can you create a PR against current https://github.com/openjdk/jdk11u, please? -- 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 beurba at microsoft.com Thu Mar 25 16:00:14 2021 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Thu, 25 Mar 2021 16:00:14 +0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: <3dce3427-973d-7dbf-9534-2d4c829e5097@redhat.com> References: , <3dce3427-973d-7dbf-9534-2d4c829e5097@redhat.com> Message-ID: >> Cross compilation is the only way to build Windows+Arm64 today, so we need >> at least the hacky variant that I suggested. > Time to fix that, surely? A bootstrapping build should be a minimum. The problem is that MSVC and friends aren't available for Windows/AArch64 host, and there is no ETA when Microsoft is gonna ship them [1, 2]. Also cygwin isn't available. You could run both via emulation, but that's not fun. The only viable route on that front is to build through WSL1 (support for that was added by the aforementioned WINENV patch) which would replace the cygwin environment, but would still run x86 MSVC binaries through emulation. However that scenario doesn't even work yet on tip today. > Can you create a PR against current https://github.com/openjdk/jdk11u please? Bot said no :-/ https://github.com/openjdk/jdk11u/pull/2 What happened to switching it over to Skara tooling [3]? I *really* wanna avoid dealing with webrevs. -Bernhard [1] https://developercommunity.visualstudio.com/t/ARM64-Build-of-Visual-Studio/841406 [2] https://developercommunity.visualstudio.com/t/Native-ARM-Support-for-Visual-Studio/1161018 [3] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/004934.html ________________________________________ From: Andrew Haley Sent: Thursday, March 25, 2021 16:11 To: Bernhard Urban-Forster; Vladimir Kempik Cc: Anton Kozlov; aarch64-port-dev at openjdk.java.net; Monica Beckwith; jdk-updates-dev at openjdk.java.net; Magnus Ihse Bursie; openjdk-aarch64 Subject: Re: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u On 3/24/21 10:10 PM, Bernhard Urban-Forster wrote: > Here is a rebased jdk11u branch btw: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flewurm%2Fjdk11u%2Fcommits%2Fjdk11u-windows&data=04%7C01%7Cbeurba%40microsoft.com%7C445121a02e404d77c1d908d8efa0639f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637522819449692596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4LtyB5bhj9ZcEirOw3BXAFssuYJQP%2FbihAsuvR6Vg6A%3D&reserved=0 Can you create a PR against current https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk11u&data=04%7C01%7Cbeurba%40microsoft.com%7C445121a02e404d77c1d908d8efa0639f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637522819449702559%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MqWuufR9B9%2FpGhhmygD4NxiMY3Iy2YrGhp5EZSxaGh4%3D&reserved=0, please? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=04%7C01%7Cbeurba%40microsoft.com%7C445121a02e404d77c1d908d8efa0639f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637522819449702559%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CQjNW1ZMiqi2kd24oikuB%2BqtVTgriwuod6%2Bxosp1NUE%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Mar 25 16:21:31 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Mar 2021 16:21:31 +0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: References: <3dce3427-973d-7dbf-9534-2d4c829e5097@redhat.com> Message-ID: On 3/25/21 4:00 PM, Bernhard Urban-Forster wrote: > Bot said no :-/ https://github.com/openjdk/jdk11u/pull/2 Huh? It looks fine. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Thu Mar 25 16:30:45 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 25 Mar 2021 17:30:45 +0100 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: References: <3dce3427-973d-7dbf-9534-2d4c829e5097@redhat.com> Message-ID: <536cfc7be4ad88d34068ee649f5c96e24f5d3959.camel@redhat.com> On Thu, 2021-03-25 at 16:21 +0000, Andrew Haley wrote: > On 3/25/21 4:00 PM, Bernhard Urban-Forster wrote: > > Bot said no :-/ https://github.com/openjdk/jdk11u/pull/2 > > Huh? It looks fine. Just to clarify. jdk11u hasn't transitioned to skara yet. jdk11u-dev will transition to it in June[1]. At that point the bots will no longer auto-close PRs. It hasn't been announced that we actually transition, unfortunately. I don't see anything beyond the proposal email, but we have had a meeting where the proposal was agreed on. Let me ask Christoph about what's up with the skara announcement for 11u. Thanks, Severin [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/004934.html From aph at redhat.com Thu Mar 25 16:42:45 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Mar 2021 16:42:45 +0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: <536cfc7be4ad88d34068ee649f5c96e24f5d3959.camel@redhat.com> References: <3dce3427-973d-7dbf-9534-2d4c829e5097@redhat.com> <536cfc7be4ad88d34068ee649f5c96e24f5d3959.camel@redhat.com> Message-ID: <339748a7-b8ce-ed94-ad93-9bf60e38d0af@redhat.com> On 3/25/21 4:30 PM, Severin Gehwolf wrote: > Just to clarify. jdk11u hasn't transitioned to skara yet. jdk11u-dev > will transition to it in June[1]. At that point the bots will no longer > auto-close PRs. Sure. I don't care if it's been auto-closed, I can still review it. -- 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 beurba at microsoft.com Thu Mar 25 21:48:35 2021 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Thu, 25 Mar 2021 21:48:35 +0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u In-Reply-To: <339748a7-b8ce-ed94-ad93-9bf60e38d0af@redhat.com> References: <3dce3427-973d-7dbf-9534-2d4c829e5097@redhat.com> <536cfc7be4ad88d34068ee649f5c96e24f5d3959.camel@redhat.com>, <339748a7-b8ce-ed94-ad93-9bf60e38d0af@redhat.com> Message-ID: > Just to clarify. jdk11u hasn't transitioned to skara yet. jdk11u-dev > will transition to it in June[1]. At that point the bots will no longer > > auto-close PRs. > > Sure. I don't care if it's been auto-closed, I can still review it. Hah, that's actually a good idea! Let's do the review feedback loop on that PR, and once finalized I can turn that into a webrev. That doesn't sound too painful to me :-) Thanks, -Bernhard ________________________________________ From: Andrew Haley Sent: Thursday, March 25, 2021 17:42 To: Severin Gehwolf; Bernhard Urban-Forster; Vladimir Kempik Cc: Anton Kozlov; aarch64-port-dev at openjdk.java.net; Monica Beckwith; jdk-updates-dev at openjdk.java.net; Magnus Ihse Bursie; openjdk-aarch64 Subject: Re: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u On 3/25/21 4:30 PM, Severin Gehwolf wrote: > Just to clarify. jdk11u hasn't transitioned to skara yet. jdk11u-dev > will transition to it in June[1]. At that point the bots will no longer > auto-close PRs. Sure. I don't care if it's been auto-closed, I can still review it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=04%7C01%7Cbeurba%40microsoft.com%7C75b981562be84529033908d8efad0888%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637522873741905341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I0HxiyMAwKx1sYxvy8%2Fs8arCVLjO0g2LFDOJKGkMPak%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dlemmond at amazon.com Thu Mar 25 21:51:12 2021 From: dlemmond at amazon.com (Lemmond, Dan) Date: Thu, 25 Mar 2021 21:51:12 +0000 Subject: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining Message-ID: <2D2975C3-22B3-41FF-8120-9081C87B90CD@amazon.com> Hello, I?d like to request a review for this backport of JDK-8059241 JBS: https://bugs.openjdk.java.net/browse/JDK-8059241 Webrev: http://cr.openjdk.java.net/~dlemmond/8059241/webrev.11u.00/ The patch applied cleanly save for the first hunk in compile.cpp which required a small fix. Hotspot successfully compiled after the patch was applied and Tier1 tests all passed. There is a small bugtail for this issue, which I?ll be sending reviews out for shortly. Thanks, Dan From yan at azul.com Fri Mar 26 07:35:04 2021 From: yan at azul.com (Yuri Nesterenko) Date: Fri, 26 Mar 2021 10:35:04 +0300 Subject: [13u notice] 13u-dev open for July 13.0.8 release Message-ID: <9e960789-b206-239a-2b06-c86ad7fbd735@azul.com> Hi, almost as planned, 13u-dev is open for 13.0.8 July 2021 release, tag 13.0.8+0 set, you are welcome! Thanks, --yan From aph at redhat.com Fri Mar 26 08:20:37 2021 From: aph at redhat.com (Andrew Haley) Date: Fri, 26 Mar 2021 08:20:37 +0000 Subject: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining In-Reply-To: <2D2975C3-22B3-41FF-8120-9081C87B90CD@amazon.com> References: <2D2975C3-22B3-41FF-8120-9081C87B90CD@amazon.com> Message-ID: On 3/25/21 9:51 PM, Lemmond, Dan wrote: > I?d like to request a review for this backport of JDK-8059241 > JBS: https://bugs.openjdk.java.net/browse/JDK-8059241 > Webrev: http://cr.openjdk.java.net/~dlemmond/8059241/webrev.11u.00/ Ouch. We'd need a C2 specialist to have a very close look at the risk of backporting this. -- 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 Fri Mar 26 08:22:42 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Mar 2021 08:22:42 +0000 Subject: [11u] Announcement: Switch to Git/Github for 11.0.13 release cycle Message-ID: Hi, I'd like to hereby officially announce the transition of OpenJDK 11 Updates to Git/Github/Skara with the 11.0.13 update release cycle. After having a call between the 11u maintainers and Skara folks, we agreed to execute upon the initial proposal [0]. So the switch of the jdk11u-dev repository should happen on or around June 2nd and jdk11u will be switched on or around August 3rd, as per the 11.0.13 schedule [1]. The Skara tooling for backport releases seems to be in good shape already and we think that by the time we start using it in 11u it will be mature enough for our purposes. In the call Erik and Robin showed the tooling for backport releases and they could positively answer the questions that we found to be still open from maintainers perspective. The JBS item for the 11u transition is https://bugs.openjdk.java.net/browse/SKARA-935. Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/004934.html [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u From rwestrel at redhat.com Fri Mar 26 09:21:06 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 26 Mar 2021 10:21:06 +0100 Subject: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining In-Reply-To: References: <2D2975C3-22B3-41FF-8120-9081C87B90CD@amazon.com> Message-ID: <87sg4iqni5.fsf@redhat.com> >> I?d like to request a review for this backport of JDK-8059241 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8059241 >> Webrev: http://cr.openjdk.java.net/~dlemmond/8059241/webrev.11u.00/ > > Ouch. We'd need a C2 specialist to have a very close look at the risk > of backporting this. This should mostly affect workloads that make heavy use of invokedynamic. That alone would decrease the risk. The fix has been integrated a while ago so it's well tested. I would say the change itself is clearly not trivial but fairly low risk. Roland. From aph at redhat.com Fri Mar 26 09:41:53 2021 From: aph at redhat.com (Andrew Haley) Date: Fri, 26 Mar 2021 09:41:53 +0000 Subject: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining In-Reply-To: <87sg4iqni5.fsf@redhat.com> References: <2D2975C3-22B3-41FF-8120-9081C87B90CD@amazon.com> <87sg4iqni5.fsf@redhat.com> Message-ID: On 3/26/21 9:21 AM, Roland Westrelin wrote: > >>> I?d like to request a review for this backport of JDK-8059241 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8059241 >>> Webrev: http://cr.openjdk.java.net/~dlemmond/8059241/webrev.11u.00/ >> >> Ouch. We'd need a C2 specialist to have a very close look at the risk >> of backporting this. > > This should mostly affect workloads that make heavy use of > invokedynamic. That alone would decrease the risk. The fix has been > integrated a while ago so it's well tested. I would say the change > itself is clearly not trivial but fairly low risk. Okay. Will you review this, please? And please consider the likely performance gain v.s churn and risk. -- 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 Fri Mar 26 10:39:34 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 26 Mar 2021 10:39:34 GMT Subject: [jdk13u-dev] RFR: 8234691: Potential double-free in ParallelSPCleanupTask constructor Message-ID: I'd like to backport JDK-8234691 to jdk13u for parity with jdk11u. The original patch applied cleanly. All regular tests passed. ------------- Commit messages: - Backport f8f698465d534af375d4f1a36b0f8d1bf12073cb Changes: https://git.openjdk.java.net/jdk13u-dev/pull/163/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=163&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234691 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/163/head:pull/163 PR: https://git.openjdk.java.net/jdk13u-dev/pull/163 From omikhaltcova at openjdk.java.net Fri Mar 26 10:54:28 2021 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 26 Mar 2021 10:54:28 GMT Subject: [jdk13u-dev] Integrated: 8234691: Potential double-free in ParallelSPCleanupTask constructor In-Reply-To: References: Message-ID: <7pvEsN-heR487lZXc66HuHgicmhFOoEizTRFbzZ_MGc=.ace6fbac-1ca7-4eb1-a32d-9bb61535e1e5@github.com> On Fri, 26 Mar 2021 10:31:22 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8234691 to jdk13u for parity with jdk11u. > The original patch applied cleanly. > All regular tests passed. This pull request has now been integrated. Changeset: 9c3e6c08 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/9c3e6c08 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod 8234691: Potential double-free in ParallelSPCleanupTask constructor Prevent extraneous constructor call Backport-of: f8f698465d534af375d4f1a36b0f8d1bf12073cb ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/163 From yan at openjdk.java.net Fri Mar 26 11:01:23 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 26 Mar 2021 11:01:23 GMT Subject: [jdk15u-dev] RFR: 8264256: Update version .jcheck/conf in jdk15u-dev to be 15.0.4 Message-ID: <7SuL6BjDTi-b441c0ResZfA4zuVWjx-mTMSCPu_kWgM=.c24ac9d7-b639-45cd-beb6-e86d2ef35c12@github.com> Instruct updater script to use 15.0.4 release version from now on. Should integrate that no sooner than the version is created in JBS. ------------- Commit messages: - 8264256: Update version .jcheck/conf in jdk15u-dev to be 15.0.4 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/1/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=1&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264256 Stats: 28 lines in 1 file changed: 26 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/1.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/1/head:pull/1 PR: https://git.openjdk.java.net/jdk15u-dev/pull/1 From yan at openjdk.java.net Fri Mar 26 11:17:43 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 26 Mar 2021 11:17:43 GMT Subject: [jdk15u-dev] RFR: 8264255: Bump update version for OpenJDK: jdk-15.0.4 Message-ID: <5UYW_DuoX_5EDdjdLLd7eLC6xqfiUTO1EkOXYZdylgU=.d1804d1d-4fdc-4b8d-9192-942bcce5010e@github.com> Once the version number 15.0.4 is created in JBS and .jcheck/conf is updated by 8264256, we should switch the current version number in make/autoconf/version-numbers ------------- Commit messages: - 8264255: Bump update version for OpenJDK: jdk-15.0.4 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/2/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=2&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264255 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/2.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/2/head:pull/2 PR: https://git.openjdk.java.net/jdk15u-dev/pull/2 From bae at openjdk.java.net Fri Mar 26 11:34:28 2021 From: bae at openjdk.java.net (Andrew Brygin) Date: Fri, 26 Mar 2021 11:34:28 GMT Subject: [jdk15u-dev] RFR: 8264255: Bump update version for OpenJDK: jdk-15.0.4 In-Reply-To: <5UYW_DuoX_5EDdjdLLd7eLC6xqfiUTO1EkOXYZdylgU=.d1804d1d-4fdc-4b8d-9192-942bcce5010e@github.com> References: <5UYW_DuoX_5EDdjdLLd7eLC6xqfiUTO1EkOXYZdylgU=.d1804d1d-4fdc-4b8d-9192-942bcce5010e@github.com> Message-ID: On Fri, 26 Mar 2021 11:12:57 GMT, Yuri Nesterenko wrote: > Once the version number 15.0.4 is created in JBS and .jcheck/conf is updated by 8264256, we should switch the current version number in make/autoconf/version-numbers Looks fine. ------------- Marked as reviewed by bae (Reviewer). PR: https://git.openjdk.java.net/jdk15u-dev/pull/2 From bae at openjdk.java.net Fri Mar 26 11:37:29 2021 From: bae at openjdk.java.net (Andrew Brygin) Date: Fri, 26 Mar 2021 11:37:29 GMT Subject: [jdk15u-dev] RFR: 8264256: Update version .jcheck/conf in jdk15u-dev to be 15.0.4 In-Reply-To: <7SuL6BjDTi-b441c0ResZfA4zuVWjx-mTMSCPu_kWgM=.c24ac9d7-b639-45cd-beb6-e86d2ef35c12@github.com> References: <7SuL6BjDTi-b441c0ResZfA4zuVWjx-mTMSCPu_kWgM=.c24ac9d7-b639-45cd-beb6-e86d2ef35c12@github.com> Message-ID: On Fri, 26 Mar 2021 10:57:49 GMT, Yuri Nesterenko wrote: > Instruct updater script to use 15.0.4 release version from now on. > Should integrate that no sooner than the version is created in JBS. Marked as reviewed by bae (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/1 From martin.doerr at sap.com Fri Mar 26 11:52:57 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 26 Mar 2021 11:52:57 +0000 Subject: [11u] RFR: 8238812: C2 crashes with SIGFPE due to a division that floats above its zero check Message-ID: Hi, JDK-8238812 is backported to 11.0.12-oracle. I'd like to backport it for parity. It applies cleanly, but the test needs a small modification: The flag StressIGVN is not available in 11u (was introduced by JDK-8252219), so I had to remove it. Bug: https://bugs.openjdk.java.net/browse/JDK-8238812 Original change: https://git.openjdk.java.net/jdk/commit/4b5be40a 11u backport: http://cr.openjdk.java.net/~mdoerr/8238812_C2_bad_AD_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Fri Mar 26 11:54:24 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 26 Mar 2021 11:54:24 +0000 Subject: [11u] RFR: 8238812: C2 crashes with SIGFPE due to a division that floats above its zero check In-Reply-To: References: Message-ID: Sorry, head line was wrong. Will resend. From: Doerr, Martin Sent: Freitag, 26. M?rz 2021 12:53 To: jdk-updates-dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' Cc: Lindenmaier, Goetz ; Langer, Christoph Subject: [11u] RFR: 8238812: C2 crashes with SIGFPE due to a division that floats above its zero check Hi, JDK-8238812 is backported to 11.0.12-oracle. I'd like to backport it for parity. It applies cleanly, but the test needs a small modification: The flag StressIGVN is not available in 11u (was introduced by JDK-8252219), so I had to remove it. Bug: https://bugs.openjdk.java.net/browse/JDK-8238812 Original change: https://git.openjdk.java.net/jdk/commit/4b5be40a 11u backport: http://cr.openjdk.java.net/~mdoerr/8238812_C2_bad_AD_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Fri Mar 26 11:55:07 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 26 Mar 2021 11:55:07 +0000 Subject: [11u] RFR: 8238812: assert(false) failed: bad AD file Message-ID: Hi, JDK-8238812 is backported to 11.0.12-oracle. I'd like to backport it for parity. It applies cleanly, but the test needs a small modification: StressIGVN is not available in 11u, so I had to remove it. Bug: https://bugs.openjdk.java.net/browse/JDK-8238812 Original change: https://git.openjdk.java.net/jdk/commit/4b5be40a 11u backport: http://cr.openjdk.java.net/~mdoerr/8238812_C2_bad_AD_11u/webrev.00/ Please review. Best regards, Martin From alexsch at openjdk.java.net Fri Mar 26 12:28:40 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 26 Mar 2021 12:28:40 GMT Subject: [jdk16u] RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be singleton Message-ID: This is the jdk16u backport of the fix for JDK-8263968. The original patch applies cleanly without modification. Tested with JCK and jtreg. ------------- Commit messages: - Backport 133a63b4a1a2ef2e4a51fdf9edac073078692f39 Changes: https://git.openjdk.java.net/jdk16u/pull/90/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=90&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263968 Stats: 22 lines in 3 files changed: 19 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk16u/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/90/head:pull/90 PR: https://git.openjdk.java.net/jdk16u/pull/90 From alexsch at openjdk.java.net Fri Mar 26 13:04:31 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 26 Mar 2021 13:04:31 GMT Subject: [jdk16u] Integrated: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be singleton In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 12:24:04 GMT, Alexander Scherbatiy wrote: > This is the jdk16u backport of the fix for JDK-8263968. The original patch applies cleanly without modification. Tested with JCK and jtreg. This pull request has now been integrated. Changeset: 5375fda6 Author: Alexander Scherbatiy URL: https://git.openjdk.java.net/jdk16u/commit/5375fda6 Stats: 22 lines in 3 files changed: 19 ins; 0 del; 3 mod 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be singleton Backport-of: 133a63b4a1a2ef2e4a51fdf9edac073078692f39 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/90 From phh at openjdk.java.net Fri Mar 26 16:29:55 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Fri, 26 Mar 2021 16:29:55 GMT Subject: [jdk16u] RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl Message-ID: Please review this backport to 16u. The backport is clean, except for syntax-only changes to catch expressions, and one context change in SSLSocketImpl.java. Original JBS: https://bugs.openjdk.java.net/browse/JDK-8259662 Original commit: https://github.com/openjdk/jdk/commit/63f8fc87 ------------- Commit messages: - 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl Changes: https://git.openjdk.java.net/jdk16u/pull/93/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=93&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259662 Stats: 204 lines in 7 files changed: 177 ins; 4 del; 23 mod Patch: https://git.openjdk.java.net/jdk16u/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/93/head:pull/93 PR: https://git.openjdk.java.net/jdk16u/pull/93 From hohensee at amazon.com Fri Mar 26 16:32:02 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 26 Mar 2021 16:32:02 +0000 Subject: [11u] Announcement: Switch to Git/Github for 11.0.13 release cycle Message-ID: Is there a wiki (or other source) on the github backport process using Skara tooling? Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Langer, Christoph" Date: Friday, March 26, 2021 at 1:23 AM To: "jdk-updates-dev at openjdk.java.net" Cc: "skara-dev at openjdk.java.net" , Erik Helin , Robin Westberg , Andrew Haley , Severin Gehwolf , "Lindenmaier, Goetz" Subject: [11u] Announcement: Switch to Git/Github for 11.0.13 release cycle Hi, I'd like to hereby officially announce the transition of OpenJDK 11 Updates to Git/Github/Skara with the 11.0.13 update release cycle. After having a call between the 11u maintainers and Skara folks, we agreed to execute upon the initial proposal [0]. So the switch of the jdk11u-dev repository should happen on or around June 2nd and jdk11u will be switched on or around August 3rd, as per the 11.0.13 schedule [1]. The Skara tooling for backport releases seems to be in good shape already and we think that by the time we start using it in 11u it will be mature enough for our purposes. In the call Erik and Robin showed the tooling for backport releases and they could positively answer the questions that we found to be still open from maintainers perspective. The JBS item for the 11u transition is https://bugs.openjdk.java.net/browse/SKARA-935. Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/004934.html [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u From hohensee at amazon.com Fri Mar 26 16:36:26 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 26 Mar 2021 16:36:26 +0000 Subject: [11u] RFR: 8238812: assert(false) failed: bad AD file Message-ID: <09285153-B75E-4CAF-A496-1B2C58E89AF1@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: hotspot-compiler-dev on behalf of "Doerr, Martin" Date: Friday, March 26, 2021 at 4:56 AM To: "jdk-updates-dev at openjdk.java.net" , "'hotspot-compiler-dev at openjdk.java.net'" Cc: "Lindenmaier, Goetz" , "Langer, Christoph" Subject: [11u] RFR: 8238812: assert(false) failed: bad AD file Hi, JDK-8238812 is backported to 11.0.12-oracle. I'd like to backport it for parity. It applies cleanly, but the test needs a small modification: StressIGVN is not available in 11u, so I had to remove it. Bug: https://bugs.openjdk.java.net/browse/JDK-8238812 Original change: https://git.openjdk.java.net/jdk/commit/4b5be40a 11u backport: http://cr.openjdk.java.net/~mdoerr/8238812_C2_bad_AD_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Fri Mar 26 16:52:16 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 26 Mar 2021 16:52:16 +0000 Subject: [11u] RFR: 8238812: assert(false) failed: bad AD file In-Reply-To: <09285153-B75E-4CAF-A496-1B2C58E89AF1@amazon.com> References: <09285153-B75E-4CAF-A496-1B2C58E89AF1@amazon.com> Message-ID: Hi Paul, thanks for the review! Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Freitag, 26. M?rz 2021 17:36 > To: Doerr, Martin ; jdk-updates- > dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' compiler-dev at openjdk.java.net> > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: RE: [11u] RFR: 8238812: assert(false) failed: bad AD file > > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: hotspot-compiler-dev retn at openjdk.java.net> on behalf of "Doerr, Martin" > > Date: Friday, March 26, 2021 at 4:56 AM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net>, "'hotspot-compiler-dev at openjdk.java.net'" > > Cc: "Lindenmaier, Goetz" , "Langer, > Christoph" > Subject: [11u] RFR: 8238812: assert(false) failed: bad AD file > > Hi, > > JDK-8238812 is backported to 11.0.12-oracle. I'd like to backport it for parity. > It applies cleanly, but the test needs a small modification: StressIGVN is not > available in 11u, so I had to remove it. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8238812 > > Original change: > https://git.openjdk.java.net/jdk/commit/4b5be40a > > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8238812_C2_bad_AD_11u/webrev.00/ > > Please review. > > Best regards, > Martin > From christoph.langer at sap.com Fri Mar 26 17:03:24 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Mar 2021 17:03:24 +0000 Subject: [11u] Announcement: Switch to Git/Github for 11.0.13 release cycle In-Reply-To: References: Message-ID: Hi, there's this: https://wiki.openjdk.java.net/display/SKARA/Backports. Maybe it is not quite "final" yet. For anybody interested in trying out the Skara backport process, you could do backports in 16u, 13u and as of today, I guess 15u, too. I'm sure the Skara team is welcoming any feedback ?? Best regards Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Freitag, 26. M?rz 2021 17:32 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: skara-dev at openjdk.java.net; erik.helin ; > robin.westberg ; aph ; > sgehwolf ; Lindenmaier, Goetz > > Subject: RE: [11u] Announcement: Switch to Git/Github for 11.0.13 release > cycle > > Is there a wiki (or other source) on the github backport process using Skara > tooling? > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of "Langer, Christoph" > Date: Friday, March 26, 2021 at 1:23 AM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Cc: "skara-dev at openjdk.java.net" , Erik > Helin , Robin Westberg > , Andrew Haley , Severin > Gehwolf , "Lindenmaier, Goetz" > > Subject: [11u] Announcement: Switch to Git/Github for 11.0.13 release cycle > > Hi, > > I'd like to hereby officially announce the transition of OpenJDK 11 Updates to > Git/Github/Skara with the 11.0.13 update release cycle. > > After having a call between the 11u maintainers and Skara folks, we agreed > to execute upon the initial proposal [0]. So the switch of the jdk11u-dev > repository should happen on or around June 2nd and jdk11u will be switched > on or around August 3rd, as per the 11.0.13 schedule [1]. > > The Skara tooling for backport releases seems to be in good shape already > and we think that by the time we start using it in 11u it will be mature enough > for our purposes. In the call Erik and Robin showed the tooling for backport > releases and they could positively answer the questions that we found to be > still open from maintainers perspective. > > The JBS item for the 11u transition is > https://bugs.openjdk.java.net/browse/SKARA-935. > > Best regards > Christoph > > [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021- > February/004934.html > [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > From clanger at openjdk.java.net Fri Mar 26 17:20:41 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 26 Mar 2021 17:20:41 GMT Subject: [jdk16u] RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 16:22:13 GMT, Paul Hohensee wrote: > Please review this backport to 16u. The backport is clean, except for syntax-only > changes to catch expressions, and one context change in SSLSocketImpl.java. > > Original JBS: https://bugs.openjdk.java.net/browse/JDK-8259662 > Original commit: https://github.com/openjdk/jdk/commit/63f8fc87 @phohensee, did you create the backport via git backport --from=openjdk/jdk 63f8fc87cdf3edb828474bb4954b76721ba8f9e5? Or the manual way described in https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-CLI ? For some reason the bots don't recognize it as a backport... You also need to request push approval via jdk16u-fix-request label in https://bugs.openjdk.java.net/browse/JDK-8259662 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/93 From dlemmond at amazon.com Fri Mar 26 17:38:40 2021 From: dlemmond at amazon.com (Lemmond, Dan) Date: Fri, 26 Mar 2021 17:38:40 +0000 Subject: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining Message-ID: <4DBB8D87-A7C8-4AF9-80CD-95226DA0E62E@amazon.com> I've applied the patches for both of the bugs in the bugtail and both of them apply cleanly. If this gets approved, they'll need to be pushed together. JBS Issues: https://bugs.openjdk.java.net/browse/JDK-8221592 https://bugs.openjdk.java.net/browse/JDK-8223581 I'll make note of this when I make the "[11u] Fix Request" comment. Roland, if you need anything from me please let me know. Thanks, Dan ?On 3/26/21, 2:42 AM, "jdk-updates-dev on behalf of Andrew Haley" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On 3/26/21 9:21 AM, Roland Westrelin wrote: > >>> I?d like to request a review for this backport of JDK-8059241 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8059241 >>> Webrev: http://cr.openjdk.java.net/~dlemmond/8059241/webrev.11u.00/ >> >> Ouch. We'd need a C2 specialist to have a very close look at the risk >> of backporting this. > > This should mostly affect workloads that make heavy use of > invokedynamic. That alone would decrease the risk. The fix has been > integrated a while ago so it's well tested. I would say the change > itself is clearly not trivial but fairly low risk. Okay. Will you review this, please? And please consider the likely performance gain v.s churn and risk. -- 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 phh at openjdk.java.net Fri Mar 26 18:14:30 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Fri, 26 Mar 2021 18:14:30 GMT Subject: [jdk16u] RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 17:17:54 GMT, Christoph Langer wrote: >> Please review this backport to 16u. The backport is clean, except for syntax-only >> changes to catch expressions, and one context change in SSLSocketImpl.java. >> >> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8259662 >> Original commit: https://github.com/openjdk/jdk/commit/63f8fc87 > > @phohensee, did you create the backport via git backport --from=openjdk/jdk 63f8fc87cdf3edb828474bb4954b76721ba8f9e5? Or the manual way described in https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-CLI ? > > For some reason the bots don't recognize it as a backport... > > You also need to request push approval via jdk16u-fix-request label in https://bugs.openjdk.java.net/browse/JDK-8259662 I did it manually (see my plaintive question!). Shall I close this PR and redo it using git backport? ------------- PR: https://git.openjdk.java.net/jdk16u/pull/93 From phh at openjdk.java.net Fri Mar 26 18:23:50 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Fri, 26 Mar 2021 18:23:50 GMT Subject: [jdk16u] RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v2] In-Reply-To: References: Message-ID: <0SbunXCMjVt2g-BCqZS5uima8nuE572RQWMsRz49HeA=.5f6ac008-e25a-4b2e-bc6e-b2ddedc055c6@github.com> > Please review this backport to 16u. The backport is clean, except for syntax-only > changes to catch expressions, and one context change in SSLSocketImpl.java. > > Original JBS: https://bugs.openjdk.java.net/browse/JDK-8259662 > Original commit: https://github.com/openjdk/jdk/commit/63f8fc87 Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: Update copyright date in SSLTransport.java ------------- Changes: - all: https://git.openjdk.java.net/jdk16u/pull/93/files - new: https://git.openjdk.java.net/jdk16u/pull/93/files/f7cb1da5..26754ab0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=93&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=93&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16u/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/93/head:pull/93 PR: https://git.openjdk.java.net/jdk16u/pull/93 From clanger at openjdk.java.net Fri Mar 26 18:26:26 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 26 Mar 2021 18:26:26 GMT Subject: [jdk16u] RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 18:11:53 GMT, Paul Hohensee wrote: > I did it manually (see my plaintive question!). Shall I close this PR and redo it using git backport? Hm, I think the commit should have had the message 'Backport 63f8fc87cdf3edb828474bb4954b76721ba8f9e5'. And probably the PR title as well. Then the bots would have recognized the backport. Maybe a force push of a squashed commit with this message would help. Or do it in another PR... ------------- PR: https://git.openjdk.java.net/jdk16u/pull/93 From phh at openjdk.java.net Fri Mar 26 18:58:31 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Fri, 26 Mar 2021 18:58:31 GMT Subject: [jdk16u] RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 18:23:16 GMT, Christoph Langer wrote: >> I did it manually (see my plaintive question!). Shall I close this PR and redo it using git backport? > >> I did it manually (see my plaintive question!). Shall I close this PR and redo it using git backport? > > Hm, I think the commit should have had the message 'Backport 63f8fc87cdf3edb828474bb4954b76721ba8f9e5'. And probably the PR title as well. Then the bots would have recognized the backport. Maybe a force push of a squashed commit with this message would help. Or do it in another PR... Closing in favor of a PR using git backport. ------------- PR: https://git.openjdk.java.net/jdk16u/pull/93 From phh at openjdk.java.net Fri Mar 26 18:58:31 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Fri, 26 Mar 2021 18:58:31 GMT Subject: [jdk16u] Withdrawn: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 16:22:13 GMT, Paul Hohensee wrote: > Please review this backport to 16u. The backport is clean, except for syntax-only > changes to catch expressions, and one context change in SSLSocketImpl.java. > > Original JBS: https://bugs.openjdk.java.net/browse/JDK-8259662 > Original commit: https://github.com/openjdk/jdk/commit/63f8fc87 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk16u/pull/93 From ilarion at azul.com Fri Mar 26 20:26:01 2021 From: ilarion at azul.com (Ilarion Nakonechnyy) Date: Fri, 26 Mar 2021 20:26:01 +0000 Subject: FW: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating proxy fails with NPE In-Reply-To: <882EC82C-4F50-4C49-BE08-4F48A00D14FE@azul.com> References: <882EC82C-4F50-4C49-BE08-4F48A00D14FE@azul.com> Message-ID: <942EE98E-1FAB-4F37-BDD3-E7A72941628F@azul.com> Dear Sirs, kindly reminder about following review request. From: Ilarion Nakonechnyy Date: Friday, 19 February 2021, 21:18 To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating proxy fails with NPE Dear sirs, I?d like to backport JDK-8236859 to JDK11. The bug causes jtreg test java/net/httpclient/websocket/WebSocketProxyTest.java to fail with timeout. Was caught on x86_64 platform, but seems that it?s platform independent. Patch applied unclear, manually merged files src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java and src/java.net.http/share/classes/jdk/internal/net/http/HttpResponseImpl.java Jdk was built on Ubuntu x86_64 and tested with tier1 Could you please review my changes? Bug: https://bugs.openjdk.java.net/browse/JDK-8236859 Webrev: http://cr.openjdk.java.net/~yan/8236859/webrev.11.0/ Original change: https://hg.openjdk.java.net/jdk/jdk/rev/ed8e7bf32188 From hohensee at amazon.com Fri Mar 26 21:08:02 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 26 Mar 2021 21:08:02 +0000 Subject: [11u] Announcement: Switch to Git/Github for 11.0.13 release cycle Message-ID: I just tried to follow the directions on the wiki. Against what repo should the backport be done, jdk16u or a personal fork of jdk16u? Based on how jdk commits work, I'd say the latter, but it's difficult for me to tell. The commit command for use after resolving conflicts seems like it should use "Backport-of" rather than "Backport". Thanks, Paul ?-----Original Message----- From: "Langer, Christoph" Date: Friday, March 26, 2021 at 10:04 AM To: "Hohensee, Paul" , "jdk-updates-dev at openjdk.java.net" Cc: "skara-dev at openjdk.java.net" , "erik.helin" , "robin.westberg" , Andrew Haley , sgehwolf , "Lindenmaier, Goetz" Subject: RE: [11u] Announcement: Switch to Git/Github for 11.0.13 release cycle Hi, there's this: https://wiki.openjdk.java.net/display/SKARA/Backports. Maybe it is not quite "final" yet. For anybody interested in trying out the Skara backport process, you could do backports in 16u, 13u and as of today, I guess 15u, too. I'm sure the Skara team is welcoming any feedback ?? Best regards Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Freitag, 26. M?rz 2021 17:32 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: skara-dev at openjdk.java.net; erik.helin ; > robin.westberg ; aph ; > sgehwolf ; Lindenmaier, Goetz > > Subject: RE: [11u] Announcement: Switch to Git/Github for 11.0.13 release > cycle > > Is there a wiki (or other source) on the github backport process using Skara > tooling? > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on > behalf of "Langer, Christoph" > Date: Friday, March 26, 2021 at 1:23 AM > To: "jdk-updates-dev at openjdk.java.net" dev at openjdk.java.net> > Cc: "skara-dev at openjdk.java.net" , Erik > Helin , Robin Westberg > , Andrew Haley , Severin > Gehwolf , "Lindenmaier, Goetz" > > Subject: [11u] Announcement: Switch to Git/Github for 11.0.13 release cycle > > Hi, > > I'd like to hereby officially announce the transition of OpenJDK 11 Updates to > Git/Github/Skara with the 11.0.13 update release cycle. > > After having a call between the 11u maintainers and Skara folks, we agreed > to execute upon the initial proposal [0]. So the switch of the jdk11u-dev > repository should happen on or around June 2nd and jdk11u will be switched > on or around August 3rd, as per the 11.0.13 schedule [1]. > > The Skara tooling for backport releases seems to be in good shape already > and we think that by the time we start using it in 11u it will be mature enough > for our purposes. In the call Erik and Robin showed the tooling for backport > releases and they could positively answer the questions that we found to be > still open from maintainers perspective. > > The JBS item for the 11u transition is > https://bugs.openjdk.java.net/browse/SKARA-935. > > Best regards > Christoph > > [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021- > February/004934.html > [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > From christoph.langer at sap.com Fri Mar 26 21:45:55 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Mar 2021 21:45:55 +0000 Subject: [11u] Announcement: Switch to Git/Github for 11.0.13 release cycle In-Reply-To: References: Message-ID: Hi, I just tried it myself: https://github.com/openjdk/jdk16u/pull/94 It was actually my first git backport where something had to be resolved. And this is what I did: 1. Went to my personal fork of jdk16u 2. git checkout -b 8259662 3. git backport --from=openjdk/jdk 63f8fc87cdf3edb828474bb4954b76721ba8f9e5 -> the backport attempted the cherry-pick and since there were conflicts it stopped in error. 4. I resolved the conflicts 5. I wondered what to do now. git cherry-pick --continue wasn't possible. git commit came up with the exact original commit message. In the Wiki instructions I however read that it should usually go like git commit -m 'Backport '... 6. After some thinking I decided for git commit -m "Backport 63f8fc87cdf3edb828474bb4954b76721ba8f9e5" 6. I created the pr with git pr create --publish So, @erik.helin and @robin.westberg, I have some feedback: I think git backport should provide some git backport --continue. And that should finish the cherry-pick and set the correct commit message in the form of "Backport ..." to be recognized by the bots. Is that possible? Otherwise there should at least be a hint like "After resolving, finish with git commit -m 'Backport '". What do you think? Paul, you can try it yourself once again, if you want. I would close my PR then. Or you can just review it, either way is fine for me ?? Best regards Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Freitag, 26. M?rz 2021 22:08 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: skara-dev at openjdk.java.net; erik.helin ; > robin.westberg ; aph ; > sgehwolf ; Lindenmaier, Goetz > > Subject: Re: [11u] Announcement: Switch to Git/Github for 11.0.13 release > cycle > > I just tried to follow the directions on the wiki. > > Against what repo should the backport be done, jdk16u or a personal fork of > jdk16u? Based on how jdk commits work, I'd say the latter, but it's difficult > for me to tell. > > The commit command for use after resolving conflicts seems like it should > use "Backport-of" rather than "Backport". > > Thanks, > Paul > > ?-----Original Message----- > From: "Langer, Christoph" > Date: Friday, March 26, 2021 at 10:04 AM > To: "Hohensee, Paul" , "jdk-updates- > dev at openjdk.java.net" > Cc: "skara-dev at openjdk.java.net" , > "erik.helin" , "robin.westberg" > , Andrew Haley , > sgehwolf , "Lindenmaier, Goetz" > > Subject: RE: [11u] Announcement: Switch to Git/Github for 11.0.13 release > cycle > > Hi, > > there's this: https://wiki.openjdk.java.net/display/SKARA/Backports. Maybe > it is not quite "final" yet. > > For anybody interested in trying out the Skara backport process, you could > do backports in 16u, 13u and as of today, I guess 15u, too. > > I'm sure the Skara team is welcoming any feedback ?? > > Best regards > Christoph > > > -----Original Message----- > > From: Hohensee, Paul > > Sent: Freitag, 26. M?rz 2021 17:32 > > To: Langer, Christoph ; jdk-updates- > > dev at openjdk.java.net > > Cc: skara-dev at openjdk.java.net; erik.helin ; > > robin.westberg ; aph ; > > sgehwolf ; Lindenmaier, Goetz > > > > Subject: RE: [11u] Announcement: Switch to Git/Github for 11.0.13 release > > cycle > > > > Is there a wiki (or other source) on the github backport process using Skara > > tooling? > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: jdk-updates-dev on > > behalf of "Langer, Christoph" > > Date: Friday, March 26, 2021 at 1:23 AM > > To: "jdk-updates-dev at openjdk.java.net" > dev at openjdk.java.net> > > Cc: "skara-dev at openjdk.java.net" , Erik > > Helin , Robin Westberg > > , Andrew Haley , > Severin > > Gehwolf , "Lindenmaier, Goetz" > > > > Subject: [11u] Announcement: Switch to Git/Github for 11.0.13 release > cycle > > > > Hi, > > > > I'd like to hereby officially announce the transition of OpenJDK 11 Updates > to > > Git/Github/Skara with the 11.0.13 update release cycle. > > > > After having a call between the 11u maintainers and Skara folks, we agreed > > to execute upon the initial proposal [0]. So the switch of the jdk11u-dev > > repository should happen on or around June 2nd and jdk11u will be > switched > > on or around August 3rd, as per the 11.0.13 schedule [1]. > > > > The Skara tooling for backport releases seems to be in good shape already > > and we think that by the time we start using it in 11u it will be mature > enough > > for our purposes. In the call Erik and Robin showed the tooling for backport > > releases and they could positively answer the questions that we found to > be > > still open from maintainers perspective. > > > > The JBS item for the 11u transition is > > https://bugs.openjdk.java.net/browse/SKARA-935. > > > > Best regards > > Christoph > > > > [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021- > > February/004934.html > > [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > > From hohensee at amazon.com Fri Mar 26 21:52:57 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 26 Mar 2021 21:52:57 +0000 Subject: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating proxy fails with NPE Message-ID: Lgtm, except in HttpResponseImpl.java, the new closeRawChannel method looks like it needs its indentation fixed. In AuthenticationFilter.java, "return null" is in the scope of "PROXY_AUTHORIZED" rather than the scope of "UNAUTHORIZED". That's what I'd expect from looking at the existing 11u code, but the original patch does more checking later on. There may be more backports that should be done to incorporate that checking. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Ilarion Nakonechnyy Date: Friday, March 26, 2021 at 1:26 PM To: "jdk-updates-dev at openjdk.java.net" Subject: FW: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating proxy fails with NPE Dear Sirs, kindly reminder about following review request. From: Ilarion Nakonechnyy Date: Friday, 19 February 2021, 21:18 To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating proxy fails with NPE Dear sirs, I?d like to backport JDK-8236859 to JDK11. The bug causes jtreg test java/net/httpclient/websocket/WebSocketProxyTest.java to fail with timeout. Was caught on x86_64 platform, but seems that it?s platform independent. Patch applied unclear, manually merged files src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java and src/java.net.http/share/classes/jdk/internal/net/http/HttpResponseImpl.java Jdk was built on Ubuntu x86_64 and tested with tier1 Could you please review my changes? Bug: https://bugs.openjdk.java.net/browse/JDK-8236859 Webrev: http://cr.openjdk.java.net/~yan/8236859/webrev.11.0/ Original change: https://hg.openjdk.java.net/jdk/jdk/rev/ed8e7bf32188 From pkumaraswamy at openjdk.java.net Mon Mar 29 06:10:49 2021 From: pkumaraswamy at openjdk.java.net (Prajwal Kumaraswamy) Date: Mon, 29 Mar 2021 06:10:49 GMT Subject: [jdk16u] RFR: 8258753: StartTlsResponse.close() hangs due to synchronization issues Message-ID: This is a clean backport of JDK-8258753 ------------- Commit messages: - Backport 415553325831b79a7e55071f6bd7c73eb1a636ec Changes: https://git.openjdk.java.net/jdk16u/pull/95/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=95&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258753 Stats: 18 lines in 1 file changed: 8 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk16u/pull/95.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/95/head:pull/95 PR: https://git.openjdk.java.net/jdk16u/pull/95 From yan at openjdk.java.net Mon Mar 29 07:05:29 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 29 Mar 2021 07:05:29 GMT Subject: [jdk15u-dev] Integrated: 8264256: Update version .jcheck/conf in jdk15u-dev to be 15.0.4 In-Reply-To: <7SuL6BjDTi-b441c0ResZfA4zuVWjx-mTMSCPu_kWgM=.c24ac9d7-b639-45cd-beb6-e86d2ef35c12@github.com> References: <7SuL6BjDTi-b441c0ResZfA4zuVWjx-mTMSCPu_kWgM=.c24ac9d7-b639-45cd-beb6-e86d2ef35c12@github.com> Message-ID: On Fri, 26 Mar 2021 10:57:49 GMT, Yuri Nesterenko wrote: > Instruct updater script to use 15.0.4 release version from now on. > Should integrate that no sooner than the version is created in JBS. This pull request has now been integrated. Changeset: 6b0f39fb Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/6b0f39fb Stats: 28 lines in 1 file changed: 26 ins; 0 del; 2 mod 8264256: Update version .jcheck/conf in jdk15u-dev to be 15.0.4 Reviewed-by: bae ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/1 From yan at openjdk.java.net Mon Mar 29 07:16:34 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 29 Mar 2021 07:16:34 GMT Subject: [jdk15u-dev] Integrated: 8264255: Bump update version for OpenJDK: jdk-15.0.4 In-Reply-To: <5UYW_DuoX_5EDdjdLLd7eLC6xqfiUTO1EkOXYZdylgU=.d1804d1d-4fdc-4b8d-9192-942bcce5010e@github.com> References: <5UYW_DuoX_5EDdjdLLd7eLC6xqfiUTO1EkOXYZdylgU=.d1804d1d-4fdc-4b8d-9192-942bcce5010e@github.com> Message-ID: On Fri, 26 Mar 2021 11:12:57 GMT, Yuri Nesterenko wrote: > Once the version number 15.0.4 is created in JBS and .jcheck/conf is updated by 8264256, we should switch the current version number in make/autoconf/version-numbers This pull request has now been integrated. Changeset: 0dd7a16f Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/0dd7a16f Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8264255: Bump update version for OpenJDK: jdk-15.0.4 Reviewed-by: bae ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/2 From coffeys at openjdk.java.net Mon Mar 29 08:17:32 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Mon, 29 Mar 2021 08:17:32 GMT Subject: [jdk16u] RFR: 8258753: StartTlsResponse.close() hangs due to synchronization issues In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 06:05:13 GMT, Prajwal Kumaraswamy wrote: > This is a clean backport of JDK-8258753 (only copyright changes differ) Looks fine Marked as reviewed by coffeys (Reviewer). ------------- Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk16u/pull/95 From martin.doerr at sap.com Mon Mar 29 09:40:45 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 29 Mar 2021 09:40:45 +0000 Subject: [11u] RFR JDK-8213231 ThreadSnapshot::_threadObj can become stale In-Reply-To: References: Message-ID: Hi Jiangli, your backport looks good. You only had to integrate manually because of unrelated changes in the context. That's fine. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Jiangli Zhou > Sent: Sonntag, 21. M?rz 2021 01:10 > To: jdk-updates-dev > Subject: [11u] RFR JDK-8213231 ThreadSnapshot::_threadObj can become > stale > > Hello, > > We recently noticed JDK-8213231 related GC crashes in production > environments when running on JDK 11. The crashes were always > associated with a stale pointer from a java.lang.management.ThreadInfo > object to a bad j.l.String object. Applying JDK-8213231's fix resolved > the specific crashes. I'd like to backport JDK-8213231 to JDK 11u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213231 > Original commit: http://hg.openjdk.java.net/jdk/jdk/rev/391d671f222b > Webrev: http://cr.openjdk.java.net/~jiangli/backport-8213231/webrev.00/ > > The patch did not apply cleanly. The following diff in > threadService.hpp were hand merged: > > --- threadService.hpp > +++ threadService.hpp > @@ -213,12 +213,15 @@ > ThreadConcurrentLocks* _concurrent_locks; > ThreadSnapshot* _next; > > -public: > - // Dummy snapshot > + // ThreadSnapshot instances should only be created via > + // ThreadDumpResult::add_thread_snapshot. > + friend class ThreadDumpResult; > ThreadSnapshot() : _thread(NULL), _threadObj(NULL), > _blocker_object(NULL), _blocker_object_owner(NULL), > _stack_trace(NULL), _concurrent_locks(NULL), > _next(NULL) {}; > - ThreadSnapshot(ThreadsList * t_list, JavaThread* thread); > + void initialize(ThreadsList * t_list, JavaThread* thread); > + > +public: > ~ThreadSnapshot(); > > Testing: Linux x86_64 tier1 tests > > Best, > Jiangli From christoph.goettschkes at microdoc.com Mon Mar 29 10:00:24 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Mon, 29 Mar 2021 12:00:24 +0200 Subject: [11u] 8207247: AARCH64: Enable Minimal and Client VM builds Message-ID: <37hw4wck0y-1@userp2050.oracle.com> Hi, could someone please sponsor this clean and already approved backport of 8207247 to 11u? Bug: https://bugs.openjdk.java.net/browse/JDK-8207247 Webrev: https://cr.openjdk.java.net/~cgo/8207247/webrev.11u.00/ Thanks, Christoph From jaroslav.bachorik at datadoghq.com Mon Mar 29 10:22:10 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 29 Mar 2021 12:22:10 +0200 Subject: [11u] RFR: 8258414: OldObjectSample events too expensive In-Reply-To: References: Message-ID: Hi Florian, a few nits: - src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp L287 - IMO, the TODO is not necessary L293 - I think the comment `// caller needs ResourceMark` should not be removed L303 - Not sure if using Module_lock instead of ClassLoaderDataGraph_lock is correct. Also, this change seems to be bringing in changes unrelated to the patch. From what is happening in other places it would seem that a safepoint should be asserted instead (or nothing should be done). I will let Markus weigh in on this. - src/hotspot/share/jfr/support/jfrAllocationTracer.cpp L38 - can this be completely removed? - src/hotspot/share/jfr/support/jfrAllocationTracer.hpp L30 - I think `class JfrThreadLocal;` can also be removed Cheers, -JB- On Wed, Mar 24, 2021 at 8:42 PM Florian David wrote: > > Hi, > > Please review this 11u backport. It's very similar to the original patch, > except for the class loader data graph lock and JfrKlassUnloading::sort() > method which are not available in 11u. > > The missing lock has been replaced by locking the module_lock instead, > as it is done in jfrcheckpointManager.cpp:363. > JfrKlassUnloading class does not exist and thus sort() method is not replaced, > I added a TODO instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258414 > webrev: http://cr.openjdk.java.net/~fdavid/8258414/webrev.00/ > Original PR: https://github.com/openjdk/jdk/pull/2780 > > Testing: > - Linux x86_64 tier1 tests > - SPECvm 2008 on a 96 cores/192 Gib server. JFR recording size is 75.12 MB before the patch and 3.08 MB after the patch. > > Let me know what you think. > > Thanks, > Florian From rwestrel at redhat.com Mon Mar 29 10:59:39 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 29 Mar 2021 12:59:39 +0200 Subject: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining In-Reply-To: <2D2975C3-22B3-41FF-8120-9081C87B90CD@amazon.com> References: <2D2975C3-22B3-41FF-8120-9081C87B90CD@amazon.com> Message-ID: <87lfa6ql7o.fsf@redhat.com> > Webrev: http://cr.openjdk.java.net/~dlemmond/8059241/webrev.11u.00/ That looks good to me. Roland. From rwestrel at redhat.com Mon Mar 29 11:03:40 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 29 Mar 2021 13:03:40 +0200 Subject: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining In-Reply-To: References: <2D2975C3-22B3-41FF-8120-9081C87B90CD@amazon.com> <87sg4iqni5.fsf@redhat.com> Message-ID: <87im5aql0z.fsf@redhat.com> > Okay. Will you review this, please? And please consider the likely > performance gain v.s churn and risk. I reviewed it. I think we would need to know what motivates the backport to make a judgement. Roland. From aph at redhat.com Mon Mar 29 14:46:12 2021 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Mar 2021 15:46:12 +0100 Subject: [11u] RFR: 8059241: C2: Excessive RemoveUseless passes during incremental inlining In-Reply-To: <87im5aql0z.fsf@redhat.com> References: <2D2975C3-22B3-41FF-8120-9081C87B90CD@amazon.com> <87sg4iqni5.fsf@redhat.com> <87im5aql0z.fsf@redhat.com> Message-ID: <4e19af2b-2411-a7e5-76bf-0561708ae630@redhat.com> On 3/29/21 12:03 PM, Roland Westrelin wrote: > >> Okay. Will you review this, please? And please consider the likely >> performance gain v.s churn and risk. > > I reviewed it. I think we would need to know what motivates the > backport to make a judgement. OK, thanks. Over to you, Dan. -- 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 jianglizhou at google.com Mon Mar 29 16:23:25 2021 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 29 Mar 2021 09:23:25 -0700 Subject: [11u] RFR JDK-8213231 ThreadSnapshot::_threadObj can become stale In-Reply-To: References: Message-ID: +jdk-updates-dev at openjdk.java.net On Mon, Mar 29, 2021 at 9:22 AM Jiangli Zhou wrote: > > Thanks, Martin. I see the backport is also approved in bugster. Plan > to submit today. > > Best, > Jiangli > > On Mon, Mar 29, 2021 at 2:40 AM Doerr, Martin wrote: > > > > Hi Jiangli, > > > > your backport looks good. You only had to integrate manually because of unrelated changes in the context. That's fine. > > > > Best regards, > > Martin > > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of Jiangli Zhou > > > Sent: Sonntag, 21. M?rz 2021 01:10 > > > To: jdk-updates-dev > > > Subject: [11u] RFR JDK-8213231 ThreadSnapshot::_threadObj can become > > > stale > > > > > > Hello, > > > > > > We recently noticed JDK-8213231 related GC crashes in production > > > environments when running on JDK 11. The crashes were always > > > associated with a stale pointer from a java.lang.management.ThreadInfo > > > object to a bad j.l.String object. Applying JDK-8213231's fix resolved > > > the specific crashes. I'd like to backport JDK-8213231 to JDK 11u. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213231 > > > Original commit: http://hg.openjdk.java.net/jdk/jdk/rev/391d671f222b > > > Webrev: http://cr.openjdk.java.net/~jiangli/backport-8213231/webrev.00/ > > > > > > The patch did not apply cleanly. The following diff in > > > threadService.hpp were hand merged: > > > > > > --- threadService.hpp > > > +++ threadService.hpp > > > @@ -213,12 +213,15 @@ > > > ThreadConcurrentLocks* _concurrent_locks; > > > ThreadSnapshot* _next; > > > > > > -public: > > > - // Dummy snapshot > > > + // ThreadSnapshot instances should only be created via > > > + // ThreadDumpResult::add_thread_snapshot. > > > + friend class ThreadDumpResult; > > > ThreadSnapshot() : _thread(NULL), _threadObj(NULL), > > > _blocker_object(NULL), _blocker_object_owner(NULL), > > > _stack_trace(NULL), _concurrent_locks(NULL), > > > _next(NULL) {}; > > > - ThreadSnapshot(ThreadsList * t_list, JavaThread* thread); > > > + void initialize(ThreadsList * t_list, JavaThread* thread); > > > + > > > +public: > > > ~ThreadSnapshot(); > > > > > > Testing: Linux x86_64 tier1 tests > > > > > > Best, > > > Jiangli From vkempik at openjdk.java.net Tue Mar 30 11:10:03 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 30 Mar 2021 11:10:03 GMT Subject: [jdk13u-dev] RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 Message-ID: Backport-of: 0257caad38b4358bd151e993b708603fce2056f2 Please review this backport of 8261397 to jdk13u-dev patch applied cleanly, but had to be changed due to missing MACOS_ONLY macro in jdk13. ------------- Commit messages: - 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/164/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=164&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261397 Stats: 33 lines in 3 files changed: 32 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/164.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/164/head:pull/164 PR: https://git.openjdk.java.net/jdk13u-dev/pull/164 From yan at openjdk.java.net Tue Mar 30 11:43:42 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 30 Mar 2021 11:43:42 GMT Subject: [jdk13u-dev] RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 11:04:22 GMT, Vladimir Kempik wrote: > Backport-of: 0257caad38b4358bd151e993b708603fce2056f2 > > Please review this backport of 8261397 to jdk13u-dev > > patch applied cleanly, but had to be changed due to missing MACOS_ONLY macro in jdk13. Somebody would need to change that in unknown future for a different emulation or a fix in Rosetta -- but not now. ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/164 From martin.doerr at sap.com Tue Mar 30 12:01:12 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 30 Mar 2021 12:01:12 +0000 Subject: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE Message-ID: Hi, JDK-8254631 is backported to 11.0.12-oracle. I'd like to backport it for parity. It applies cleanly, but the javadoc parts don't compile with 11u. They are not compatible with 11u and are documented to be dropped in the CSR (linked below). As also documented in the CSR, the old behavior can get restored by specifying the property: jdk.tls.alpnCharset=UTF-8 Bug: https://bugs.openjdk.java.net/browse/JDK-8254631 Original change: https://git.openjdk.java.net/jdk/commit/fe5cccc1 11u CSR: https://bugs.openjdk.java.net/browse/JDK-8264177 11u backport: http://cr.openjdk.java.net/~mdoerr/8254631_ALPN_11u/webrev.00/ Please review. Best regards, Martin From vkempik at openjdk.java.net Tue Mar 30 12:03:37 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 30 Mar 2021 12:03:37 GMT Subject: [jdk13u-dev] Integrated: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 11:04:22 GMT, Vladimir Kempik wrote: > Backport-of: 0257caad38b4358bd151e993b708603fce2056f2 > > Please review this backport of 8261397 to jdk13u-dev > > patch applied cleanly, but had to be changed due to missing MACOS_ONLY macro in jdk13. This pull request has now been integrated. Changeset: dff02a66 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/dff02a66 Stats: 33 lines in 3 files changed: 32 ins; 0 del; 1 mod 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 Reviewed-by: yan ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/164 From vkempik at azul.com Tue Mar 30 12:22:11 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 30 Mar 2021 12:22:11 +0000 Subject: [11u] RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 Message-ID: <2B36539B-D845-4734-BB9C-FCC536C7D3E2@azul.com> Please review this backport of 8261397 to jdk11u The fix didn?t apply cleanly due to MACOS_ONLY macro missing in jdk11. The fix is low-risk, affect only macos_x86 when running in rosetta2 translation mode on m1 mac. Checked the build with fix on m1 mac with testcase from the bug, testcase now works. The webrev - http://cr.openjdk.java.net/~vkempik/8261397/webrev.00/ The Bug - https://bugs.openjdk.java.net/browse/JDK-8261397 Regards, Vladimir From yan at azul.com Tue Mar 30 13:07:32 2021 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 30 Mar 2021 16:07:32 +0300 Subject: [15u notice] 15u-dev created in Git and open for 15.0.4 Message-ID: Hi all, note that 15u-dev team repository created in GitHub and open for 15.0.4 July 2021 release. The master 15u is still in Mercurial and will be moved to Git after the April release. Cheers! --yan From pkumaraswamy at openjdk.java.net Tue Mar 30 14:55:15 2021 From: pkumaraswamy at openjdk.java.net (Prajwal Kumaraswamy) Date: Tue, 30 Mar 2021 14:55:15 GMT Subject: [jdk16u] Integrated: 8258753: StartTlsResponse.close() hangs due to synchronization issues In-Reply-To: References: Message-ID: <72i2oPJLVRbFCeV8w8e35kcACHwDTeG0Ih-LEgYeeb8=.b6c8d771-e693-41a7-8e78-1bf0faf675d9@github.com> On Mon, 29 Mar 2021 06:05:13 GMT, Prajwal Kumaraswamy wrote: > This is a clean backport of JDK-8258753 (only copyright changes differ) This pull request has now been integrated. Changeset: 484087bd Author: Prajwal Kumaraswamy Committer: Sean Coffey URL: https://git.openjdk.java.net/jdk16u/commit/484087bd Stats: 18 lines in 1 file changed: 8 ins; 2 del; 8 mod 8258753: StartTlsResponse.close() hangs due to synchronization issues Reviewed-by: coffeys ------------- PR: https://git.openjdk.java.net/jdk16u/pull/95 From hseigel at openjdk.java.net Tue Mar 30 15:56:30 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 30 Mar 2021 15:56:30 GMT Subject: [jdk16u] Integrated: 8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION Message-ID: Backport of JDK-8261262 to JDK-16u. The patch applied cleanly and was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and tiers 3-5 on Linux x64. ------------- Commit messages: - Backport 7b9d2562abf3462da0af908b66fab98371f5946f Changes: https://git.openjdk.java.net/jdk16u/pull/96/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=96&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261262 Stats: 10 lines in 1 file changed: 0 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jdk16u/pull/96.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/96/head:pull/96 PR: https://git.openjdk.java.net/jdk16u/pull/96 From hseigel at openjdk.java.net Tue Mar 30 15:56:30 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 30 Mar 2021 15:56:30 GMT Subject: [jdk16u] Integrated: 8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 15:49:10 GMT, Harold Seigel wrote: > Backport of JDK-8261262 to JDK-16u. The patch applied cleanly and was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and tiers 3-5 on Linux x64. This pull request has now been integrated. Changeset: 566703ac Author: Harold Seigel URL: https://git.openjdk.java.net/jdk16u/commit/566703ac Stats: 10 lines in 1 file changed: 0 ins; 3 del; 7 mod 8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION Backport-of: 7b9d2562abf3462da0af908b66fab98371f5946f ------------- PR: https://git.openjdk.java.net/jdk16u/pull/96 From hseigel at openjdk.java.net Tue Mar 30 17:22:34 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 30 Mar 2021 17:22:34 GMT Subject: [jdk16u] RFR: 8263564: Consolidate POSIX code for runtime exit support: os::shutdown, os::abort and os::die Message-ID: Please review this backport of JDK-8263564 to JDK-16u. The original bug fix patch applied cleanly except for files os_linux.cpp and os_posix.cpp. But, the resulting hand merge resulted in code very similar to the original fix. After applying the patch to a JDK-16u repo and modifying the appropriate os_<..>.cpp files, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tiers 3-5 on Linux x64. ------------- Commit messages: - Backport 554dd29fb67b9a25ad161920b57e238c06024938 Changes: https://git.openjdk.java.net/jdk16u/pull/97/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=97&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263564 Stats: 210 lines in 4 files changed: 56 ins; 152 del; 2 mod Patch: https://git.openjdk.java.net/jdk16u/pull/97.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/97/head:pull/97 PR: https://git.openjdk.java.net/jdk16u/pull/97 From vkempik at openjdk.java.net Tue Mar 30 17:35:35 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 30 Mar 2021 17:35:35 GMT Subject: [jdk15u-dev] RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 Message-ID: Clean backport of 8261397 to jdk15u-dev addresses crashes of intel java in rosetta2 translator ------------- Commit messages: - Backport 0257caad38b4358bd151e993b708603fce2056f2 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/3/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=3&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261397 Stats: 30 lines in 3 files changed: 29 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/3.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/3/head:pull/3 PR: https://git.openjdk.java.net/jdk15u-dev/pull/3 From vkempik at openjdk.java.net Tue Mar 30 17:52:18 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 30 Mar 2021 17:52:18 GMT Subject: [jdk15u-dev] Integrated: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 In-Reply-To: References: Message-ID: <060ViPoYFEME2tw_uRaKh-krlwv4C_G2W-wQH-UqUEs=.033fc5a2-77d7-4158-9e8d-a14f9e88a10d@github.com> On Tue, 30 Mar 2021 17:27:47 GMT, Vladimir Kempik wrote: > Clean backport of 8261397 to jdk15u-dev > addresses crashes of intel java in rosetta2 translator This pull request has now been integrated. Changeset: 53b642ab Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk15u-dev/commit/53b642ab Stats: 30 lines in 3 files changed: 29 ins; 0 del; 1 mod 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 Backport-of: 0257caad38b4358bd151e993b708603fce2056f2 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/3 From hohensee at amazon.com Tue Mar 30 19:26:14 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 30 Mar 2021 19:26:14 +0000 Subject: [11u] RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 Message-ID: <9256EBB2-8F54-4468-97BB-41C24E664AEB@amazon.com> Needs a copyright update to 2021 in os_bsd_x86.cpp, and to 2019 in vm_version_bsd_x86.cpp. The original author forgot to update the copyright dates to 2021 in vm_version_bsd_x86.cpp and vm_version_x86.hpp, but I don't think that's our problem. Otherwise lgtm. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of Vladimir Kempik Date: Tuesday, March 30, 2021 at 5:22 AM To: jdk-updates-dev Subject: [11u] RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 Please review this backport of 8261397 to jdk11u The fix didn?t apply cleanly due to MACOS_ONLY macro missing in jdk11. The fix is low-risk, affect only macos_x86 when running in rosetta2 translation mode on m1 mac. Checked the build with fix on m1 mac with testcase from the bug, testcase now works. The webrev - http://cr.openjdk.java.net/~vkempik/8261397/webrev.00/ The Bug - https://bugs.openjdk.java.net/browse/JDK-8261397 Regards, Vladimir From dholmes at openjdk.java.net Tue Mar 30 21:54:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 30 Mar 2021 21:54:13 GMT Subject: [jdk16u] RFR: 8263564: Consolidate POSIX code for runtime exit support: os::shutdown, os::abort and os::die In-Reply-To: References: Message-ID: <2qlPBetJPhYYaKB0RXhWUkSJGG1qICP-ls9Y7ZYJ_Mc=.09bc949a-8d8e-4b77-b6c0-d01bc4b7a0e4@github.com> On Tue, 30 Mar 2021 17:17:15 GMT, Harold Seigel wrote: > Please review this backport of JDK-8263564 to JDK-16u. The original bug fix patch applied cleanly except for files os_linux.cpp and os_posix.cpp. But, the resulting hand merge resulted in code very similar to the original fix. After applying the patch to a JDK-16u repo and modifying the appropriate os_<..>.cpp files, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tiers 3-5 on Linux x64. Looks like an accurate backport. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk16u/pull/97 From yan at openjdk.java.net Wed Mar 31 07:53:31 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 31 Mar 2021 07:53:31 GMT Subject: [jdk15u-dev] RFR: 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection Message-ID: applied as clean or more as for 13u (a context copyright difference only). ------------- Commit messages: - Backport db9c114d40cd20c2854121ed8b40a7c9ef8e59b3 Changes: https://git.openjdk.java.net/jdk15u-dev/pull/4/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk15u-dev&pr=4&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-7146776 Stats: 45 lines in 2 files changed: 25 ins; 15 del; 5 mod Patch: https://git.openjdk.java.net/jdk15u-dev/pull/4.diff Fetch: git fetch https://git.openjdk.java.net/jdk15u-dev pull/4/head:pull/4 PR: https://git.openjdk.java.net/jdk15u-dev/pull/4 From bae at openjdk.java.net Wed Mar 31 08:02:17 2021 From: bae at openjdk.java.net (Andrew Brygin) Date: Wed, 31 Mar 2021 08:02:17 GMT Subject: [jdk15u-dev] RFR: 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 07:48:21 GMT, Yuri Nesterenko wrote: > applied as clean or more as for 13u (a context copyright difference only). Looks fine. ------------- Marked as reviewed by bae (Reviewer). PR: https://git.openjdk.java.net/jdk15u-dev/pull/4 From yan at openjdk.java.net Wed Mar 31 08:06:24 2021 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 31 Mar 2021 08:06:24 GMT Subject: [jdk15u-dev] Integrated: 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 07:48:21 GMT, Yuri Nesterenko wrote: > applied as clean or more as for 13u (a context copyright difference only). This pull request has now been integrated. Changeset: c2f0adb5 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk15u-dev/commit/c2f0adb5 Stats: 45 lines in 2 files changed: 25 ins; 15 del; 5 mod 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection Reviewed-by: bae Backport-of: db9c114d40cd20c2854121ed8b40a7c9ef8e59b3 ------------- PR: https://git.openjdk.java.net/jdk15u-dev/pull/4 From hseigel at openjdk.java.net Wed Mar 31 12:29:25 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 31 Mar 2021 12:29:25 GMT Subject: [jdk16u] RFR: 8263564: Consolidate POSIX code for runtime exit support: os::shutdown, os::abort and os::die In-Reply-To: <2qlPBetJPhYYaKB0RXhWUkSJGG1qICP-ls9Y7ZYJ_Mc=.09bc949a-8d8e-4b77-b6c0-d01bc4b7a0e4@github.com> References: <2qlPBetJPhYYaKB0RXhWUkSJGG1qICP-ls9Y7ZYJ_Mc=.09bc949a-8d8e-4b77-b6c0-d01bc4b7a0e4@github.com> Message-ID: On Tue, 30 Mar 2021 21:51:20 GMT, David Holmes wrote: >> Please review this backport of JDK-8263564 to JDK-16u. The original bug fix patch applied cleanly except for files os_linux.cpp and os_posix.cpp. But, the resulting hand merge resulted in code very similar to the original fix. After applying the patch to a JDK-16u repo and modifying the appropriate os_<..>.cpp files, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tiers 3-5 on Linux x64. > > Looks like an accurate backport. > > Thanks, > David Thanks David for reviewing this! ------------- PR: https://git.openjdk.java.net/jdk16u/pull/97 From hseigel at openjdk.java.net Wed Mar 31 12:29:26 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 31 Mar 2021 12:29:26 GMT Subject: [jdk16u] Integrated: 8263564: Consolidate POSIX code for runtime exit support: os::shutdown, os::abort and os::die In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 17:17:15 GMT, Harold Seigel wrote: > Please review this backport of JDK-8263564 to JDK-16u. The original bug fix patch applied cleanly except for files os_linux.cpp and os_posix.cpp. But, the resulting hand merge resulted in code very similar to the original fix. After applying the patch to a JDK-16u repo and modifying the appropriate os_<..>.cpp files, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tiers 3-5 on Linux x64. This pull request has now been integrated. Changeset: e99595bb Author: Harold Seigel URL: https://git.openjdk.java.net/jdk16u/commit/e99595bb Stats: 210 lines in 4 files changed: 56 ins; 152 del; 2 mod 8263564: Consolidate POSIX code for runtime exit support: os::shutdown, os::abort and os::die Reviewed-by: dholmes Backport-of: 554dd29fb67b9a25ad161920b57e238c06024938 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/97 From rrich at openjdk.java.net Wed Mar 31 13:07:15 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 31 Mar 2021 13:07:15 GMT Subject: [jdk16u] Integrated: 8259627: Potential memory leaks in JVMTI after JDK-8227745 In-Reply-To: <7PrjnS9-HlTCguNRev561cNUcjRceS5ixiIcLe8Fpsc=.ad9588fe-8470-41c2-a679-3986c3a9e276@github.com> References: <7PrjnS9-HlTCguNRev561cNUcjRceS5ixiIcLe8Fpsc=.ad9588fe-8470-41c2-a679-3986c3a9e276@github.com> Message-ID: On Thu, 18 Mar 2021 16:41:11 GMT, Richard Reingruber wrote: > This is the jdk16u backport of the fix for JDK-8259627. The original patch applies cleanly without modification. > > The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms This pull request has now been integrated. Changeset: 72be1e24 Author: Richard Reingruber URL: https://git.openjdk.java.net/jdk16u/commit/72be1e24 Stats: 16 lines in 1 file changed: 8 ins; 8 del; 0 mod 8259627: Potential memory leaks in JVMTI after JDK-8227745 Backport-of: 6d4a593f8d139f633e4942518059f1e2c0ab0384 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/87 From hseigel at openjdk.java.net Wed Mar 31 18:14:34 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 31 Mar 2021 18:14:34 GMT Subject: [jdk16u] Integrated: 8261916: gtest/GTestWrapper.java vmErrorTest.unimplemented1_vm_assert failed Message-ID: The patch for this JDK-16u backport of JDK-8261916 applied cleanly and was regression tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. ------------- Commit messages: - Backport 8c1112a690480340bb9d69bfaa463b5619829808 Changes: https://git.openjdk.java.net/jdk16u/pull/98/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=98&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261916 Stats: 31 lines in 2 files changed: 20 ins; 3 del; 8 mod Patch: https://git.openjdk.java.net/jdk16u/pull/98.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/98/head:pull/98 PR: https://git.openjdk.java.net/jdk16u/pull/98 From hseigel at openjdk.java.net Wed Mar 31 18:14:34 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 31 Mar 2021 18:14:34 GMT Subject: [jdk16u] Integrated: 8261916: gtest/GTestWrapper.java vmErrorTest.unimplemented1_vm_assert failed In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 18:04:49 GMT, Harold Seigel wrote: > The patch for this JDK-16u backport of JDK-8261916 applied cleanly and was regression tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. This pull request has now been integrated. Changeset: 3464a0f1 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk16u/commit/3464a0f1 Stats: 31 lines in 2 files changed: 20 ins; 3 del; 8 mod 8261916: gtest/GTestWrapper.java vmErrorTest.unimplemented1_vm_assert failed Backport-of: 8c1112a690480340bb9d69bfaa463b5619829808 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/98 From aivanov at openjdk.java.net Wed Mar 31 18:35:39 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 31 Mar 2021 18:35:39 GMT Subject: [jdk16u] Integrated: 8263311: Watch registry changes for remote printers update instead of polling Message-ID: 8263311: Watch registry changes for remote printers update instead of polling ------------- Commit messages: - 8263311: Watch registry changes for remote printers update instead of polling Changes: https://git.openjdk.java.net/jdk16u/pull/99/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=99&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263311 Stats: 207 lines in 3 files changed: 31 ins; 158 del; 18 mod Patch: https://git.openjdk.java.net/jdk16u/pull/99.diff Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/99/head:pull/99 PR: https://git.openjdk.java.net/jdk16u/pull/99 From aivanov at openjdk.java.net Wed Mar 31 18:35:39 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 31 Mar 2021 18:35:39 GMT Subject: [jdk16u] Integrated: 8263311: Watch registry changes for remote printers update instead of polling In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 18:26:17 GMT, Alexey Ivanov wrote: > 8263311: Watch registry changes for remote printers update instead of polling This pull request has now been integrated. Changeset: 31940f15 Author: Alexey Ivanov URL: https://git.openjdk.java.net/jdk16u/commit/31940f15 Stats: 207 lines in 3 files changed: 31 ins; 158 del; 18 mod 8263311: Watch registry changes for remote printers update instead of polling Backport-of: a85dc557b30f5fe8a27b265ff0fd8eba51ed0a73 ------------- PR: https://git.openjdk.java.net/jdk16u/pull/99 From beurba at microsoft.com Tue Mar 23 21:35:40 2021 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Tue, 23 Mar 2021 21:35:40 -0000 Subject: JDK-8253947: JEP 388 Windows/AArch64 backport to jdk11u Message-ID: Hello, Spinning off the discussion from here: https://github.com/openjdk/jdk/pull/2200#issuecomment-804927150 And further context, there have been some discussions about it before: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-October/009727.html Open questions: 1. JEP 391 (macOS/AArch64) has a dependency on JEP 388, and I'm assuming we want both to be backported. Question: Is it preferred to do it one go (both together), or should we do it separately (that would be Windows first, then macOS)? 2. JEP 388 includes build changes to add cross compilation support for Windows in a hacky way. It's enough to get a build out of it [1], but it's not exactly clean. It was eventually cleaned up with the "WINENV" patch by Magnus [2], but imho it isn't trivial to backport that change. Thoughts? Assuming the answer to question 1 is to split the backports: I think https://github.com/openjdk/aarch64-port/tree/jdk11-windows by Ludovic is in an okay shape, but I will take it for a spin tomorrow and then submit an initial PR against https://github.com/openjdk/jdk11u Thank you, -Bernhard [1] with workarounds: https://github.com/openjdk/jdk/pull/212#issuecomment-695024586 [2] https://github.com/openjdk/jdk/pull/1597