From christoph.langer at sap.com Mon Nov 2 08:00:42 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 2 Nov 2020 08:00:42 +0000 Subject: [11u] Respin of JDK 11.0.9 with JDK-8250861 and JDK-8255603 -> 11.0.9.1 In-Reply-To: <4ff2839dcb37c16694c85cf943961498446db38c.camel@redhat.com> References: <4ff2839dcb37c16694c85cf943961498446db38c.camel@redhat.com> Message-ID: Hi Severin, > Here are my thoughts: > > JDK-8250861 is a regression introduced in 11.0.9 and a serious crasher > bug in c2. If consensus is to fix it with an async update to 11.0.9, > then we should do the same for 8u272 (and possibly JDK 13). It looks > like for JDK 15 it'll end up in 15.0.2. Just some more data points :) > > As to JDK-8255603, my preference would be to defer to 11.0.10. While > the fix seems benign, it appears nobody noticed this until very > recently. 11.0.5 got out in October 2019. There is a known work-around. > At least it seems strange to rush this fix now, where it's been out in > the wild for about a year. I concur. So for the OpenJDK 11.0.9 respin we'll only take JDK-8250861 then. We'll probably cherry-pick JDK-8255603 to our downstream SapMachine 11.0.9.1 build since we have a customer case. But such a decision can obviously be made at downstream vendor's discretion. Best regards Christoph > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8250861 > > [1] https://bugs.openjdk.java.net/browse/JDK-8255603 > > [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > October/004055.html > > From sgehwolf at redhat.com Mon Nov 2 14:15:22 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Nov 2020 15:15:22 +0100 Subject: [11u] RFR: 8254854: [cgroups v1] Metric limits not properly detected on some join controller combinations Message-ID: <35c454521f74847ad00defad2a3f6a4130954000.camel@redhat.com> Hi, Could I please get a review for this follow-up fix to JDK-8217766 which is in OpenJDK 11 since 11.0.5. The fix for JDK-8217766 was incomplete. The JDK 15 patch didn't apply cleanly due to no cgroups v2 support in JDK 11u. I've basically reworked the patch for 11u. The port was fairly straight-forward, though. 1) Changes in src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java needed to be done in src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java 2) Function names changed from setSubSystemControllerPath() JDK 15+ to setSubSystemPath() in JDK 11. Bug: https://bugs.openjdk.java.net/browse/JDK-8254854 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8254854/01/webrev/ Testing: tier 1 and Linux container tests on x86_64 (cgroups v1); manual testing of the fix[1] Thoughts? Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8254854?focusedCommentId=14377579&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14377579 From kemperw at amazon.com Mon Nov 2 17:54:26 2020 From: kemperw at amazon.com (Kemper, William) Date: Mon, 2 Nov 2020 17:54:26 +0000 Subject: [11u] RFR 8255269: Unsigned overflow in g1Policy.cpp Message-ID: <1604339666029.33147@amazon.com> Hello. I'd like to request a review to backport this simple fix to jdk11u. Original issue: https://bugs.openjdk.java.net/browse/JDK-8255269 Webrev: http://cr.openjdk.java.net/~phh/8255269/webrev.11u.02/? Thank you, William From goetz.lindenmaier at sap.com Mon Nov 2 19:47:59 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 2 Nov 2020 19:47:59 +0000 Subject: [11u] RFR: 8255781: Bump patch update version for OpenJDK: jdk-11.0.9.1 Message-ID: Hi, As decided in this mail thread, I'll bump the version of jdk-updates/jdk11u to 11.0.9.1. I'll push this change and the fix latest on Wednesday, Nov 4th. I'll add corresponding tags, too. Please review. http://cr.openjdk.java.net/~goetz/wr20/8255781-Bump_version_11.0.9.1-jdk11/01/ Best regards, Goetz. From christoph.langer at sap.com Tue Nov 3 13:19:42 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 3 Nov 2020 13:19:42 +0000 Subject: [11u] RFR: 8255781: Bump patch update version for OpenJDK: jdk-11.0.9.1 In-Reply-To: References: Message-ID: Hi Goetz, this looks correct to me. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 2. November 2020 20:48 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 8255781: Bump patch update version for > OpenJDK: jdk-11.0.9.1 > > Hi, > > As decided in this mail thread, I'll bump the version of jdk-updates/jdk11u to > 11.0.9.1. > I'll push this change and the fix latest on Wednesday, Nov 4th. I'll add > corresponding tags, too. > > Please review. > > http://cr.openjdk.java.net/~goetz/wr20/8255781-Bump_version_11.0.9.1- > jdk11/01/ > > Best regards, > Goetz. From yan at openjdk.java.net Tue Nov 3 14:05:06 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 3 Nov 2020 14:05:06 GMT Subject: [jdk13u-dev] RFR: 8229378: jdwp library loader in linker_md.c quietly truncates on buffer overflow Message-ID: This should be a clean backport. ------------- Commit messages: - Backport d57af047374f29e96ebe78de165a0dd8c6a41d03 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/7/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=7&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8229378 Stats: 40 lines in 2 files changed: 20 ins; 12 del; 8 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/7.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/7/head:pull/7 PR: https://git.openjdk.java.net/jdk13u-dev/pull/7 From github.com+71385633+kvergizova at openjdk.java.net Tue Nov 3 14:44:15 2020 From: github.com+71385633+kvergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 3 Nov 2020 14:44:15 GMT Subject: [jdk13u-dev] RFR: 8226575: OperatingSystemMXBean should be made container aware Message-ID: The patch applies cleanly, but it requires some modifications. The original patch added new methods to OperatingSystemMXBean according to CSR JDK-8228428. Backporting them to 13u is not suitable. Similar to 11u/8u, existing methods have been changed to return the container values instead. CSR for 13u is filed: JDK-8255834, it's similar to 11u/8u CSR JDK-8248804. Tested with tier1 and container tests on Linux and Windows, the only failure is containers/docker/TestMemoryAwareness.java which is fixed by follow-up JDK-8236617, the plan is to push them together. ------------- Commit messages: - Backport 7b82266a159ce363708e347aba7e1b0d38206b48 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/8/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=8&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8226575 Stats: 347 lines in 12 files changed: 323 ins; 2 del; 22 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/8.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/8/head:pull/8 PR: https://git.openjdk.java.net/jdk13u-dev/pull/8 From yan at openjdk.java.net Tue Nov 3 14:49:58 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 3 Nov 2020 14:49:58 GMT Subject: [jdk13u-dev] RFR: 8229378: jdwp library loader in linker_md.c quietly truncates on buffer overflow In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 13:57:31 GMT, Yuri Nesterenko wrote: > This should be a clean backport. Please don't review it yet! I'm waiting for an answer how to configure the repository to allow pushing of such a fix without extra reviewers. ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/7 From goetz.lindenmaier at sap.com Tue Nov 3 15:39:19 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 3 Nov 2020 15:39:19 +0000 Subject: [11u communication] tag 11.0.10+1 Message-ID: Hi, The plan for jdk-11.0.10 says that today 11.0.10 is merged to jdk11u and tag 11.0.10+1 is pushed. See the 11.0.10 timeline here: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u As we want to use jdk11u for preparation of 11.0.9.1, I will delay pulling 11.0.10+1 to jdk11u until 11.0.9.1 is ga. For now, I will push tag 11.0.10+1 in jdk11u-dev, only. Best regards, Goetz. From hohensee at amazon.com Tue Nov 3 19:04:26 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 3 Nov 2020 19:04:26 +0000 Subject: [11u] RFR 8255269: Unsigned overflow in g1Policy.cpp In-Reply-To: <1604339666029.33147@amazon.com> References: <1604339666029.33147@amazon.com> Message-ID: <3463446D-C5F3-4F08-82C0-0F8EB84EA72B@amazon.com> Hi, William. The patch should be based on the original 13u one, which you can get using one of the Skara CLI tools, ?git hg-export ?. That patch comes with a copyright year change that?s missing from your webrev. Please also describe what tests you?ve run. These could be the hotspot gc tests (test/hotspot/jtreg/gc) and a more general one such as tier1. You can run these using, e.g., make run-test TEST=?test/hotspot/jtreg/gc? make run-test TEST=tier1 Thanks, Paul From: "Kemper, William" Date: Monday, November 2, 2020 at 9:54 AM To: "jdk-updates-dev at openjdk.java.net" Subject: [11u] RFR 8255269: Unsigned overflow in g1Policy.cpp Hello. I'd like to request a review to backport this simple fix to jdk11u. Original issue: https://bugs.openjdk.java.net/browse/JDK-8255269 Webrev: http://cr.openjdk.java.net/~phh/8255269/webrev.11u.02/? Thank you, William From kemperw at amazon.com Wed Nov 4 01:22:27 2020 From: kemperw at amazon.com (Kemper, William) Date: Wed, 4 Nov 2020 01:22:27 +0000 Subject: [11u] RFR 8255269: Unsigned overflow in g1Policy.cpp Message-ID: <5198514db2aa46e5985adcc28b1856c5@EX13D17UWB001.ant.amazon.com> Here's a patch based on jdk13u using the Skara CLI tools: git hg-export 7e95c0a5 # HG changeset patch # User phh # Date 1603811625 0 # Tue Oct 15:13:45 2020 +0000 8255269: Unsigned overflow in g1Policy.cpp Reviewed-by: yan Contributed-by: William Kemper > diff --git a/src/hotspot/share/gc/g1/g1Policy.cpp b/src/hotspot/share/gc/g1/g1Policy.cpp index 91eceb7375..dec7f57de6 100644 --- a/src/hotspot/share/gc/g1/g1Policy.cpp +++ b/src/hotspot/share/gc/g1/g1Policy.cpp @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -692,11 +692,11 @@ void G1Policy::record_collection_pause_end(double pause_time_ms, size_t cards_sc _analytics->report_rs_length_diff((double) rs_length_diff); size_t freed_bytes = heap_used_bytes_before_gc - cur_used_bytes; - size_t copied_bytes = _collection_set->bytes_used_before() - freed_bytes; - double cost_per_byte_ms = 0.0; - if (copied_bytes > 0) { - cost_per_byte_ms = (average_time_ms(G1GCPhaseTimes::ObjCopy) + average_time_ms(G1GCPhaseTimes::OptObjCopy)) / (double) copied_bytes; + if (_collection_set->bytes_used_before() > freed_bytes) { + size_t copied_bytes = _collection_set->bytes_used_before() - freed_bytes; + double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy); + double cost_per_byte_ms = average_copy_time / (double) copied_bytes; _analytics->report_cost_per_byte_ms(cost_per_byte_ms, collector_state()->mark_or_rebuild_in_progress()); } I ran the jtreg tests for G1 against the release build on my workstation (x86, Ubuntu 18.04). The results were the same before and after the patch was applied: test/hotspot/jtreg/gc/g1 Test results: passed: 56; failed: 4; error: 1 It doesn't look like the failures and error have anything to do with this change. Thanks, William From sgehwolf at redhat.com Wed Nov 4 09:21:42 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 04 Nov 2020 10:21:42 +0100 Subject: [11u] RFR: 8255781: Bump patch update version for OpenJDK: jdk-11.0.9.1 In-Reply-To: References: Message-ID: <05190c14f5d5ff748fc47a7474f3dc2eae3da707.camel@redhat.com> On Mon, 2020-11-02 at 19:47 +0000, Lindenmaier, Goetz wrote: > Hi, > > As decided in this mail thread, I'll bump the version of jdk-updates/jdk11u to 11.0.9.1. > I'll push this change and the fix latest on Wednesday, Nov 4th. I'll add corresponding tags, too. > > Please review. > > http://cr.openjdk.java.net/~goetz/wr20/8255781-Bump_version_11.0.9.1-jdk11/01/ What's the tag and build number going to be? I take it something like this? Tag(s): jdk-11.0.9.1+1 jdk-11.0.9.1-ga (pointing to jdk-11.0.9.1+1) Thus, build number 1. Thoughts? Thanks, Severin From goetz.lindenmaier at sap.com Wed Nov 4 09:33:53 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 4 Nov 2020 09:33:53 +0000 Subject: [11u] RFR: 8255781: Bump patch update version for OpenJDK: jdk-11.0.9.1 In-Reply-To: <05190c14f5d5ff748fc47a7474f3dc2eae3da707.camel@redhat.com> References: <05190c14f5d5ff748fc47a7474f3dc2eae3da707.camel@redhat.com> Message-ID: Hi Severin, Yes, and there will be a 11.0.9.1+0. Best regards, Goetz. > -----Original Message----- > From: Severin Gehwolf > Sent: Wednesday, November 4, 2020 10:22 AM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8255781: Bump patch update version for OpenJDK: > jdk-11.0.9.1 > > On Mon, 2020-11-02 at 19:47 +0000, Lindenmaier, Goetz wrote: > > Hi, > > > > As decided in this mail thread, I'll bump the version of jdk-updates/jdk11u > to 11.0.9.1. > > I'll push this change and the fix latest on Wednesday, Nov 4th. I'll add > corresponding tags, too. > > > > Please review. > > > > http://cr.openjdk.java.net/~goetz/wr20/8255781-Bump_version_11.0.9.1- > jdk11/01/ > > What's the tag and build number going to be? I take it something like > this? > > Tag(s): > jdk-11.0.9.1+1 > jdk-11.0.9.1-ga (pointing to jdk-11.0.9.1+1) > > Thus, build number 1. > > Thoughts? > > Thanks, > Severin From goetz.lindenmaier at sap.com Wed Nov 4 09:34:14 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 4 Nov 2020 09:34:14 +0000 Subject: [11u] RFR: 8255781: Bump patch update version for OpenJDK: jdk-11.0.9.1 In-Reply-To: References: Message-ID: Hi Christoph, Thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Tuesday, November 3, 2020 2:20 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8255781: Bump patch update version for OpenJDK: > jdk-11.0.9.1 > > Hi Goetz, > > this looks correct to me. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Montag, 2. November 2020 20:48 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR: 8255781: Bump patch update version for > > OpenJDK: jdk-11.0.9.1 > > > > Hi, > > > > As decided in this mail thread, I'll bump the version of jdk-updates/jdk11u > to > > 11.0.9.1. > > I'll push this change and the fix latest on Wednesday, Nov 4th. I'll add > > corresponding tags, too. > > > > Please review. > > > > http://cr.openjdk.java.net/~goetz/wr20/8255781-Bump_version_11.0.9.1- > > jdk11/01/ > > > > Best regards, > > Goetz. From sgehwolf at redhat.com Wed Nov 4 09:43:40 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 04 Nov 2020 10:43:40 +0100 Subject: [11u] RFR: 8255781: Bump patch update version for OpenJDK: jdk-11.0.9.1 In-Reply-To: References: <05190c14f5d5ff748fc47a7474f3dc2eae3da707.camel@redhat.com> Message-ID: <73375cc7fbc10ec3d00a8e4822039ca69cdb3519.camel@redhat.com> On Wed, 2020-11-04 at 09:33 +0000, Lindenmaier, Goetz wrote: > Hi Severin, > > Yes, and there will be a 11.0.9.1+0. Why not 11.0.9.1+1? We've never had a build zero other than for branch points. Are you saying there will be 11.0.9.1+0 and 11.0.9.1+1? Thanks, Severin > Best regards, > Goetz. > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Wednesday, November 4, 2020 10:22 AM > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: Re: [11u] RFR: 8255781: Bump patch update version for > > OpenJDK: > > jdk-11.0.9.1 > > > > On Mon, 2020-11-02 at 19:47 +0000, Lindenmaier, Goetz wrote: > > > Hi, > > > > > > As decided in this mail thread, I'll bump the version of jdk- > > > updates/jdk11u > > to 11.0.9.1. > > > I'll push this change and the fix latest on Wednesday, Nov 4th. > > > I'll add > > corresponding tags, too. > > > Please review. > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8255781-Bump_version_11.0.9.1- > > jdk11/01/ > > > > What's the tag and build number going to be? I take it something > > like > > this? > > > > Tag(s): > > jdk-11.0.9.1+1 > > jdk-11.0.9.1-ga (pointing to jdk-11.0.9.1+1) > > > > Thus, build number 1. > > > > Thoughts? > > > > Thanks, > > Severin From goetz.lindenmaier at sap.com Wed Nov 4 11:06:43 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 4 Nov 2020 11:06:43 +0000 Subject: [11u] RFR: 8255781: Bump patch update version for OpenJDK: jdk-11.0.9.1 In-Reply-To: <73375cc7fbc10ec3d00a8e4822039ca69cdb3519.camel@redhat.com> References: <05190c14f5d5ff748fc47a7474f3dc2eae3da707.camel@redhat.com> <73375cc7fbc10ec3d00a8e4822039ca69cdb3519.camel@redhat.com> Message-ID: > Are you saying there will be 11.0.9.1+0 and 11.0.9.1+1? Yes ?? It's a branch point, isn't it? Best regards, Goetz. > -----Original Message----- > From: Severin Gehwolf > Sent: Wednesday, November 4, 2020 10:44 AM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8255781: Bump patch update version for OpenJDK: > jdk-11.0.9.1 > > On Wed, 2020-11-04 at 09:33 +0000, Lindenmaier, Goetz wrote: > > Hi Severin, > > > > Yes, and there will be a 11.0.9.1+0. > > Why not 11.0.9.1+1? We've never had a build zero other than for branch > points. Are you saying there will be 11.0.9.1+0 and 11.0.9.1+1? > > Thanks, > Severin > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: Severin Gehwolf > > > Sent: Wednesday, November 4, 2020 10:22 AM > > > To: Lindenmaier, Goetz ; jdk-updates- > > > dev at openjdk.java.net > > > Subject: Re: [11u] RFR: 8255781: Bump patch update version for > > > OpenJDK: > > > jdk-11.0.9.1 > > > > > > On Mon, 2020-11-02 at 19:47 +0000, Lindenmaier, Goetz wrote: > > > > Hi, > > > > > > > > As decided in this mail thread, I'll bump the version of jdk- > > > > updates/jdk11u > > > to 11.0.9.1. > > > > I'll push this change and the fix latest on Wednesday, Nov 4th. > > > > I'll add > > > corresponding tags, too. > > > > Please review. > > > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8255781- > Bump_version_11.0.9.1- > > > jdk11/01/ > > > > > > What's the tag and build number going to be? I take it something > > > like > > > this? > > > > > > Tag(s): > > > jdk-11.0.9.1+1 > > > jdk-11.0.9.1-ga (pointing to jdk-11.0.9.1+1) > > > > > > Thus, build number 1. > > > > > > Thoughts? > > > > > > Thanks, > > > Severin From sgehwolf at redhat.com Wed Nov 4 14:02:21 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 04 Nov 2020 15:02:21 +0100 Subject: [11u] RFR: 8255781: Bump patch update version for OpenJDK: jdk-11.0.9.1 In-Reply-To: References: <05190c14f5d5ff748fc47a7474f3dc2eae3da707.camel@redhat.com> <73375cc7fbc10ec3d00a8e4822039ca69cdb3519.camel@redhat.com> Message-ID: On Wed, 2020-11-04 at 11:06 +0000, Lindenmaier, Goetz wrote: > > Are you saying there will be 11.0.9.1+0 and 11.0.9.1+1? > Yes ?? :) > It's a branch point, isn't it? Sorry, mea culpa. I failed to recognize the "and" in "... and there will be a 11.0.9.1+0". Nevermind me. Thanks, Severin > Best regards, > Goetz. > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Wednesday, November 4, 2020 10:44 AM > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: Re: [11u] RFR: 8255781: Bump patch update version for OpenJDK: > > jdk-11.0.9.1 > > > > On Wed, 2020-11-04 at 09:33 +0000, Lindenmaier, Goetz wrote: > > > Hi Severin, > > > > > > Yes, and there will be a 11.0.9.1+0. > > > > Why not 11.0.9.1+1? We've never had a build zero other than for branch > > points. Are you saying there will be 11.0.9.1+0 and 11.0.9.1+1? > > > > Thanks, > > Severin > > > > > Best regards, > > > Goetz. > > > > > > > -----Original Message----- > > > > From: Severin Gehwolf > > > > Sent: Wednesday, November 4, 2020 10:22 AM > > > > To: Lindenmaier, Goetz ; jdk-updates- > > > > dev at openjdk.java.net > > > > Subject: Re: [11u] RFR: 8255781: Bump patch update version for > > > > OpenJDK: > > > > jdk-11.0.9.1 > > > > > > > > On Mon, 2020-11-02 at 19:47 +0000, Lindenmaier, Goetz wrote: > > > > > Hi, > > > > > > > > > > As decided in this mail thread, I'll bump the version of jdk- > > > > > updates/jdk11u > > > > to 11.0.9.1. > > > > > I'll push this change and the fix latest on Wednesday, Nov 4th. > > > > > I'll add > > > > corresponding tags, too. > > > > > Please review. > > > > > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8255781- > > Bump_version_11.0.9.1- > > > > jdk11/01/ > > > > > > > > What's the tag and build number going to be? I take it something > > > > like > > > > this? > > > > > > > > Tag(s): > > > > jdk-11.0.9.1+1 > > > > jdk-11.0.9.1-ga (pointing to jdk-11.0.9.1+1) > > > > > > > > Thus, build number 1. > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Severin From hohensee at amazon.com Wed Nov 4 16:18:01 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 4 Nov 2020 16:18:01 +0000 Subject: [11u] RFR 8255269: Unsigned overflow in g1Policy.cpp In-Reply-To: <5198514db2aa46e5985adcc28b1856c5@EX13D17UWB001.ant.amazon.com> References: <5198514db2aa46e5985adcc28b1856c5@EX13D17UWB001.ant.amazon.com> Message-ID: <8570056C-66CE-405B-831A-70EA10DBBC3C@amazon.com> Thanks, lgtm now. I'll tag the issue. Paul ?On 11/3/20, 5:23 PM, "jdk-updates-dev on behalf of Kemper, William" wrote: Here's a patch based on jdk13u using the Skara CLI tools: git hg-export 7e95c0a5 # HG changeset patch # User phh # Date 1603811625 0 # Tue Oct 15:13:45 2020 +0000 8255269: Unsigned overflow in g1Policy.cpp Reviewed-by: yan Contributed-by: William Kemper > diff --git a/src/hotspot/share/gc/g1/g1Policy.cpp b/src/hotspot/share/gc/g1/g1Policy.cpp index 91eceb7375..dec7f57de6 100644 --- a/src/hotspot/share/gc/g1/g1Policy.cpp +++ b/src/hotspot/share/gc/g1/g1Policy.cpp @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -692,11 +692,11 @@ void G1Policy::record_collection_pause_end(double pause_time_ms, size_t cards_sc _analytics->report_rs_length_diff((double) rs_length_diff); size_t freed_bytes = heap_used_bytes_before_gc - cur_used_bytes; - size_t copied_bytes = _collection_set->bytes_used_before() - freed_bytes; - double cost_per_byte_ms = 0.0; - if (copied_bytes > 0) { - cost_per_byte_ms = (average_time_ms(G1GCPhaseTimes::ObjCopy) + average_time_ms(G1GCPhaseTimes::OptObjCopy)) / (double) copied_bytes; + if (_collection_set->bytes_used_before() > freed_bytes) { + size_t copied_bytes = _collection_set->bytes_used_before() - freed_bytes; + double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy); + double cost_per_byte_ms = average_copy_time / (double) copied_bytes; _analytics->report_cost_per_byte_ms(cost_per_byte_ms, collector_state()->mark_or_rebuild_in_progress()); } I ran the jtreg tests for G1 against the release build on my workstation (x86, Ubuntu 18.04). The results were the same before and after the patch was applied: test/hotspot/jtreg/gc/g1 Test results: passed: 56; failed: 4; error: 1 It doesn't look like the failures and error have anything to do with this change. Thanks, William From johnc at azul.com Wed Nov 4 16:51:12 2020 From: johnc at azul.com (John Cuthbertson) Date: Wed, 4 Nov 2020 16:51:12 +0000 Subject: [11u] RFR 8255269: Unsigned overflow in g1Policy.cpp In-Reply-To: <8570056C-66CE-405B-831A-70EA10DBBC3C@amazon.com> References: <5198514db2aa46e5985adcc28b1856c5@EX13D17UWB001.ant.amazon.com> <8570056C-66CE-405B-831A-70EA10DBBC3C@amazon.com> Message-ID: <9A834BBF-587D-466E-9E07-B7A5EF934F3E@azul.com> Hi William, Paul, Does this patch have the same issue as before ? the missed 'average_time_ms(G1GCPhaseTimes::OptObjCopy)? term in the calculation of average_copy_time? Will that be resolved by back porting Paul?s fix? JohnC > On Nov 4, 2020, at 8:18 AM, Hohensee, Paul wrote: > > Thanks, lgtm now. I'll tag the issue. > > Paul > > ?On 11/3/20, 5:23 PM, "jdk-updates-dev on behalf of Kemper, William" wrote: > > Here's a patch based on jdk13u using the Skara CLI tools: > > git hg-export 7e95c0a5 > # HG changeset patch > # User phh > # Date 1603811625 0 > # Tue Oct 15:13:45 2020 +0000 > 8255269: Unsigned overflow in g1Policy.cpp > Reviewed-by: yan > Contributed-by: William Kemper > > > diff --git a/src/hotspot/share/gc/g1/g1Policy.cpp b/src/hotspot/share/gc/g1/g1Policy.cpp > index 91eceb7375..dec7f57de6 100644 > --- a/src/hotspot/share/gc/g1/g1Policy.cpp > +++ b/src/hotspot/share/gc/g1/g1Policy.cpp > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -692,11 +692,11 @@ void G1Policy::record_collection_pause_end(double pause_time_ms, size_t cards_sc > _analytics->report_rs_length_diff((double) rs_length_diff); > > size_t freed_bytes = heap_used_bytes_before_gc - cur_used_bytes; > - size_t copied_bytes = _collection_set->bytes_used_before() - freed_bytes; > - double cost_per_byte_ms = 0.0; > > - if (copied_bytes > 0) { > - cost_per_byte_ms = (average_time_ms(G1GCPhaseTimes::ObjCopy) + average_time_ms(G1GCPhaseTimes::OptObjCopy)) / (double) copied_bytes; > + if (_collection_set->bytes_used_before() > freed_bytes) { > + size_t copied_bytes = _collection_set->bytes_used_before() - freed_bytes; > + double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy); > + double cost_per_byte_ms = average_copy_time / (double) copied_bytes; > _analytics->report_cost_per_byte_ms(cost_per_byte_ms, collector_state()->mark_or_rebuild_in_progress()); > } > > I ran the jtreg tests for G1 against the release build on my workstation (x86, Ubuntu 18.04). The results were the same before and after the patch was applied: > > test/hotspot/jtreg/gc/g1 > Test results: passed: 56; failed: 4; error: 1 > > It doesn't look like the failures and error have anything to do with this change. > > Thanks, > William > From kemperw at amazon.com Wed Nov 4 17:04:35 2020 From: kemperw at amazon.com (Kemper, William) Date: Wed, 4 Nov 2020 17:04:35 +0000 Subject: [11u] RFR 8255269: Unsigned overflow in g1Policy.cpp In-Reply-To: <9A834BBF-587D-466E-9E07-B7A5EF934F3E@azul.com> References: <5198514db2aa46e5985adcc28b1856c5@EX13D17UWB001.ant.amazon.com> <8570056C-66CE-405B-831A-70EA10DBBC3C@amazon.com>, <9A834BBF-587D-466E-9E07-B7A5EF934F3E@azul.com> Message-ID: <1604509475536.1680@amazon.com> G1GCPhaseTimes::OptObjCopy was added in 13 during a larger refactoring effort (https://bugs.openjdk.java.net/browse/JDK-8218668). This enum value doesn't exist in 11 so it's expected that it's not used in the patch for 11. Thanks, William ________________________________________ From: John Cuthbertson Sent: Wednesday, November 4, 2020 8:51 AM To: Hohensee, Paul Cc: Kemper, William; jdk-updates-dev at openjdk.java.net Subject: RE: [EXTERNAL] [11u] RFR 8255269: Unsigned overflow in g1Policy.cpp 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 William, Paul, Does this patch have the same issue as before ? the missed 'average_time_ms(G1GCPhaseTimes::OptObjCopy)? term in the calculation of average_copy_time? Will that be resolved by back porting Paul?s fix? JohnC > On Nov 4, 2020, at 8:18 AM, Hohensee, Paul wrote: > > Thanks, lgtm now. I'll tag the issue. > > Paul > > ?On 11/3/20, 5:23 PM, "jdk-updates-dev on behalf of Kemper, William" wrote: > > Here's a patch based on jdk13u using the Skara CLI tools: > > git hg-export 7e95c0a5 > # HG changeset patch > # User phh > # Date 1603811625 0 > # Tue Oct 15:13:45 2020 +0000 > 8255269: Unsigned overflow in g1Policy.cpp > Reviewed-by: yan > Contributed-by: William Kemper > > > diff --git a/src/hotspot/share/gc/g1/g1Policy.cpp b/src/hotspot/share/gc/g1/g1Policy.cpp > index 91eceb7375..dec7f57de6 100644 > --- a/src/hotspot/share/gc/g1/g1Policy.cpp > +++ b/src/hotspot/share/gc/g1/g1Policy.cpp > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -692,11 +692,11 @@ void G1Policy::record_collection_pause_end(double pause_time_ms, size_t cards_sc > _analytics->report_rs_length_diff((double) rs_length_diff); > > size_t freed_bytes = heap_used_bytes_before_gc - cur_used_bytes; > - size_t copied_bytes = _collection_set->bytes_used_before() - freed_bytes; > - double cost_per_byte_ms = 0.0; > > - if (copied_bytes > 0) { > - cost_per_byte_ms = (average_time_ms(G1GCPhaseTimes::ObjCopy) + average_time_ms(G1GCPhaseTimes::OptObjCopy)) / (double) copied_bytes; > + if (_collection_set->bytes_used_before() > freed_bytes) { > + size_t copied_bytes = _collection_set->bytes_used_before() - freed_bytes; > + double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy); > + double cost_per_byte_ms = average_copy_time / (double) copied_bytes; > _analytics->report_cost_per_byte_ms(cost_per_byte_ms, collector_state()->mark_or_rebuild_in_progress()); > } > > I ran the jtreg tests for G1 against the release build on my workstation (x86, Ubuntu 18.04). The results were the same before and after the patch was applied: > > test/hotspot/jtreg/gc/g1 > Test results: passed: 56; failed: 4; error: 1 > > It doesn't look like the failures and error have anything to do with this change. > > Thanks, > William > From johnc at azul.com Wed Nov 4 19:17:36 2020 From: johnc at azul.com (John Cuthbertson) Date: Wed, 4 Nov 2020 19:17:36 +0000 Subject: [11u] RFR 8255269: Unsigned overflow in g1Policy.cpp In-Reply-To: <1604509475536.1680@amazon.com> References: <5198514db2aa46e5985adcc28b1856c5@EX13D17UWB001.ant.amazon.com> <8570056C-66CE-405B-831A-70EA10DBBC3C@amazon.com> <9A834BBF-587D-466E-9E07-B7A5EF934F3E@azul.com> <1604509475536.1680@amazon.com> Message-ID: Hi William, Thanks for confirming. JohnC > On Nov 4, 2020, at 9:04 AM, Kemper, William wrote: > > G1GCPhaseTimes::OptObjCopy was added in 13 during a larger refactoring effort (https://bugs.openjdk.java.net/browse/JDK-8218668). This enum value doesn't exist in 11 so it's expected that it's not used in the patch for 11. > > Thanks, > William > ________________________________________ > From: John Cuthbertson > Sent: Wednesday, November 4, 2020 8:51 AM > To: Hohensee, Paul > Cc: Kemper, William; jdk-updates-dev at openjdk.java.net > Subject: RE: [EXTERNAL] [11u] RFR 8255269: Unsigned overflow in g1Policy.cpp > > 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 William, Paul, > > Does this patch have the same issue as before ? the missed 'average_time_ms(G1GCPhaseTimes::OptObjCopy)? term in the calculation of average_copy_time? Will that be resolved by back porting Paul?s fix? > > JohnC > >> On Nov 4, 2020, at 8:18 AM, Hohensee, Paul wrote: >> >> Thanks, lgtm now. I'll tag the issue. >> >> Paul >> >> ?On 11/3/20, 5:23 PM, "jdk-updates-dev on behalf of Kemper, William" wrote: >> >> Here's a patch based on jdk13u using the Skara CLI tools: >> >> git hg-export 7e95c0a5 >> # HG changeset patch >> # User phh >> # Date 1603811625 0 >> # Tue Oct 15:13:45 2020 +0000 >> 8255269: Unsigned overflow in g1Policy.cpp >> Reviewed-by: yan >> Contributed-by: William Kemper > >> >> diff --git a/src/hotspot/share/gc/g1/g1Policy.cpp b/src/hotspot/share/gc/g1/g1Policy.cpp >> index 91eceb7375..dec7f57de6 100644 >> --- a/src/hotspot/share/gc/g1/g1Policy.cpp >> +++ b/src/hotspot/share/gc/g1/g1Policy.cpp >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -692,11 +692,11 @@ void G1Policy::record_collection_pause_end(double pause_time_ms, size_t cards_sc >> _analytics->report_rs_length_diff((double) rs_length_diff); >> >> size_t freed_bytes = heap_used_bytes_before_gc - cur_used_bytes; >> - size_t copied_bytes = _collection_set->bytes_used_before() - freed_bytes; >> - double cost_per_byte_ms = 0.0; >> >> - if (copied_bytes > 0) { >> - cost_per_byte_ms = (average_time_ms(G1GCPhaseTimes::ObjCopy) + average_time_ms(G1GCPhaseTimes::OptObjCopy)) / (double) copied_bytes; >> + if (_collection_set->bytes_used_before() > freed_bytes) { >> + size_t copied_bytes = _collection_set->bytes_used_before() - freed_bytes; >> + double average_copy_time = average_time_ms(G1GCPhaseTimes::ObjCopy); >> + double cost_per_byte_ms = average_copy_time / (double) copied_bytes; >> _analytics->report_cost_per_byte_ms(cost_per_byte_ms, collector_state()->mark_or_rebuild_in_progress()); >> } >> >> I ran the jtreg tests for G1 against the release build on my workstation (x86, Ubuntu 18.04). The results were the same before and after the patch was applied: >> >> test/hotspot/jtreg/gc/g1 >> Test results: passed: 56; failed: 4; error: 1 >> >> It doesn't look like the failures and error have anything to do with this change. >> >> Thanks, >> William >> > From yan at azul.com Thu Nov 5 07:32:43 2020 From: yan at azul.com (Yuri Nesterenko) Date: Thu, 5 Nov 2020 10:32:43 +0300 Subject: [13u] RFR: 8255933: Bump patch update version for OpenJDK: jdk-13.0.5.1 Message-ID: <2a12eba3-757e-1b08-77c5-07febfc5ef00@azul.com> Hi, we will follow jdk11u fixing one issue, that with the crash, in a patch release. I hope to push the fix tomorrow together with necessary tags just after this technical update: http://cr.openjdk.java.net/~yan/8255933/webrev.00/ Please take a look. Thanks, --yan From abrygin at azul.com Thu Nov 5 08:01:38 2020 From: abrygin at azul.com (Andrew Brygin) Date: Thu, 5 Nov 2020 11:01:38 +0300 Subject: [13u] RFR: 8255933: Bump patch update version for OpenJDK: jdk-13.0.5.1 In-Reply-To: <2a12eba3-757e-1b08-77c5-07febfc5ef00@azul.com> References: <2a12eba3-757e-1b08-77c5-07febfc5ef00@azul.com> Message-ID: <9001903c-9c2b-44d1-180b-31bc3b1fe1ba@azul.com> Hello Yuri, the change looks fine to me. Thanks, Andrew On 05/11/2020 10:32, Yuri Nesterenko wrote: > Hi, > > we will follow jdk11u fixing one issue, that with the crash, in a patch release. > I hope to push the fix tomorrow together with necessary tags just after this > technical update: > > http://cr.openjdk.java.net/~yan/8255933/webrev.00/ > > Please take a look. > > Thanks, > --yan > From github.com+71385633+kvergizova at openjdk.java.net Thu Nov 5 09:17:10 2020 From: github.com+71385633+kvergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 5 Nov 2020 09:17:10 GMT Subject: [jdk13u-dev] RFR: 8238676: jni crashes on accessing it from process exit hook Message-ID: I would like to backport 8238676 to 13u, it's already included into 11u. The patch applies almost cleanly except for: - changes in make/test/JtregNativeHotspot.gmk reapplied manually due to different context (8179317 is not in 13u) - the second hunk of src/hotspot/share/prims/jni.cpp reapplied manually due to different context (8234739 is not in 13u) Tested with tier1 on Windows, the added test fails without the patch and passes with it. ------------- Commit messages: - Backport c42de93347d1647045f47dda7b50a1cd25db72b5 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/9/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=9&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238676 Stats: 220 lines in 4 files changed: 211 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/9/head:pull/9 PR: https://git.openjdk.java.net/jdk13u-dev/pull/9 From yan at openjdk.java.net Thu Nov 5 12:52:55 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 5 Nov 2020 12:52:55 GMT Subject: [jdk13u-dev] RFR: 8238676: jni crashes on accessing it from process exit hook In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 09:11:10 GMT, Ekaterina Vergizova wrote: > I would like to backport 8238676 to 13u, it's already included into 11u. > > The patch applies almost cleanly except for: > - changes in make/test/JtregNativeHotspot.gmk reapplied manually due to different context (8179317 is not in 13u) > - the second hunk of src/hotspot/share/prims/jni.cpp reapplied manually due to different context (8234739 is not in 13u) > > Tested with tier1 on Windows, the added test fails without the patch and passes with it. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/9 From goetz.lindenmaier at sap.com Thu Nov 5 13:30:53 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 5 Nov 2020 13:30:53 +0000 Subject: [11u] Second opinion? RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: <16555fcf94e4150aa3de4ebadcc391e530434fcb.camel@redhat.com> Message-ID: Hi, We agreed internally that this needs no further work, so I'll push it tomorrow. Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Monday, October 12, 2020 1:24 PM > To: 'Severin Gehwolf' ; 'Alvarez, David' > ; Doerr, Martin ; jdk- > updates-dev at openjdk.java.net > Cc: Martin Balao Alonso > Subject: RE: [11u] Second opinion? RFR: 8171279: Support X25519 and X448 > in TLS > > Hi Severin, Martin, > > That's fine, there is no hurry! Any input is > appreciated. > > Best regards, > Goetz. > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Monday, October 12, 2020 12:24 PM > > To: Lindenmaier, Goetz ; 'Alvarez, David' > > ; Doerr, Martin ; jdk- > > updates-dev at openjdk.java.net > > Cc: Martin Balao Alonso > > Subject: Re: [11u] Second opinion? RFR: 8171279: Support X25519 and > X448 > > in TLS > > > > Hi G?tz, > > > > On Mon, 2020-10-12 at 06:39 +0000, Lindenmaier, Goetz wrote: > > > Hi, > > > > > > I gave it a try: > > > http://cr.openjdk.java.net/~goetz/wr20/8171279-X25519_in_TLS- > > jdk11/02-incremental/ > > > I think this incremental change restores the lost functionality. > > > It does not break any of the existing tests. But I didn't run > > > any tests for FIPS. > > > > > > On the other side, Matthias found this: > > > https://github.com/elastic/elasticsearch/issues/37250 > > > The larger comment a bit down states that FIPS is unusable in 11. > > > If so, I would prefer to skip the incremental change above. > > > > > > Full webrev: > > > http://cr.openjdk.java.net/~goetz/wr20/8171279-X25519_in_TLS- > > jdk11/02/ > > > > Adding Martin Balao who has done some FIPS work. He mentioned that > > he'll be looking at this after the 11.0.9 release is done. So if you > > would be OK with waiting a bit before getting this integrated we'd > > appreciate it. It's still early in the 11.0.10 cycle. Thoughts? > > > > Thanks, > > Severin > > > > > Best regards, > > > Goetz > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: jdk-updates-dev On > > Behalf > > > > Of Lindenmaier, Goetz > > > > Sent: Thursday, October 8, 2020 6:37 PM > > > > To: 'Alvarez, David' ; Doerr, Martin > > > > ; jdk-updates-dev at openjdk.java.net > > > > Subject: [CAUTION] RE: [11u] Second opinion? RFR: 8171279: Support > > > > X25519 and X448 in TLS > > > > > > > > Hi David, > > > > > > > > > I haven't tested the full FIPS functionality, > > > > That is the problem. I don't have appropriate tests, either. > > > > > > > > > but code like this: > > > > > import com.sun.net.ssl.internal.ssl.Provider; > > > > > > > > > > public class FipsProviderTest { > > > > > public static void main(String[] args) { > > > > > com.sun.net.ssl.internal.ssl.Provider p = new Provider( > > > > > "cryptoProvider"); > > > > > } > > > > > } > > > > > > > > > > > > > > > That makes use of that constructor will no longer work. > > > > > > > > Ok, I see how you can reach the FIPS functionality. > > > > But the example is obviously too small to touch > > > > the code I changed. > > > > It compiles fine, with and without the change. > > > > And it runs fine if I add SunJSSE as provider, for example. > > > > > > > > > I don't know > > > > > what is our statement regarding the usage of --add-exports, are we > ok > > > > > breaking solutions that make use of it? If we are, is it only when we > > > > > have no other option or will be one situation like this one acceptable? > > > > Yes, I would prefer to not change the behavior even for > > > > things not explicitly exposed. > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > Thanks, > > > > > David > > > > > > > > > > > > > > > On Wed, 2020-10-07 at 07:50 +0000, Lindenmaier, Goetz wrote: > > > > > > CAUTION: This email originated from outside of the organization. > Do > > > > > > not click links or open attachments unless you can confirm the > sender > > > > > > and know the content is safe. > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > I would like to get a second opinion on how to deal > > > > > > with the lost FIPS coding in this downport. > > > > > > Could someone from outside SAP have a look please? > > > > > > > > > > > > Thanks, > > > > > > Goetz. > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Doerr, Martin > > > > > > > Sent: Tuesday, October 6, 2020 8:12 PM > > > > > > > To: Lindenmaier, Goetz ; jdk- > > updates- > > > > dev > > > > > > > > > > > > > > Subject: RE: [11u] RFR: 8171279: Support X25519 and X448 in TLS > > > > > > > > > > > > > > Hi G?tz, > > > > > > > > > > > > > > thanks for backporting this change. I think it's good to put it > > > > > > > into 11.0.10, > > > > > > > now, so we have enough testing time. > > > > > > > Please find comments and questions inline. > > > > > > > > > > > > > > > > > > > > > > file > > > > > > > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java > > > > > > > > Non-applying chunk fixes typo in a comment that is not in 11. > > > > > > > > I copied the comment to 11. > > > > > > > > > > > > > > Good. > > > > > > > > > > > > > > > > > > > > > > file > > > > > > > > > src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java > > > > > > > > Deleting class DHEKAKeyDerivation failed because the code in 11 > > > > > > > > uses > > > > > > > > JsseJce.getKeyAgreement() > > > > > > > > where the patch uses KeyAgreement.getInstance(). > > > > > > > > > > > > > > Right. > > > > > > > > > > > > > > > > > > > > > > file > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchang > > > > > > > > e.java > > > > > > > > 11 has different imports. > > > > > > > > The remaining conflicts arise from different usages of > > > > > > > > KeyFactory, ECUtil > > > > > > > > > > > > > > and > > > > > > > > JsseJce. > > > > > > > > > > > > > > Good. > > > > > > > > > > > > > > > > > > > > > > file > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java > > > > > > > > The conflicts arise from different usages of KeyAgreement and > > > > > > > > JsseJce. > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > file > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchang > > > > > > > > e.java > > > > > > > > Different imports. > > > > > > > > The remaining conflicts arise from different usages of > > > > > > > > KeyFactory, ECUtil > > > > > > > > > > > > > > and > > > > > > > > JsseJce. > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > file > > > > > > > > src/java.base/share/classes/sun/security/ssl/SSLExtension.java > > > > > > > > Copyright > > > > > > > > > > > > > > > > file > > > > > > > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.j > > > > > > > ava > > > > > > > > Copyright > > > > > > > > > > > > > > We don't edit Copyright headers for backports. Ok. > > > > > > > > > > > > > > > > > > > > > > file > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java > > > > > > > > imports > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > file > > > > > > > > > > > > > > > > > > > > > > > > src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtensi > > > > > > > on.jav > > > > > > > > a > > > > > > > > Different imports. > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > Enums are moved to a file of their own: NamedGroup.java > > > > > > > > Removing the enums does not apply because in 13 FIPS support > > was > > > > > > > > removed. > > > > > > > > > > > > > > So you just deleted them manually. Fine. > > > > > > > > > > > > > > > Also, a name string was added. > > > > > > > > > > > > > > You mean "String name" in the code you removed? > > > > > > > > > > > > > > > The supported group types differ, too. > > > > > > > > > > > > > > That's expected. Did that cause manual integration? > > > > > > > > > > > > > > > In 11, the enums have a row of additional functionality that > > > > > > > > I now removed, too. E.g., additional constructors, > > > > > > > > isSupported(), > > > > > > > > isECAvailable. > > > > > > > > > > > > > > That's in the code which is gone. That's fine. > > > > > > > > > > > > > > > Some further differences are again usages of ECUtil, JsseJce etc. > > > > > > > > The original patch has more NamedGroups: "// Secondary NIST > > > > > > > > curves" > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > file test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java > > > > > > > > configureClientSocket() already in 11. We downported this with > > > > > > > > a previous change. > > > > > > > > > > > > > > Ok. I can see this code is already there. > > > > > > > > > > > > > > > The NamedGroups enum is moved to a file of it's own. > > > > > > > > Before this change, the named Groups knew about FIPS in 11. > The > > > > > > > > new > > > > > > > > > > > > > > ones > > > > > > > > don't. > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8217835 "Remove > the > > > > > > > > experimental SunJSSE FIPS compliant mode" > > > > > > > > removed FIPS support in 13 before this change was implemented. > > > > > > > > > > > > > > > > As I understand 8217835, the experimental FIPS feature cannot > be > > > > > > > > used in > > > > > > > > 11, it just remained in the code. So I skipped adapting > > > > > > > > NamedGroups to the > > > > > > > > old behaviour, I can not test it anyways. > > > > > > > > What do you think, do we need to add this code to > > > > > > > > NamedGroupd.java > > > > > > > > again? > > > > > > > > > > > > > > Sounds like this is ok according to the CSR > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8217907 > > > > > > > Since this file is new with this backport, I prefer keeping it like > > > > > > > the original > > > > > > > one for the backport. > > > > > > > We could open a new bug in case anybody wants it back, but I > guess > > > > > > > that's > > > > > > > not the case. > > > > > > > > > > > > > > There's still some Fips code there: > > > > > > > (!requireFips || namedGroup.isFips)*/ ) { // GL fix isFips > > > > > > > With a comment! > > > > > > > What are you planning to do with it? > > > > > > > > > > > > > > > > > > > > > > There are two follow ups, > > > > > > > > 8224650: Add tests to support X25519 and X448 in TLS > > > > > > > > 8243549: > > > > > > > > sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java > > > > > > > > failed with Unsupported signature algorithm: DSA > > > > > > > > > > > > > > > > I have downported these too, and will send RFR once this is > > > > > > > > stable. > > > > > > > > Existing and new test are all passing. > > > > > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8171279 > > > > > > > > http://hg.openjdk.java.net/jdk/jdk/rev/946f7f2d321c > > > > > > > > > > > > > > Ok. That's an important point. > > > > > > > There may be more to come, but that's all we currently have > AFAICS. > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > Martin From christoph.langer at sap.com Thu Nov 5 16:37:38 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Nov 2020 16:37:38 +0000 Subject: [15u] Push JDK-8239105 and JDK-8254081 Message-ID: Hi Rob, JDK-8239105 [0] and JDK-8254081 [1] must have been backported to JDK15u already, since backport items with version 15.0.2 exist. Unfortunately, it seems that they have only been pushed to Oracle's internal repository. Is it ok if I push them to the public 15u, too? We're currently getting test failures. Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8239105 [1] https://bugs.openjdk.java.net/browse/JDK-8254081 From goetz.lindenmaier at sap.com Fri Nov 6 07:45:01 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Nov 2020 07:45:01 +0000 Subject: [11u] RFR: 8173361: various crashes in JvmtiExport::post_compiled_method_load Message-ID: Hi, I downport this for parity with 11.0.10-oracle. The code does not fit very well. I removed a guarantee because is_unloading() does not exist in 11. I turned some MutexLocker to MutexLockerEx which takes the Mutex::_no_safepoint_check_flag enum argument. http://cr.openjdk.java.net/~goetz/wr20/8173361-post_compiled_method-jdk11/01/webrev/ Please review. There are some follow up changes for jvmti which all need similar adaptions. https://bugs.openjdk.java.net/browse/JDK-8173361 https://hg.openjdk.java.net/jdk/jdk/rev/e79ece2eb1ba Best regards, Goetz From goetz.lindenmaier at sap.com Fri Nov 6 08:01:22 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Nov 2020 08:01:22 +0000 Subject: [11u] RFR: 8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators Message-ID: Hi I am downporting this for parity with 11.0.10-oracle. I had to resolve and adapt the code, e.g. I replaced MutexLocker by MutexLockerEx. http://cr.openjdk.java.net/~goetz/wr20/8173658-post_class_unload-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8173658 https://hg.openjdk.java.net/jdk/jdk/rev/4774b50671ed Best regards, Goetz. From goetz.lindenmaier at sap.com Fri Nov 6 08:38:50 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Nov 2020 08:38:50 +0000 Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" Message-ID: Hi I am downporting this for parity with 11.0.10-oracle. http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/01/ I had to resolve and fis in quite some places: src/hotspot/share/code/nmethod.cpp Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. Added 'this' to call of JvmtiDeferredEvent::compiled_method_unload_event() src/hotspot/share/code/nmethod.hpp Trivial, resolved. src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. I removed NMethodIterator::only_alive_and_not_unloading and call next_alive instead. The NMethodIterator differs in head a lot. src/hotspot/share/prims/jvmtiExport.cpp Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, nmethod *nm) from head which is called in src/hotspot/share/prims/jvmtiExport.hpp Resolved. Deleted method has different arguments. src/hotspot/share/prims/jvmtiImpl.hpp Resolved. src/hotspot/share/runtime/serviceThread.cpp Context different. Please review. https://bugs.openjdk.java.net/browse/JDK-8212160 https://hg.openjdk.java.net/jdk/jdk/rev/366c0f357ee6 Best regards, Goetz From github.com+71385633+kvergizova at openjdk.java.net Fri Nov 6 09:08:03 2020 From: github.com+71385633+kvergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 6 Nov 2020 09:08:03 GMT Subject: [jdk13u-dev] RFR: 8249255: Build fails if source code in cygwin home dir Message-ID: I would like to backport 8249255 to 13u, it's already included into 11u. The patch doesn't apply cleanly, because 8239708 is not backported to 13u. - the patch should be applied to make/autoconf/basics.m4 instead of make/autoconf/basic.m4 - BASIC_FIXUP_PATH should be used instead of UTIL_FIXUP_PATH from the original patch Testing: jdk13u-dev placed in cygwin home is built successfully after applying the patch. ------------- Commit messages: - Backport a9b7ae8ac20b6d4bec36f91a40c749c757c887af Changes: https://git.openjdk.java.net/jdk13u-dev/pull/10/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=10&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249255 Stats: 9 lines in 1 file changed: 5 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/10.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/10/head:pull/10 PR: https://git.openjdk.java.net/jdk13u-dev/pull/10 From martin.doerr at sap.com Fri Nov 6 09:50:20 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 6 Nov 2020 09:50:20 +0000 Subject: [11u] RFR: 8224650: Add tests to support X25519 and X448 in TLS In-Reply-To: References: Message-ID: Hi G?tz, this makes sense to me. Looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Mittwoch, 7. Oktober 2020 10:35 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8224650: Add tests to support X25519 and > X448 in TLS > > Hi, > > I am downporting this for 11.0.10-oracle parity. > Also, this is needed to test JDK-8171279. > http://cr.openjdk.java.net/~goetz/wr20/8224650-X25519_test-jdk11/01/ > > The changes to SSLSocketTemplate.java have been downported already: > https://bugs.openjdk.java.net/browse/JDK-8249159 > 8249159: Downport test rework for SSLSocketTemplate from 8224650 > > In the new test, I had to remove four Cipher suites that are not > supported in 11. > I just commented them so in case these Cipher suites are downported > It is more easy to find that they must be enabled in this test. > > https://bugs.openjdk.java.net/browse/JDK-8224650 > http://hg.openjdk.java.net/jdk/jdk13/rev/ed7851b2d5e4 > > Best regards, > Goetz. From rs at jelastic.com Sat Nov 7 16:08:10 2020 From: rs at jelastic.com (Ruslan Synytsky) Date: Sat, 7 Nov 2020 18:08:10 +0200 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: <004c01d6adbf$4cf91780$e6eb4680$@alibaba-inc.com> References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> <42e88c3e-763a-644e-a9ad-9299c9f36d5a@redhat.com> <001901d6ab3e$6cc96bb0$465c4310$@alibaba-inc.com> <004c01d6adbf$4cf91780$e6eb4680$@alibaba-inc.com> Message-ID: Hi All, will it be considered as a "green light" if no additional feedback / comments come during 14 days? Or is there a possibility to block the progress by ignoring a thread? Please help me to understand how the backporting process works. Thank you On Thu, 29 Oct 2020 at 08:47, Liang Mao wrote: > Hi All, > > For the potential memory footprint issue from JDK-6490394,I made more > tests. > Fixed IR test on specjbb2015 shows that memory footprint will climb > more aggressively than original 11u. That could be an issue but it also > exists > in JDK12 to JDK15 for 4 releases. > > (I use following options to test: > -Dspecjbb.controller.type=PRESET -Dspecjbb.controller.preset.ir=4000 > -Dspecjbb.controller.preset.duration=1000000 -XX:ParallelGCThreads=8 > -XX:+UseG1GC -Xmx10g -Xms1g -jar specjbb2015.jar -m COMPOSITE) > > As I suggested in previous mail that we can do resizing in remark only > with > (G1PeriodicGCInterval != 0) : > > http://cr.openjdk.java.net/~lmao/jep346.11u/all.webrev.01/ > > The diff with all.webrev.00 only contains: > > < + if (G1PeriodicGCInterval != 0) { > < + _g1h->resize_heap_if_necessary(); > < + } > --- > > + _g1h->resize_heap_if_necessary(); > > The tier1 is clean with fastdebug and the above specjbb2015 test won't have > memory footprint issues anymore. So looks like most of impacts will be > excluded > from default G1. Could someone please take a look? > > Thanks, > Liang > > > > -----Original Message----- > > From: Liang Mao [mailto:maoliang.ml at alibaba-inc.com] > > Sent: 2020?10?26? 10:19 > > To: 'Aleksey Shipilev' ; 'jdk-updates-dev' > > dev at openjdk.java.net>; 'Lindenmaier, Goetz' ; > > 'Martijn Verburg' ; 'Ruslan Synytsky' > > > > Subject: RE: [11u] Backport JEP 346 : Promptly Return Unused Committed > > Memory from G1 > > > > Hi Aleksey, > > > > Thanks very much for your careful initial review! > > > > > So, for the current action items: > > > a) JDK-8238932 needs to be added, trivially; > > Yes. It should be added although trival. > > > > > > > b) JDK-6490394 needs to be investigated on footprint impact, > > > possibly involving Man Cao / Google; > > > > JDK-6490394 might increase the memory footprint because introducing the > > heap resize in remark phase. But we also need this to shrink the heap > for saving > > memory. The heap sizing heuristics in 11u has some original issues that > it would > > unnecessarily expand heap size with a fixed input. Thomas made a lot of > efforts > > on this later: > > https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020- > > June/030090.html > > Even with a fixed IR running for specjbb2015 (as - > > Dspecjbb.controller.preset.ir=4000), > > the heap will expand continuously. > > > > So I think that's why JEP346 is valuable in 11u because not only memory > > footprint issue in Java is a common sense but there're also some > uncessary > > memory expansion in G1. > > > > For the potential issue of increasing footprint by default, can we make > a very > > simple fix that we only do resize in remark with (G1PeriodicGCInterval > != 0): > > > > +if (G1PeriodicGCInterval != 0) { > > _g1h->resize_heap_if_necessary(); > > +} > > > > So the additional sizing only happen with a specified > G1PeriodicGCInterval. > > > > > c) JDK-8218880 deserves more attention/testing, possibly involving > > > others; > > > > > > > It seems the only real severe issue brought by the JEP. But periodic > triggering GC > > with GC locks on is not a common scenario. So it is acceptable that it > took 3 > > months to find the bug. And the fix is straight forward that just don't > trigger GC > > when GC locks on. After half and one year, there're no other bugs from > the > > feature. It looks stable for quite a long time (3 releases). > > > > Thanks, > > Liang > > > > > -----Original Message----- > > > From: Aleksey Shipilev [mailto:shade at redhat.com] > > > Sent: 2020?10?22? 20:08 > > > To: Liang Mao ; jdk-updates-dev > > > ; Lindenmaier, Goetz > > > ; Martijn Verburg > > > ; Ruslan Synytsky > > > Subject: Re: [11u] Backport JEP 346 : Promptly Return Unused Committed > > > Memory from G1 > > > > > > On 9/25/20 8:42 AM, Liang Mao wrote: > > > > All changes of the JEP only contains of hunderds lines of code: > > > > http://cr.openjdk.java.net/~lmao/jep346.11u/all.webrev.00/ > > > > > > Andrew asked me to follow up on this from the GC implementation/risk > > > perspective. > > > > > > The first cursory review follows. > > > > > > This issue seems to be missing from the batch: > > > JDK-8238932: Invalid tier1_gc_1 test group definition > > > > > > A philosophical point: the obvious risk for this kind of backport is > > > breaking something. Since G1 is the default garbage collector in 11u, > > > breaking it would break most applications that run with out of the box > > > settings. This can be partially mitigated if we had the kill-switch > > > for the code, and that depends on how code is structured. > > > > > > Per-issue comments: > > > > > > > 1) JDK-8071913: Filter out entries to free/uncommitted regions > > > > during iteration > > > > http://cr.openjdk.java.net/~lmao/jep346.11u/8071913.webrev.00/ > > > > > > This looks like a faithful reproduction of original change. This thing > > > concerns me the most: it touches the RSet code without any recourse in > case it > > is broken. > > > > > > > 2) JDK-6490394: G1: Allow heap shrinking / memory unmapping after > > > > reclaiming regions during Remark > > > > > > Man Cao reports in the comments there that Google's internal JDK 11 > > > had regressed memory footprint after this change. I cannot see if > > > there was any follow-up on that. > > > > > > > 3) JDK-8213898: CDS dumping of springboot asserts in > > > > G1ArchiveAllocator::alloc_new_region > > > > > > This seems to be a simple fix for another regression introduced by JDK- > > 6490394. > > > Looks fine. > > > > > > > 4) JDK-8212657: Implementation of JDK-8204089 Promptly Return Unused > > > > Committed Memory from G1 > > > > http://cr.openjdk.java.net/~lmao/jep346.11u/8212657.webrev.00/ > > > > > > This looks like a faithful reproduction of the original change. It > > > seems fairly innocious, and codepaths revert to nops with > > > -XX:G1PeriodicGCInterval=0 and - XX:G1PeriodicGCSystemLoadThreshold=0. > > > > > > update_rs_lengths_prediction() and update_ihop_prediction() are called > > > in the different order now, but that seems fine, as they look > independent. > > > > > > As said above, JDK-8238932 is missing as the follow-up. > > > > > > > 5) JDK-8215120: 32-bit build failures after JDK-8212657 (Promptly > > > > Return Unused Committed Memory from G1) > > > > > > Simple follow up after JDK-8212657. Looks fine. > > > > > > > 6) JDK-8215149: TestOptionsWithRangesDynamic.java fails after > > > > JDK-8215120 > > > > > > ...and another one. Looks fine. > > > > > > > 7) JDK-8215548: G1PeriodicGCSystemLoadThreshold needs to be a double > > > > > > Simple follow up for JDK-8212657. Looks fine. > > > > > > > 8) JDK-8216490: Spammy periodic GC log message contains random time > > > > stamp with periodic gc disabled > > > > > > UX fix after JDK-8212657. Looks fine. > > > > > > > 9) JDK-8218880: G1 crashes when issuing a periodic GC while the > > > > GCLocker is held > > > > http://cr.openjdk.java.net/~lmao/jep346.11u/8218880.webrev.00/ > > > > > > This looks like a faithful reproduction of the original change. > > > > > > What concerns me, though, is that the bug was found full 3 months > > > after introducing! And it crashed the VM hard, because periodic GC > > > entered collect() from a non-Java thread! I would need some time to > > > breathe out and prove to myself it is safe now. > > > > > > > 10) JDK-8212883: Setting a double manageable flag with jcmd/jinfo > > > > crashes the JVM > > > > > > This one can actually be backported ahead of time to 11u, I think. I > > > understand it is needed for > > > JDK-8215548 in this queue, but I don't think that's a blocker for a > > > separate inclusion, and it could be useful for other backports. > > > > > > So, for the current action items: > > > a) JDK-8238932 needs to be added, trivially; > > > b) JDK-6490394 needs to be investigated on footprint impact, > > > possibly involving Man Cao / Google; > > > c) JDK-8218880 deserves more attention/testing, possibly involving > > > others; > > > > > > Thanks, > > > -Aleksey > > -- Ruslan Synytsky CEO @ Jelastic Multi-Cloud PaaS From Martijn.Verburg at microsoft.com Sun Nov 8 15:39:29 2020 From: Martijn.Verburg at microsoft.com (Martijn Verburg) Date: Sun, 8 Nov 2020 15:39:29 +0000 Subject: [EXTERNAL] Re: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> <42e88c3e-763a-644e-a9ad-9299c9f36d5a@redhat.com> <001901d6ab3e$6cc96bb0$465c4310$@alibaba-inc.com> <004c01d6adbf$4cf91780$e6eb4680$@alibaba-inc.com>, Message-ID: My understanding is that you need to drive to consensus and have the project led explicitly approve a change like this. You may want to review the Shenandoah enablement thread as a an example of this. Cheers, Martijn ________________________________ From: Ruslan Synytsky Sent: Saturday, November 7, 2020 16:08 To: Liang Mao ; Aleksey Shipilev Cc: jdk-updates-dev ; Lindenmaier, Goetz ; Martijn Verburg Subject: [EXTERNAL] Re: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 Hi All, will it be considered as a "green light" if no additional feedback / comments come during 14 days? Or is there a possibility to block the progress by ignoring a thread? Please help me to understand how the backporting process works. Thank you On Thu, 29 Oct 2020 at 08:47, Liang Mao > wrote: Hi All, For the potential memory footprint issue from JDK-6490394,I made more tests. Fixed IR test on specjbb2015 shows that memory footprint will climb more aggressively than original 11u. That could be an issue but it also exists in JDK12 to JDK15 for 4 releases. (I use following options to test: -Dspecjbb.controller.type=PRESET -Dspecjbb.controller.preset.ir=4000 -Dspecjbb.controller.preset.duration=1000000 -XX:ParallelGCThreads=8 -XX:+UseG1GC -Xmx10g -Xms1g -jar specjbb2015.jar -m COMPOSITE) As I suggested in previous mail that we can do resizing in remark only with (G1PeriodicGCInterval != 0) : http://cr.openjdk.java.net/~lmao/jep346.11u/all.webrev.01/ The diff with all.webrev.00 only contains: < + if (G1PeriodicGCInterval != 0) { < + _g1h->resize_heap_if_necessary(); < + } --- > + _g1h->resize_heap_if_necessary(); The tier1 is clean with fastdebug and the above specjbb2015 test won't have memory footprint issues anymore. So looks like most of impacts will be excluded from default G1. Could someone please take a look? Thanks, Liang > -----Original Message----- > From: Liang Mao [mailto:maoliang.ml at alibaba-inc.com] > Sent: 2020?10?26? 10:19 > To: 'Aleksey Shipilev' >; 'jdk-updates-dev' dev at openjdk.java.net>; 'Lindenmaier, Goetz' >; > 'Martijn Verburg' >; 'Ruslan Synytsky' > > > Subject: RE: [11u] Backport JEP 346 : Promptly Return Unused Committed > Memory from G1 > > Hi Aleksey, > > Thanks very much for your careful initial review! > > > So, for the current action items: > > a) JDK-8238932 needs to be added, trivially; > Yes. It should be added although trival. > > > > b) JDK-6490394 needs to be investigated on footprint impact, > > possibly involving Man Cao / Google; > > JDK-6490394 might increase the memory footprint because introducing the > heap resize in remark phase. But we also need this to shrink the heap for saving > memory. The heap sizing heuristics in 11u has some original issues that it would > unnecessarily expand heap size with a fixed input. Thomas made a lot of efforts > on this later: > https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020- > June/030090.html > Even with a fixed IR running for specjbb2015 (as - > Dspecjbb.controller.preset.ir=4000), > the heap will expand continuously. > > So I think that's why JEP346 is valuable in 11u because not only memory > footprint issue in Java is a common sense but there're also some uncessary > memory expansion in G1. > > For the potential issue of increasing footprint by default, can we make a very > simple fix that we only do resize in remark with (G1PeriodicGCInterval != 0): > > +if (G1PeriodicGCInterval != 0) { > _g1h->resize_heap_if_necessary(); > +} > > So the additional sizing only happen with a specified G1PeriodicGCInterval. > > > c) JDK-8218880 deserves more attention/testing, possibly involving > > others; > > > > It seems the only real severe issue brought by the JEP. But periodic triggering GC > with GC locks on is not a common scenario. So it is acceptable that it took 3 > months to find the bug. And the fix is straight forward that just don't trigger GC > when GC locks on. After half and one year, there're no other bugs from the > feature. It looks stable for quite a long time (3 releases). > > Thanks, > Liang > > > -----Original Message----- > > From: Aleksey Shipilev [mailto:shade at redhat.com] > > Sent: 2020?10?22? 20:08 > > To: Liang Mao >; jdk-updates-dev > > >; Lindenmaier, Goetz > > >; Martijn Verburg > > >; Ruslan Synytsky > > > Subject: Re: [11u] Backport JEP 346 : Promptly Return Unused Committed > > Memory from G1 > > > > On 9/25/20 8:42 AM, Liang Mao wrote: > > > All changes of the JEP only contains of hunderds lines of code: > > > http://cr.openjdk.java.net/~lmao/jep346.11u/all.webrev.00/ > > > > Andrew asked me to follow up on this from the GC implementation/risk > > perspective. > > > > The first cursory review follows. > > > > This issue seems to be missing from the batch: > > JDK-8238932: Invalid tier1_gc_1 test group definition > > > > A philosophical point: the obvious risk for this kind of backport is > > breaking something. Since G1 is the default garbage collector in 11u, > > breaking it would break most applications that run with out of the box > > settings. This can be partially mitigated if we had the kill-switch > > for the code, and that depends on how code is structured. > > > > Per-issue comments: > > > > > 1) JDK-8071913: Filter out entries to free/uncommitted regions > > > during iteration > > > http://cr.openjdk.java.net/~lmao/jep346.11u/8071913.webrev.00/ > > > > This looks like a faithful reproduction of original change. This thing > > concerns me the most: it touches the RSet code without any recourse in case it > is broken. > > > > > 2) JDK-6490394: G1: Allow heap shrinking / memory unmapping after > > > reclaiming regions during Remark > > > > Man Cao reports in the comments there that Google's internal JDK 11 > > had regressed memory footprint after this change. I cannot see if > > there was any follow-up on that. > > > > > 3) JDK-8213898: CDS dumping of springboot asserts in > > > G1ArchiveAllocator::alloc_new_region > > > > This seems to be a simple fix for another regression introduced by JDK- > 6490394. > > Looks fine. > > > > > 4) JDK-8212657: Implementation of JDK-8204089 Promptly Return Unused > > > Committed Memory from G1 > > > http://cr.openjdk.java.net/~lmao/jep346.11u/8212657.webrev.00/ > > > > This looks like a faithful reproduction of the original change. It > > seems fairly innocious, and codepaths revert to nops with > > -XX:G1PeriodicGCInterval=0 and - XX:G1PeriodicGCSystemLoadThreshold=0. > > > > update_rs_lengths_prediction() and update_ihop_prediction() are called > > in the different order now, but that seems fine, as they look independent. > > > > As said above, JDK-8238932 is missing as the follow-up. > > > > > 5) JDK-8215120: 32-bit build failures after JDK-8212657 (Promptly > > > Return Unused Committed Memory from G1) > > > > Simple follow up after JDK-8212657. Looks fine. > > > > > 6) JDK-8215149: TestOptionsWithRangesDynamic.java fails after > > > JDK-8215120 > > > > ...and another one. Looks fine. > > > > > 7) JDK-8215548: G1PeriodicGCSystemLoadThreshold needs to be a double > > > > Simple follow up for JDK-8212657. Looks fine. > > > > > 8) JDK-8216490: Spammy periodic GC log message contains random time > > > stamp with periodic gc disabled > > > > UX fix after JDK-8212657. Looks fine. > > > > > 9) JDK-8218880: G1 crashes when issuing a periodic GC while the > > > GCLocker is held > > > http://cr.openjdk.java.net/~lmao/jep346.11u/8218880.webrev.00/ > > > > This looks like a faithful reproduction of the original change. > > > > What concerns me, though, is that the bug was found full 3 months > > after introducing! And it crashed the VM hard, because periodic GC > > entered collect() from a non-Java thread! I would need some time to > > breathe out and prove to myself it is safe now. > > > > > 10) JDK-8212883: Setting a double manageable flag with jcmd/jinfo > > > crashes the JVM > > > > This one can actually be backported ahead of time to 11u, I think. I > > understand it is needed for > > JDK-8215548 in this queue, but I don't think that's a blocker for a > > separate inclusion, and it could be useful for other backports. > > > > So, for the current action items: > > a) JDK-8238932 needs to be added, trivially; > > b) JDK-6490394 needs to be investigated on footprint impact, > > possibly involving Man Cao / Google; > > c) JDK-8218880 deserves more attention/testing, possibly involving > > others; > > > > Thanks, > > -Aleksey -- Ruslan Synytsky CEO @ Jelastic Multi-Cloud PaaS From shade at redhat.com Sun Nov 8 19:24:29 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 8 Nov 2020 20:24:29 +0100 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> <42e88c3e-763a-644e-a9ad-9299c9f36d5a@redhat.com> <001901d6ab3e$6cc96bb0$465c4310$@alibaba-inc.com> <004c01d6adbf$4cf91780$e6eb4680$@alibaba-inc.com> Message-ID: <6b3d0093-5263-2f37-4d1a-df8f869328f1@redhat.com> On 11/7/20 5:08 PM, Ruslan Synytsky wrote: > Hi All, will it be considered as a "green light" if no additional?feedback / comments come during 14 > days? Or is there a possibility?to block the progress by ignoring a thread??Please help me to > understand how the backporting process works. There are no implicit timeouts almost anywhere in OpenJDK projects (with notable exceptions of role voting, I think), and almost everywhere you need the affirmative action. Here is how the backporting process works: until formal maintainers say "yes" or "no", nothing is certain. Andrew, having that Lead (maybe as in, "made from lead") Maintainer hat burden on his shoulders, asked me to follow up with risk assessment. I did the first round, and now I have to follow up on Liang's improvements for the second round. I am planning to get around to that soon. Even the simple patches sometimes drag for many days / few weeks, until reviewers catch up. For the change like this, it is prudent to expect a very careful pace on top of that. -- Thanks, -Aleksey From rs at jelastic.com Sun Nov 8 20:39:27 2020 From: rs at jelastic.com (Ruslan Synytsky) Date: Sun, 8 Nov 2020 22:39:27 +0200 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: <6b3d0093-5263-2f37-4d1a-df8f869328f1@redhat.com> References: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> <42e88c3e-763a-644e-a9ad-9299c9f36d5a@redhat.com> <001901d6ab3e$6cc96bb0$465c4310$@alibaba-inc.com> <004c01d6adbf$4cf91780$e6eb4680$@alibaba-inc.com> <6b3d0093-5263-2f37-4d1a-df8f869328f1@redhat.com> Message-ID: Aleksey, thank you for the process clarification. It helps to stay passionate. No doubts that we should be careful. And no push, I wanted to understand if coordination is necessary here. Looking forward to getting your second round feedback. Regards Ruslan On Sun, 8 Nov 2020 at 21:24, Aleksey Shipilev wrote: > On 11/7/20 5:08 PM, Ruslan Synytsky wrote: > > Hi All, will it be considered as a "green light" if no > additional feedback / comments come during 14 > > days? Or is there a possibility to block the progress by ignoring a > thread? Please help me to > > understand how the backporting process works. > > There are no implicit timeouts almost anywhere in OpenJDK projects (with > notable exceptions of role > voting, I think), and almost everywhere you need the affirmative action. > Here is how the backporting > process works: until formal maintainers say "yes" or "no", nothing is > certain. > > Andrew, having that Lead (maybe as in, "made from lead") Maintainer hat > burden on his shoulders, > asked me to follow up with risk assessment. I did the first round, and now > I have to follow up on > Liang's improvements for the second round. I am planning to get around to > that soon. > > Even the simple patches sometimes drag for many days / few weeks, until > reviewers catch up. For the > change like this, it is prudent to expect a very careful pace on top of > that. > > -- > Thanks, > -Aleksey > > From takiguc at linux.vnet.ibm.com Mon Nov 9 02:20:28 2020 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 09 Nov 2020 11:20:28 +0900 Subject: [11u] Do you have a plan to upgrade JDK11's JLine to 3.14.0 ? Message-ID: Hello. Do you have a plan to upgrade JDK11's JLine to 3.14.0 ? It seems JDK 11.0.9's JLine is 3.12.1 [1] I found jshell's Tab key completion feature did not work on AIX's dtterm terminal window. I could not recreate this issue on JDK 11.0.8. I executed following instruction on JDK 11.0.9. 1. Type "Sys" on jshell, 2. Press Tab key. It should be changed to "System", but completion feature did not work. It worked fine on aixterm and xterm window. So it seems dtterm unique issue. I executed same instruction on JDK15 and JDK16 EA on AIX's dtterm, it worked fine as expected. It seemed JLine was upgraded to 3.14.0. [2] [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/4fd46d208f0a/src/jdk.internal.le/share/legal/jline.md [2: https://github.com/openjdk/jdk/blob/master/src/jdk.internal.le/share/legal/jline.md Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From goetz.lindenmaier at sap.com Mon Nov 9 07:07:03 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 Nov 2020 07:07:03 +0000 Subject: [11u] RFR: 8224650: Add tests to support X25519 and X448 in TLS In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing! Best regards, Goetz. -----Original Message----- From: Doerr, Martin Sent: Freitag, 6. November 2020 10:50 To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8224650: Add tests to support X25519 and X448 in TLS Hi G?tz, this makes sense to me. Looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Mittwoch, 7. Oktober 2020 10:35 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8224650: Add tests to support X25519 and > X448 in TLS > > Hi, > > I am downporting this for 11.0.10-oracle parity. > Also, this is needed to test JDK-8171279. > http://cr.openjdk.java.net/~goetz/wr20/8224650-X25519_test-jdk11/01/ > > The changes to SSLSocketTemplate.java have been downported already: > https://bugs.openjdk.java.net/browse/JDK-8249159 > 8249159: Downport test rework for SSLSocketTemplate from 8224650 > > In the new test, I had to remove four Cipher suites that are not > supported in 11. > I just commented them so in case these Cipher suites are downported > It is more easy to find that they must be enabled in this test. > > https://bugs.openjdk.java.net/browse/JDK-8224650 > http://hg.openjdk.java.net/jdk/jdk13/rev/ed7851b2d5e4 > > Best regards, > Goetz. From anleonar at redhat.com Mon Nov 9 09:13:30 2020 From: anleonar at redhat.com (Andrew Leonard) Date: Mon, 9 Nov 2020 09:13:30 +0000 Subject: RFR: jdk11u Backport 8234393: [macos] printing ignores printer tray Message-ID: Hi, Please can I request a review of this webrev for the backport of https://bugs.openjdk.java.net/browse/JDK-8234393 Webrev: https://cr.openjdk.java.net/~aleonard/8234393/webrev.00/ The patch is the same as from the original jdk patch, apart from the merge-conflict resolution. I have successfully tested tier1 and tier2. Thanks Andrew From anleonar at redhat.com Mon Nov 9 09:28:55 2020 From: anleonar at redhat.com (Andrew Leonard) Date: Mon, 9 Nov 2020 09:28:55 +0000 Subject: jdk-11.0.9.1+1 downstream semver issues...? Message-ID: Hi, Although not directly an issue for OpenJDK, I thought I would just mention that some vendors have had issues mapping this release patch due to mapping problems to "semver" format. A number of the binary packages produced use semver (https://semver.org/) which does not support a 4 dotted version, which means having to map this patch in some way and still maintain version ordering/upgrade path etc. Not sure what the answer is, but just thought i'd bring the subject up. Thanks Andrew From goetz.lindenmaier at sap.com Mon Nov 9 09:52:32 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 Nov 2020 09:52:32 +0000 Subject: jdk-11.0.9.1+1 downstream semver issues...? In-Reply-To: References: Message-ID: Hi, OpenJDK even supports more dots. See also JEP 322: Time-Based Release Versioning [1]. Oracle has released 11.0.8.0.4 VMs etc. [2] I think this is not easy to change. (I'm not sure about the wording, is 11.0.9.1 four-dotted or three-dotted?) Best regards, Goetz. [1] JEP 322: Time-Based Release Versioning http://openjdk.java.net/jeps/322 [2] https://bugs.openjdk.java.net/browse/JDK-8252959?jql=project%20%3D%20JDK%20AND%20fixVersion%20in%20(11.0.8.0.4-oracle) -----Original Message----- From: jdk-updates-dev On Behalf Of Andrew Leonard Sent: Montag, 9. November 2020 10:29 To: jdk-updates-dev at openjdk.java.net Subject: jdk-11.0.9.1+1 downstream semver issues...? Hi, Although not directly an issue for OpenJDK, I thought I would just mention that some vendors have had issues mapping this release patch due to mapping problems to "semver" format. A number of the binary packages produced use semver (https://semver.org/) which does not support a 4 dotted version, which means having to map this patch in some way and still maintain version ordering/upgrade path etc. Not sure what the answer is, but just thought i'd bring the subject up. Thanks Andrew From christoph.langer at sap.com Mon Nov 9 10:05:04 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 9 Nov 2020 10:05:04 +0000 Subject: RFR: jdk11u Backport 8234393: [macos] printing ignores printer tray In-Reply-To: References: Message-ID: Hi Andrew, looks good. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Leonard > Sent: Montag, 9. November 2020 10:14 > To: jdk-updates-dev at openjdk.java.net > Subject: RFR: jdk11u Backport 8234393: [macos] printing ignores printer tray > > Hi, > Please can I request a review of this webrev for the backport of > https://bugs.openjdk.java.net/browse/JDK-8234393 > Webrev: https://cr.openjdk.java.net/~aleonard/8234393/webrev.00/ > The patch is the same as from the original jdk patch, apart from the > merge-conflict resolution. > I have successfully tested tier1 and tier2. > Thanks > Andrew From christoph.langer at sap.com Mon Nov 9 10:39:22 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 9 Nov 2020 10:39:22 +0000 Subject: [11u] Do you have a plan to upgrade JDK11's JLine to 3.14.0 ? In-Reply-To: References: Message-ID: Hi Ichiroh, do I understand correctly, that your scenario works with 11.0.8 but now fails with 11.0.9? Then I guess it would be a regression introduced with the backport of JDK-8229815: Upgrade Jline to 3.12.1 [0]. I'm currently not aware of plans to also backport JDK-8241598: Upgrade JLine to 3.14.0 [1] to 11u. Also Oracle didn't backport it into their 11u release. So I fear if you're interested in getting the issue fixed, you'll need to investigate and see whether it can be fixed, either on top of 3.12.1 or by proposing a backport change for JDK-8241598. But I'm not sure on whether the latter one would be accepted. Best regards Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8229815 [1] https://bugs.openjdk.java.net/browse/JDK-8241598 > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ichiroh Takiguchi > Sent: Montag, 9. November 2020 03:20 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] Do you have a plan to upgrade JDK11's JLine to 3.14.0 ? > > Hello. > > Do you have a plan to upgrade JDK11's JLine to 3.14.0 ? > > It seems JDK 11.0.9's JLine is 3.12.1 [1] > > I found jshell's Tab key completion feature did not work on AIX's dtterm > terminal window. > I could not recreate this issue on JDK 11.0.8. > > I executed following instruction on JDK 11.0.9. > 1. Type "Sys" on jshell, > 2. Press Tab key. It should be changed to "System", but completion > feature did not work. > > It worked fine on aixterm and xterm window. > So it seems dtterm unique issue. > > I executed same instruction on JDK15 and JDK16 EA on AIX's dtterm, it > worked fine as expected. > It seemed JLine was upgraded to 3.14.0. [2] > > [1] > https://hg.openjdk.java.net/jdk- > updates/jdk11u/file/4fd46d208f0a/src/jdk.internal.le/share/legal/jline.md > [2: > https://github.com/openjdk/jdk/blob/master/src/jdk.internal.le/share/legal > /jline.md > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. From anleonar at redhat.com Mon Nov 9 13:22:29 2020 From: anleonar at redhat.com (Andrew Leonard) Date: Mon, 9 Nov 2020 13:22:29 +0000 Subject: RFR: jdk11u Backport 8234393: [macos] printing ignores printer tray In-Reply-To: References: Message-ID: Thanks Christoph On Mon, Nov 9, 2020 at 10:06 AM Langer, Christoph wrote: > Hi Andrew, > > looks good. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Andrew Leonard > > Sent: Montag, 9. November 2020 10:14 > > To: jdk-updates-dev at openjdk.java.net > > Subject: RFR: jdk11u Backport 8234393: [macos] printing ignores printer > tray > > > > Hi, > > Please can I request a review of this webrev for the backport of > > https://bugs.openjdk.java.net/browse/JDK-8234393 > > Webrev: https://cr.openjdk.java.net/~aleonard/8234393/webrev.00/ > > The patch is the same as from the original jdk patch, apart from the > > merge-conflict resolution. > > I have successfully tested tier1 and tier2. > > Thanks > > Andrew > From aph at redhat.com Mon Nov 9 16:27:11 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 9 Nov 2020 16:27:11 +0000 Subject: [11u] RFR: 8249607: C2: assert(!had_error) failed: bad dominance In-Reply-To: References: Message-ID: On 23/10/2020 18:30, Lindenmaier, Goetz wrote: > I am downporting this for parity with 11.0.10-oracle. > > http://cr.openjdk.java.net/~goetz/wr20/8249607-bad_dominance-jdk11/01/ > > I had to do real trivial resolves in loopnode.hpp due to space > Differences in the context. > > https://bugs.openjdk.java.net/browse/JDK-8249607 > https://hg.openjdk.java.net/jdk/jdk/rev/05d7a0663063 Did the test case fail for you before you applied the patch? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Nov 9 16:37:53 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 9 Nov 2020 16:37:53 +0000 Subject: [11u] RFR: 8208677: Move inner metaspace cleaning out of class unloading In-Reply-To: <3f386b3bfefe471f8a7bbd73e6bb9427@azul.com> References: <3f386b3bfefe471f8a7bbd73e6bb9427@azul.com> Message-ID: <30ec6f7c-8594-5d5d-b0e2-52cab63f0507@redhat.com> On 23/09/2020 22:09, Ekaterina Vergizova wrote: > I would like to backport 8208677 to 11u as a prerequisite for 8210422. > 8210422 fixes the crash described in 8251945 that is already fixed in 11.0.10-oracle. > The full list of suggested prerequisites is specified in [1]. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8208677 > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/aa3bfacc912c > Webrev for 11u: https://cr.openjdk.java.net/~apetushkov/8208677/webrev.00/ > > The patch applies almost cleanly except for the change in src/hotspot/share/code/nmethod.cpp. > It is already included in 11u by 8220718. > > Tested with tier1; the full list of backports specified in [1] is tested with full regression. This is turning into a maze of twisty passages. It does looks to me like we should try to fix this without importing such a long list of dependencies. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Nov 10 09:36:40 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 10 Nov 2020 09:36:40 +0000 Subject: [11u] RFR (S) 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse In-Reply-To: References: Message-ID: <38b5c5c7-9089-eb17-aae8-0d368db3d526@redhat.com> On 9/23/20 11:30 AM, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8245051 > https://hg.openjdk.java.net/jdk/jdk/rev/497fd9f9129c > > The patch does not apply cleanly, because context is different. I reapplied hunks by hand. Field > initializers need to follow the declaration order, as to not disturb -Wreorder. > > 11u variant: > https://cr.openjdk.java.net/~shade/8245051/webrev.11u.01/ > > Testing: tier{1,2} OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rob.mckenna at oracle.com Tue Nov 10 16:10:03 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 10 Nov 2020 16:10:03 +0000 Subject: [15u] Push JDK-8239105 and JDK-8254081 In-Reply-To: References: Message-ID: <20201110161003.GE16626@DESKTOP-JNNKIHU.localdomain> This appears to have been mistakenly pushed to the wrong repo. Leave it with me. -Rob On 05/11/20 16:37, Langer, Christoph wrote: > Hi Rob, > > JDK-8239105 [0] and JDK-8254081 [1] must have been backported to JDK15u already, since backport items with version 15.0.2 exist. Unfortunately, it seems that they have only been pushed to Oracle's internal repository. > > Is it ok if I push them to the public 15u, too? We're currently getting test failures. > > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8239105 > [1] https://bugs.openjdk.java.net/browse/JDK-8254081 > From phh at openjdk.java.net Tue Nov 10 16:20:58 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Tue, 10 Nov 2020 16:20:58 GMT Subject: [jdk13u-dev] RFR: 8249255: Build fails if source code in cygwin home dir In-Reply-To: References: Message-ID: <2iONxDTBbMQEojY9qZPcYEE30F-y24ww9HoXZfP_ObQ=.81384369-6f4d-4ec7-a398-c444fe42c5e5@github.com> On Fri, 6 Nov 2020 09:04:07 GMT, Ekaterina Vergizova wrote: > I would like to backport 8249255 to 13u, it's already included into 11u. > The patch doesn't apply cleanly, because 8239708 is not backported to 13u. > - the patch should be applied to make/autoconf/basics.m4 instead of make/autoconf/basic.m4 > - BASIC_FIXUP_PATH should be used instead of UTIL_FIXUP_PATH from the original patch > > Testing: jdk13u-dev placed in cygwin home is built successfully after applying the patch. Marked as reviewed by phh (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/10 From hohensee at amazon.com Tue Nov 10 16:17:53 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 10 Nov 2020 16:17:53 +0000 Subject: [jdk13u-dev] RFR: 8249255: Build fails if source code in cygwin home dir In-Reply-To: References: Message-ID: <7D0A9563-F4F2-49CD-BF9D-FC0FF7DAB16D@amazon.com> Lgtm (it's the 11u patch brought forward). Thanks, Paul ?On 11/6/20, 1:09 AM, "jdk-updates-dev on behalf of Ekaterina Vergizova" wrote: I would like to backport 8249255 to 13u, it's already included into 11u. The patch doesn't apply cleanly, because 8239708 is not backported to 13u. - the patch should be applied to make/autoconf/basics.m4 instead of make/autoconf/basic.m4 - BASIC_FIXUP_PATH should be used instead of UTIL_FIXUP_PATH from the original patch Testing: jdk13u-dev placed in cygwin home is built successfully after applying the patch. ------------- Commit messages: - Backport a9b7ae8ac20b6d4bec36f91a40c749c757c887af Changes: https://git.openjdk.java.net/jdk13u-dev/pull/10/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=10&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249255 Stats: 9 lines in 1 file changed: 5 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/10.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/10/head:pull/10 PR: https://git.openjdk.java.net/jdk13u-dev/pull/10 From hohensee at amazon.com Tue Nov 10 22:29:10 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 10 Nov 2020 22:29:10 +0000 Subject: RFR/A: 8234863: Increase default value of MaxInlineLevel Message-ID: <7436F56D-007F-4F46-ACD7-5886683A0BF6@amazon.com> I?d like to backport this patch, which increases the default value of MaxInlineDepth from 9 to 15. Since it changes behavior, it requires a backport CSR. Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8234863 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/3c8af950e849 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8235336 Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8256164 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8256165 The patch is clean, so I?ve tagged the issue with jdk11u-fix-request. The CSR needs review before we can proceed. The patch has been in use internally at Amazon with no reliability, footprint, or performance issues. I?ve run tier1-3 tests successfully. Thanks, Paul From hohensee at amazon.com Tue Nov 10 22:47:24 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 10 Nov 2020 22:47:24 +0000 Subject: [11u] RFR/A: 8234863: Increase default value of MaxInlineLevel Message-ID: <0740CD34-7F75-4896-99CD-EA1A64D3BA3A@amazon.com> Corrected subject to note that this is an 11u request. ?On 11/10/20, 2:30 PM, "jdk-updates-dev on behalf of Hohensee, Paul" wrote: I?d like to backport this patch, which increases the default value of MaxInlineDepth from 9 to 15. Since it changes behavior, it requires a backport CSR. Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8234863 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/3c8af950e849 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8235336 Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8256164 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8256165 The patch is clean, so I?ve tagged the issue with jdk11u-fix-request. The CSR needs review before we can proceed. The patch has been in use internally at Amazon with no reliability, footprint, or performance issues. I?ve run tier1-3 tests successfully. Thanks, Paul From github.com+71385633+kvergizova at openjdk.java.net Wed Nov 11 07:57:27 2020 From: github.com+71385633+kvergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 11 Nov 2020 07:57:27 GMT Subject: [jdk13u-dev] RFR: 8250928: JFR: Improve hash algorithm for stack traces Message-ID: I would like to backport 8250928 to 13u, it's already included into 11u. The patch applies almost cleanly except for the second hunk of jfrStackTrace.cpp due to different context (8236743 is not in 13u), reapplied manually. Tested with tier1 and jdk/jfr. ------------- Commit messages: - Backport 12879e91b43798750f9c7656dacc5085dd20cc96 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/12/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=12&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250928 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/12/head:pull/12 PR: https://git.openjdk.java.net/jdk13u-dev/pull/12 From shade at redhat.com Wed Nov 11 10:00:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 11 Nov 2020 11:00:23 +0100 Subject: [15u] MonitorInfo bugs: JDK-8249192 and JDK-8251118 Message-ID: Hi again, I asked this question in the relevant RFR threads, but they apparently went unnoticed. Therefore, let me ask this in a new thread. This is about the following issues: 8249192: MonitorInfo stores raw oops across safepoints 8251118: BiasedLocking::preserve_marks should not have a HandleMar At the time 15.0.1 was open for pushes, it had been stated that both issues were pushed to some CPU repo. I was under impression it was to appear in 15.0.1 release, but it did not. So, there are no changes in current 15u: https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8249192 https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251118 There is still the "Resolved" backport in 15.0.2 for one of the issues: https://bugs.openjdk.java.net/browse/JDK-8251485 ...and there is no resolved backport for another. So, is there a private 15.0.2 CPU repo within Oracle? Are we expecting both issues to come with 15.0.2 CPU push? Even in this case, can we push the change to open 15.0.2, so we would be able to test it in open repositories before next CPU hits? -- Thanks, -Aleksey From shade at redhat.com Wed Nov 11 10:12:53 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 11 Nov 2020 11:12:53 +0100 Subject: [11u] RFR (S) 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse In-Reply-To: <38b5c5c7-9089-eb17-aae8-0d368db3d526@redhat.com> References: <38b5c5c7-9089-eb17-aae8-0d368db3d526@redhat.com> Message-ID: <24b194d2-3b6e-8a67-20c1-445889297a7d@redhat.com> On 11/10/20 10:36 AM, Andrew Haley wrote: > On 9/23/20 11:30 AM, Aleksey Shipilev wrote: >> Original bug: >> https://bugs.openjdk.java.net/browse/JDK-8245051 >> https://hg.openjdk.java.net/jdk/jdk/rev/497fd9f9129c >> >> The patch does not apply cleanly, because context is different. I reapplied hunks by hand. Field >> initializers need to follow the declaration order, as to not disturb -Wreorder. >> >> 11u variant: >> https://cr.openjdk.java.net/~shade/8245051/webrev.11u.01/ >> >> Testing: tier{1,2} > > OK, thanks. Thanks, tagged. -- Thanks, -Aleksey From yan at openjdk.java.net Wed Nov 11 14:30:55 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 11 Nov 2020 14:30:55 GMT Subject: [jdk13u-dev] RFR: 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 07:52:46 GMT, Ekaterina Vergizova wrote: > I would like to backport 8250928 to 13u, it's already included into 11u. > > The patch applies almost cleanly except for the second hunk of jfrStackTrace.cpp due to different context (8236743 is not in 13u), reapplied manually. > > Tested with tier1 and jdk/jfr. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/12 From github.com+73305611+omikhaltsova at openjdk.java.net Wed Nov 11 16:26:05 2020 From: github.com+73305611+omikhaltsova at openjdk.java.net (Olga Mikhaltsova) Date: Wed, 11 Nov 2020 16:26:05 GMT Subject: [jdk13u-dev] RFR: 8228448: Jconsole can't connect to itself Message-ID: It's a backport of JDK-8228448 to jdk13u. The fix is already included to jdk11u (JDK-8248202). The patch applied cleanly. Checked this fix on macOS. ------------- Commit messages: - Backport 5decc88da489e751a0ed3b836aac0b6d51a1c2da Changes: https://git.openjdk.java.net/jdk13u-dev/pull/11/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=11&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8228448 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/11.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/11/head:pull/11 PR: https://git.openjdk.java.net/jdk13u-dev/pull/11 From robilad at openjdk.java.net Wed Nov 11 16:26:05 2020 From: robilad at openjdk.java.net (Dalibor Topic) Date: Wed, 11 Nov 2020 16:26:05 GMT Subject: [jdk13u-dev] RFR: 8228448: Jconsole can't connect to itself In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 16:05:49 GMT, Olga Mikhaltsova wrote: > It's a backport of JDK-8228448 to jdk13u. The fix is already included to jdk11u (JDK-8248202). > The patch applied cleanly. Checked this fix on macOS. Hi, please contact me at Dalibor.topic at oracle.com so that I can verify your GitHub account. Thanks! ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/11 From goetz.lindenmaier at sap.com Thu Nov 12 07:04:03 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 12 Nov 2020 07:04:03 +0000 Subject: [11u] RFR: 8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators In-Reply-To: References: Message-ID: Hi, Please check http://cr.openjdk.java.net/~goetz/wr20/8173658-post_class_unload-jdk11/02/ I had lost changes to the test file because of the C/C++ mismatch. Best regards, Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Freitag, 6. November 2020 09:01 To: jdk-updates-dev at openjdk.java.net Subject: [11u] RFR: 8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators Hi I am downporting this for parity with 11.0.10-oracle. I had to resolve and adapt the code, e.g. I replaced MutexLocker by MutexLockerEx. http://cr.openjdk.java.net/~goetz/wr20/8173658-post_class_unload-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8173658 https://hg.openjdk.java.net/jdk/jdk/rev/4774b50671ed Best regards, Goetz. From christoph.langer at sap.com Thu Nov 12 08:02:04 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 Nov 2020 08:02:04 +0000 Subject: [11u] RFR: 8218021: Have jarsigner preserve posix permission attributes Message-ID: Hi, please review the 11u backport of JDK-8218021: Have jarsigner preserve posix permission attributes. To backport it, I first had to resolve some conflicts: - Changes for jdk/internal/access/JavaUtilZipFileAccess.java went to jdk/internal/misc/JavaUtilZipFileAccess.java. - Change to module-info.java had to be adapted because of different package of JavaUtilZipFileAccess - Change to src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java had to be adapted because CRLCHECK is not present in 11u (was introduced with JDK-8242060 [0] in JDK 15 and not backported) - Omitted changes to src/java.base/share/classes/sun/security/provider/certpath/OCSP.java and test/jdk/sun/security/util/Resources/Usages.java for the same reason (missing JDK-8242060 [0]) Then I included the part from JDK-8242060 [0] that adds the class src/java.base/share/classes/sun/security/util/Event.java which is a prerequisite of the functionality to emit warnings when POSIX permissions are present. I obviously also resolved the changes to Event.java coming with JDK-8218021. Eventually, to make the test work, I first included the functionality of jdk.test.lib.SecurityTools.jar() from from JDK-8180573 [1]. Then, since zipfs of JDK11 does not support POSIX permissions, we need to generate the zip file against which we test using a higher JDK with zipfs POSIX support. For that, I borrowed and adapted some coding of the test that came with JDK-8250968 [2] which solves a similar problem of incorporating a zip file generated with external tools. I generated the zip file with JDK15 and imported it as a byte array declaration into the test body. The bug has a CSR attached but it was already approved for 11-pool, so no additional work here. Bug: https://bugs.openjdk.java.net/browse/JDK-8218021 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8218021.11u/ Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/d886e752a7b0 CSR: https://bugs.openjdk.java.net/browse/JDK-8247499 Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8242060 Add revocation checking to jarsigner [1] https://bugs.openjdk.java.net/browse/JDK-8180573 Refactor sun/security/tools shell tests to plain java tests [2] https://bugs.openjdk.java.net/browse/JDK-8250968 Symlinks attributes not preserved when using jarsigner on zip files From christoph.langer at sap.com Thu Nov 12 09:06:49 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 Nov 2020 09:06:49 +0000 Subject: [11u] RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files Message-ID: Hi, please review the 11u backport of JDK- 8250968: Symlinks attributes not preserved when using jarsigner on zip files. It is relating to and following up JDK-8218021: Have jarsigner preserve posix permission attributes for which I have just sent an RFR as well [0]. Both fixes are part of Oracle 11.0.10. So, with JDK-8218021 applied, this patch goes in quite smoothly. Only a few trivial merge conflicts needed to be resolved, half of them were copyright year conflicts. Furthermore, JavaUtilZipFileAccess.java.rej is in a different package in JDK11. The bug has a CSR attached which also was approved for 11-pool already. Bug: https://bugs.openjdk.java.net/browse/JDK-8250968 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8250968.11u/ Original Change: https://github.com/openjdk/jdk/commit/7686e871 CSR: https://bugs.openjdk.java.net/browse/JDK-8252517 Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-November/004118.html From linzang at tencent.com Thu Nov 12 10:40:54 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Thu, 12 Nov 2020 10:40:54 +0000 Subject: [Discuss] backport - parallel heap inspection for different GC Heap Message-ID: Dear All, Recently I have made an enhancement that inspect heap parallelly for different GC heap (PSS, G1, Shenandoah and Z) and the patches have been pushed to jdk master. The result show significant speedup of ?jmap -histo?. I am planing to backport them to jdk14u and jdk11u, and also add CMS Support if needed, but I want to know whether it will be accept before starting the real work, because it add ?parallel? option to jmap command, which may affect compatibility. May I ask your opinion about it? Thanks. FYI. The original bug: https://bugs.openjdk.java.net/browse/JDK-8214535 BRs, Lin From github.com+73305611+omikhaltsova at openjdk.java.net Thu Nov 12 11:58:54 2020 From: github.com+73305611+omikhaltsova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 12 Nov 2020 11:58:54 GMT Subject: [jdk13u-dev] Integrated: 8228448: Jconsole can't connect to itself In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 16:05:49 GMT, Olga Mikhaltsova wrote: > It's a backport of JDK-8228448 to jdk13u. The fix is already included to jdk11u (JDK-8248202). > The patch applied cleanly. Checked this fix on macOS. This pull request has now been integrated. Changeset: dfb19d52 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/dfb19d52 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8228448: Jconsole can't connect to itself Additions done to allow jconsole to connect to itself Backport-of: 5decc88da489e751a0ed3b836aac0b6d51a1c2da ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/11 From yan at openjdk.java.net Thu Nov 12 12:22:58 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 12 Nov 2020 12:22:58 GMT Subject: [jdk13u-dev] Integrated: 8229378: jdwp library loader in linker_md.c quietly truncates on buffer overflow In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 13:57:31 GMT, Yuri Nesterenko wrote: > This should be a clean backport. This pull request has now been integrated. Changeset: b0080193 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/b0080193 Stats: 40 lines in 2 files changed: 20 ins; 12 del; 8 mod 8229378: jdwp library loader in linker_md.c quietly truncates on buffer overflow Check buffer overflow when the jdwp agent full dll name is built Backport-of: d57af047374f29e96ebe78de165a0dd8c6a41d03 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/7 From github.com+71385633+kvergizova at openjdk.java.net Thu Nov 12 12:32:59 2020 From: github.com+71385633+kvergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 12 Nov 2020 12:32:59 GMT Subject: [jdk13u-dev] Integrated: 8249255: Build fails if source code in cygwin home dir In-Reply-To: References: Message-ID: On Fri, 6 Nov 2020 09:04:07 GMT, Ekaterina Vergizova wrote: > I would like to backport 8249255 to 13u, it's already included into 11u. > The patch doesn't apply cleanly, because 8239708 is not backported to 13u. > - the patch should be applied to make/autoconf/basics.m4 instead of make/autoconf/basic.m4 > - BASIC_FIXUP_PATH should be used instead of UTIL_FIXUP_PATH from the original patch > > Testing: jdk13u-dev placed in cygwin home is built successfully after applying the patch. This pull request has now been integrated. Changeset: 1ca24725 Author: kvergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/1ca24725 Stats: 9 lines in 1 file changed: 5 ins; 4 del; 0 mod 8249255: Build fails if source code in cygwin home dir Reviewed-by: phh Backport-of: a9b7ae8ac20b6d4bec36f91a40c749c757c887af ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/10 From github.com+71385633+kvergizova at openjdk.java.net Thu Nov 12 12:33:56 2020 From: github.com+71385633+kvergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 12 Nov 2020 12:33:56 GMT Subject: [jdk13u-dev] Integrated: 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: Message-ID: <6yC58XxHmDpinQcYUtLVm4rprNx1K-6_MZpuQj2hYbQ=.bc9c9081-69c1-41ec-81ce-94207a2add4f@github.com> On Wed, 11 Nov 2020 07:52:46 GMT, Ekaterina Vergizova wrote: > I would like to backport 8250928 to 13u, it's already included into 11u. > > The patch applies almost cleanly except for the second hunk of jfrStackTrace.cpp due to different context (8236743 is not in 13u), reapplied manually. > > Tested with tier1 and jdk/jfr. This pull request has now been integrated. Changeset: 43e72d28 Author: kvergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/43e72d28 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8250928: JFR: Improve hash algorithm for stack traces Reviewed-by: yan Backport-of: 12879e91b43798750f9c7656dacc5085dd20cc96 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/12 From yan at openjdk.java.net Thu Nov 12 15:07:10 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 12 Nov 2020 15:07:10 GMT Subject: [jdk13u-dev] RFR: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response Message-ID: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response ------------- Commit messages: - Backport da1abd18db7c38c421a86b81941811c035ed3ed5 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/13/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=13&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238270 Stats: 342 lines in 4 files changed: 336 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/13/head:pull/13 PR: https://git.openjdk.java.net/jdk13u-dev/pull/13 From yan at openjdk.java.net Thu Nov 12 15:10:58 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 12 Nov 2020 15:10:58 GMT Subject: [jdk13u-dev] Integrated: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 15:01:00 GMT, Yuri Nesterenko wrote: > 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response This pull request has now been integrated. Changeset: 552a0986 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/552a0986 Stats: 342 lines in 4 files changed: 336 ins; 0 del; 6 mod 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response The HTTP/2 Stream is updated to register a trivial data subscriber in case of 204 so that the END_STREAM is correctly processed. Backport-of: da1abd18db7c38c421a86b81941811c035ed3ed5 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/13 From shade at redhat.com Thu Nov 12 15:24:02 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 12 Nov 2020 16:24:02 +0100 Subject: [11u] RFR 8255550: x86: Assembler::cmpq(Address dst, Register src) encoding is incorrect Message-ID: <863259a3-3baa-4b22-c7e4-8917d646bdfe@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8255550 https://git.openjdk.java.net/jdk/commit/9e5bbff5 Backporting this for parity in 11u. The code shape is a bit different due to clean ups in later JDK. 11u patch is: diff -r 36e0ac0a01ad src/hotspot/cpu/x86/assembler_x86.cpp --- a/src/hotspot/cpu/x86/assembler_x86.cpp Wed May 20 11:29:11 2020 -0700 +++ b/src/hotspot/cpu/x86/assembler_x86.cpp Thu Nov 12 15:47:56 2020 +0100 @@ -8588,7 +8588,7 @@ void Assembler::cmpq(Address dst, Register src) { InstructionMark im(this); prefixq(dst, src); - emit_int8(0x3B); + emit_int8(0x39); emit_operand(src, dst); } Testing: checking code usages (none!), tier1 -- Thanks, -Aleksey From hohensee at amazon.com Thu Nov 12 15:29:09 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 12 Nov 2020 15:29:09 +0000 Subject: [11u] RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files Message-ID: Lgtm. Thanks, Paul ?On 11/12/20, 1:07 AM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: Hi, please review the 11u backport of JDK- 8250968: Symlinks attributes not preserved when using jarsigner on zip files. It is relating to and following up JDK-8218021: Have jarsigner preserve posix permission attributes for which I have just sent an RFR as well [0]. Both fixes are part of Oracle 11.0.10. So, with JDK-8218021 applied, this patch goes in quite smoothly. Only a few trivial merge conflicts needed to be resolved, half of them were copyright year conflicts. Furthermore, JavaUtilZipFileAccess.java.rej is in a different package in JDK11. The bug has a CSR attached which also was approved for 11-pool already. Bug: https://bugs.openjdk.java.net/browse/JDK-8250968 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8250968.11u/ Original Change: https://github.com/openjdk/jdk/commit/7686e871 CSR: https://bugs.openjdk.java.net/browse/JDK-8252517 Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-November/004118.html From hohensee at amazon.com Thu Nov 12 15:37:58 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 12 Nov 2020 15:37:58 +0000 Subject: [11u] RFR: 8218021: Have jarsigner preserve posix permission attributes Message-ID: Is there a reason not to first backport JDK-8242060 and JDK-8180573? Thanks, Paul ?On 11/12/20, 12:03 AM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: Hi, please review the 11u backport of JDK-8218021: Have jarsigner preserve posix permission attributes. To backport it, I first had to resolve some conflicts: - Changes for jdk/internal/access/JavaUtilZipFileAccess.java went to jdk/internal/misc/JavaUtilZipFileAccess.java. - Change to module-info.java had to be adapted because of different package of JavaUtilZipFileAccess - Change to src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java had to be adapted because CRLCHECK is not present in 11u (was introduced with JDK-8242060 [0] in JDK 15 and not backported) - Omitted changes to src/java.base/share/classes/sun/security/provider/certpath/OCSP.java and test/jdk/sun/security/util/Resources/Usages.java for the same reason (missing JDK-8242060 [0]) Then I included the part from JDK-8242060 [0] that adds the class src/java.base/share/classes/sun/security/util/Event.java which is a prerequisite of the functionality to emit warnings when POSIX permissions are present. I obviously also resolved the changes to Event.java coming with JDK-8218021. Eventually, to make the test work, I first included the functionality of jdk.test.lib.SecurityTools.jar() from from JDK-8180573 [1]. Then, since zipfs of JDK11 does not support POSIX permissions, we need to generate the zip file against which we test using a higher JDK with zipfs POSIX support. For that, I borrowed and adapted some coding of the test that came with JDK-8250968 [2] which solves a similar problem of incorporating a zip file generated with external tools. I generated the zip file with JDK15 and imported it as a byte array declaration into the test body. The bug has a CSR attached but it was already approved for 11-pool, so no additional work here. Bug: https://bugs.openjdk.java.net/browse/JDK-8218021 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8218021.11u/ Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/d886e752a7b0 CSR: https://bugs.openjdk.java.net/browse/JDK-8247499 Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8242060 Add revocation checking to jarsigner [1] https://bugs.openjdk.java.net/browse/JDK-8180573 Refactor sun/security/tools shell tests to plain java tests [2] https://bugs.openjdk.java.net/browse/JDK-8250968 Symlinks attributes not preserved when using jarsigner on zip files From hohensee at amazon.com Thu Nov 12 15:40:08 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 12 Nov 2020 15:40:08 +0000 Subject: [11u] RFR 8255550: x86: Assembler::cmpq(Address dst, Register src) encoding is incorrect Message-ID: <5060CFCB-16AE-46DE-A6CB-A47B24F0A981@amazon.com> Lgtm. Thanks Paul ?On 11/12/20, 7:25 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: Original bug: https://bugs.openjdk.java.net/browse/JDK-8255550 https://git.openjdk.java.net/jdk/commit/9e5bbff5 Backporting this for parity in 11u. The code shape is a bit different due to clean ups in later JDK. 11u patch is: diff -r 36e0ac0a01ad src/hotspot/cpu/x86/assembler_x86.cpp --- a/src/hotspot/cpu/x86/assembler_x86.cpp Wed May 20 11:29:11 2020 -0700 +++ b/src/hotspot/cpu/x86/assembler_x86.cpp Thu Nov 12 15:47:56 2020 +0100 @@ -8588,7 +8588,7 @@ void Assembler::cmpq(Address dst, Register src) { InstructionMark im(this); prefixq(dst, src); - emit_int8(0x3B); + emit_int8(0x39); emit_operand(src, dst); } Testing: checking code usages (none!), tier1 -- Thanks, -Aleksey From hohensee at amazon.com Thu Nov 12 16:05:56 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 12 Nov 2020 16:05:56 +0000 Subject: [Discuss] backport - parallel heap inspection for different GC Heap Message-ID: You mean 15u, not 14u, right? Because 14u is an orphan release afaik. I'm ok with adding "parallel" as a jmap command line option. It's purely additive, and so doesn't break existing code. You'll need backport CSRs, and you'll definitely have to add 11u CMS support. Thanks, Paul ?On 11/12/20, 2:42 AM, "jdk-updates-dev on behalf of linzang(??)" wrote: Dear All, Recently I have made an enhancement that inspect heap parallelly for different GC heap (PSS, G1, Shenandoah and Z) and the patches have been pushed to jdk master. The result show significant speedup of ?jmap -histo?. I am planing to backport them to jdk14u and jdk11u, and also add CMS Support if needed, but I want to know whether it will be accept before starting the real work, because it add ?parallel? option to jmap command, which may affect compatibility. May I ask your opinion about it? Thanks. FYI. The original bug: https://bugs.openjdk.java.net/browse/JDK-8214535 BRs, Lin From christoph.langer at sap.com Thu Nov 12 16:09:35 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 Nov 2020 16:09:35 +0000 Subject: [11u] RFR: 8218021: Have jarsigner preserve posix permission attributes In-Reply-To: References: Message-ID: Hi Paul, thanks for looking at this. I didn't want to backport JDK-8242060 because it is another enhancement for jarsigner with a CSR attached. Oracle did not backport it to 11u. So I didn't want to go all the way with nobody asking for it. It would be additional work and if worst comes to worse, additional trouble ?? As for JDK-8180573: This is a larger test refactoring where I didn't see the benefit of going through all the work to make it fit. It didn't apply cleanly and had several conflicts to begin with. And also no indication of it being ported to Oracle's 11u. Best regards Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 12. November 2020 16:38 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8218021: Have jarsigner preserve posix permission > attributes > > Is there a reason not to first backport JDK-8242060 and JDK-8180573? > > Thanks, > Paul > > ?On 11/12/20, 12:03 AM, "jdk-updates-dev on behalf of Langer, Christoph" > christoph.langer at sap.com> wrote: > > Hi, > > please review the 11u backport of JDK-8218021: Have jarsigner preserve > posix permission attributes. > > To backport it, I first had to resolve some conflicts: > - Changes for jdk/internal/access/JavaUtilZipFileAccess.java went to > jdk/internal/misc/JavaUtilZipFileAccess.java. > - Change to module-info.java had to be adapted because of different > package of JavaUtilZipFileAccess > - Change to > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java had to > be adapted because CRLCHECK is not present in 11u (was introduced with > JDK-8242060 [0] in JDK 15 and not backported) > - Omitted changes to > src/java.base/share/classes/sun/security/provider/certpath/OCSP.java and > test/jdk/sun/security/util/Resources/Usages.java for the same reason > (missing JDK-8242060 [0]) > > Then I included the part from JDK-8242060 [0] that adds the class > src/java.base/share/classes/sun/security/util/Event.java which is a > prerequisite of the functionality to emit warnings when POSIX permissions > are present. I obviously also resolved the changes to Event.java coming with > JDK-8218021. > > Eventually, to make the test work, I first included the functionality of > jdk.test.lib.SecurityTools.jar() from from JDK-8180573 [1]. Then, since zipfs of > JDK11 does not support POSIX permissions, we need to generate the zip file > against which we test using a higher JDK with zipfs POSIX support. For that, I > borrowed and adapted some coding of the test that came with JDK-8250968 > [2] which solves a similar problem of incorporating a zip file generated with > external tools. I generated the zip file with JDK15 and imported it as a byte > array declaration into the test body. > > The bug has a CSR attached but it was already approved for 11-pool, so no > additional work here. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218021 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8218021.11u/ > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/d886e752a7b0 > CSR: https://bugs.openjdk.java.net/browse/JDK-8247499 > > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8242060 Add revocation > checking to jarsigner > [1] https://bugs.openjdk.java.net/browse/JDK-8180573 Refactor > sun/security/tools shell tests to plain java tests > [2] https://bugs.openjdk.java.net/browse/JDK-8250968 Symlinks > attributes not preserved when using jarsigner on zip files > From christoph.langer at sap.com Thu Nov 12 16:10:30 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 Nov 2020 16:10:30 +0000 Subject: [11u] RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: References: Message-ID: Thanks! > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 12. November 2020 16:29 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8250968: Symlinks attributes not preserved when > using jarsigner on zip files > > Lgtm. > > Thanks, > Paul > > ?On 11/12/20, 1:07 AM, "jdk-updates-dev on behalf of Langer, Christoph" > christoph.langer at sap.com> wrote: > > Hi, > > please review the 11u backport of JDK- 8250968: Symlinks attributes not > preserved when using jarsigner on zip files. It is relating to and following up > JDK-8218021: Have jarsigner preserve posix permission attributes for which I > have just sent an RFR as well [0]. Both fixes are part of Oracle 11.0.10. > > So, with JDK-8218021 applied, this patch goes in quite smoothly. Only a few > trivial merge conflicts needed to be resolved, half of them were copyright > year conflicts. Furthermore, JavaUtilZipFileAccess.java.rej is in a different > package in JDK11. > > The bug has a CSR attached which also was approved for 11-pool already. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8250968 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8250968.11u/ > Original Change: https://github.com/openjdk/jdk/commit/7686e871 > CSR: https://bugs.openjdk.java.net/browse/JDK-8252517 > > Thanks > Christoph > > [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > November/004118.html > From github.com+71385633+kvergizova at openjdk.java.net Thu Nov 12 16:22:09 2020 From: github.com+71385633+kvergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 12 Nov 2020 16:22:09 GMT Subject: [jdk13u-dev] RFR: 8252754: Hash code calculation of JfrStackTrace is inconsistent Message-ID: I would like to backport 8252754 to 13u as follow-up fix for 8250928, that is approved for 13u. The patch applies almost cleanly except for the second hunk of jfrStackTrace.cpp due to different context (8236743 is not in 13u), reapplied manually. Tested with tier1 and jdk/jfr. ------------- Commit messages: - Backport 43d36857d03f7880aa8a776930ef9d02e92b9ed2 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/14/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=14&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252754 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/14.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/14/head:pull/14 PR: https://git.openjdk.java.net/jdk13u-dev/pull/14 From yan at openjdk.java.net Thu Nov 12 16:33:01 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 12 Nov 2020 16:33:01 GMT Subject: [jdk13u-dev] RFR: 8252754: Hash code calculation of JfrStackTrace is inconsistent In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 16:16:38 GMT, Ekaterina Vergizova wrote: > I would like to backport 8252754 to 13u as follow-up fix for 8250928, that is approved for 13u. > > The patch applies almost cleanly except for the second hunk of jfrStackTrace.cpp due to different context (8236743 is not in 13u), reapplied manually. > > Tested with tier1 and jdk/jfr. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/14 From zgu at redhat.com Thu Nov 12 21:51:57 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 12 Nov 2020 16:51:57 -0500 Subject: [11u] RFR 8255550: x86: Assembler::cmpq(Address dst, Register src) encoding is incorrect In-Reply-To: <863259a3-3baa-4b22-c7e4-8917d646bdfe@redhat.com> References: <863259a3-3baa-4b22-c7e4-8917d646bdfe@redhat.com> Message-ID: Looks good. -Zhengyu On 11/12/20 10:24 AM, Aleksey Shipilev wrote: > Original bug: > ? https://bugs.openjdk.java.net/browse/JDK-8255550 > ? https://git.openjdk.java.net/jdk/commit/9e5bbff5 > > Backporting this for parity in 11u. The code shape is a bit different > due to clean ups in later JDK. 11u patch is: > > diff -r 36e0ac0a01ad src/hotspot/cpu/x86/assembler_x86.cpp > --- a/src/hotspot/cpu/x86/assembler_x86.cpp???? Wed May 20 11:29:11 2020 > -0700 > +++ b/src/hotspot/cpu/x86/assembler_x86.cpp???? Thu Nov 12 15:47:56 2020 > +0100 > @@ -8588,7 +8588,7 @@ > ?void Assembler::cmpq(Address dst, Register src) { > ?? InstructionMark im(this); > ?? prefixq(dst, src); > -? emit_int8(0x3B); > +? emit_int8(0x39); > ?? emit_operand(src, dst); > ?} > > Testing: checking code usages (none!), tier1 > From linzang at tencent.com Fri Nov 13 05:00:58 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Fri, 13 Nov 2020 05:00:58 +0000 Subject: [Discuss] backport - parallel heap inspection for different GC Heap(Internet mail) In-Reply-To: References: Message-ID: Hi Paul, Yes, it should be 15u, not 14u, Thanks! I will first start from 11u for backporting and add CMS support. BRs, Lin ?On 2020/11/13, 12:06 AM, "Hohensee, Paul" wrote: You mean 15u, not 14u, right? Because 14u is an orphan release afaik. I'm ok with adding "parallel" as a jmap command line option. It's purely additive, and so doesn't break existing code. You'll need backport CSRs, and you'll definitely have to add 11u CMS support. Thanks, Paul On 11/12/20, 2:42 AM, "jdk-updates-dev on behalf of linzang(??)" wrote: Dear All, Recently I have made an enhancement that inspect heap parallelly for different GC heap (PSS, G1, Shenandoah and Z) and the patches have been pushed to jdk master. The result show significant speedup of ?jmap -histo?. I am planing to backport them to jdk14u and jdk11u, and also add CMS Support if needed, but I want to know whether it will be accept before starting the real work, because it add ?parallel? option to jmap command, which may affect compatibility. May I ask your opinion about it? Thanks. FYI. The original bug: https://bugs.openjdk.java.net/browse/JDK-8214535 BRs, Lin From shade at redhat.com Fri Nov 13 08:20:13 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 13 Nov 2020 09:20:13 +0100 Subject: [11u] RFR 8255550: x86: Assembler::cmpq(Address dst, Register src) encoding is incorrect In-Reply-To: References: <863259a3-3baa-4b22-c7e4-8917d646bdfe@redhat.com> Message-ID: On 11/12/20 10:51 PM, Zhengyu Gu wrote: > Looks good. Thanks, tagged. -- -Aleksey From shade at redhat.com Fri Nov 13 08:23:18 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 13 Nov 2020 09:23:18 +0100 Subject: [11u] RFR 8250825: C2 crashes with assert(field != __null) failed: missing field Message-ID: <08ff1672-1298-4bfb-85c4-622d0b4a1386@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8250825 https://hg.openjdk.java.net/jdk/jdk/rev/bd4d4ab3c2c1 11u does not have is_reference_type helper, and so the patch does not apply cleanly. 11u variant: https://cr.openjdk.java.net/~shade/8250825/webrev.11u.01/ Testing: new test (fails without the fix, passes with it); tier{1,2} -- Thanks, -Aleksey From shade at redhat.com Fri Nov 13 08:28:46 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 13 Nov 2020 09:28:46 +0100 Subject: [11u] RFR 8255466: C2 crashes at ciObject::get_oop() const+0x0 Message-ID: <0a32a3e0-c390-d763-d405-74440ccd7bb4@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8255466 https://git.openjdk.java.net/jdk/commit/56eb5f54 vectorIntrinsics.cpp hunk is not applicable, because it was added by JDK-8223347 in JDK 16. The rest applies cleanly. 11u variant: https://cr.openjdk.java.net/~shade/8255466/webrev.11u.01/ Testing: new test (fails without the patch, passes with it); tier{1,2} -- Thanks, -Aleksey From shade at redhat.com Fri Nov 13 08:46:32 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 13 Nov 2020 09:46:32 +0100 Subject: [11u] RFR 8243488: Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket Message-ID: <74f10fed-7df1-9615-0df3-e41ba74dfce9@redhat.com> Original improvement: https://bugs.openjdk.java.net/browse/JDK-8243488 https://hg.openjdk.java.net/jdk/jdk/rev/cf9358cd555b Backporting better tests. The conflict for 11u is in removal of the old test (that is now subsumed by the new one). Removed that test by hand. 11u variant: https://cr.openjdk.java.net/~shade/8243488/webrev.11u.01/ Testing: affected tests on Linux x86_64 -- Thanks, -Aleksey From abakhtin at openjdk.java.net Fri Nov 13 09:05:18 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Fri, 13 Nov 2020 09:05:18 GMT Subject: [jdk13u-dev] RFR: 8248865: Document JNDI/LDAP timeout properties Message-ID: I would like to backport JDK-8248865 to 13u. The patch applies cleanly. ------------- Commit messages: - 8248865: Document JNDI/LDAP timeout properties Changes: https://git.openjdk.java.net/jdk13u-dev/pull/15/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=15&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248865 Stats: 37 lines in 1 file changed: 35 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/15.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/15/head:pull/15 PR: https://git.openjdk.java.net/jdk13u-dev/pull/15 From abakhtin at openjdk.java.net Fri Nov 13 11:14:24 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Fri, 13 Nov 2020 11:14:24 GMT Subject: [jdk13u-dev] RFR: 8248865: Document JNDI/LDAP timeout properties [v2] In-Reply-To: References: Message-ID: <4oN-B6AN1ozZclKnWWEQWIIFsczTxiyOrjhXEoxq5p4=.8e7feea6-e974-460b-a7c1-7b16989f8a87@github.com> > I would like to backport JDK-8248865 to 13u. > The patch applies cleanly. Alexey Bakhtin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. ------------- Changes: - all: https://git.openjdk.java.net/jdk13u-dev/pull/15/files - new: https://git.openjdk.java.net/jdk13u-dev/pull/15/files/96fa7f0c..552a0986 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=15&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=15&range=00-01 Stats: 37 lines in 1 file changed: 1 ins; 35 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/15.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/15/head:pull/15 PR: https://git.openjdk.java.net/jdk13u-dev/pull/15 From abakhtin at openjdk.java.net Fri Nov 13 11:14:25 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Fri, 13 Nov 2020 11:14:25 GMT Subject: [jdk13u-dev] Integrated: 8248865: Document JNDI/LDAP timeout properties In-Reply-To: References: Message-ID: <3ucCwdasexj6-iG3FjX3bmrGIXBvEQHAOXxLAHv-5rQ=.212bd6e1-28a1-42ef-b4d5-40d33de2e5a1@github.com> On Fri, 13 Nov 2020 08:59:19 GMT, Alexey Bakhtin wrote: > I would like to backport JDK-8248865 to 13u. > The patch applies cleanly. This pull request has now been integrated. Changeset: 552a0986 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/552a0986 Stats: 342 lines in 4 files changed: 336 ins; 0 del; 6 mod 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response The HTTP/2 Stream is updated to register a trivial data subscriber in case of 204 so that the END_STREAM is correctly processed. Backport-of: da1abd18db7c38c421a86b81941811c035ed3ed5 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/15 From abakhtin at openjdk.java.net Fri Nov 13 11:30:07 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Fri, 13 Nov 2020 11:30:07 GMT Subject: [jdk13u-dev] RFR: 8248865: Document JNDI/LDAP timeout properties Message-ID: <-yLOV0oQ_2PvrQShDZqb8WiFmFikauS3ie0j-pypuHY=.4e4f45f4-2bda-4b57-bebb-6237f103fca4@github.com> I would like to backport 8248865 to 13u. The patch applies cleanly ------------- Commit messages: - 8248865: Document JNDI/LDAP timeout properties Changes: https://git.openjdk.java.net/jdk13u-dev/pull/16/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=16&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248865 Stats: 37 lines in 1 file changed: 35 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/16.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/16/head:pull/16 PR: https://git.openjdk.java.net/jdk13u-dev/pull/16 From abakhtin at openjdk.java.net Fri Nov 13 11:38:58 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Fri, 13 Nov 2020 11:38:58 GMT Subject: [jdk13u-dev] Integrated: 8248865: Document JNDI/LDAP timeout properties In-Reply-To: <-yLOV0oQ_2PvrQShDZqb8WiFmFikauS3ie0j-pypuHY=.4e4f45f4-2bda-4b57-bebb-6237f103fca4@github.com> References: <-yLOV0oQ_2PvrQShDZqb8WiFmFikauS3ie0j-pypuHY=.4e4f45f4-2bda-4b57-bebb-6237f103fca4@github.com> Message-ID: On Fri, 13 Nov 2020 11:23:05 GMT, Alexey Bakhtin wrote: > I would like to backport 8248865 to 13u. > The patch applies cleanly This pull request has now been integrated. Changeset: 492fafb2 Author: Alexey Bakhtin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/492fafb2 Stats: 37 lines in 1 file changed: 35 ins; 1 del; 1 mod 8248865: Document JNDI/LDAP timeout properties Documentation added in the module-info of java.naming Backport-of: d308558d4fb98fc85b6574a9de229b255fc7ee7c ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/16 From martin.doerr at sap.com Fri Nov 13 15:05:47 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 13 Nov 2020 15:05:47 +0000 Subject: [11u] RFR: 8173361: various crashes in JvmtiExport::post_compiled_method_load In-Reply-To: References: Message-ID: Hi G?tz, backport looks good. Thanks, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 6. November 2020 08:45 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8173361: various crashes in > JvmtiExport::post_compiled_method_load > > Hi, > > I downport this for parity with 11.0.10-oracle. > The code does not fit very well. > I removed a guarantee because is_unloading() does not exist in 11. > I turned some MutexLocker to MutexLockerEx which takes the > Mutex::_no_safepoint_check_flag enum argument. > > http://cr.openjdk.java.net/~goetz/wr20/8173361-post_compiled_method- > jdk11/01/webrev/ > > Please review. > > There are some follow up changes for jvmti which all need similar adaptions. > > https://bugs.openjdk.java.net/browse/JDK-8173361 > https://hg.openjdk.java.net/jdk/jdk/rev/e79ece2eb1ba > > Best regards, > Goetz From hohensee at amazon.com Fri Nov 13 15:19:54 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 13 Nov 2020 15:19:54 +0000 Subject: [11u] RFR 8250825: C2 crashes with assert(field != __null) failed: missing field Message-ID: Lgtm. Thanks, Paul ?On 11/13/20, 12:24 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: Original fix: https://bugs.openjdk.java.net/browse/JDK-8250825 https://hg.openjdk.java.net/jdk/jdk/rev/bd4d4ab3c2c1 11u does not have is_reference_type helper, and so the patch does not apply cleanly. 11u variant: https://cr.openjdk.java.net/~shade/8250825/webrev.11u.01/ Testing: new test (fails without the fix, passes with it); tier{1,2} -- Thanks, -Aleksey From hohensee at amazon.com Fri Nov 13 15:25:35 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 13 Nov 2020 15:25:35 +0000 Subject: [11u] RFR 8243488: Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket Message-ID: <2352747D-BFCB-4D8C-9F9A-6D42A913B1C1@amazon.com> Lgtm. Thanks, Paul ?On 11/13/20, 12:47 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: Original improvement: https://bugs.openjdk.java.net/browse/JDK-8243488 https://hg.openjdk.java.net/jdk/jdk/rev/cf9358cd555b Backporting better tests. The conflict for 11u is in removal of the old test (that is now subsumed by the new one). Removed that test by hand. 11u variant: https://cr.openjdk.java.net/~shade/8243488/webrev.11u.01/ Testing: affected tests on Linux x86_64 -- Thanks, -Aleksey From hohensee at amazon.com Fri Nov 13 15:22:48 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 13 Nov 2020 15:22:48 +0000 Subject: [11u] RFR 8255466: C2 crashes at ciObject::get_oop() const+0x0 Message-ID: <9B007EAC-1EBF-4323-9FEF-85DA148F4A9E@amazon.com> Lgtm. Thanks, Paul ?On 11/13/20, 12:29 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: Original fix: https://bugs.openjdk.java.net/browse/JDK-8255466 https://git.openjdk.java.net/jdk/commit/56eb5f54 vectorIntrinsics.cpp hunk is not applicable, because it was added by JDK-8223347 in JDK 16. The rest applies cleanly. 11u variant: https://cr.openjdk.java.net/~shade/8255466/webrev.11u.01/ Testing: new test (fails without the patch, passes with it); tier{1,2} -- Thanks, -Aleksey From martin.doerr at sap.com Fri Nov 13 15:38:06 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 13 Nov 2020 15:38:06 +0000 Subject: [11u] RFR: 8173361: various crashes in JvmtiExport::post_compiled_method_load In-Reply-To: References: Message-ID: Please make sure to check all follow-up fixes before pushing. I think we need to request backport of the following one, too: https://bugs.openjdk.java.net/browse/JDK-8235218 Best regards, Martin > -----Original Message----- > From: Doerr, Martin > Sent: Freitag, 13. November 2020 16:06 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8173361: various crashes in > JvmtiExport::post_compiled_method_load > > Hi G?tz, > > backport looks good. > > Thanks, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Freitag, 6. November 2020 08:45 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8173361: various crashes in > > JvmtiExport::post_compiled_method_load > > > > Hi, > > > > I downport this for parity with 11.0.10-oracle. > > The code does not fit very well. > > I removed a guarantee because is_unloading() does not exist in 11. > > I turned some MutexLocker to MutexLockerEx which takes the > > Mutex::_no_safepoint_check_flag enum argument. > > > > http://cr.openjdk.java.net/~goetz/wr20/8173361-post_compiled_method- > > jdk11/01/webrev/ > > > > Please review. > > > > There are some follow up changes for jvmti which all need similar > adaptions. > > > > https://bugs.openjdk.java.net/browse/JDK-8173361 > > https://hg.openjdk.java.net/jdk/jdk/rev/e79ece2eb1ba > > > > Best regards, > > Goetz From github.com+71385633+kvergizova at openjdk.java.net Fri Nov 13 16:14:57 2020 From: github.com+71385633+kvergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 13 Nov 2020 16:14:57 GMT Subject: [jdk13u-dev] Integrated: 8252754: Hash code calculation of JfrStackTrace is inconsistent In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 16:16:38 GMT, Ekaterina Vergizova wrote: > I would like to backport 8252754 to 13u as follow-up fix for 8250928, that is approved for 13u. > > The patch applies almost cleanly except for the second hunk of jfrStackTrace.cpp due to different context (8236743 is not in 13u), reapplied manually. > > Tested with tier1 and jdk/jfr. This pull request has now been integrated. Changeset: 95d9a1c2 Author: kvergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/95d9a1c2 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8252754: Hash code calculation of JfrStackTrace is inconsistent Reviewed-by: yan Backport-of: 43d36857d03f7880aa8a776930ef9d02e92b9ed2 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/14 From hohensee at amazon.com Fri Nov 13 16:33:29 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 13 Nov 2020 16:33:29 +0000 Subject: [11u] RFR: 8218021: Have jarsigner preserve posix permission attributes In-Reply-To: <0CD523AD-D7A7-44E1-96AB-345C10DCCBC6@amazon.com> References: <0CD523AD-D7A7-44E1-96AB-345C10DCCBC6@amazon.com> Message-ID: Seems reasonable. Reviewed. Thanks, Paul ?On 11/12/20, 12:45 PM, "Paul Hohensee" wrote: ?On 11/12/20, 8:10 AM, "Langer, Christoph" wrote: Hi Paul, thanks for looking at this. I didn't want to backport JDK-8242060 because it is another enhancement for jarsigner with a CSR attached. Oracle did not backport it to 11u. So I didn't want to go all the way with nobody asking for it. It would be additional work and if worst comes to worse, additional trouble ?? As for JDK-8180573: This is a larger test refactoring where I didn't see the benefit of going through all the work to make it fit. It didn't apply cleanly and had several conflicts to begin with. And also no indication of it being ported to Oracle's 11u. Best regards Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 12. November 2020 16:38 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8218021: Have jarsigner preserve posix permission > attributes > > Is there a reason not to first backport JDK-8242060 and JDK-8180573? > > Thanks, > Paul > > On 11/12/20, 12:03 AM, "jdk-updates-dev on behalf of Langer, Christoph" > christoph.langer at sap.com> wrote: > > Hi, > > please review the 11u backport of JDK-8218021: Have jarsigner preserve > posix permission attributes. > > To backport it, I first had to resolve some conflicts: > - Changes for jdk/internal/access/JavaUtilZipFileAccess.java went to > jdk/internal/misc/JavaUtilZipFileAccess.java. > - Change to module-info.java had to be adapted because of different > package of JavaUtilZipFileAccess > - Change to > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java had to > be adapted because CRLCHECK is not present in 11u (was introduced with > JDK-8242060 [0] in JDK 15 and not backported) > - Omitted changes to > src/java.base/share/classes/sun/security/provider/certpath/OCSP.java and > test/jdk/sun/security/util/Resources/Usages.java for the same reason > (missing JDK-8242060 [0]) > > Then I included the part from JDK-8242060 [0] that adds the class > src/java.base/share/classes/sun/security/util/Event.java which is a > prerequisite of the functionality to emit warnings when POSIX permissions > are present. I obviously also resolved the changes to Event.java coming with > JDK-8218021. > > Eventually, to make the test work, I first included the functionality of > jdk.test.lib.SecurityTools.jar() from from JDK-8180573 [1]. Then, since zipfs of > JDK11 does not support POSIX permissions, we need to generate the zip file > against which we test using a higher JDK with zipfs POSIX support. For that, I > borrowed and adapted some coding of the test that came with JDK-8250968 > [2] which solves a similar problem of incorporating a zip file generated with > external tools. I generated the zip file with JDK15 and imported it as a byte > array declaration into the test body. > > The bug has a CSR attached but it was already approved for 11-pool, so no > additional work here. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218021 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8218021.11u/ > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/d886e752a7b0 > CSR: https://bugs.openjdk.java.net/browse/JDK-8247499 > > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8242060 Add revocation > checking to jarsigner > [1] https://bugs.openjdk.java.net/browse/JDK-8180573 Refactor > sun/security/tools shell tests to plain java tests > [2] https://bugs.openjdk.java.net/browse/JDK-8250968 Symlinks > attributes not preserved when using jarsigner on zip files > From christoph.langer at sap.com Fri Nov 13 16:43:29 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 13 Nov 2020 16:43:29 +0000 Subject: [11u] RFR: 8218021: Have jarsigner preserve posix permission attributes In-Reply-To: References: <0CD523AD-D7A7-44E1-96AB-345C10DCCBC6@amazon.com> Message-ID: Thanks, Paul. > -----Original Message----- > From: Hohensee, Paul > Sent: Freitag, 13. November 2020 17:33 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8218021: Have jarsigner preserve posix permission > attributes > > Seems reasonable. Reviewed. > > Thanks, > Paul > > ?On 11/12/20, 12:45 PM, "Paul Hohensee" wrote: > > ?On 11/12/20, 8:10 AM, "Langer, Christoph" > wrote: > > Hi Paul, > > thanks for looking at this. > > I didn't want to backport JDK-8242060 because it is another enhancement > for jarsigner with a CSR attached. Oracle did not backport it to 11u. So I didn't > want to go all the way with nobody asking for it. It would be additional work > and if worst comes to worse, additional trouble ?? > As for JDK-8180573: This is a larger test refactoring where I didn't see the > benefit of going through all the work to make it fit. It didn't apply cleanly and > had several conflicts to begin with. And also no indication of it being ported > to Oracle's 11u. > > Best regards > Christoph > > > -----Original Message----- > > From: Hohensee, Paul > > Sent: Donnerstag, 12. November 2020 16:38 > > To: Langer, Christoph ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8218021: Have jarsigner preserve posix > permission > > attributes > > > > Is there a reason not to first backport JDK-8242060 and JDK-8180573? > > > > Thanks, > > Paul > > > > On 11/12/20, 12:03 AM, "jdk-updates-dev on behalf of Langer, > Christoph" > > > christoph.langer at sap.com> wrote: > > > > Hi, > > > > please review the 11u backport of JDK-8218021: Have jarsigner > preserve > > posix permission attributes. > > > > To backport it, I first had to resolve some conflicts: > > - Changes for jdk/internal/access/JavaUtilZipFileAccess.java went to > > jdk/internal/misc/JavaUtilZipFileAccess.java. > > - Change to module-info.java had to be adapted because of different > > package of JavaUtilZipFileAccess > > - Change to > > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java > had to > > be adapted because CRLCHECK is not present in 11u (was introduced > with > > JDK-8242060 [0] in JDK 15 and not backported) > > - Omitted changes to > > src/java.base/share/classes/sun/security/provider/certpath/OCSP.java > and > > test/jdk/sun/security/util/Resources/Usages.java for the same reason > > (missing JDK-8242060 [0]) > > > > Then I included the part from JDK-8242060 [0] that adds the class > > src/java.base/share/classes/sun/security/util/Event.java which is a > > prerequisite of the functionality to emit warnings when POSIX > permissions > > are present. I obviously also resolved the changes to Event.java coming > with > > JDK-8218021. > > > > Eventually, to make the test work, I first included the functionality of > > jdk.test.lib.SecurityTools.jar() from from JDK-8180573 [1]. Then, since > zipfs of > > JDK11 does not support POSIX permissions, we need to generate the > zip file > > against which we test using a higher JDK with zipfs POSIX support. For > that, I > > borrowed and adapted some coding of the test that came with JDK- > 8250968 > > [2] which solves a similar problem of incorporating a zip file generated > with > > external tools. I generated the zip file with JDK15 and imported it as a > byte > > array declaration into the test body. > > > > The bug has a CSR attached but it was already approved for 11-pool, > so no > > additional work here. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218021 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8218021.11u/ > > Original Change: > https://hg.openjdk.java.net/jdk/jdk/rev/d886e752a7b0 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8247499 > > > > Thanks > > Christoph > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8242060 Add > revocation > > checking to jarsigner > > [1] https://bugs.openjdk.java.net/browse/JDK-8180573 Refactor > > sun/security/tools shell tests to plain java tests > > [2] https://bugs.openjdk.java.net/browse/JDK-8250968 Symlinks > > attributes not preserved when using jarsigner on zip files > > > From goetz.lindenmaier at sap.com Fri Nov 13 17:15:02 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 13 Nov 2020 17:15:02 +0000 Subject: [11u] RFR: 8173361: various crashes in JvmtiExport::post_compiled_method_load In-Reply-To: References: Message-ID: Hi Martin, Thanks for pointing me to that change. I requested Downport for it and will push them together. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Friday, November 13, 2020 4:38 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8173361: various crashes in > JvmtiExport::post_compiled_method_load > > Please make sure to check all follow-up fixes before pushing. I think we need > to request backport of the following one, too: > https://bugs.openjdk.java.net/browse/JDK-8235218 > > Best regards, > Martin > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Freitag, 13. November 2020 16:06 > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8173361: various crashes in > > JvmtiExport::post_compiled_method_load > > > > Hi G?tz, > > > > backport looks good. > > > > Thanks, > > Martin > > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of Lindenmaier, Goetz > > > Sent: Freitag, 6. November 2020 08:45 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: [11u] RFR: 8173361: various crashes in > > > JvmtiExport::post_compiled_method_load > > > > > > Hi, > > > > > > I downport this for parity with 11.0.10-oracle. > > > The code does not fit very well. > > > I removed a guarantee because is_unloading() does not exist in 11. > > > I turned some MutexLocker to MutexLockerEx which takes the > > > Mutex::_no_safepoint_check_flag enum argument. > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8173361- > post_compiled_method- > > > jdk11/01/webrev/ > > > > > > Please review. > > > > > > There are some follow up changes for jvmti which all need similar > > adaptions. > > > > > > https://bugs.openjdk.java.net/browse/JDK-8173361 > > > https://hg.openjdk.java.net/jdk/jdk/rev/e79ece2eb1ba > > > > > > Best regards, > > > Goetz From abakhtin at openjdk.java.net Mon Nov 16 10:48:04 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Mon, 16 Nov 2020 10:48:04 GMT Subject: [jdk13u-dev] RFR: 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect Message-ID: I would like to backport 8151678 to 13u as a follow-up of JDK-8160768. The patch applies cleanly This patch is also required for clean backport of JDK-8062947 ------------- Commit messages: - 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect Changes: https://git.openjdk.java.net/jdk13u-dev/pull/17/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=17&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8151678 Stats: 623 lines in 5 files changed: 265 ins; 180 del; 178 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/17.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/17/head:pull/17 PR: https://git.openjdk.java.net/jdk13u-dev/pull/17 From abakhtin at openjdk.java.net Mon Nov 16 13:11:00 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Mon, 16 Nov 2020 13:11:00 GMT Subject: [jdk13u-dev] Integrated: 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 10:42:32 GMT, Alexey Bakhtin wrote: > I would like to backport 8151678 to 13u as a follow-up of JDK-8160768. > The patch applies cleanly > This patch is also required for clean backport of JDK-8062947 This pull request has now been integrated. Changeset: d41400cf Author: Alexey Bakhtin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/d41400cf Stats: 623 lines in 5 files changed: 265 ins; 180 del; 178 mod 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect Backport-of: 49a4d4b87ecf56d44b644df65f9a2a2c74f922f3 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/17 From abakhtin at openjdk.java.net Mon Nov 16 14:08:14 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Mon, 16 Nov 2020 14:08:14 GMT Subject: [jdk13u-dev] RFR: 8062947: Fix exception message to correctly represent LDAP connection failure Message-ID: I'd like to backport JDK-8062947 to 13u as a follow-up of JDK-8160768. Patch applies cleanly. This patch is also required for clean backport of JDK-8245527 ------------- Commit messages: - 8062947: Fix exception message to correctly represent LDAP connection failure Changes: https://git.openjdk.java.net/jdk13u-dev/pull/18/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=18&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8062947 Stats: 246 lines in 3 files changed: 195 ins; 41 del; 10 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/18.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/18/head:pull/18 PR: https://git.openjdk.java.net/jdk13u-dev/pull/18 From yan at azul.com Mon Nov 16 16:09:12 2020 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 16 Nov 2020 19:09:12 +0300 Subject: [13u notice] jdk13u is now in Git Message-ID: <8751c860-928e-cf77-52b3-4aebfd88a8ee@azul.com> Hi all, finally, jdk13u master repository is now https://github.com/openjdk/jdk13u. It is still identical to hg version but we expect to make 13.0.6+1 soon. Thanks! --yan From christoph.langer at sap.com Tue Nov 17 10:19:02 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 17 Nov 2020 10:19:02 +0000 Subject: [11u] RFR: 8256452: Integrate missing part of JDK-8232370 to 11u Message-ID: Hi, please review this 11u only change. JDK-8232370 [0] had been backported before JDK-8210560 [1]. So, at the time, the update for RedefineImplementor.java was omitted since that file was only introduced with JDK-8210560. Now, after the latter was backported, we should also update RedefineImplementor.java to get the IDE green again. Bug: https://bugs.openjdk.java.net/browse/JDK-8256452 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8256452.11u/ Original Change (JDK-8232370): https://hg.openjdk.java.net/jdk/jdk/rev/5f14a659a8cb Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8232370 [1] https://bugs.openjdk.java.net/browse/JDK-8210560 From evergizova at openjdk.java.net Tue Nov 17 12:02:11 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Tue, 17 Nov 2020 12:02:11 GMT Subject: [jdk13u-dev] RFR: 8239477: jdk/jfr/jcmd/TestJcmdStartStopDefault.java fails -XX:+VerifyOops with "verify_oop: rsi: broken oop" Message-ID: I would like to backport 8239477 to 13u, it's already included into 11u. The patch doesn't apply cleanly due to the different context (8245957 is not in 13u), reapplied manually. Tested with tier1 and jdk/jfr, the affected test fails without the patch and passes with it. ------------- Commit messages: - Backport b5775c831d27544870b6155cadc7d9861b93c438 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/19/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=19&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8239477 Stats: 9 lines in 1 file changed: 4 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/19.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/19/head:pull/19 PR: https://git.openjdk.java.net/jdk13u-dev/pull/19 From goetz.lindenmaier at sap.com Tue Nov 17 14:02:35 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 17 Nov 2020 14:02:35 +0000 Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" Message-ID: Hi, I have another update to this change. I had to resolve it again because of the Minimal VM fix 8235218 pushed after 8173361. http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/03/ Also, I reqested downport for Minimal VM fixes required after this change: JDK-8236124 Minimal VM slowdebug build failed after JDK-8212160 JDK-8235456 Minimal VM is broken after JDK-8212160 These both are clean downports once this is pushed. I would appreciate reviews ?? Best regards, Goetz. Hi, Please look at http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/02/ I had lost the changes to the test file because of C/C++ mismatch. Best regards, Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Freitag, 6. November 2020 09:39 To: jdk-updates-dev at openjdk.java.net Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" Hi I am downporting this for parity with 11.0.10-oracle. http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/01/ I had to resolve and fis in quite some places: src/hotspot/share/code/nmethod.cpp Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. Added 'this' to call of JvmtiDeferredEvent::compiled_method_unload_event() src/hotspot/share/code/nmethod.hpp Trivial, resolved. src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. I removed NMethodIterator::only_alive_and_not_unloading and call next_alive instead. The NMethodIterator differs in head a lot. src/hotspot/share/prims/jvmtiExport.cpp Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, nmethod *nm) from head which is called in src/hotspot/share/prims/jvmtiExport.hpp Resolved. Deleted method has different arguments. src/hotspot/share/prims/jvmtiImpl.hpp Resolved. src/hotspot/share/runtime/serviceThread.cpp Context different. Please review. https://bugs.openjdk.java.net/browse/JDK-8212160 https://hg.openjdk.java.net/jdk/jdk/rev/366c0f357ee6 Best regards, Goetz From github.com+73305611+omikhaltsova at openjdk.java.net Tue Nov 17 19:09:14 2020 From: github.com+73305611+omikhaltsova at openjdk.java.net (Olga Mikhaltsova) Date: Tue, 17 Nov 2020 19:09:14 GMT Subject: [jdk13u-dev] RFR: 8226374: Restrict TLS signature schemes and named groups Message-ID: Please review this backport of JDK-8226374 to jdk13u. This patch is also required for clean backport of JDK-8233954 to jdk13u. The patch didn't apply cleanly due to the context change in SignatureScheme.java by backport of JDK-8242141. A slight conflict was merged. ------------- Commit messages: - Backport 316140ff92af7ac1aadb74de9cd37a5f3c412406 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/20/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=20&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8226374 Stats: 1116 lines in 18 files changed: 497 ins; 313 del; 306 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/20/head:pull/20 PR: https://git.openjdk.java.net/jdk13u-dev/pull/20 From mbalao at redhat.com Tue Nov 17 20:05:36 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 17 Nov 2020 17:05:36 -0300 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: Message-ID: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> Hi, Apologize for being so late on this one -was on CPU and leave after that-. I know this has been committed already, but I have some concerns about the decisions taken. > file src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java > Deleting class DHEKAKeyDerivation failed because the code in 11 uses JsseJce.getKeyAgreement() > where the patch uses KeyAgreement.getInstance(). Yes, because SunJSSE may be initialized with a specific crypto provider for 'FIPS mode' in 11 (note that KeyAgreement.getInstance may choose any enabled security provider in order of preference). This feature was later removed. > > As I understand 8217835, the experimental FIPS feature cannot be used in > 11, it just remained in the code. So I skipped adapting NamedGroups to the > old behaviour, I can not test it anyways. > What do you think, do we need to add this code to NamedGroupd.java again? > The conclusion in 8217835 that SunJSSE FIPS mode cannot be used in JDK9+ was never accurate and, today, not true. In particular, the provider load ignored the extra parameter (from java.security configuration line) because there was a bug that was fixed later [1]. In my opinion, we should not remove SunJSSE FIPS mode in 11u. This would be removing an API from a stable release. Our users and us rely on that. My suggestion would be to make the necessary changes so the crypto provider used by SunJSSE remain to be the one obtained from JsseJce, even for the key derivation schemes here. Thoughts? Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8230923 From abakhtin at openjdk.java.net Wed Nov 18 09:46:08 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Wed, 18 Nov 2020 09:46:08 GMT Subject: [jdk13u-dev] Integrated: 8062947: Fix exception message to correctly represent LDAP connection failure In-Reply-To: References: Message-ID: <_BAGu28fBEUVTBPI4QuRX9wTV3LbzcOlf_2KIsPztFQ=.787abff2-a83c-447b-8494-eca69200124e@github.com> On Mon, 16 Nov 2020 14:02:21 GMT, Alexey Bakhtin wrote: > I'd like to backport JDK-8062947 to 13u as a follow-up of JDK-8160768. > Patch applies cleanly. > This patch is also required for clean backport of JDK-8245527 This pull request has now been integrated. Changeset: a4794b2c Author: Alexey Bakhtin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/a4794b2c Stats: 246 lines in 3 files changed: 195 ins; 41 del; 10 mod 8062947: Fix exception message to correctly represent LDAP connection failure Backport-of: 61864c28d1eb6ce9cfcb9ce57b1741c57630d502 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/18 From sgehwolf at redhat.com Wed Nov 18 10:25:26 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 18 Nov 2020 11:25:26 +0100 Subject: [11u] RFR: 8256483: [TESTBUG] serviceability/jvmti/GetClassMethods/libOverpassMethods.c fails to compile on gcc 4.4.x Message-ID: <3b27eef3c4dd1682b8c1cb39293d1fd54a23511b.camel@redhat.com> Hi, Please review this build fix for test-image on gcc 4.4.x systems. JDK- 8216324 is included with 11.0.10+1 and has an initial declaration in the for loop. The fix is trivial and makes the build proceed further. Another issue relating to JDK-8249821 is still ongoing. This breaks our vanilla OpenJDK 11 builds. This isn't really suitable for jdk/jdk as it's moved on to later toolchains. JDK 11.0.9 built fine with gcc 4.4.x, though, so I'd like to fix it in 11. Bug: https://bugs.openjdk.java.net/browse/JDK-8256483 Proposed fix: diff --git a/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMethods.c b/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMethods.c --- a/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMethods.c +++ b/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMethods.c @@ -95,7 +95,8 @@ return NULL; } - for (int i = 0; i < method_count; i++) { + int i; + for (i = 0; i < method_count; i++) { jint modifiers = 0; err = JNI_ENV_PTR(jvmti)->GetMethodModifiers(JNI_ENV_ARG2(jvmti, methods[i], &modifiers)); if (err != JVMTI_ERROR_NONE) { Testing: Build of test-image target proceeds with it in place. Thoughts? Thanks, Severin From shade at redhat.com Wed Nov 18 11:18:31 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 18 Nov 2020 12:18:31 +0100 Subject: [11u] RFR: 8256483: [TESTBUG] serviceability/jvmti/GetClassMethods/libOverpassMethods.c fails to compile on gcc 4.4.x In-Reply-To: <3b27eef3c4dd1682b8c1cb39293d1fd54a23511b.camel@redhat.com> References: <3b27eef3c4dd1682b8c1cb39293d1fd54a23511b.camel@redhat.com> Message-ID: On 11/18/20 11:25 AM, Severin Gehwolf wrote: > diff --git a/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMethods.c b/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMethods.c > --- a/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMethods.c > +++ b/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMethods.c > @@ -95,7 +95,8 @@ > return NULL; > } > > - for (int i = 0; i < method_count; i++) { > + int i; > + for (i = 0; i < method_count; i++) { > jint modifiers = 0; > err = JNI_ENV_PTR(jvmti)->GetMethodModifiers(JNI_ENV_ARG2(jvmti, methods[i], &modifiers)); > if (err != JVMTI_ERROR_NONE) { > > > Testing: Build of test-image target proceeds with it in place. > > Thoughts? First thought: ew. Looks okay. -- -Aleksey From matthias.baesken at sap.com Wed Nov 18 12:09:40 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 18 Nov 2020 12:09:40 +0000 Subject: [11u] RFR: 8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators Message-ID: Hi G?tz , thanks for the backport. >Please check >http://cr.openjdk.java.net/~goetz/wr20/8173658-post_class_unload-jdk11/02/ > > I had lost changes to the test file because of the C/C++ mismatch. Looks good to me . 2 smaller remarks (do not need another webrev) : 1) I would like to prefer to have set_thread_state in 11 at one place too , we have this in jdk/jdk ( src/hotspot/share/runtime/thread.inline.hpp ) : 127inline void JavaThread::set_thread_state(JavaThreadState s) { 128 assert(current_or_null() == NULL || current_or_null() == this, 129 "state change should only be called by the current thread"); 130#if defined(PPC64) || defined (AARCH64) 131 // Use membars when accessing volatile _thread_state. See 132 // Threads::create_vm() for size checks. 133 Atomic::release_store((volatile jint*)&_thread_state, (jint)s); 134#else 135 _thread_state = s; 136#endif 137} But it's up to you if you want to include it in this patch or not. 2) When importing your patch I was running into "Extraneous text in comment src/hotspot/share/runtime/thread.hpp:1223: Trailing whitespace" You might want to check this. Best regards, Matthias From shade at redhat.com Wed Nov 18 12:09:55 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 18 Nov 2020 13:09:55 +0100 Subject: [11u] RFR (S) 8255457: Shenandoah: cleanup ShenandoahMarkTask Message-ID: Original RFE: https://bugs.openjdk.java.net/browse/JDK-8255457 https://git.openjdk.java.net/jdk/commit/1215b1a8 This patch does not apply cleanly to 11u, because of the contextual differences. Most significant difference is that in HEAD JDK the affected class is trivially copyable, and the shared code already adjusted to accept that. 11u, however, would fail to compile due to odd cv-stripping casts. Therefore, I had to keep copying constructors and assignment operators. 11u webrev: https://cr.openjdk.java.net/~shade/8255457/webrev.11u.01/ Testing: Linux {x86_64, x86_32} hotspot_gc_shenandoah -- Thanks, -Aleksey From goetz.lindenmaier at sap.com Wed Nov 18 12:22:41 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 18 Nov 2020 12:22:41 +0000 Subject: [11u] RFR: 8256483: [TESTBUG] serviceability/jvmti/GetClassMethods/libOverpassMethods.c fails to compile on gcc 4.4.x In-Reply-To: <3b27eef3c4dd1682b8c1cb39293d1fd54a23511b.camel@redhat.com> References: <3b27eef3c4dd1682b8c1cb39293d1fd54a23511b.camel@redhat.com> Message-ID: Hi Severin, Thanks for fixing this. Looks good. Could you please check that the other two changes out for review compile with your toolchain? They also bring new C code I converted from C++. [11u] RFR: 8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-November/004117.html and [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-November/004162.html Best regards, Goetz. > -----Original Message----- > From: Severin Gehwolf > Sent: Wednesday, November 18, 2020 11:25 AM > To: jdk-updates-dev > Cc: Lindenmaier, Goetz > Subject: [11u] RFR: 8256483: [TESTBUG] > serviceability/jvmti/GetClassMethods/libOverpassMethods.c fails to compile > on gcc 4.4.x > > Hi, > > Please review this build fix for test-image on gcc 4.4.x systems. JDK- > 8216324 is included with 11.0.10+1 and has an initial declaration in > the for loop. The fix is trivial and makes the build proceed further. > Another issue relating to JDK-8249821 is still ongoing. This breaks our > vanilla OpenJDK 11 builds. This isn't really suitable for jdk/jdk as > it's moved on to later toolchains. JDK 11.0.9 built fine with gcc > 4.4.x, though, so I'd like to fix it in 11. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8256483 > > Proposed fix: > > diff --git > a/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMeth > ods.c > b/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMeth > ods.c > --- > a/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMeth > ods.c > +++ > b/test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMeth > ods.c > @@ -95,7 +95,8 @@ > return NULL; > } > > - for (int i = 0; i < method_count; i++) { > + int i; > + for (i = 0; i < method_count; i++) { > jint modifiers = 0; > err = JNI_ENV_PTR(jvmti)->GetMethodModifiers(JNI_ENV_ARG2(jvmti, > methods[i], &modifiers)); > if (err != JVMTI_ERROR_NONE) { > > > Testing: Build of test-image target proceeds with it in place. > > Thoughts? > > Thanks, > Severin From filipe.roque at premium-minds.com Wed Nov 18 12:44:44 2020 From: filipe.roque at premium-minds.com (Filipe Roque) Date: Wed, 18 Nov 2020 12:44:44 +0000 Subject: [11u] RFR: 8211450: UndetVar::dup is not copying the kind field to the duplicated instance In-Reply-To: References: Message-ID: ping ? Thanks, Filipe Roque On Thu, 2020-10-15 at 15:17 +0000, Filipe Roque wrote: > Hi, > > I would like to backport this fix to 11u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211450 > Fix (Original): https://hg.openjdk.java.net/jdk/jdk/rev/52155b28cdb7 > > I've verified the patch and would be glad if someone could sponsor > the > backport. > > The original patch itself doesn't apply cleanly, due to conflict with > copyright year in file > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > > I have edited the original patch to remove that conflict, which can > be > found below. > > For additional context, as my team is trying to move from Java 8 to > Java 11, we have encountered the bug > https://bugs.openjdk.java.net/browse/JDK-8232766. Although it is > marked > Unresolved, this bug has been fixed in JDK 12 and all later > versions. > > I have bisected the jdk sources to discovered which changeset fixed > the > commit and discovered it was the JDK-8211450. > > Thanks, > Filipe Roque > > > > # HG changeset patch > # User vromero > # Date 1541719432 18000 > # Node ID 52155b28cdb7fc2a8c8a096c561c68be87fb8cc8 > # Parent 4ad404da00887d427e9a3822fa8a7355fdac9832 > 8211450: UndetVar::dup is not copying the kind field to the > duplicated > instance > Reviewed-by: mcimadamore > > diff -r 4ad404da0088 -r 52155b28cdb7 > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > Thu Nov 08 23:31:08 2018 +0100 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > Thu Nov 08 18:23:52 2018 -0500 > @@ -2020,6 +2020,7 @@ > for (IncorporationAction action : incorporationActions) > { > uv2.incorporationActions.add(action.dup(uv2)); > } > + uv2.kind = kind; > } > > @Override > diff -r 4ad404da0088 -r 52155b28cdb7 > test/langtools/tools/javac/T8211450/ThrownTypeVarTest.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/langtools/tools/javac/T8211450/ThrownTypeVarTest.java > Thu Nov 08 18:23:52 2018 -0500 > @@ -0,0 +1,49 @@ > +/* > + * Copyright (c) 2018, Oracle and/or its affiliates. All rights > reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify > it > + * under the terms of the GNU General Public License version 2 only, > as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY > or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > License > + * version 2 for more details (a copy is included in the LICENSE > file > that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software > Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 > USA > + * or visit www.oracle.com if you need additional information or > have > any > + * questions. > + */ > + > +/* > + * @test > + * @bug 8211450 > + * @summary UndetVar::dup is not copying the kind field to the > duplicated instance > + * @compile ThrownTypeVarTest.java > + */ > + > +import java.io.*; > + > +public class ThrownTypeVarTest { > + void repro() throws IOException { > + when(f(any())); > + } > + > + interface MyInt {} > + > + T2 f(MyInt g) throws > IOException, E2 { > + return null; > + } > + > + static T3 any() { > + return null; > + } > + > + static void when(T4 methodCall) {} > +} > From shade at redhat.com Wed Nov 18 13:17:27 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 18 Nov 2020 14:17:27 +0100 Subject: [15u] MonitorInfo bugs: JDK-8249192 and JDK-8251118 In-Reply-To: References: Message-ID: On 11/11/20 11:00 AM, Aleksey Shipilev wrote: > Hi again, > > I asked this question in the relevant RFR threads, but they apparently went unnoticed. Therefore, > let me ask this in a new thread. > > This is about the following issues: > 8249192: MonitorInfo stores raw oops across safepoints > 8251118: BiasedLocking::preserve_marks should not have a HandleMar > > At the time 15.0.1 was open for pushes, it had been stated that both issues were pushed to some CPU > repo. I was under impression it was to appear in 15.0.1 release, but it did not. So, there are no > changes in current 15u: > https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8249192 > https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251118 > > There is still the "Resolved" backport in 15.0.2 for one of the issues: > https://bugs.openjdk.java.net/browse/JDK-8251485 > > ...and there is no resolved backport for another. > > So, is there a private 15.0.2 CPU repo within Oracle? Are we expecting both issues to come with > 15.0.2 CPU push? Even in this case, can we push the change to open 15.0.2, so we would be able to > test it in open repositories before next CPU hits? Friendly reminder. -- Thanks, -Aleksey From hohensee at amazon.com Wed Nov 18 13:46:43 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 18 Nov 2020 13:46:43 +0000 Subject: [11u] RFR: 8211450: UndetVar::dup is not copying the kind field to the duplicated instance Message-ID: <95B10861-F0CB-4FFD-979A-DC78A135F1AC@amazon.com> Lgtm. I've applied the patch and the included test passes. I'll sponsor. Thanks, Paul ?On 11/18/20, 4:45 AM, "jdk-updates-dev on behalf of Filipe Roque" wrote: ping ? Thanks, Filipe Roque On Thu, 2020-10-15 at 15:17 +0000, Filipe Roque wrote: > Hi, > > I would like to backport this fix to 11u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211450 > Fix (Original): https://hg.openjdk.java.net/jdk/jdk/rev/52155b28cdb7 > > I've verified the patch and would be glad if someone could sponsor > the > backport. > > The original patch itself doesn't apply cleanly, due to conflict with > copyright year in file > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > > I have edited the original patch to remove that conflict, which can > be > found below. > > For additional context, as my team is trying to move from Java 8 to > Java 11, we have encountered the bug > https://bugs.openjdk.java.net/browse/JDK-8232766. Although it is > marked > Unresolved, this bug has been fixed in JDK 12 and all later > versions. > > I have bisected the jdk sources to discovered which changeset fixed > the > commit and discovered it was the JDK-8211450. > > Thanks, > Filipe Roque > > > > # HG changeset patch > # User vromero > # Date 1541719432 18000 > # Node ID 52155b28cdb7fc2a8c8a096c561c68be87fb8cc8 > # Parent 4ad404da00887d427e9a3822fa8a7355fdac9832 > 8211450: UndetVar::dup is not copying the kind field to the > duplicated > instance > Reviewed-by: mcimadamore > > diff -r 4ad404da0088 -r 52155b28cdb7 > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > Thu Nov 08 23:31:08 2018 +0100 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > Thu Nov 08 18:23:52 2018 -0500 > @@ -2020,6 +2020,7 @@ > for (IncorporationAction action : incorporationActions) > { > uv2.incorporationActions.add(action.dup(uv2)); > } > + uv2.kind = kind; > } > > @Override > diff -r 4ad404da0088 -r 52155b28cdb7 > test/langtools/tools/javac/T8211450/ThrownTypeVarTest.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/langtools/tools/javac/T8211450/ThrownTypeVarTest.java > Thu Nov 08 18:23:52 2018 -0500 > @@ -0,0 +1,49 @@ > +/* > + * Copyright (c) 2018, Oracle and/or its affiliates. All rights > reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify > it > + * under the terms of the GNU General Public License version 2 only, > as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY > or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > License > + * version 2 for more details (a copy is included in the LICENSE > file > that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software > Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 > USA > + * or visit www.oracle.com if you need additional information or > have > any > + * questions. > + */ > + > +/* > + * @test > + * @bug 8211450 > + * @summary UndetVar::dup is not copying the kind field to the > duplicated instance > + * @compile ThrownTypeVarTest.java > + */ > + > +import java.io.*; > + > +public class ThrownTypeVarTest { > + void repro() throws IOException { > + when(f(any())); > + } > + > + interface MyInt {} > + > + T2 f(MyInt g) throws > IOException, E2 { > + return null; > + } > + > + static T3 any() { > + return null; > + } > + > + static void when(T4 methodCall) {} > +} > From yan at openjdk.java.net Wed Nov 18 15:15:01 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 18 Nov 2020 15:15:01 GMT Subject: [jdk13u-dev] RFR: 8226374: Restrict TLS signature schemes and named groups In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 19:03:15 GMT, Olga Mikhaltsova wrote: > Please review this backport of JDK-8226374 to jdk13u. > This patch is also required for clean backport of JDK-8233954 to jdk13u. > > The patch didn't apply cleanly due to the context change in SignatureScheme.java by backport of JDK-8242141. > A slight conflict was merged. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/20 From abakhtin at openjdk.java.net Wed Nov 18 15:44:04 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Wed, 18 Nov 2020 15:44:04 GMT Subject: [jdk13u-dev] RFR: 8226374: Restrict TLS signature schemes and named groups In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 15:11:52 GMT, Yuri Nesterenko wrote: >> Please review this backport of JDK-8226374 to jdk13u. >> This patch is also required for clean backport of JDK-8233954 to jdk13u. >> >> The patch didn't apply cleanly due to the context change in SignatureScheme.java by backport of JDK-8242141. >> A slight conflict was merged. > > Marked as reviewed by yan (Reviewer). I'm not a reviewer, but I looked through the patch and it looks good to me. ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/20 From github.com+73305611+omikhaltsova at openjdk.java.net Wed Nov 18 15:56:07 2020 From: github.com+73305611+omikhaltsova at openjdk.java.net (Olga Mikhaltsova) Date: Wed, 18 Nov 2020 15:56:07 GMT Subject: [jdk13u-dev] Integrated: 8226374: Restrict TLS signature schemes and named groups In-Reply-To: References: Message-ID: <9kU3ezbqMCH1TfBhRMjvyKKpbuHzjewSd9fz7gO1Vpk=.53fbca8d-a6f5-4d1e-9e08-fb83c8b831ed@github.com> On Tue, 17 Nov 2020 19:03:15 GMT, Olga Mikhaltsova wrote: > Please review this backport of JDK-8226374 to jdk13u. > This patch is also required for clean backport of JDK-8233954 to jdk13u. > > The patch didn't apply cleanly due to the context change in SignatureScheme.java by backport of JDK-8242141. > A slight conflict was merged. This pull request has now been integrated. Changeset: 384445d2 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/384445d2 Stats: 1116 lines in 18 files changed: 497 ins; 313 del; 306 mod 8226374: Restrict TLS signature schemes and named groups Reviewed-by: yan Backport-of: 316140ff92af7ac1aadb74de9cd37a5f3c412406 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/20 From sgehwolf at redhat.com Wed Nov 18 19:36:01 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 18 Nov 2020 20:36:01 +0100 Subject: [11u] RFR: 8256557: libharfbuzz fails to link on gcc 4.4.x due to -Wl,-z,defs Message-ID: <83e11a83ebd1ac8e633d9058d6398a65a5da5f06.camel@redhat.com> Hi, Please review this JDK 11.0.10 specific fix for building slowdebug on a system with gcc 4.4.x (e.g. RHEL 6). JDK-8249821 got backported to 11.0.10 and that causes one slight difference in how libharfbuzz is being linked: When it was linked as part of libfontmanager.so there was no -Wl,-z,defs. After JDK-8249821 it's there, which makes the build fail for slowdebug on this old toolchain. The proposal is to remove - Wl,-z,defs from LDFLAGS_JDKLIB for libharfbuzz as was done before. Bug: https://bugs.openjdk.java.net/browse/JDK-8256557 Patch: diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -608,8 +608,9 @@ truncwarn wvarhidenmem wvarhidemem wbadlkginit identexpected \ hidevf w_novirtualdescr arrowrtn2 unknownpragma, \ DISABLED_WARNINGS_microsoft := 4267 4244 4090 4146 4334 4819 4101 4068 4805 4138, \ - LDFLAGS := $(LDFLAGS_JDKLIB) \ - $(call SET_SHARED_LIBRARY_ORIGIN), \ + LDFLAGS := $(subst -Xlinker -z -Xlinker defs,, \ + $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))) \ + $(call SET_SHARED_LIBRARY_ORIGIN), \ LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ LDFLAGS_aix := -Wl$(COMMA)-berok, \ LIBS := $(BUILD_LIBHARFBUZZ), \ Tested build on gcc 4.4.x slowdebug. Works with the patch. I know this isn't pretty, but as there were no code changes done in JDK-8249821 it would preserve the status quo. Plus, it would unbreak our vanilla JDK 11 builds. Thoughts? Thanks, Severin From richard.reingruber at sap.com Wed Nov 18 21:28:46 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 18 Nov 2020 21:28:46 +0000 Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" In-Reply-To: References: Message-ID: Hi G?tz, I'm getting ready to review this. If I'm not mistaken, your patch has 8173658 as prerequisite which is currently out for review. It took me a few keystrokes and mouse clicks to figure this out. I'd suggest informing about prerequisite patches in the RFR mail. Cheers, Richard. -----Original Message----- From: jdk-updates-dev On Behalf Of Lindenmaier, Goetz Sent: Dienstag, 17. November 2020 15:03 To: jdk-updates-dev at openjdk.java.net Subject: [CAUTION] RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" Hi, I have another update to this change. I had to resolve it again because of the Minimal VM fix 8235218 pushed after 8173361. http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/03/ Also, I reqested downport for Minimal VM fixes required after this change: JDK-8236124 Minimal VM slowdebug build failed after JDK-8212160 JDK-8235456 Minimal VM is broken after JDK-8212160 These both are clean downports once this is pushed. I would appreciate reviews ?? Best regards, Goetz. Hi, Please look at http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/02/ I had lost the changes to the test file because of C/C++ mismatch. Best regards, Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Freitag, 6. November 2020 09:39 To: jdk-updates-dev at openjdk.java.net Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" Hi I am downporting this for parity with 11.0.10-oracle. http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/01/ I had to resolve and fis in quite some places: src/hotspot/share/code/nmethod.cpp Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. Added 'this' to call of JvmtiDeferredEvent::compiled_method_unload_event() src/hotspot/share/code/nmethod.hpp Trivial, resolved. src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. I removed NMethodIterator::only_alive_and_not_unloading and call next_alive instead. The NMethodIterator differs in head a lot. src/hotspot/share/prims/jvmtiExport.cpp Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, nmethod *nm) from head which is called in src/hotspot/share/prims/jvmtiExport.hpp Resolved. Deleted method has different arguments. src/hotspot/share/prims/jvmtiImpl.hpp Resolved. src/hotspot/share/runtime/serviceThread.cpp Context different. Please review. https://bugs.openjdk.java.net/browse/JDK-8212160 https://hg.openjdk.java.net/jdk/jdk/rev/366c0f357ee6 Best regards, Goetz From hohensee at amazon.com Thu Nov 19 00:48:47 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 19 Nov 2020 00:48:47 +0000 Subject: [11u] RFR: 8256557: libharfbuzz fails to link on gcc 4.4.x due to -Wl, -z, defs Message-ID: <7DBFFABE-0AC1-4957-9590-3F74A8052271@amazon.com> Set according to gcc version instead? Thanks, Paul ?On 11/18/20, 11:37 AM, "jdk-updates-dev on behalf of Severin Gehwolf" wrote: Hi, Please review this JDK 11.0.10 specific fix for building slowdebug on a system with gcc 4.4.x (e.g. RHEL 6). JDK-8249821 got backported to 11.0.10 and that causes one slight difference in how libharfbuzz is being linked: When it was linked as part of libfontmanager.so there was no -Wl,-z,defs. After JDK-8249821 it's there, which makes the build fail for slowdebug on this old toolchain. The proposal is to remove - Wl,-z,defs from LDFLAGS_JDKLIB for libharfbuzz as was done before. Bug: https://bugs.openjdk.java.net/browse/JDK-8256557 Patch: diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -608,8 +608,9 @@ truncwarn wvarhidenmem wvarhidemem wbadlkginit identexpected \ hidevf w_novirtualdescr arrowrtn2 unknownpragma, \ DISABLED_WARNINGS_microsoft := 4267 4244 4090 4146 4334 4819 4101 4068 4805 4138, \ - LDFLAGS := $(LDFLAGS_JDKLIB) \ - $(call SET_SHARED_LIBRARY_ORIGIN), \ + LDFLAGS := $(subst -Xlinker -z -Xlinker defs,, \ + $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))) \ + $(call SET_SHARED_LIBRARY_ORIGIN), \ LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ LDFLAGS_aix := -Wl$(COMMA)-berok, \ LIBS := $(BUILD_LIBHARFBUZZ), \ Tested build on gcc 4.4.x slowdebug. Works with the patch. I know this isn't pretty, but as there were no code changes done in JDK-8249821 it would preserve the status quo. Plus, it would unbreak our vanilla JDK 11 builds. Thoughts? Thanks, Severin From matthias.baesken at sap.com Thu Nov 19 08:05:20 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 19 Nov 2020 08:05:20 +0000 Subject: [11u] RFR: 8256452: Integrate missing part of JDK-8232370 to 11u In-Reply-To: References: Message-ID: Hi Christoph, the change looks good thanks for backporting. Best regards, Matthias >please review this 11u only change. > >JDK-8232370 [0] had been backported before JDK-8210560 [1]. So, at the time, the update for RedefineImplementor.java was omitted since that file was only introduced with JDK-8210560. Now, after the latter >was backported, we should also update RedefineImplementor.java to get the IDE green again. > >Bug: https://bugs.openjdk.java.net/browse/JDK-8256452 >Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8256452.11u/ >Original Change (JDK-8232370): https://hg.openjdk.java.net/jdk/jdk/rev/5f14a659a8cb > >Thanks >Christoph > >[0] https://bugs.openjdk.java.net/browse/JDK-8232370 >[1] https://bugs.openjdk.java.net/browse/JDK-8210560 From volker.simonis at gmail.com Thu Nov 19 10:10:28 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 19 Nov 2020 11:10:28 +0100 Subject: [8u, 11u] Disabling TLS 1.0/1.1 in 8u292/11.0.11 ? Message-ID: Hi 8u/11u maintainers, Oracle has announced in their "Cryptographic Roadmap" [1] that they will disable TLS 1.0/1.1 in Oracle jdk 7,8,11 by 2021-04-20 and in jdk 16 by 2021-03-16. A change/csr for jdk 16 [2,3] is currently under review [4]. Do you plan to do the same for 8u292 and 11.0.11 in April 2021? Thank you and best regards, Volker [1] https://java.com/en/jre-jdk-cryptoroadmap.html [2] https://bugs.openjdk.java.net/browse/JDK-8202343 [3] https://bugs.openjdk.java.net/browse/JDK-8254713 [4] https://github.com/openjdk/jdk/pull/1235 From goetz.lindenmaier at sap.com Thu Nov 19 10:16:08 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Nov 2020 10:16:08 +0000 Subject: [11u] RFR: 8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators In-Reply-To: References: Message-ID: Hi Matthias, Thanks for reviewing. 1) You mean I should move the function body to the .inline.hpp file? I would like to leave the function in the header to avoid having to fix includes in platforms other than ppc and s390. 2) I will make sure it jchecks fine before pushing. Best regards, Goetz. From: Baesken, Matthias Sent: Wednesday, November 18, 2020 1:10 PM To: jdk-updates-dev at openjdk.java.net Cc: Lindenmaier, Goetz ; Doerr, Martin Subject: Re : [11u] RFR: 8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators Hi G?tz , thanks for the backport. >Please check >http://cr.openjdk.java.net/~goetz/wr20/8173658-post_class_unload-jdk11/02/ > > I had lost changes to the test file because of the C/C++ mismatch. Looks good to me . 2 smaller remarks (do not need another webrev) : 1) I would like to prefer to have set_thread_state in 11 at one place too , we have this in jdk/jdk ( src/hotspot/share/runtime/thread.inline.hpp ) : 127inline void JavaThread::set_thread_state(JavaThreadState s) { 128 assert(current_or_null() == NULL || current_or_null() == this, 129 "state change should only be called by the current thread"); 130#if defined(PPC64) || defined (AARCH64) 131 // Use membars when accessing volatile _thread_state. See 132 // Threads::create_vm() for size checks. 133 Atomic::release_store((volatile jint*)&_thread_state, (jint)s); 134#else 135 _thread_state = s; 136#endif 137} But it's up to you if you want to include it in this patch or not. 2) When importing your patch I was running into "Extraneous text in comment src/hotspot/share/runtime/thread.hpp:1223: Trailing whitespace" You might want to check this. Best regards, Matthias From matthias.baesken at sap.com Thu Nov 19 10:53:48 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 19 Nov 2020 10:53:48 +0000 Subject: [11u] RFR: 8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators In-Reply-To: References: Message-ID: Hi G?tz, regarding 1) yes in thread.iniline.hpp like it is done in jdk/jdk . (but maybe there is some follow up change for this and we might "nicely" backport the follow up change ) Best regards, Matthias From: Lindenmaier, Goetz Sent: Donnerstag, 19. November 2020 11:16 To: Baesken, Matthias ; jdk-updates-dev at openjdk.java.net Cc: Doerr, Martin Subject: RE: Re : [11u] RFR: 8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators Hi Matthias, Thanks for reviewing. 1) You mean I should move the function body to the .inline.hpp file? I would like to leave the function in the header to avoid having to fix includes in platforms other than ppc and s390. 2) I will make sure it jchecks fine before pushing. Best regards, Goetz. From: Baesken, Matthias > Sent: Wednesday, November 18, 2020 1:10 PM To: jdk-updates-dev at openjdk.java.net Cc: Lindenmaier, Goetz >; Doerr, Martin > Subject: Re : [11u] RFR: 8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators Hi G?tz , thanks for the backport. >Please check >http://cr.openjdk.java.net/~goetz/wr20/8173658-post_class_unload-jdk11/02/ > > I had lost changes to the test file because of the C/C++ mismatch. Looks good to me . 2 smaller remarks (do not need another webrev) : 1) I would like to prefer to have set_thread_state in 11 at one place too , we have this in jdk/jdk ( src/hotspot/share/runtime/thread.inline.hpp ) : 127inline void JavaThread::set_thread_state(JavaThreadState s) { 128 assert(current_or_null() == NULL || current_or_null() == this, 129 "state change should only be called by the current thread"); 130#if defined(PPC64) || defined (AARCH64) 131 // Use membars when accessing volatile _thread_state. See 132 // Threads::create_vm() for size checks. 133 Atomic::release_store((volatile jint*)&_thread_state, (jint)s); 134#else 135 _thread_state = s; 136#endif 137} But it's up to you if you want to include it in this patch or not. 2) When importing your patch I was running into "Extraneous text in comment src/hotspot/share/runtime/thread.hpp:1223: Trailing whitespace" You might want to check this. Best regards, Matthias From abakhtin at openjdk.java.net Thu Nov 19 12:07:26 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Thu, 19 Nov 2020 12:07:26 GMT Subject: [jdk13u-dev] RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos Message-ID: I would like to backport JDK-8245527 to 13u The patch applies cleanly ------------- Commit messages: - 8245527: LDAP Channel Binding support for Java GSS/Kerberos Changes: https://git.openjdk.java.net/jdk13u-dev/pull/21/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=21&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245527 Stats: 543 lines in 10 files changed: 531 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/21.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/21/head:pull/21 PR: https://git.openjdk.java.net/jdk13u-dev/pull/21 From rkennke at redhat.com Thu Nov 19 12:27:06 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 19 Nov 2020 13:27:06 +0100 Subject: [11u] RFR (S) 8255457: Shenandoah: cleanup ShenandoahMarkTask In-Reply-To: References: Message-ID: Looks good to me! Thanks, Roman On 18/11/2020 13:09, Aleksey Shipilev wrote: > Original RFE: > ? https://bugs.openjdk.java.net/browse/JDK-8255457 > ? https://git.openjdk.java.net/jdk/commit/1215b1a8 > > This patch does not apply cleanly to 11u, because of the contextual > differences. Most significant difference is that in HEAD JDK the > affected class is trivially copyable, and the shared code already > adjusted to accept that. 11u, however, would fail to compile due to odd > cv-stripping casts. Therefore, I had to keep copying constructors and > assignment operators. > > 11u webrev: > ? https://cr.openjdk.java.net/~shade/8255457/webrev.11u.01/ > > Testing: Linux {x86_64, x86_32} hotspot_gc_shenandoah > From shade at redhat.com Thu Nov 19 12:34:32 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 19 Nov 2020 13:34:32 +0100 Subject: [11u] RFR (S) 8255457: Shenandoah: cleanup ShenandoahMarkTask In-Reply-To: References: Message-ID: <8bac41c4-e3f0-3f9b-c71e-79cdd91f5123@redhat.com> On 11/19/20 1:27 PM, Roman Kennke wrote: > Looks good to me! Thanks, tagged. -- -Aleksey From abakhtin at openjdk.java.net Thu Nov 19 12:47:06 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Thu, 19 Nov 2020 12:47:06 GMT Subject: [jdk13u-dev] Integrated: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 12:01:47 GMT, Alexey Bakhtin wrote: > I would like to backport JDK-8245527 to 13u > The patch applies cleanly This pull request has now been integrated. Changeset: 97ba018b Author: Alexey Bakhtin Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/97ba018b Stats: 543 lines in 10 files changed: 531 ins; 0 del; 12 mod 8245527: LDAP Channel Binding support for Java GSS/Kerberos Backport-of: cfa3f7493149170f2b23a516bc95110dab43fd06 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/21 From christoph.langer at sap.com Thu Nov 19 12:53:46 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Nov 2020 12:53:46 +0000 Subject: [8u, 11u] Disabling TLS 1.0/1.1 in 8u292/11.0.11 ? In-Reply-To: References: Message-ID: Hi Volker, speaking for 11u: I would think so. Unless somebody has really good reasons not to follow Oracle here. After all, if somebody would have issues with that after April, there would always be the fallback to turn it back on via java.security. So I see the risk as quite acceptable. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Volker Simonis > Sent: Donnerstag, 19. November 2020 11:10 > To: jdk8u-dev ; jdk-updates-dev updates-dev at openjdk.java.net> > Subject: [8u, 11u] Disabling TLS 1.0/1.1 in 8u292/11.0.11 ? > > Hi 8u/11u maintainers, > > Oracle has announced in their "Cryptographic Roadmap" [1] that they > will disable TLS 1.0/1.1 in Oracle jdk 7,8,11 by 2021-04-20 and in jdk > 16 by 2021-03-16. A change/csr for jdk 16 [2,3] is currently under > review [4]. > > Do you plan to do the same for 8u292 and 11.0.11 in April 2021? > > Thank you and best regards, > Volker > > [1] https://java.com/en/jre-jdk-cryptoroadmap.html > [2] https://bugs.openjdk.java.net/browse/JDK-8202343 > [3] https://bugs.openjdk.java.net/browse/JDK-8254713 > [4] https://github.com/openjdk/jdk/pull/1235 From volker.simonis at gmail.com Thu Nov 19 13:00:36 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 19 Nov 2020 14:00:36 +0100 Subject: [8u, 11u] Disabling TLS 1.0/1.1 in 8u292/11.0.11 ? In-Reply-To: References: Message-ID: On Thu, Nov 19, 2020 at 1:53 PM Langer, Christoph wrote: > > Hi Volker, > > speaking for 11u: I would think so. Unless somebody has really good reasons not to follow Oracle here. > > After all, if somebody would have issues with that after April, there would always be the fallback to turn it back on via java.security. So I see the risk as quite acceptable. > Thanks Christoph, that pretty much exactly matches my point of view :) > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Volker Simonis > > Sent: Donnerstag, 19. November 2020 11:10 > > To: jdk8u-dev ; jdk-updates-dev > updates-dev at openjdk.java.net> > > Subject: [8u, 11u] Disabling TLS 1.0/1.1 in 8u292/11.0.11 ? > > > > Hi 8u/11u maintainers, > > > > Oracle has announced in their "Cryptographic Roadmap" [1] that they > > will disable TLS 1.0/1.1 in Oracle jdk 7,8,11 by 2021-04-20 and in jdk > > 16 by 2021-03-16. A change/csr for jdk 16 [2,3] is currently under > > review [4]. > > > > Do you plan to do the same for 8u292 and 11.0.11 in April 2021? > > > > Thank you and best regards, > > Volker > > > > [1] https://java.com/en/jre-jdk-cryptoroadmap.html > > [2] https://bugs.openjdk.java.net/browse/JDK-8202343 > > [3] https://bugs.openjdk.java.net/browse/JDK-8254713 > > [4] https://github.com/openjdk/jdk/pull/1235 From richard.reingruber at sap.com Thu Nov 19 17:17:10 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 19 Nov 2020 17:17:10 +0000 Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" In-Reply-To: References: Message-ID: Hi G?tz, --- src/hotspot/share/prims/jvmtiExport.cpp > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, nmethod *nm) > from head which is called in It would be cleaner to downport the original bugfix but I'm ok with your solution. --- src/hotspot/share/runtime/serviceThread.cpp the patch you prepared seems to be missing the change marked with !!! of the original patch @@ -209,7 +219,8 @@ if (_jvmti_event != NULL) { _jvmti_event->nmethods_do(cf); } + // Requires a lock, because threads can be adding to this queue. !!! MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); - JvmtiDeferredEventQueue::nmethods_do(cf); + _jvmti_service_queue.nmethods_do(cf); This is inadvertently, isn't it? The rest is good looking ;) Cheers, Richard. -----Original Message----- From: jdk-updates-dev On Behalf Of Reingruber, Richard Sent: Mittwoch, 18. November 2020 22:29 To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" Hi G?tz, I'm getting ready to review this. If I'm not mistaken, your patch has 8173658 as prerequisite which is currently out for review. It took me a few keystrokes and mouse clicks to figure this out. I'd suggest informing about prerequisite patches in the RFR mail. Cheers, Richard. -----Original Message----- From: jdk-updates-dev On Behalf Of Lindenmaier, Goetz Sent: Dienstag, 17. November 2020 15:03 To: jdk-updates-dev at openjdk.java.net Subject: [CAUTION] RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" Hi, I have another update to this change. I had to resolve it again because of the Minimal VM fix 8235218 pushed after 8173361. http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/03/ Also, I reqested downport for Minimal VM fixes required after this change: JDK-8236124 Minimal VM slowdebug build failed after JDK-8212160 JDK-8235456 Minimal VM is broken after JDK-8212160 These both are clean downports once this is pushed. I would appreciate reviews ?? Best regards, Goetz. Hi, Please look at http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/02/ I had lost the changes to the test file because of C/C++ mismatch. Best regards, Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Freitag, 6. November 2020 09:39 To: jdk-updates-dev at openjdk.java.net Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" Hi I am downporting this for parity with 11.0.10-oracle. http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/01/ I had to resolve and fis in quite some places: src/hotspot/share/code/nmethod.cpp Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. Added 'this' to call of JvmtiDeferredEvent::compiled_method_unload_event() src/hotspot/share/code/nmethod.hpp Trivial, resolved. src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. I removed NMethodIterator::only_alive_and_not_unloading and call next_alive instead. The NMethodIterator differs in head a lot. src/hotspot/share/prims/jvmtiExport.cpp Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, nmethod *nm) from head which is called in src/hotspot/share/prims/jvmtiExport.hpp Resolved. Deleted method has different arguments. src/hotspot/share/prims/jvmtiImpl.hpp Resolved. src/hotspot/share/runtime/serviceThread.cpp Context different. Please review. https://bugs.openjdk.java.net/browse/JDK-8212160 https://hg.openjdk.java.net/jdk/jdk/rev/366c0f357ee6 Best regards, Goetz From ecki at zusammenkunft.net Thu Nov 19 19:54:37 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 19 Nov 2020 19:54:37 +0000 Subject: [8u, 11u] Disabling TLS 1.0/1.1 in 8u292/11.0.11 ? In-Reply-To: References: , Message-ID: Hello, I don?t really understand why this has to be disabled. I can somewhat understand why the protocols are removed from the default context (however removing it from tlsv1 seems odd). But disabling it means you cannot programmatically turn it on... I think the common understanding is, that tls1.1 is not optimal and hard to configure well, but it is not considered broken, or? We encounter quite a few customers who would have to modify the JDK installation in that case. Can it be de-disabled (new word!) as a system property, maybe? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: jdk8u-dev im Auftrag von Langer, Christoph Gesendet: Thursday, November 19, 2020 1:53:46 PM An: Volker Simonis ; jdk8u-dev ; jdk-updates-dev Betreff: RE: [8u, 11u] Disabling TLS 1.0/1.1 in 8u292/11.0.11 ? Hi Volker, speaking for 11u: I would think so. Unless somebody has really good reasons not to follow Oracle here. After all, if somebody would have issues with that after April, there would always be the fallback to turn it back on via java.security. So I see the risk as quite acceptable. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Volker Simonis > Sent: Donnerstag, 19. November 2020 11:10 > To: jdk8u-dev ; jdk-updates-dev updates-dev at openjdk.java.net> > Subject: [8u, 11u] Disabling TLS 1.0/1.1 in 8u292/11.0.11 ? > > Hi 8u/11u maintainers, > > Oracle has announced in their "Cryptographic Roadmap" [1] that they > will disable TLS 1.0/1.1 in Oracle jdk 7,8,11 by 2021-04-20 and in jdk > 16 by 2021-03-16. A change/csr for jdk 16 [2,3] is currently under > review [4]. > > Do you plan to do the same for 8u292 and 11.0.11 in April 2021? > > Thank you and best regards, > Volker > > [1] https://java.com/en/jre-jdk-cryptoroadmap.html > [2] https://bugs.openjdk.java.net/browse/JDK-8202343 > [3] https://bugs.openjdk.java.net/browse/JDK-8254713 > [4] https://github.com/openjdk/jdk/pull/1235 From yan at openjdk.java.net Fri Nov 20 09:55:06 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 20 Nov 2020 09:55:06 GMT Subject: [jdk13u-dev] RFR: 8239477: jdk/jfr/jcmd/TestJcmdStartStopDefault.java fails -XX:+VerifyOops with "verify_oop: rsi: broken oop" In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 11:56:39 GMT, Ekaterina Vergizova wrote: > I would like to backport 8239477 to 13u, it's already included into 11u. > > The patch doesn't apply cleanly due to the different context (8245957 is not in 13u), reapplied manually. > > Tested with tier1 and jdk/jfr, the affected test fails without the patch and passes with it. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/19 From evergizova at openjdk.java.net Fri Nov 20 10:18:09 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 20 Nov 2020 10:18:09 GMT Subject: [jdk13u-dev] Integrated: 8239477: jdk/jfr/jcmd/TestJcmdStartStopDefault.java fails -XX:+VerifyOops with "verify_oop: rsi: broken oop" In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 11:56:39 GMT, Ekaterina Vergizova wrote: > I would like to backport 8239477 to 13u, it's already included into 11u. > > The patch doesn't apply cleanly due to the different context (8245957 is not in 13u), reapplied manually. > > Tested with tier1 and jdk/jfr, the affected test fails without the patch and passes with it. This pull request has now been integrated. Changeset: ad457aff Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/ad457aff Stats: 9 lines in 1 file changed: 4 ins; 2 del; 3 mod 8239477: jdk/jfr/jcmd/TestJcmdStartStopDefault.java fails -XX:+VerifyOops with "verify_oop: rsi: broken oop" Use T_ADDRESS instead of T_OBJECT to load metadata. Reviewed-by: yan Backport-of: b5775c831d27544870b6155cadc7d9861b93c438 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/19 From evergizova at openjdk.java.net Fri Nov 20 10:21:09 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 20 Nov 2020 10:21:09 GMT Subject: [jdk13u-dev] Integrated: 8238676: jni crashes on accessing it from process exit hook In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 09:11:10 GMT, Ekaterina Vergizova wrote: > I would like to backport 8238676 to 13u, it's already included into 11u. > > The patch applies almost cleanly except for: > - changes in make/test/JtregNativeHotspot.gmk reapplied manually due to different context (8179317 is not in 13u) > - the second hunk of src/hotspot/share/prims/jni.cpp reapplied manually due to different context (8234739 is not in 13u) > > Tested with tier1 on Windows, the added test fails without the patch and passes with it. This pull request has now been integrated. Changeset: 4cf46e98 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/4cf46e98 Stats: 220 lines in 4 files changed: 211 ins; 0 del; 9 mod 8238676: jni crashes on accessing it from process exit hook Reviewed-by: yan Backport-of: c42de93347d1647045f47dda7b50a1cd25db72b5 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/9 From evergizova at openjdk.java.net Fri Nov 20 10:49:09 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 20 Nov 2020 10:49:09 GMT Subject: [jdk13u-dev] RFR: 8240603: Windows 32bit compile error after 8238676 Message-ID: <5Flf7OZYetUTB6l-qNxHowE14JTRSUieAaJJA77AX7o=.efb041e9-86c3-42fa-bc0b-e75ff632996b@github.com> I'd like to backport 8240603 to 13u as follow-up fix for JDK-8238676 that is already included to 13u. The patch applies cleanly and resolves the problem. ------------- Commit messages: - Backport f10fd7a78ee1038a8a0b9b95ffd63b76c65cb9b2 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/22/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=22&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240603 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/22.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/22/head:pull/22 PR: https://git.openjdk.java.net/jdk13u-dev/pull/22 From evergizova at openjdk.java.net Fri Nov 20 11:26:04 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 20 Nov 2020 11:26:04 GMT Subject: [jdk13u-dev] Integrated: 8240603: Windows 32bit compile error after 8238676 In-Reply-To: <5Flf7OZYetUTB6l-qNxHowE14JTRSUieAaJJA77AX7o=.efb041e9-86c3-42fa-bc0b-e75ff632996b@github.com> References: <5Flf7OZYetUTB6l-qNxHowE14JTRSUieAaJJA77AX7o=.efb041e9-86c3-42fa-bc0b-e75ff632996b@github.com> Message-ID: On Fri, 20 Nov 2020 10:40:04 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8240603 to 13u as follow-up fix for JDK-8238676 that is already included to 13u. > The patch applies cleanly and resolves the problem. This pull request has now been integrated. Changeset: d3a2f768 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/d3a2f768 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8240603: Windows 32bit compile error after 8238676 Backport-of: f10fd7a78ee1038a8a0b9b95ffd63b76c65cb9b2 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/22 From goetz.lindenmaier at sap.com Fri Nov 20 13:58:51 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 20 Nov 2020 13:58:51 +0000 Subject: [11u] RFR: 8235829: graal crashes with Zombie.java test Message-ID: Hi, I am downporting this for parity with 11.0.10-oracle. http://cr.openjdk.java.net/~goetz/wr20/8235823-graal_zombie_crash-jdk11/01/ The original change adds a lot of BarrierSetNMethod barriers. This barrier type does not exist in 11. It is not needed as no concurrent class unloading is implemented in 11. That was added upstream for ZGC and Shenandoah. I omitted this coding. https://bugs.openjdk.java.net/browse/JDK-8235829 https://hg.openjdk.java.net/jdk/jdk14/rev/26bb0fe2270a Best regards, Goetz. From yan at openjdk.java.net Fri Nov 20 15:25:22 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 20 Nov 2020 15:25:22 GMT Subject: [jdk13u-dev] RFR: 8233452: java.math.BigDecimal.sqrt() with RoundingMode.FLOOR results in incorrect result Message-ID: <5HpGohbKb_rctbgU7cEccmJzZNCrgjmz3gL_8-cbMCc=.f38a31d2-baf5-421f-818b-5214615c4d11@github.com> jdk13u is also affected. I would like to downport it, too. Applies clean. Related tests pass, and the modified test fails and pass before and after the fix as expected. ------------- Commit messages: - Backport 006b5e0f964db3d957af0e2956890bc8a53e3cb4 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/23/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=23&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233452 Stats: 670 lines in 2 files changed: 617 ins; 10 del; 43 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/23.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/23/head:pull/23 PR: https://git.openjdk.java.net/jdk13u-dev/pull/23 From yan at openjdk.java.net Fri Nov 20 15:30:01 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 20 Nov 2020 15:30:01 GMT Subject: [jdk13u-dev] Integrated: 8233452: java.math.BigDecimal.sqrt() with RoundingMode.FLOOR results in incorrect result In-Reply-To: <5HpGohbKb_rctbgU7cEccmJzZNCrgjmz3gL_8-cbMCc=.f38a31d2-baf5-421f-818b-5214615c4d11@github.com> References: <5HpGohbKb_rctbgU7cEccmJzZNCrgjmz3gL_8-cbMCc=.f38a31d2-baf5-421f-818b-5214615c4d11@github.com> Message-ID: <0YUo2eAxKFQZLagA6XW_patZfWvUr71Rtrh3ixgWUik=.719ff1a0-910f-4622-a333-38e30775efc6@github.com> On Fri, 20 Nov 2020 15:20:07 GMT, Yuri Nesterenko wrote: > jdk13u is also affected. I would like to downport it, too. Applies clean. Related tests pass, and the modified test fails and pass before and after the fix as expected. This pull request has now been integrated. Changeset: 09ed2f51 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/09ed2f51 Stats: 670 lines in 2 files changed: 617 ins; 10 del; 43 mod 8233452: java.math.BigDecimal.sqrt() with RoundingMode.FLOOR results in incorrect result Backport-of: 006b5e0f964db3d957af0e2956890bc8a53e3cb4 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/23 From sgehwolf at redhat.com Fri Nov 20 20:49:05 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 20 Nov 2020 21:49:05 +0100 Subject: [11u] RFR: 8256557: libharfbuzz fails to link on gcc 4.4.x due to -Wl, -z, defs In-Reply-To: <7DBFFABE-0AC1-4957-9590-3F74A8052271@amazon.com> References: <7DBFFABE-0AC1-4957-9590-3F74A8052271@amazon.com> Message-ID: Hi Paul, Thanks for the review! On Thu, 2020-11-19 at 00:48 +0000, Hohensee, Paul wrote: > Set according to gcc version instead? OK. How about this? diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -547,6 +547,16 @@ HARFBUZZ_CFLAGS += -DHB_EXTERN=__declspec\(dllexport\) endif + LIBHARFBUZZ_LDFLAGS := $(LDFLAGS_JDKLIB) \ + $(call SET_SHARED_LIBRARY_ORIGIN) + ifeq ($(TOOLCHAIN_TYPE), gcc) + ifeq ($(CC_VERSION_NUMBER), 4.4.7) + LIBHARFBUZZ_LDFLAGS := $(subst -Xlinker -z -Xlinker defs,, \ + $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))) \ + $(call SET_SHARED_LIBRARY_ORIGIN) + endif + endif + ifneq ($(OPENJDK_TARGET_OS), windows) HARFBUZZ_CFLAGS += -DGETPAGESIZE -DHAVE_MPROTECT -DHAVE_PTHREAD \ -DHAVE_SYSCONF -DHAVE_SYS_MMAN_H -DHAVE_UNISTD_H \ @@ -608,8 +618,7 @@ truncwarn wvarhidenmem wvarhidemem wbadlkginit identexpected \ hidevf w_novirtualdescr arrowrtn2 unknownpragma, \ DISABLED_WARNINGS_microsoft := 4267 4244 4090 4146 4334 4819 4101 4068 4805 4138, \ - LDFLAGS := $(LDFLAGS_JDKLIB) \ - $(call SET_SHARED_LIBRARY_ORIGIN), \ + LDFLAGS := $(LIBHARFBUZZ_LDFLAGS), \ LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ LDFLAGS_aix := -Wl$(COMMA)-berok, \ LIBS := $(BUILD_LIBHARFBUZZ), \ Thanks, Severin > ?On 11/18/20, 11:37 AM, "jdk-updates-dev on behalf of Severin Gehwolf" wrote: > > Hi, > > Please review this JDK 11.0.10 specific fix for building slowdebug on a > system with gcc 4.4.x (e.g. RHEL 6). JDK-8249821 got backported to > 11.0.10 and that causes one slight difference in how libharfbuzz is > being linked: When it was linked as part of libfontmanager.so there was > no -Wl,-z,defs. After JDK-8249821 it's there, which makes the build > fail for slowdebug on this old toolchain. The proposal is to remove - > Wl,-z,defs from LDFLAGS_JDKLIB for libharfbuzz as was done before. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8256557 > > Patch: > > diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk > +++ b/make/lib/Awt2dLibraries.gmk > @@ -608,8 +608,9 @@ > truncwarn wvarhidenmem wvarhidemem wbadlkginit identexpected \ > hidevf w_novirtualdescr arrowrtn2 unknownpragma, \ > DISABLED_WARNINGS_microsoft := 4267 4244 4090 4146 4334 4819 4101 4068 4805 4138, \ > - LDFLAGS := $(LDFLAGS_JDKLIB) \ > - $(call SET_SHARED_LIBRARY_ORIGIN), \ > + LDFLAGS := $(subst -Xlinker -z -Xlinker defs,, \ > + $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))) \ > + $(call SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ > LDFLAGS_aix := -Wl$(COMMA)-berok, \ > LIBS := $(BUILD_LIBHARFBUZZ), \ > > Tested build on gcc 4.4.x slowdebug. Works with the patch. > > I know this isn't pretty, but as there were no code changes done > in JDK-8249821 it would preserve the status quo. Plus, it would unbreak > our vanilla JDK 11 builds. > > Thoughts? > > Thanks, > Severin > > From hohensee at amazon.com Fri Nov 20 21:23:11 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 20 Nov 2020 21:23:11 +0000 Subject: [11u] RFR: 8256557: libharfbuzz fails to link on gcc 4.4.x due to -Wl, -z, defs Message-ID: <7492238D-6B7E-41E3-8B63-6AF492628540@amazon.com> Looks good! Thanks, Paul ?On 11/20/20, 12:49 PM, "Severin Gehwolf" wrote: Hi Paul, Thanks for the review! On Thu, 2020-11-19 at 00:48 +0000, Hohensee, Paul wrote: > Set according to gcc version instead? OK. How about this? diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -547,6 +547,16 @@ HARFBUZZ_CFLAGS += -DHB_EXTERN=__declspec\(dllexport\) endif + LIBHARFBUZZ_LDFLAGS := $(LDFLAGS_JDKLIB) \ + $(call SET_SHARED_LIBRARY_ORIGIN) + ifeq ($(TOOLCHAIN_TYPE), gcc) + ifeq ($(CC_VERSION_NUMBER), 4.4.7) + LIBHARFBUZZ_LDFLAGS := $(subst -Xlinker -z -Xlinker defs,, \ + $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))) \ + $(call SET_SHARED_LIBRARY_ORIGIN) + endif + endif + ifneq ($(OPENJDK_TARGET_OS), windows) HARFBUZZ_CFLAGS += -DGETPAGESIZE -DHAVE_MPROTECT -DHAVE_PTHREAD \ -DHAVE_SYSCONF -DHAVE_SYS_MMAN_H -DHAVE_UNISTD_H \ @@ -608,8 +618,7 @@ truncwarn wvarhidenmem wvarhidemem wbadlkginit identexpected \ hidevf w_novirtualdescr arrowrtn2 unknownpragma, \ DISABLED_WARNINGS_microsoft := 4267 4244 4090 4146 4334 4819 4101 4068 4805 4138, \ - LDFLAGS := $(LDFLAGS_JDKLIB) \ - $(call SET_SHARED_LIBRARY_ORIGIN), \ + LDFLAGS := $(LIBHARFBUZZ_LDFLAGS), \ LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ LDFLAGS_aix := -Wl$(COMMA)-berok, \ LIBS := $(BUILD_LIBHARFBUZZ), \ Thanks, Severin > On 11/18/20, 11:37 AM, "jdk-updates-dev on behalf of Severin Gehwolf" wrote: > > Hi, > > Please review this JDK 11.0.10 specific fix for building slowdebug on a > system with gcc 4.4.x (e.g. RHEL 6). JDK-8249821 got backported to > 11.0.10 and that causes one slight difference in how libharfbuzz is > being linked: When it was linked as part of libfontmanager.so there was > no -Wl,-z,defs. After JDK-8249821 it's there, which makes the build > fail for slowdebug on this old toolchain. The proposal is to remove - > Wl,-z,defs from LDFLAGS_JDKLIB for libharfbuzz as was done before. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8256557 > > Patch: > > diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk > +++ b/make/lib/Awt2dLibraries.gmk > @@ -608,8 +608,9 @@ > truncwarn wvarhidenmem wvarhidemem wbadlkginit identexpected \ > hidevf w_novirtualdescr arrowrtn2 unknownpragma, \ > DISABLED_WARNINGS_microsoft := 4267 4244 4090 4146 4334 4819 4101 4068 4805 4138, \ > - LDFLAGS := $(LDFLAGS_JDKLIB) \ > - $(call SET_SHARED_LIBRARY_ORIGIN), \ > + LDFLAGS := $(subst -Xlinker -z -Xlinker defs,, \ > + $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))) \ > + $(call SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ > LDFLAGS_aix := -Wl$(COMMA)-berok, \ > LIBS := $(BUILD_LIBHARFBUZZ), \ > > Tested build on gcc 4.4.x slowdebug. Works with the patch. > > I know this isn't pretty, but as there were no code changes done > in JDK-8249821 it would preserve the status quo. Plus, it would unbreak > our vanilla JDK 11 builds. > > Thoughts? > > Thanks, > Severin > > From sgehwolf at redhat.com Mon Nov 23 09:00:39 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 23 Nov 2020 10:00:39 +0100 Subject: [11u] RFR: 8256557: libharfbuzz fails to link on gcc 4.4.x due to -Wl, -z, defs In-Reply-To: <7492238D-6B7E-41E3-8B63-6AF492628540@amazon.com> References: <7492238D-6B7E-41E3-8B63-6AF492628540@amazon.com> Message-ID: <9ee727531c1178704f01b2560a892c1ed6126d29.camel@redhat.com> On Fri, 2020-11-20 at 21:23 +0000, Hohensee, Paul wrote: > Looks good! Thanks for the review, Paul! Cheers, Severin > Thanks, > Paul > > ?On 11/20/20, 12:49 PM, "Severin Gehwolf" wrote: > > Hi Paul, > > Thanks for the review! > > On Thu, 2020-11-19 at 00:48 +0000, Hohensee, Paul wrote: > > Set according to gcc version instead? > > OK. How about this? > > diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk > +++ b/make/lib/Awt2dLibraries.gmk > @@ -547,6 +547,16 @@ > HARFBUZZ_CFLAGS += -DHB_EXTERN=__declspec\(dllexport\) > endif > > + LIBHARFBUZZ_LDFLAGS := $(LDFLAGS_JDKLIB) \ > + $(call SET_SHARED_LIBRARY_ORIGIN) > + ifeq ($(TOOLCHAIN_TYPE), gcc) > + ifeq ($(CC_VERSION_NUMBER), 4.4.7) > + LIBHARFBUZZ_LDFLAGS := $(subst -Xlinker -z -Xlinker defs,, \ > + $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))) \ > + $(call SET_SHARED_LIBRARY_ORIGIN) > + endif > + endif > + > ifneq ($(OPENJDK_TARGET_OS), windows) > HARFBUZZ_CFLAGS += -DGETPAGESIZE -DHAVE_MPROTECT -DHAVE_PTHREAD \ > -DHAVE_SYSCONF -DHAVE_SYS_MMAN_H -DHAVE_UNISTD_H \ > @@ -608,8 +618,7 @@ > truncwarn wvarhidenmem wvarhidemem wbadlkginit identexpected \ > hidevf w_novirtualdescr arrowrtn2 unknownpragma, \ > DISABLED_WARNINGS_microsoft := 4267 4244 4090 4146 4334 4819 4101 4068 4805 4138, \ > - LDFLAGS := $(LDFLAGS_JDKLIB) \ > - $(call SET_SHARED_LIBRARY_ORIGIN), \ > + LDFLAGS := $(LIBHARFBUZZ_LDFLAGS), \ > LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ > LDFLAGS_aix := -Wl$(COMMA)-berok, \ > LIBS := $(BUILD_LIBHARFBUZZ), \ > > > Thanks, > Severin > > > > On 11/18/20, 11:37 AM, "jdk-updates-dev on behalf of Severin Gehwolf" wrote: > > > > Hi, > > > > Please review this JDK 11.0.10 specific fix for building slowdebug on a > > system with gcc 4.4.x (e.g. RHEL 6). JDK-8249821 got backported to > > 11.0.10 and that causes one slight difference in how libharfbuzz is > > being linked: When it was linked as part of libfontmanager.so there was > > no -Wl,-z,defs. After JDK-8249821 it's there, which makes the build > > fail for slowdebug on this old toolchain. The proposal is to remove - > > Wl,-z,defs from LDFLAGS_JDKLIB for libharfbuzz as was done before. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8256557 > > > > Patch: > > > > diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > > --- a/make/lib/Awt2dLibraries.gmk > > +++ b/make/lib/Awt2dLibraries.gmk > > @@ -608,8 +608,9 @@ > > truncwarn wvarhidenmem wvarhidemem wbadlkginit identexpected \ > > hidevf w_novirtualdescr arrowrtn2 unknownpragma, \ > > DISABLED_WARNINGS_microsoft := 4267 4244 4090 4146 4334 4819 4101 4068 4805 4138, \ > > - LDFLAGS := $(LDFLAGS_JDKLIB) \ > > - $(call SET_SHARED_LIBRARY_ORIGIN), \ > > + LDFLAGS := $(subst -Xlinker -z -Xlinker defs,, \ > > + $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB))) \ > > + $(call SET_SHARED_LIBRARY_ORIGIN), \ > > LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ > > LDFLAGS_aix := -Wl$(COMMA)-berok, \ > > LIBS := $(BUILD_LIBHARFBUZZ), \ > > > > Tested build on gcc 4.4.x slowdebug. Works with the patch. > > > > I know this isn't pretty, but as there were no code changes done > > in JDK-8249821 it would preserve the status quo. Plus, it would unbreak > > our vanilla JDK 11 builds. > > > > Thoughts? > > > > Thanks, > > Severin > > > > > > From goetz.lindenmaier at sap.com Mon Nov 23 09:16:52 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Nov 2020 09:16:52 +0000 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> Message-ID: Hi Martin, I implemented the FIPS stuff that I first had left out And pushed the change along with it. Anyways, I would not have removed all of the FIPS support, only the code that had to be ported for the change. But the code is untested. If you know how, you might want to test it. Best regards, Goetz. > -----Original Message----- > From: Martin Balao > Sent: Tuesday, November 17, 2020 9:06 PM > To: jdk-updates-dev at openjdk.java.net; Lindenmaier, Goetz > > Cc: Severin Gehwolf > Subject: Re: [11u] RFR: 8171279: Support X25519 and X448 in TLS > > Hi, > > Apologize for being so late on this one -was on CPU and leave after > that-. I know this has been committed already, but I have some concerns > about the decisions taken. > > > file src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java > > Deleting class DHEKAKeyDerivation failed because the code in 11 uses > JsseJce.getKeyAgreement() > > where the patch uses KeyAgreement.getInstance(). > > Yes, because SunJSSE may be initialized with a specific crypto provider > for 'FIPS mode' in 11 (note that KeyAgreement.getInstance may choose any > enabled security provider in order of preference). This feature was > later removed. > > > > > As I understand 8217835, the experimental FIPS feature cannot be used in > > 11, it just remained in the code. So I skipped adapting NamedGroups to the > > old behaviour, I can not test it anyways. > > What do you think, do we need to add this code to NamedGroupd.java > again? > > > > The conclusion in 8217835 that SunJSSE FIPS mode cannot be used in JDK9+ > was never accurate and, today, not true. In particular, the provider > load ignored the extra parameter (from java.security configuration line) > because there was a bug that was fixed later [1]. > > In my opinion, we should not remove SunJSSE FIPS mode in 11u. This would > be removing an API from a stable release. Our users and us rely on that. > My suggestion would be to make the necessary changes so the crypto > provider used by SunJSSE remain to be the one obtained from JsseJce, > even for the key derivation schemes here. > > Thoughts? > > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8230923 From akashche at redhat.com Mon Nov 23 11:04:11 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 23 Nov 2020 11:04:11 +0000 Subject: [11u] RFR: 8232854: URLClassLoader.close() doesn't close cached JAR file on Windows when load() fails In-Reply-To: <361f077a-6d89-6de4-c613-2fed37a4c269@redhat.com> References: <361f077a-6d89-6de4-c613-2fed37a4c269@redhat.com> Message-ID: Hi, On 3/1/20, Alex Kashchenko wrote: > Hi, > > Please review the fix to JDK-8232854 for 11u: > > Jira issue: https://bugs.openjdk.java.net/browse/JDK-8232854 > > Webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8232854/webrev.00/ > > Patch is implemented based on a test code included with the Jira issue. > It fixes the case, when URLClassLoader is created with URL, that stars > with "jar:file:" and ends with non-root path inside JAR like > "foo.jar!/somedir/". > > Codepath in this case includes URLClassPath.Loader class, that requires > special handling when resources are loaded from a JAR file. Issue with > closing JAR file (on classloader close) on this codepath was previously > fixed in JDK-6896088: > > Jira issue: https://bugs.openjdk.java.net/browse/JDK-6896088 > > Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/3af394bb6f59 > > This fix is complementary to 6896088, it is filling the "jarfile" field > in URLClassPath.Loader class (to be able to close the JAR file later) in > case, when requested resource failed to be loaded from this JAR. Note, > that getJarFile() on URLConnection to original resource cannot be used > in this case, because this method checks that requested resource is > valid. URLConnection to the root URL in this JAR is used instead. > > There probably exist more elegant solutions to this problem. This patch > is fix-only and should not affect any existing logic in URLClassPath. > > Test included with this fix is similar to > java/net/URLClassLoader/B6896088.java test. It uses specific JAR > structure (with a classfile inside "somedir" directory that is not a > part of class package) and checks JAR file closing after both successful > and failed load attempts. Test fails on Windows without this patch, on > Linux it always passes. Please review this updated fix to JDK-8232854 for 11u: Jira issue: https://bugs.openjdk.java.net/browse/JDK-8232854 Webrev: https://cr.openjdk.java.net/~akasko/jdk11u/8232854/webrev.01/ More broad fix to the underlying problem was discussed for jdk-latest [1][2][3]. It is proposed to proceed with this narrow point fix for jdk11 (and then jdk8). Updated patch was taken from this email sent by Rob McKenna [4]. Comparing with the patch originally proposed in webrev.00: code change to URLClassPath.java is equivalent, RemoveJar.java test is more thorough. Testing: checked that included test fails on Windows without the patch and passes with it (on Linux it always passes), ran relevant parts of JCK. [1] https://mail.openjdk.java.net/pipermail/net-dev/2020-April/013756.html [2] https://mail.openjdk.java.net/pipermail/net-dev/2020-May/013884.html [3] https://mail.openjdk.java.net/pipermail/net-dev/2020-June/014058.html [4] https://mail.openjdk.java.net/pipermail/net-dev/2019-November/013341.html -- -Alex From rwestrel at redhat.com Mon Nov 23 11:04:12 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 23 Nov 2020 12:04:12 +0100 Subject: [11u] 8229495: SIGILL in C2 generated OSR compilation Message-ID: <873610l4gj.fsf@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8229495 https://hg.openjdk.java.net/jdk/jdk15/rev/c973b5ec934d Original patch does not apply cleanly to 11u (different context in loopTransform.cpp, loopnode.cpp, node.hpp) but the 11u patch is identical to the original patch (except for a change related to node budget handling which doesn't exist in 11). 11u webrev: http://cr.openjdk.java.net/~roland/8229495.11u/webrev.00/ Testing: x86_64 build, tier1. The test case passes with and without the patch (I noticed when working on the upstream fix that that test case is fragile so it's not unexpected). Roland. From sgehwolf at redhat.com Mon Nov 23 11:50:02 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 23 Nov 2020 12:50:02 +0100 Subject: PING? [11u] RFR: 8254854: [cgroups v1] Metric limits not properly detected on some join controller combinations In-Reply-To: <35c454521f74847ad00defad2a3f6a4130954000.camel@redhat.com> References: <35c454521f74847ad00defad2a3f6a4130954000.camel@redhat.com> Message-ID: Ping? On Mon, 2020-11-02 at 15:15 +0100, Severin Gehwolf wrote: > Hi, > > Could I please get a review for this follow-up fix to JDK-8217766 which > is in OpenJDK 11 since 11.0.5. The fix for JDK-8217766 was incomplete. > The JDK 15 patch didn't apply cleanly due to no cgroups v2 support in > JDK 11u. I've basically reworked the patch for 11u. The port was fairly > straight-forward, though. > > 1) > Changes in src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java > needed to be done in src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java > > 2) > Function names changed from setSubSystemControllerPath() JDK 15+ to > setSubSystemPath() in JDK 11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8254854 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8254854/01/webrev/ > > Testing: tier 1 and Linux container tests on x86_64 (cgroups v1); > manual testing of the fix[1] > > Thoughts? > > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8254854?focusedCommentId=14377579&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14377579 From martin.doerr at sap.com Mon Nov 23 13:02:36 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 23 Nov 2020 13:02:36 +0000 Subject: [11u] RFR: 8235829: graal crashes with Zombie.java test In-Reply-To: References: Message-ID: Hi G?tz, right, the nmethod barriers for concurrent class unloading with zGC and Shenandoah are not needed in 11u. Looks good to me. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 20. November 2020 14:59 > To: jdk-updates-dev > Subject: [11u] RFR: 8235829: graal crashes with Zombie.java test > > Hi, > > I am downporting this for parity with 11.0.10-oracle. > > http://cr.openjdk.java.net/~goetz/wr20/8235823-graal_zombie_crash- > jdk11/01/ > > The original change adds a lot of BarrierSetNMethod barriers. > This barrier type does not exist in 11. It is not needed as no > concurrent class unloading is implemented in 11. That was added upstream > for ZGC and Shenandoah. > I omitted this coding. > > https://bugs.openjdk.java.net/browse/JDK-8235829 > https://hg.openjdk.java.net/jdk/jdk14/rev/26bb0fe2270a > > Best regards, > Goetz. From tobias.hartmann at oracle.com Mon Nov 23 13:33:50 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 23 Nov 2020 14:33:50 +0100 Subject: [11u] 8229495: SIGILL in C2 generated OSR compilation In-Reply-To: <873610l4gj.fsf@redhat.com> References: <873610l4gj.fsf@redhat.com> Message-ID: Looks good to me. Best regards, Tobias On 23.11.20 12:04, Roland Westrelin wrote: > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8229495 > https://hg.openjdk.java.net/jdk/jdk15/rev/c973b5ec934d > > Original patch does not apply cleanly to 11u (different context in > loopTransform.cpp, loopnode.cpp, node.hpp) but the 11u patch is > identical to the original patch (except for a change related to node > budget handling which doesn't exist in 11). > > 11u webrev: > http://cr.openjdk.java.net/~roland/8229495.11u/webrev.00/ > > Testing: x86_64 build, tier1. The test case passes with and without the > patch (I noticed when working on the upstream fix that that test case is > fragile so it's not unexpected). > > Roland. > From rwestrel at redhat.com Mon Nov 23 14:13:34 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 23 Nov 2020 15:13:34 +0100 Subject: [11u] 8229495: SIGILL in C2 generated OSR compilation In-Reply-To: References: <873610l4gj.fsf@redhat.com> Message-ID: <87zh38jh4h.fsf@redhat.com> > Looks good to me. Thanks for the review. Roland. From vladimir.kozlov at oracle.com Mon Nov 23 16:28:43 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 23 Nov 2020 08:28:43 -0800 Subject: [11u] 8229495: SIGILL in C2 generated OSR compilation In-Reply-To: <873610l4gj.fsf@redhat.com> References: <873610l4gj.fsf@redhat.com> Message-ID: <3dc7c40f-5b16-4018-be98-cb1a6718c141@oracle.com> New test TestRCEAfterUnrolling.java is missing. Otherwise backport looks fine. Thanks, Vladimir On 11/23/20 3:04 AM, Roland Westrelin wrote: > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8229495 > https://hg.openjdk.java.net/jdk/jdk15/rev/c973b5ec934d > > Original patch does not apply cleanly to 11u (different context in > loopTransform.cpp, loopnode.cpp, node.hpp) but the 11u patch is > identical to the original patch (except for a change related to node > budget handling which doesn't exist in 11). > > 11u webrev: > http://cr.openjdk.java.net/~roland/8229495.11u/webrev.00/ > > Testing: x86_64 build, tier1. The test case passes with and without the > patch (I noticed when working on the upstream fix that that test case is > fragile so it's not unexpected). > > Roland. > From rwestrel at redhat.com Mon Nov 23 16:38:15 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 23 Nov 2020 17:38:15 +0100 Subject: [11u] 8229495: SIGILL in C2 generated OSR compilation In-Reply-To: <3dc7c40f-5b16-4018-be98-cb1a6718c141@oracle.com> References: <873610l4gj.fsf@redhat.com> <3dc7c40f-5b16-4018-be98-cb1a6718c141@oracle.com> Message-ID: <87wnycjafc.fsf@redhat.com> > New test TestRCEAfterUnrolling.java is missing. Otherwise backport looks fine. Thanks for the review. Here with the test case: http://cr.openjdk.java.net/~roland/8229495.11u/webrev.01/ Roland. From vkempik at openjdk.java.net Mon Nov 23 17:43:11 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 23 Nov 2020 17:43:11 GMT Subject: [jdk13u-dev] RFR: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11 Reviewed-by: kcr, psadhukhan In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 17:39:18 GMT, Vladimir Kempik wrote: > Backport-of: 2048bcb648c2f42b59119eb603d33e8878c58650 applies cleanly, tests : jdk:tier1, jdk:tier2 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/24 From vkempik at openjdk.java.net Mon Nov 23 17:43:11 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 23 Nov 2020 17:43:11 GMT Subject: [jdk13u-dev] RFR: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11 Reviewed-by: kcr, psadhukhan Message-ID: Backport-of: 2048bcb648c2f42b59119eb603d33e8878c58650 ------------- Commit messages: - 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11 Reviewed-by: kcr, psadhukhan Changes: https://git.openjdk.java.net/jdk13u-dev/pull/24/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=24&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244621 Stats: 32 lines in 1 file changed: 27 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/24.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/24/head:pull/24 PR: https://git.openjdk.java.net/jdk13u-dev/pull/24 From vladimir.kozlov at oracle.com Mon Nov 23 17:53:24 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 23 Nov 2020 09:53:24 -0800 Subject: [11u] 8229495: SIGILL in C2 generated OSR compilation In-Reply-To: <87wnycjafc.fsf@redhat.com> References: <873610l4gj.fsf@redhat.com> <3dc7c40f-5b16-4018-be98-cb1a6718c141@oracle.com> <87wnycjafc.fsf@redhat.com> Message-ID: Good. Thanks, Vladimir On 11/23/20 8:38 AM, Roland Westrelin wrote: > >> New test TestRCEAfterUnrolling.java is missing. Otherwise backport looks fine. > > Thanks for the review. Here with the test case: > > http://cr.openjdk.java.net/~roland/8229495.11u/webrev.01/ > > Roland. > From yan at openjdk.java.net Mon Nov 23 17:59:05 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 23 Nov 2020 17:59:05 GMT Subject: [jdk13u-dev] RFR: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11 In-Reply-To: References: Message-ID: <3_ySf8oK-cq99USJkt3HArz5Kn6abY5SKVlWGLKkOYo=.d7839e30-54cf-487a-929d-d37e9c2b41ce@github.com> On Mon, 23 Nov 2020 17:39:18 GMT, Vladimir Kempik wrote: > Backport-of: 2048bcb648c2f42b59119eb603d33e8878c58650 Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/24 From vkempik at openjdk.java.net Mon Nov 23 17:59:06 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 23 Nov 2020 17:59:06 GMT Subject: [jdk13u-dev] Integrated: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11 In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 17:39:18 GMT, Vladimir Kempik wrote: > Backport-of: 2048bcb648c2f42b59119eb603d33e8878c58650 This pull request has now been integrated. Changeset: a5c86241 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk13u-dev/commit/a5c86241 Stats: 32 lines in 1 file changed: 27 ins; 1 del; 4 mod 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11 Reviewed-by: yan ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/24 From hohensee at amazon.com Mon Nov 23 18:00:04 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 23 Nov 2020 18:00:04 +0000 Subject: [11u] RFR: 8250636: iso8601_time returns incorrect offset part on MacOS Message-ID: <68CA080B-67C1-4E2A-830B-0E1AD623ABD2@amazon.com> Companion request to 8u backport request. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8250636 Patch: https://hg.openjdk.java.net/jdk/jdk/rev/6103df4b7702 Backport webrev: http://cr.openjdk.java.net/~phh/8250636/webrev.11u.00/ Backport not clean due to having to update copyright date to 2020, and a context difference before the deletion of get_timezone(). Paired with backport of JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251365 Patch: https://hg.openjdk.java.net/jdk/jdk/rev/1096ad4dbf62 This patch applies cleanly after the above one for 8250636. Thanks, Paul From hohensee at amazon.com Mon Nov 23 19:10:03 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 23 Nov 2020 19:10:03 +0000 Subject: PING? [11u] RFR: 8254854: [cgroups v1] Metric limits not properly detected on some join controller combinations Message-ID: Lgtm. Thanks, Paul ?On 11/23/20, 3:50 AM, "jdk-updates-dev on behalf of Severin Gehwolf" wrote: Ping? On Mon, 2020-11-02 at 15:15 +0100, Severin Gehwolf wrote: > Hi, > > Could I please get a review for this follow-up fix to JDK-8217766 which > is in OpenJDK 11 since 11.0.5. The fix for JDK-8217766 was incomplete. > The JDK 15 patch didn't apply cleanly due to no cgroups v2 support in > JDK 11u. I've basically reworked the patch for 11u. The port was fairly > straight-forward, though. > > 1) > Changes in src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java > needed to be done in src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java > > 2) > Function names changed from setSubSystemControllerPath() JDK 15+ to > setSubSystemPath() in JDK 11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8254854 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8254854/01/webrev/ > > Testing: tier 1 and Linux container tests on x86_64 (cgroups v1); > manual testing of the fix[1] > > Thoughts? > > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8254854?focusedCommentId=14377579&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14377579 From sgehwolf at redhat.com Mon Nov 23 19:44:20 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 23 Nov 2020 20:44:20 +0100 Subject: [11u] RFR: 8256452: Integrate missing part of JDK-8232370 to 11u In-Reply-To: References: Message-ID: <70812c720de6b5b715467367fbd31ebf0c0a4042.camel@redhat.com> On Tue, 2020-11-17 at 10:19 +0000, Langer, Christoph wrote: > Hi, > > please review this 11u only change. > > JDK-8232370 [0] had been backported before JDK-8210560 [1]. So, at > the time, the update for RedefineImplementor.java was omitted since > that file was only introduced with JDK-8210560. Now, after the latter > was backported, we should also update RedefineImplementor.java to get > the IDE green again. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8256452 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8256452.11u/ This looks fine to me. Thanks, Severin From goetz.lindenmaier at sap.com Tue Nov 24 07:41:30 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Nov 2020 07:41:30 +0000 Subject: [11u] RFR: 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv Message-ID: Hi, I would like to downport this fix for jvmti. Some of the coding added here is needed by follow-up 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" which I downported for 11.0.10-oracle parity. The change applies clean, but I had to convert the test coding from C++ to C. http://cr.openjdk.java.net/~goetz/wr20/8222072-wrong_jvmtiEnv-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8222072 http://hg.openjdk.java.net/jdk/jdk/rev/96230a5ef2ec Best regards Goetz. From goetz.lindenmaier at sap.com Tue Nov 24 07:56:45 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Nov 2020 07:56:45 +0000 Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" In-Reply-To: References: Message-ID: Hi Richard, Thanks for reviewing! Yes, you are right, downporting the predecessor makes sense. It is a limited change and a pure fix as I understand. I requested downport and sent a RFR for it: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-November/004220.html This affects the patch of this change, so I made a new webrev. It also incorporates the comment I missed: http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/04/ Best regards, Goetz. > -----Original Message----- > From: Reingruber, Richard > Sent: Thursday, November 19, 2020 6:17 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi G?tz, > > --- src/hotspot/share/prims/jvmtiExport.cpp > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > nmethod *nm) > > from head which is called in > > It would be cleaner to downport the original bugfix but I'm ok with your > solution. > > --- src/hotspot/share/runtime/serviceThread.cpp > > the patch you prepared seems to be missing the change marked with !!! of > the original patch > > @@ -209,7 +219,8 @@ > if (_jvmti_event != NULL) { > _jvmti_event->nmethods_do(cf); > } > + // Requires a lock, because threads can be adding to this queue. !!! > MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); > - JvmtiDeferredEventQueue::nmethods_do(cf); > + _jvmti_service_queue.nmethods_do(cf); > > This is inadvertently, isn't it? > > The rest is good looking ;) > > Cheers, Richard. > > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Reingruber, Richard > Sent: Mittwoch, 18. November 2020 22:29 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi G?tz, > > I'm getting ready to review this. > > If I'm not mistaken, your patch has 8173658 as prerequisite which is currently > out for review. It took me a few keystrokes and mouse clicks to figure this > out. I'd suggest informing about prerequisite patches in the RFR mail. > > Cheers, Richard. > > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Lindenmaier, Goetz > Sent: Dienstag, 17. November 2020 15:03 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != 0LL) failed: resolving NULL _value" > > Hi, > > I have another update to this change. > I had to resolve it again because of the Minimal VM fix 8235218 pushed > after 8173361. > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/03/ > > Also, I reqested downport for Minimal VM fixes required after this change: > JDK-8236124 Minimal VM slowdebug build failed after JDK-8212160 > JDK-8235456 Minimal VM is broken after JDK-8212160 > These both are clean downports once this is pushed. > > I would appreciate reviews ?? > > Best regards, > Goetz. > > > Hi, > > Please look at > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/02/ > > I had lost the changes to the test file because of C/C++ mismatch. > > Best regards, > Goetz. > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 6. November 2020 09:39 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) > failed: resolving NULL _value" > > Hi > > I am downporting this for parity with 11.0.10-oracle. > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/01/ > I had to resolve and fis in quite some places: > > src/hotspot/share/code/nmethod.cpp > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > Added 'this' to call of JvmtiDeferredEvent::compiled_method_unload_event() > > src/hotspot/share/code/nmethod.hpp > Trivial, resolved. > > src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > I removed NMethodIterator::only_alive_and_not_unloading and call > next_alive instead. > The NMethodIterator differs in head a lot. > > src/hotspot/share/prims/jvmtiExport.cpp > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > nmethod *nm) > from head which is called in > > src/hotspot/share/prims/jvmtiExport.hpp > Resolved. Deleted method has different arguments. > > src/hotspot/share/prims/jvmtiImpl.hpp > Resolved. > > src/hotspot/share/runtime/serviceThread.cpp > Context different. > > Please review. > https://bugs.openjdk.java.net/browse/JDK-8212160 > https://hg.openjdk.java.net/jdk/jdk/rev/366c0f357ee6 > > Best regards, > Goetz From yan at openjdk.java.net Tue Nov 24 08:52:09 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 24 Nov 2020 08:52:09 GMT Subject: [jdk13u-dev] Integrated: 8238579: HttpsURLConnection drops the timeout and hangs forever in read Message-ID: Should be fixed in 13u, too. Patch applies clean, all relevant regtests pass. ------------- Commit messages: - Backport ff8e7d4087063a6d040c19079d28640993f07da8 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/25/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=25&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238579 Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/25/head:pull/25 PR: https://git.openjdk.java.net/jdk13u-dev/pull/25 From yan at openjdk.java.net Tue Nov 24 08:52:09 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 24 Nov 2020 08:52:09 GMT Subject: [jdk13u-dev] Integrated: 8238579: HttpsURLConnection drops the timeout and hangs forever in read In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 08:44:33 GMT, Yuri Nesterenko wrote: > Should be fixed in 13u, too. Patch applies clean, all relevant regtests pass. This pull request has now been integrated. Changeset: 538464bf Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/538464bf Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod 8238579: HttpsURLConnection drops the timeout and hangs forever in read HttpsURLConnection drops the timeout and hangs forever in read Backport-of: ff8e7d4087063a6d040c19079d28640993f07da8 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/25 From goetz.lindenmaier at sap.com Tue Nov 24 10:14:51 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Nov 2020 10:14:51 +0000 Subject: [11u reminder]: jdk 11.0.10 rampdown starts Tuesday, December 1st, 18:00 CET. Message-ID: Hi, I would like to remind everybody who is working on jdk 11 updates that rampdown of 11.0.10 starts next Tuesday, December 1st, at 18:00 CET. At that point in time the last merge from jdk11u-dev to jdk11u will take place. Please push all changes you want to get to 11.0.10 before that date. After that, changes for 11.0.10 must be requested with jdk11u-critical-request tags, and they need to be pushed directly to jdk11u. Best regards, Goetz See also https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u From richard.reingruber at sap.com Tue Nov 24 15:23:54 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 24 Nov 2020 15:23:54 +0000 Subject: [11u] RFR: 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: References: Message-ID: Hi G?tz, > The change applies clean, but I had to convert the test coding > from C++ to C. I'd suggest to replace true/false with JNI_TRUE/JNI_FALSE and change the type of fail_status to jboolean. Cheers, Richard. -----Original Message----- From: jdk-updates-dev On Behalf Of Lindenmaier, Goetz Sent: Dienstag, 24. November 2020 08:42 To: jdk-updates-dev at openjdk.java.net Subject: [11u] RFR: 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv Hi, I would like to downport this fix for jvmti. Some of the coding added here is needed by follow-up 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" which I downported for 11.0.10-oracle parity. The change applies clean, but I had to convert the test coding from C++ to C. http://cr.openjdk.java.net/~goetz/wr20/8222072-wrong_jvmtiEnv-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8222072 http://hg.openjdk.java.net/jdk/jdk/rev/96230a5ef2ec Best regards Goetz. From yan at openjdk.java.net Tue Nov 24 15:31:04 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 24 Nov 2020 15:31:04 GMT Subject: [jdk13u-dev] RFR: 8241138: http.nonProxyHosts=* causes StringIndexOutOfBoundsException in DefaultProxySelector Message-ID: <47WelMWPnjPL4kdyYX_5r1ryDLDASB3MyDJDj4e-i04=.4183e216-882e-48fd-bbda-2e82417b0a04@github.com> Patch applies clean with different copyright year in context. Because of that, it perhaps would need an approval. ------------- Commit messages: - Backport 59af1c2af4d98b333a71aa711033a704809d58c0 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/26/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=26&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241138 Stats: 12 lines in 2 files changed: 8 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/26.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/26/head:pull/26 PR: https://git.openjdk.java.net/jdk13u-dev/pull/26 From richard.reingruber at sap.com Tue Nov 24 15:35:15 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 24 Nov 2020 15:35:15 +0000 Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" In-Reply-To: References: Message-ID: Hi G?tz, > This affects the patch of this change, so I made a new webrev. > It also incorporates the comment I missed: > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/04/ Seems you forgot to remove the commented-out version of JvmtiExport::post_compiled_method_load(JvmtiEnv* env, nmethod *nm) See http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/04/src/hotspot/share/prims/jvmtiExport.cpp.udiff.html Cheers, Richard. -----Original Message----- From: Lindenmaier, Goetz Sent: Dienstag, 24. November 2020 08:57 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" Hi Richard, Thanks for reviewing! Yes, you are right, downporting the predecessor makes sense. It is a limited change and a pure fix as I understand. I requested downport and sent a RFR for it: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-November/004220.html This affects the patch of this change, so I made a new webrev. It also incorporates the comment I missed: http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/04/ Best regards, Goetz. > -----Original Message----- > From: Reingruber, Richard > Sent: Thursday, November 19, 2020 6:17 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi G?tz, > > --- src/hotspot/share/prims/jvmtiExport.cpp > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > nmethod *nm) > > from head which is called in > > It would be cleaner to downport the original bugfix but I'm ok with your > solution. > > --- src/hotspot/share/runtime/serviceThread.cpp > > the patch you prepared seems to be missing the change marked with !!! of > the original patch > > @@ -209,7 +219,8 @@ > if (_jvmti_event != NULL) { > _jvmti_event->nmethods_do(cf); > } > + // Requires a lock, because threads can be adding to this queue. !!! > MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); > - JvmtiDeferredEventQueue::nmethods_do(cf); > + _jvmti_service_queue.nmethods_do(cf); > > This is inadvertently, isn't it? > > The rest is good looking ;) > > Cheers, Richard. > > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Reingruber, Richard > Sent: Mittwoch, 18. November 2020 22:29 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi G?tz, > > I'm getting ready to review this. > > If I'm not mistaken, your patch has 8173658 as prerequisite which is currently > out for review. It took me a few keystrokes and mouse clicks to figure this > out. I'd suggest informing about prerequisite patches in the RFR mail. > > Cheers, Richard. > > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Lindenmaier, Goetz > Sent: Dienstag, 17. November 2020 15:03 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != 0LL) failed: resolving NULL _value" > > Hi, > > I have another update to this change. > I had to resolve it again because of the Minimal VM fix 8235218 pushed > after 8173361. > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/03/ > > Also, I reqested downport for Minimal VM fixes required after this change: > JDK-8236124 Minimal VM slowdebug build failed after JDK-8212160 > JDK-8235456 Minimal VM is broken after JDK-8212160 > These both are clean downports once this is pushed. > > I would appreciate reviews ?? > > Best regards, > Goetz. > > > Hi, > > Please look at > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/02/ > > I had lost the changes to the test file because of C/C++ mismatch. > > Best regards, > Goetz. > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 6. November 2020 09:39 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) > failed: resolving NULL _value" > > Hi > > I am downporting this for parity with 11.0.10-oracle. > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/01/ > I had to resolve and fis in quite some places: > > src/hotspot/share/code/nmethod.cpp > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > Added 'this' to call of JvmtiDeferredEvent::compiled_method_unload_event() > > src/hotspot/share/code/nmethod.hpp > Trivial, resolved. > > src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > I removed NMethodIterator::only_alive_and_not_unloading and call > next_alive instead. > The NMethodIterator differs in head a lot. > > src/hotspot/share/prims/jvmtiExport.cpp > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > nmethod *nm) > from head which is called in > > src/hotspot/share/prims/jvmtiExport.hpp > Resolved. Deleted method has different arguments. > > src/hotspot/share/prims/jvmtiImpl.hpp > Resolved. > > src/hotspot/share/runtime/serviceThread.cpp > Context different. > > Please review. > https://bugs.openjdk.java.net/browse/JDK-8212160 > https://hg.openjdk.java.net/jdk/jdk/rev/366c0f357ee6 > > Best regards, > Goetz From dcherepanov at openjdk.java.net Tue Nov 24 15:38:59 2020 From: dcherepanov at openjdk.java.net (Dmitry Cherepanov) Date: Tue, 24 Nov 2020 15:38:59 GMT Subject: [jdk13u-dev] RFR: 8241138: http.nonProxyHosts=* causes StringIndexOutOfBoundsException in DefaultProxySelector In-Reply-To: <47WelMWPnjPL4kdyYX_5r1ryDLDASB3MyDJDj4e-i04=.4183e216-882e-48fd-bbda-2e82417b0a04@github.com> References: <47WelMWPnjPL4kdyYX_5r1ryDLDASB3MyDJDj4e-i04=.4183e216-882e-48fd-bbda-2e82417b0a04@github.com> Message-ID: On Tue, 24 Nov 2020 15:26:30 GMT, Yuri Nesterenko wrote: > Patch applies clean with different copyright year in context. Because of that, it perhaps would need an approval. Marked as reviewed by dcherepanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/26 From yan at openjdk.java.net Tue Nov 24 15:44:59 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 24 Nov 2020 15:44:59 GMT Subject: [jdk13u-dev] Integrated: 8241138: http.nonProxyHosts=* causes StringIndexOutOfBoundsException in DefaultProxySelector In-Reply-To: <47WelMWPnjPL4kdyYX_5r1ryDLDASB3MyDJDj4e-i04=.4183e216-882e-48fd-bbda-2e82417b0a04@github.com> References: <47WelMWPnjPL4kdyYX_5r1ryDLDASB3MyDJDj4e-i04=.4183e216-882e-48fd-bbda-2e82417b0a04@github.com> Message-ID: On Tue, 24 Nov 2020 15:26:30 GMT, Yuri Nesterenko wrote: > Patch applies clean with different copyright year in context. Because of that, it perhaps would need an approval. This pull request has now been integrated. Changeset: 4623f5a9 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/4623f5a9 Stats: 12 lines in 2 files changed: 8 ins; 0 del; 4 mod 8241138: http.nonProxyHosts=* causes StringIndexOutOfBoundsException in DefaultProxySelector Reviewed-by: dcherepanov Backport-of: 59af1c2af4d98b333a71aa711033a704809d58c0 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/26 From mbalao at redhat.com Tue Nov 24 18:20:38 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 24 Nov 2020 15:20:38 -0300 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> Message-ID: <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> Hi Goetz, I'm not entirely sure how the FIPS support was not broken in 11u after 8171279. What I see previous to the backport is that the crypto provider for the key exchange scheme was obtained through the JsseJce::getKeyAgreement method [1]. This method takes into account the presence of a FIPS-initialized SunJSSE engine [2]. After the backport, I see that the implementation of any security provider could be used [3]. This means that the FIPS promise (that is: the SunJSSE engine will obtain all the crypto primitives from the security provider used for its initialization) is broken. Let me know if I'm overlooking something. Note: Severin let me know that we are close to ramp-down (this week). Thanks, Martin.- -- [1] - http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/780bcf674789/src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java#l502 [2] - http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/ce4f7a2e4da5/src/java.base/share/classes/sun/security/ssl/JsseJce.java#l243 [3] - http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/ce4f7a2e4da5/src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java#l102 On 11/23/20 6:16 AM, Lindenmaier, Goetz wrote: > Hi Martin, > > I implemented the FIPS stuff that I first had left out > And pushed the change along with it. > Anyways, I would not have removed all of the FIPS support, > only the code that had to be ported for the change. > But the code is untested. > > If you know how, you might want to test it. > > Best regards, > Goetz. From gnu.andrew at redhat.com Wed Nov 25 06:56:12 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 25 Nov 2020 06:56:12 +0000 Subject: [11u] RFR: 8250636: iso8601_time returns incorrect offset part on MacOS In-Reply-To: <68CA080B-67C1-4E2A-830B-0E1AD623ABD2@amazon.com> References: <68CA080B-67C1-4E2A-830B-0E1AD623ABD2@amazon.com> Message-ID: <20201125065612.GA440191@rincewind> On 18:00 Mon 23 Nov , Hohensee, Paul wrote: > Companion request to 8u backport request. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8250636 > Patch: https://hg.openjdk.java.net/jdk/jdk/rev/6103df4b7702 > > Backport webrev: http://cr.openjdk.java.net/~phh/8250636/webrev.11u.00/ > > Backport not clean due to having to update copyright date to 2020, and a context difference before the deletion of get_timezone(). Looks ok. > > Paired with backport of > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251365 > Patch: https://hg.openjdk.java.net/jdk/jdk/rev/1096ad4dbf62 > > This patch applies cleanly after the above one for 8250636. > So no review required? > Thanks, > Paul > Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Wed Nov 25 08:34:47 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 25 Nov 2020 09:34:47 +0100 Subject: [15u] MonitorInfo bugs: JDK-8249192 and JDK-8251118 In-Reply-To: References: Message-ID: <5413f266-4010-10ba-d58f-cd592c2f1346@redhat.com> Rob, On 11/18/20 2:17 PM, Aleksey Shipilev wrote: > On 11/11/20 11:00 AM, Aleksey Shipilev wrote: >> Hi again, >> >> I asked this question in the relevant RFR threads, but they apparently went unnoticed. Therefore, >> let me ask this in a new thread. >> >> This is about the following issues: >> 8249192: MonitorInfo stores raw oops across safepoints >> 8251118: BiasedLocking::preserve_marks should not have a HandleMar >> >> At the time 15.0.1 was open for pushes, it had been stated that both issues were pushed to some CPU >> repo. I was under impression it was to appear in 15.0.1 release, but it did not. So, there are no >> changes in current 15u: >> https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8249192 >> https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251118 >> >> There is still the "Resolved" backport in 15.0.2 for one of the issues: >> https://bugs.openjdk.java.net/browse/JDK-8251485 >> >> ...and there is no resolved backport for another. >> >> So, is there a private 15.0.2 CPU repo within Oracle? Are we expecting both issues to come with >> 15.0.2 CPU push? Even in this case, can we push the change to open 15.0.2, so we would be able to >> test it in open repositories before next CPU hits? > > Friendly reminder. Another friendly reminder. -- Thanks, -Aleksey From evergizova at openjdk.java.net Wed Nov 25 12:11:03 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 25 Nov 2020 12:11:03 GMT Subject: [jdk13u-dev] RFR: 8210977: jdk/jfr/event/oldobject/TestThreadLocalLeak.java fails to find ThreadLocalObject Message-ID: I'd like to backport 8210977 to 13u. This is a test only change that increases tests stability. The original patch applies cleanly. The affected test passes. ------------- Commit messages: - Merge branch 'master' of https://github.com/openjdk/jdk13u-dev into backport-8210977 - Backport f3cd52e3c73ad525456a20b5190a3a97e862ec15 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/27/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=27&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8210977 Stats: 13 lines in 1 file changed: 4 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/27/head:pull/27 PR: https://git.openjdk.java.net/jdk13u-dev/pull/27 From evergizova at openjdk.java.net Wed Nov 25 12:20:01 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 25 Nov 2020 12:20:01 GMT Subject: [jdk13u-dev] RFR: 8210977: jdk/jfr/event/oldobject/TestThreadLocalLeak.java fails to find ThreadLocalObject [v2] In-Reply-To: References: Message-ID: > I'd like to backport 8210977 to 13u. This is a test only change that increases tests stability. > The original patch applies cleanly. > The affected test passes. Ekaterina Vergizova has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Backport f3cd52e3c73ad525456a20b5190a3a97e862ec15 ------------- Changes: https://git.openjdk.java.net/jdk13u-dev/pull/27/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=27&range=01 Stats: 13 lines in 1 file changed: 4 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/27/head:pull/27 PR: https://git.openjdk.java.net/jdk13u-dev/pull/27 From evergizova at openjdk.java.net Wed Nov 25 12:40:06 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 25 Nov 2020 12:40:06 GMT Subject: [jdk13u-dev] RFR: 8213535: Windows HiDPI html lightweight tooltips are truncated Message-ID: I'd like to backport 8213535 to 13u. The original patch applies cleanly and fixes the problem. Tested with jdk/javax/swing, no regressions. ------------- Commit messages: - Backport a1b5e010038ec9013fc1afdcbbc162a0005372f8 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/28/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=28&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8213535 Stats: 124 lines in 5 files changed: 71 ins; 25 del; 28 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/28.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/28/head:pull/28 PR: https://git.openjdk.java.net/jdk13u-dev/pull/28 From evergizova at openjdk.java.net Wed Nov 25 12:46:08 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 25 Nov 2020 12:46:08 GMT Subject: [jdk13u-dev] RFR: 8227006: [linux] Runtime.availableProcessors execution time increased by factor of 100 Message-ID: I'd like to backport 8227006 to 13u. The patch applies cleanly. Tested with tier1, containers tests and reproducer from this bug. ------------- Commit messages: - Backport f5632e62b2faa1733f3b2feefec48380e29c161c Changes: https://git.openjdk.java.net/jdk13u-dev/pull/29/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=29&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8227006 Stats: 39 lines in 2 files changed: 31 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/29/head:pull/29 PR: https://git.openjdk.java.net/jdk13u-dev/pull/29 From evergizova at openjdk.java.net Wed Nov 25 12:52:07 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 25 Nov 2020 12:52:07 GMT Subject: [jdk13u-dev] RFR: 8230767: FlightRecorderListener returns null recording Message-ID: <2zRQg1kpA6ISjWPpOUJT5FTYXGyYGuunCwghDUJtgII=.6f438a32-5d23-4a6f-b9d3-229eba039620@github.com> I'd like to backport 8230767 to 13u. The original patch applies cleanly and fixes the problem. Tested with tier1 and jdk/jfr. The added test fails without the patch and passes with it. ------------- Commit messages: - Backport b3d2b3ba5fbd7ca383b1ba0311ab1a1f3c60198f Changes: https://git.openjdk.java.net/jdk13u-dev/pull/30/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=30&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8230767 Stats: 41 lines in 2 files changed: 40 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/30.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/30/head:pull/30 PR: https://git.openjdk.java.net/jdk13u-dev/pull/30 From evergizova at openjdk.java.net Wed Nov 25 13:17:08 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Wed, 25 Nov 2020 13:17:08 GMT Subject: [jdk13u-dev] RFR: 8243489: Thread CPU Load event may contain wrong data for CPU time under certain conditions Message-ID: <0Rtfr4NOW1u6bZOkq9c27AIujUraNBM-aqqdrzTB1HQ=.b1ec94af-5023-4f7c-a525-803d67e615bb@github.com> I'd like to backport 8243489 to 13u. The original patch applies cleanly and fixes the problem. Tested with tier1 and jdk/jfr. The added tests fail without the patch and pass with it. ------------- Commit messages: - Backport 313758a57aa6d284332f09c73e8ccfecfb06bc3e Changes: https://git.openjdk.java.net/jdk13u-dev/pull/31/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=31&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243489 Stats: 85 lines in 2 files changed: 82 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/31/head:pull/31 PR: https://git.openjdk.java.net/jdk13u-dev/pull/31 From hohensee at amazon.com Wed Nov 25 13:27:24 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 25 Nov 2020 13:27:24 +0000 Subject: [11u] RFR: 8250636: iso8601_time returns incorrect offset part on MacOS Message-ID: Thanks for the review, Andrew. Yes, no review required for 8251365, just maintainer approval. I included it for completeness since it's a necessary follow-on for 8250636 Thanks, Paul ?On 11/24/20, 10:57 PM, "Andrew Hughes" wrote: On 18:00 Mon 23 Nov , Hohensee, Paul wrote: > Companion request to 8u backport request. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8250636 > Patch: https://hg.openjdk.java.net/jdk/jdk/rev/6103df4b7702 > > Backport webrev: http://cr.openjdk.java.net/~phh/8250636/webrev.11u.00/ > > Backport not clean due to having to update copyright date to 2020, and a context difference before the deletion of get_timezone(). Looks ok. > > Paired with backport of > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251365 > Patch: https://hg.openjdk.java.net/jdk/jdk/rev/1096ad4dbf62 > > This patch applies cleanly after the above one for 8250636. > So no review required? > Thanks, > Paul > Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From goetz.lindenmaier at sap.com Thu Nov 26 08:50:56 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 26 Nov 2020 08:50:56 +0000 Subject: [11u] RFR: 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: References: Message-ID: Hi Richard, > I'd suggest to replace true/false with JNI_TRUE/JNI_FALSE and change the > type of fail_status to jboolean. That makes complete sense. http://cr.openjdk.java.net/~goetz/wr20/8222072-wrong_jvmtiEnv-jdk11/02/ Best, Goetz. > -----Original Message----- > From: Reingruber, Richard > Sent: Tuesday, November 24, 2020 4:24 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > CompiledMethodLoad events to wrong jvmtiEnv > > Hi G?tz, > > > The change applies clean, but I had to convert the test coding > > from C++ to C. > > I'd suggest to replace true/false with JNI_TRUE/JNI_FALSE and change the > type of > fail_status to jboolean. > > Cheers, Richard. > > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Lindenmaier, Goetz > Sent: Dienstag, 24. November 2020 08:42 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > CompiledMethodLoad events to wrong jvmtiEnv > > Hi, > > I would like to downport this fix for jvmti. > Some of the coding added here is needed by follow-up > 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving > NULL _value" > which I downported for 11.0.10-oracle parity. > > The change applies clean, but I had to convert the test coding > from C++ to C. > > http://cr.openjdk.java.net/~goetz/wr20/8222072-wrong_jvmtiEnv-jdk11/01/ > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8222072 > http://hg.openjdk.java.net/jdk/jdk/rev/96230a5ef2ec > > Best regards > Goetz. From goetz.lindenmaier at sap.com Thu Nov 26 09:04:34 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 26 Nov 2020 09:04:34 +0000 Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" In-Reply-To: References: Message-ID: Hi Richard, Oops, fixed: http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/05/ Best regards, Goetz > -----Original Message----- > From: Reingruber, Richard > Sent: Tuesday, November 24, 2020 4:35 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi G?tz, > > > This affects the patch of this change, so I made a new webrev. > > It also incorporates the comment I missed: > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/04/ > > Seems you forgot to remove the commented-out version of > JvmtiExport::post_compiled_method_load(JvmtiEnv* env, nmethod *nm) > > See http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/04/src/hotspot/share/prims/jvmtiExport.cpp.udiff.html > > Cheers, Richard. > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 24. November 2020 08:57 > To: Reingruber, Richard ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi Richard, > > Thanks for reviewing! > > Yes, you are right, downporting the predecessor makes sense. > It is a limited change and a pure fix as I understand. > I requested downport and sent a RFR for it: > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > November/004220.html > > This affects the patch of this change, so I made a new webrev. > It also incorporates the comment I missed: > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/04/ > > Best regards, > Goetz. > > > -----Original Message----- > > From: Reingruber, Richard > > Sent: Thursday, November 19, 2020 6:17 PM > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > 0LL) failed: resolving NULL _value" > > > > Hi G?tz, > > > > --- src/hotspot/share/prims/jvmtiExport.cpp > > > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > > nmethod *nm) > > > from head which is called in > > > > It would be cleaner to downport the original bugfix but I'm ok with your > > solution. > > > > --- src/hotspot/share/runtime/serviceThread.cpp > > > > the patch you prepared seems to be missing the change marked with !!! of > > the original patch > > > > @@ -209,7 +219,8 @@ > > if (_jvmti_event != NULL) { > > _jvmti_event->nmethods_do(cf); > > } > > + // Requires a lock, because threads can be adding to this queue. !!! > > MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); > > - JvmtiDeferredEventQueue::nmethods_do(cf); > > + _jvmti_service_queue.nmethods_do(cf); > > > > This is inadvertently, isn't it? > > > > The rest is good looking ;) > > > > Cheers, Richard. > > > > -----Original Message----- > > From: jdk-updates-dev On > Behalf > > Of Reingruber, Richard > > Sent: Mittwoch, 18. November 2020 22:29 > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > 0LL) failed: resolving NULL _value" > > > > Hi G?tz, > > > > I'm getting ready to review this. > > > > If I'm not mistaken, your patch has 8173658 as prerequisite which is > currently > > out for review. It took me a few keystrokes and mouse clicks to figure this > > out. I'd suggest informing about prerequisite patches in the RFR mail. > > > > Cheers, Richard. > > > > -----Original Message----- > > From: jdk-updates-dev On > Behalf > > Of Lindenmaier, Goetz > > Sent: Dienstag, 17. November 2020 15:03 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] RE: [11u] RFR: 8212160: JVMTI agent crashes with > > "assert(_value != 0LL) failed: resolving NULL _value" > > > > Hi, > > > > I have another update to this change. > > I had to resolve it again because of the Minimal VM fix 8235218 pushed > > after 8173361. > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/03/ > > > > Also, I reqested downport for Minimal VM fixes required after this change: > > JDK-8236124 Minimal VM slowdebug build failed after JDK-8212160 > > JDK-8235456 Minimal VM is broken after JDK-8212160 > > These both are clean downports once this is pushed. > > > > I would appreciate reviews ?? > > > > Best regards, > > Goetz. > > > > > > Hi, > > > > Please look at > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/02/ > > > > I had lost the changes to the test file because of C/C++ mismatch. > > > > Best regards, > > Goetz. > > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Freitag, 6. November 2020 09:39 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) > > failed: resolving NULL _value" > > > > Hi > > > > I am downporting this for parity with 11.0.10-oracle. > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/01/ > > I had to resolve and fis in quite some places: > > > > src/hotspot/share/code/nmethod.cpp > > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > > > Added 'this' to call of > JvmtiDeferredEvent::compiled_method_unload_event() > > > > src/hotspot/share/code/nmethod.hpp > > Trivial, resolved. > > > > src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp > > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > > > I removed NMethodIterator::only_alive_and_not_unloading and call > > next_alive instead. > > The NMethodIterator differs in head a lot. > > > > src/hotspot/share/prims/jvmtiExport.cpp > > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > > nmethod *nm) > > from head which is called in > > > > src/hotspot/share/prims/jvmtiExport.hpp > > Resolved. Deleted method has different arguments. > > > > src/hotspot/share/prims/jvmtiImpl.hpp > > Resolved. > > > > src/hotspot/share/runtime/serviceThread.cpp > > Context different. > > > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8212160 > > https://hg.openjdk.java.net/jdk/jdk/rev/366c0f357ee6 > > > > Best regards, > > Goetz From aph at redhat.com Thu Nov 26 10:18:14 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Nov 2020 10:18:14 +0000 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> Message-ID: <315008ad-73ae-f77d-5731-854d22083148@redhat.com> On 11/24/20 6:20 PM, Martin Balao wrote: > I'm not entirely sure how the FIPS support was not broken in 11u after > 8171279. What I see previous to the backport is that the crypto provider > for the key exchange scheme was obtained through the > JsseJce::getKeyAgreement method [1]. This method takes into account the > presence of a FIPS-initialized SunJSSE engine [2]. After the backport, I > see that the implementation of any security provider could be used [3]. > This means that the FIPS promise (that is: the SunJSSE engine will > obtain all the crypto primitives from the security provider used for its > initialization) is broken. Let me know if I'm overlooking something. Have you got a test case for 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 evergizova at openjdk.java.net Thu Nov 26 11:35:56 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 26 Nov 2020 11:35:56 GMT Subject: [jdk13u-dev] Integrated: 8210977: jdk/jfr/event/oldobject/TestThreadLocalLeak.java fails to find ThreadLocalObject In-Reply-To: References: Message-ID: <2cvdeFnGvDUKO1wiuvJXjJAcLDg4Lub02FfFhkWR3CM=.2fc1cb3a-99e7-4e3c-8f9f-51940349a766@github.com> On Wed, 25 Nov 2020 12:05:55 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8210977 to 13u. This is a test only change that increases tests stability. > The original patch applies cleanly. > The affected test passes. This pull request has now been integrated. Changeset: e9fdf002 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/e9fdf002 Stats: 13 lines in 1 file changed: 4 ins; 0 del; 9 mod 8210977: jdk/jfr/event/oldobject/TestThreadLocalLeak.java fails to find ThreadLocalObject Backport-of: f3cd52e3c73ad525456a20b5190a3a97e862ec15 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/27 From evergizova at openjdk.java.net Thu Nov 26 11:44:55 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 26 Nov 2020 11:44:55 GMT Subject: [jdk13u-dev] Integrated: 8213535: Windows HiDPI html lightweight tooltips are truncated In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 12:35:05 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8213535 to 13u. > The original patch applies cleanly and fixes the problem. > Tested with jdk/javax/swing, no regressions. This pull request has now been integrated. Changeset: 170d1a61 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/170d1a61 Stats: 124 lines in 5 files changed: 71 ins; 25 del; 28 mod 8213535: Windows HiDPI html lightweight tooltips are truncated Backport-of: a1b5e010038ec9013fc1afdcbbc162a0005372f8 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/28 From evergizova at openjdk.java.net Thu Nov 26 11:57:53 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 26 Nov 2020 11:57:53 GMT Subject: [jdk13u-dev] Integrated: 8227006: [linux] Runtime.availableProcessors execution time increased by factor of 100 In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 12:40:05 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8227006 to 13u. > The patch applies cleanly. > Tested with tier1, containers tests and reproducer from this bug. This pull request has now been integrated. Changeset: 85a31aca Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/85a31aca Stats: 39 lines in 2 files changed: 31 ins; 5 del; 3 mod 8227006: [linux] Runtime.availableProcessors execution time increased by factor of 100 Backport-of: f5632e62b2faa1733f3b2feefec48380e29c161c ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/29 From evergizova at openjdk.java.net Thu Nov 26 12:02:02 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 26 Nov 2020 12:02:02 GMT Subject: [jdk13u-dev] Integrated: 8230767: FlightRecorderListener returns null recording In-Reply-To: <2zRQg1kpA6ISjWPpOUJT5FTYXGyYGuunCwghDUJtgII=.6f438a32-5d23-4a6f-b9d3-229eba039620@github.com> References: <2zRQg1kpA6ISjWPpOUJT5FTYXGyYGuunCwghDUJtgII=.6f438a32-5d23-4a6f-b9d3-229eba039620@github.com> Message-ID: On Wed, 25 Nov 2020 12:46:04 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8230767 to 13u. > The original patch applies cleanly and fixes the problem. > Tested with tier1 and jdk/jfr. The added test fails without the patch and passes with it. This pull request has now been integrated. Changeset: 91b19c9d Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/91b19c9d Stats: 41 lines in 2 files changed: 40 ins; 0 del; 1 mod 8230767: FlightRecorderListener returns null recording Backport-of: b3d2b3ba5fbd7ca383b1ba0311ab1a1f3c60198f ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/30 From evergizova at openjdk.java.net Thu Nov 26 12:10:58 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 26 Nov 2020 12:10:58 GMT Subject: [jdk13u-dev] Integrated: 8243489: Thread CPU Load event may contain wrong data for CPU time under certain conditions In-Reply-To: <0Rtfr4NOW1u6bZOkq9c27AIujUraNBM-aqqdrzTB1HQ=.b1ec94af-5023-4f7c-a525-803d67e615bb@github.com> References: <0Rtfr4NOW1u6bZOkq9c27AIujUraNBM-aqqdrzTB1HQ=.b1ec94af-5023-4f7c-a525-803d67e615bb@github.com> Message-ID: On Wed, 25 Nov 2020 13:11:47 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8243489 to 13u. > The original patch applies cleanly and fixes the problem. > Tested with tier1 and jdk/jfr. The added tests fail without the patch and pass with it. This pull request has now been integrated. Changeset: 92da5d8f Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/92da5d8f Stats: 85 lines in 2 files changed: 82 ins; 3 del; 0 mod 8243489: Thread CPU Load event may contain wrong data for CPU time under certain conditions Backport-of: 313758a57aa6d284332f09c73e8ccfecfb06bc3e ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/31 From yan at openjdk.java.net Thu Nov 26 12:21:56 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 26 Nov 2020 12:21:56 GMT Subject: [jdk13u-dev] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 14:36:49 GMT, Ekaterina Vergizova wrote: > The patch applies cleanly, but it requires some modifications. > The original patch added new methods to OperatingSystemMXBean according to CSR JDK-8228428. Backporting them to 13u is not suitable. > Similar to 11u/8u, existing methods have been changed to return the container values instead. > CSR for 13u is filed: JDK-8255834, it's similar to 11u/8u CSR JDK-8248804. > > Tested with tier1 and container tests on Linux and Windows, the only failure is containers/docker/TestMemoryAwareness.java which is fixed by follow-up JDK-8236617, the plan is to push them together. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/8 From evergizova at openjdk.java.net Thu Nov 26 13:06:00 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 26 Nov 2020 13:06:00 GMT Subject: [jdk13u-dev] Integrated: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 14:36:49 GMT, Ekaterina Vergizova wrote: > The patch applies cleanly, but it requires some modifications. > The original patch added new methods to OperatingSystemMXBean according to CSR JDK-8228428. Backporting them to 13u is not suitable. > Similar to 11u/8u, existing methods have been changed to return the container values instead. > CSR for 13u is filed: JDK-8255834, it's similar to 11u/8u CSR JDK-8248804. > > Tested with tier1 and container tests on Linux and Windows, the only failure is containers/docker/TestMemoryAwareness.java which is fixed by follow-up JDK-8236617, the plan is to push them together. This pull request has now been integrated. Changeset: 89354b88 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/89354b88 Stats: 347 lines in 12 files changed: 323 ins; 2 del; 22 mod 8226575: OperatingSystemMXBean should be made container aware Reviewed-by: yan Backport-of: 7b82266a159ce363708e347aba7e1b0d38206b48 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/8 From richard.reingruber at sap.com Thu Nov 26 14:10:11 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 26 Nov 2020 14:10:11 +0000 Subject: [11u] RFR: 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: References: Message-ID: Thanks G?tz, looks good to me. Cheers, Richard. // Note: for some reason I'm not even listed as author in the JDK-updates project -----Original Message----- From: Lindenmaier, Goetz Sent: Donnerstag, 26. November 2020 09:51 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv Hi Richard, > I'd suggest to replace true/false with JNI_TRUE/JNI_FALSE and change the > type of fail_status to jboolean. That makes complete sense. http://cr.openjdk.java.net/~goetz/wr20/8222072-wrong_jvmtiEnv-jdk11/02/ Best, Goetz. > -----Original Message----- > From: Reingruber, Richard > Sent: Tuesday, November 24, 2020 4:24 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > CompiledMethodLoad events to wrong jvmtiEnv > > Hi G?tz, > > > The change applies clean, but I had to convert the test coding > > from C++ to C. > > I'd suggest to replace true/false with JNI_TRUE/JNI_FALSE and change the > type of > fail_status to jboolean. > > Cheers, Richard. > > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Lindenmaier, Goetz > Sent: Dienstag, 24. November 2020 08:42 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > CompiledMethodLoad events to wrong jvmtiEnv > > Hi, > > I would like to downport this fix for jvmti. > Some of the coding added here is needed by follow-up > 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving > NULL _value" > which I downported for 11.0.10-oracle parity. > > The change applies clean, but I had to convert the test coding > from C++ to C. > > http://cr.openjdk.java.net/~goetz/wr20/8222072-wrong_jvmtiEnv-jdk11/01/ > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8222072 > http://hg.openjdk.java.net/jdk/jdk/rev/96230a5ef2ec > > Best regards > Goetz. From richard.reingruber at sap.com Thu Nov 26 14:58:01 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 26 Nov 2020 14:58:01 +0000 Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" In-Reply-To: References: Message-ID: Hi G?tz, > Oops, fixed: > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/05/ Great. We're almost there now. The original patch has two occurences of the following: + // Requires a lock, because threads can be adding to this queue. Your patch lacks one and the one you've got has trailing whitespace. Cheers, Richard. -----Original Message----- From: Lindenmaier, Goetz Sent: Donnerstag, 26. November 2020 10:05 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" Hi Richard, Oops, fixed: http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/05/ Best regards, Goetz > -----Original Message----- > From: Reingruber, Richard > Sent: Tuesday, November 24, 2020 4:35 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi G?tz, > > > This affects the patch of this change, so I made a new webrev. > > It also incorporates the comment I missed: > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/04/ > > Seems you forgot to remove the commented-out version of > JvmtiExport::post_compiled_method_load(JvmtiEnv* env, nmethod *nm) > > See http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/04/src/hotspot/share/prims/jvmtiExport.cpp.udiff.html > > Cheers, Richard. > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 24. November 2020 08:57 > To: Reingruber, Richard ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi Richard, > > Thanks for reviewing! > > Yes, you are right, downporting the predecessor makes sense. > It is a limited change and a pure fix as I understand. > I requested downport and sent a RFR for it: > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > November/004220.html > > This affects the patch of this change, so I made a new webrev. > It also incorporates the comment I missed: > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/04/ > > Best regards, > Goetz. > > > -----Original Message----- > > From: Reingruber, Richard > > Sent: Thursday, November 19, 2020 6:17 PM > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > 0LL) failed: resolving NULL _value" > > > > Hi G?tz, > > > > --- src/hotspot/share/prims/jvmtiExport.cpp > > > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > > nmethod *nm) > > > from head which is called in > > > > It would be cleaner to downport the original bugfix but I'm ok with your > > solution. > > > > --- src/hotspot/share/runtime/serviceThread.cpp > > > > the patch you prepared seems to be missing the change marked with !!! of > > the original patch > > > > @@ -209,7 +219,8 @@ > > if (_jvmti_event != NULL) { > > _jvmti_event->nmethods_do(cf); > > } > > + // Requires a lock, because threads can be adding to this queue. !!! > > MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); > > - JvmtiDeferredEventQueue::nmethods_do(cf); > > + _jvmti_service_queue.nmethods_do(cf); > > > > This is inadvertently, isn't it? > > > > The rest is good looking ;) > > > > Cheers, Richard. > > > > -----Original Message----- > > From: jdk-updates-dev On > Behalf > > Of Reingruber, Richard > > Sent: Mittwoch, 18. November 2020 22:29 > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > 0LL) failed: resolving NULL _value" > > > > Hi G?tz, > > > > I'm getting ready to review this. > > > > If I'm not mistaken, your patch has 8173658 as prerequisite which is > currently > > out for review. It took me a few keystrokes and mouse clicks to figure this > > out. I'd suggest informing about prerequisite patches in the RFR mail. > > > > Cheers, Richard. > > > > -----Original Message----- > > From: jdk-updates-dev On > Behalf > > Of Lindenmaier, Goetz > > Sent: Dienstag, 17. November 2020 15:03 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] RE: [11u] RFR: 8212160: JVMTI agent crashes with > > "assert(_value != 0LL) failed: resolving NULL _value" > > > > Hi, > > > > I have another update to this change. > > I had to resolve it again because of the Minimal VM fix 8235218 pushed > > after 8173361. > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/03/ > > > > Also, I reqested downport for Minimal VM fixes required after this change: > > JDK-8236124 Minimal VM slowdebug build failed after JDK-8212160 > > JDK-8235456 Minimal VM is broken after JDK-8212160 > > These both are clean downports once this is pushed. > > > > I would appreciate reviews ?? > > > > Best regards, > > Goetz. > > > > > > Hi, > > > > Please look at > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/02/ > > > > I had lost the changes to the test file because of C/C++ mismatch. > > > > Best regards, > > Goetz. > > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Freitag, 6. November 2020 09:39 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) > > failed: resolving NULL _value" > > > > Hi > > > > I am downporting this for parity with 11.0.10-oracle. > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/01/ > > I had to resolve and fis in quite some places: > > > > src/hotspot/share/code/nmethod.cpp > > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > > > Added 'this' to call of > JvmtiDeferredEvent::compiled_method_unload_event() > > > > src/hotspot/share/code/nmethod.hpp > > Trivial, resolved. > > > > src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp > > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > > > I removed NMethodIterator::only_alive_and_not_unloading and call > > next_alive instead. > > The NMethodIterator differs in head a lot. > > > > src/hotspot/share/prims/jvmtiExport.cpp > > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > > nmethod *nm) > > from head which is called in > > > > src/hotspot/share/prims/jvmtiExport.hpp > > Resolved. Deleted method has different arguments. > > > > src/hotspot/share/prims/jvmtiImpl.hpp > > Resolved. > > > > src/hotspot/share/runtime/serviceThread.cpp > > Context different. > > > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8212160 > > https://hg.openjdk.java.net/jdk/jdk/rev/366c0f357ee6 > > > > Best regards, > > Goetz From github.com+6394632+sercher at openjdk.java.net Thu Nov 26 16:06:04 2020 From: github.com+6394632+sercher at openjdk.java.net (Sergey Chernyshev) Date: Thu, 26 Nov 2020 16:06:04 GMT Subject: [jdk13u-dev] RFR: 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR Message-ID: <3VKDuaH-g0zsEcyxVSmwGg5N4SUkw2GRpu-68KQnk5M=.ce8d498d-578d-46e9-824c-494845a4c219@github.com> Hello, I would like to create backports of 8233228 and 8172404 in 13u. The backports are already in production in 11u. The proposed 8233228 patch is exactly the same as 15u version, except for Hunk #9 at line 258(299): [https://github.com/openjdk/jdk13u-dev/commit/edec2fc6d79678111f97fa9da81d3bc1d2010538#diff-499d805909084ecc06c50b4706f8a2b3ec70ab9aaf55d54a6156c518f85f1bd6](https://github.com/openjdk/jdk13u-dev/commit/edec2fc6d79678111f97fa9da81d3bc1d2010538#diff-499d805909084ecc06c50b4706f8a2b3ec70ab9aaf55d54a6156c518f85f1bd6) in which the 8244479 is already applied. In comparison, the 15u version applies 8244479 on top of 8233228, so the changes are in reverse order. Otherwise there are no code / logic changes in the code. The further step would be to submit the 8172404 backport in the subsequent PR, in which the 15u patch applies cleanly in 13u on top of the proposed 8233228. Thank you. Best regards, Sergey Chernyshev BellSoft ------------- Commit messages: - 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR Changes: https://git.openjdk.java.net/jdk13u-dev/pull/32/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=32&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233228 Stats: 195 lines in 7 files changed: 154 ins; 7 del; 34 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/32.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/32/head:pull/32 PR: https://git.openjdk.java.net/jdk13u-dev/pull/32 From abakhtin at openjdk.java.net Thu Nov 26 16:06:04 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Thu, 26 Nov 2020 16:06:04 GMT Subject: [jdk13u-dev] RFR: 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR In-Reply-To: <3VKDuaH-g0zsEcyxVSmwGg5N4SUkw2GRpu-68KQnk5M=.ce8d498d-578d-46e9-824c-494845a4c219@github.com> References: <3VKDuaH-g0zsEcyxVSmwGg5N4SUkw2GRpu-68KQnk5M=.ce8d498d-578d-46e9-824c-494845a4c219@github.com> Message-ID: On Wed, 25 Nov 2020 14:14:58 GMT, Sergey Chernyshev wrote: > Hello, > > I would like to create backports of 8233228 and 8172404 in 13u. The backports are already in production in 11u. > > The proposed 8233228 patch is exactly the same as 15u version, except for Hunk #9 at line 258(299): > > [https://github.com/openjdk/jdk13u-dev/commit/edec2fc6d79678111f97fa9da81d3bc1d2010538#diff-499d805909084ecc06c50b4706f8a2b3ec70ab9aaf55d54a6156c518f85f1bd6](https://github.com/openjdk/jdk13u-dev/commit/edec2fc6d79678111f97fa9da81d3bc1d2010538#diff-499d805909084ecc06c50b4706f8a2b3ec70ab9aaf55d54a6156c518f85f1bd6) > > in which the 8244479 is already applied. In comparison, the 15u version applies 8244479 on top of 8233228, so the changes are in reverse order. Otherwise there are no code / logic changes in the code. > > The further step would be to submit the 8172404 backport in the subsequent PR, in which the 15u patch applies cleanly in 13u on top of the proposed 8233228. > > Thank you. > > Best regards, > Sergey Chernyshev > BellSoft I'm not a reviewer but Looks Good To Me ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/32 From yan at openjdk.java.net Thu Nov 26 16:06:04 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 26 Nov 2020 16:06:04 GMT Subject: [jdk13u-dev] RFR: 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR In-Reply-To: References: <3VKDuaH-g0zsEcyxVSmwGg5N4SUkw2GRpu-68KQnk5M=.ce8d498d-578d-46e9-824c-494845a4c219@github.com> Message-ID: <79nqtW6pw9F1Jxh6Tvlz4dO9RRXoQ1zgNcmoj-V3cww=.9060b52b-8475-4b3e-aa75-c11a63562790@github.com> On Thu, 26 Nov 2020 11:32:16 GMT, Alexey Bakhtin wrote: >> Hello, >> >> I would like to create backports of 8233228 and 8172404 in 13u. The backports are already in production in 11u. >> >> The proposed 8233228 patch is exactly the same as 15u version, except for Hunk #9 at line 258(299): >> >> [https://github.com/openjdk/jdk13u-dev/commit/edec2fc6d79678111f97fa9da81d3bc1d2010538#diff-499d805909084ecc06c50b4706f8a2b3ec70ab9aaf55d54a6156c518f85f1bd6](https://github.com/openjdk/jdk13u-dev/commit/edec2fc6d79678111f97fa9da81d3bc1d2010538#diff-499d805909084ecc06c50b4706f8a2b3ec70ab9aaf55d54a6156c518f85f1bd6) >> >> in which the 8244479 is already applied. In comparison, the 15u version applies 8244479 on top of 8233228, so the changes are in reverse order. Otherwise there are no code / logic changes in the code. >> >> The further step would be to submit the 8172404 backport in the subsequent PR, in which the 15u patch applies cleanly in 13u on top of the proposed 8233228. >> >> Thank you. >> >> Best regards, >> Sergey Chernyshev >> BellSoft > > I'm not a reviewer but Looks Good To Me Sergey, please take a look at the comment in JBS issue regarding the CSR. ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/32 From omikhaltcova at openjdk.java.net Thu Nov 26 16:55:11 2020 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 26 Nov 2020 16:55:11 GMT Subject: [jdk13u-dev] RFR: 8233954: UnsatisfiedLinkError or NoSuchAlgorithmException after removing sunec.dll Message-ID: I'd like to backport JDK-8233954 to jdk13u for parity with jdk11. The original patch applied cleanly. Jtreg tests passed. ------------- Commit messages: - Backport 5161ab9493c87313aa8b7d3e1a8a829f6254c993 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/33/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=33&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233954 Stats: 33 lines in 2 files changed: 22 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/33.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/33/head:pull/33 PR: https://git.openjdk.java.net/jdk13u-dev/pull/33 From omikhaltcova at openjdk.java.net Thu Nov 26 17:09:57 2020 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 26 Nov 2020 17:09:57 GMT Subject: [jdk13u-dev] Integrated: 8233954: UnsatisfiedLinkError or NoSuchAlgorithmException after removing sunec.dll In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 16:50:25 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8233954 to jdk13u for parity with jdk11. > The original patch applied cleanly. > Jtreg tests passed. This pull request has now been integrated. Changeset: 5af784b4 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/5af784b4 Stats: 33 lines in 2 files changed: 22 ins; 0 del; 11 mod 8233954: UnsatisfiedLinkError or NoSuchAlgorithmException after removing sunec.dll Backport-of: 5161ab9493c87313aa8b7d3e1a8a829f6254c993 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/33 From gnu.andrew at redhat.com Thu Nov 26 17:52:19 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 26 Nov 2020 17:52:19 +0000 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> Message-ID: <20201126175219.GH488659@rincewind> On 15:20 Tue 24 Nov , Martin Balao wrote: > Hi Goetz, > > I'm not entirely sure how the FIPS support was not broken in 11u after > 8171279. What I see previous to the backport is that the crypto provider > for the key exchange scheme was obtained through the > JsseJce::getKeyAgreement method [1]. This method takes into account the > presence of a FIPS-initialized SunJSSE engine [2]. After the backport, I > see that the implementation of any security provider could be used [3]. > This means that the FIPS promise (that is: the SunJSSE engine will > obtain all the crypto primitives from the security provider used for its > initialization) is broken. Let me know if I'm overlooking something. > > Note: Severin let me know that we are close to ramp-down (this week). > > Thanks, > Martin.- > FWIW, rampdown for 11u is Tuesday, the 1st of December (a few days later than 8u's on Friday) Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Nov 26 18:10:56 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 26 Nov 2020 18:10:56 +0000 Subject: [11u] RFR: JDK-8222527: HttpClient doesn't send HOST header when tunelling HTTP/1.1 through http proxy Message-ID: <20201126181056.GI488659@rincewind> Bug: https://bugs.openjdk.java.net/browse/JDK-8222527 Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8222527/webrev.01/ When connecting to a proxy, OpenJDK filters out all but the Proxy-* HTTP headers. This violates the HTTP specification which states that the Host header should always be sent. This patch includes the Host header in the proxy filter exemptions. This backport is simpler than the original included in 13u, as 11u does not include JDK-8213189, which allows the user to customise headers. As such, we only need to alter the proxy filter and not worry about the set of restricted headers being altered by the jdk.httpclient.allowRestrictedHeaders property. The included test fails on current 11u and passes with this patch. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From evergizova at openjdk.java.net Thu Nov 26 18:55:07 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Thu, 26 Nov 2020 18:55:07 GMT Subject: [jdk13u-dev] RFR: 8236617: jtreg test containers/docker/TestMemoryAwareness.java fails after 8226575 Message-ID: I'd like to backport 8236617 to 13u as follow-up fix for 8226575 that is already included to 13u. The patch doesn't apply cleanly due to the context difference in TestMemoryAwareness.java (getTotalMemorySize() and getFreeMemorySize() methods are not added to OperatingSystemMXBean in 13u by 8226575), reapplied manually. Tested with container tests, the affected test passed. ------------- Commit messages: - Backport 44f7fe57a8e90f31875bb50cd55eaf4d57b1a6f6 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/34/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=34&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236617 Stats: 17 lines in 2 files changed: 6 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/34.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/34/head:pull/34 PR: https://git.openjdk.java.net/jdk13u-dev/pull/34 From daniel.fuchs at oracle.com Thu Nov 26 19:17:14 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 26 Nov 2020 19:17:14 +0000 Subject: [11u] RFR: JDK-8222527: HttpClient doesn't send HOST header when tunelling HTTP/1.1 through http proxy In-Reply-To: <20201126181056.GI488659@rincewind> References: <20201126181056.GI488659@rincewind> Message-ID: Hi Andrew, The proposed changes look reasonable to me. best regards, -- daniel On 26/11/2020 18:10, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8222527 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8222527/webrev.01/ > > When connecting to a proxy, OpenJDK filters out all but the Proxy-* > HTTP headers. This violates the HTTP specification which states that > the Host header should always be sent. > > This patch includes the Host header in the proxy filter exemptions. > This backport is simpler than the original included in 13u, as 11u > does not include JDK-8213189, which allows the user to customise > headers. As such, we only need to alter the proxy filter and not > worry about the set of restricted headers being altered by the > jdk.httpclient.allowRestrictedHeaders property. > > The included test fails on current 11u and passes with this patch. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > From mbalao at redhat.com Thu Nov 26 20:23:41 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 26 Nov 2020 17:23:41 -0300 Subject: [8u, 11u] Disabling TLS 1.0/1.1 in 8u292/11.0.11 ? In-Reply-To: References: Message-ID: Hello, I believe we should keep OpenJDK 8 and 11 aligned to Oracle's JDK [0] and other TLS implementations as well, and remove TLS 1.0 and TLS 1.1 from a default configuration in April 2021. It's not only about the protocol being completely broken (as is the case for TLS 1.0) but improving the security posture by using better crypto primitives and more reliable configurations. There has been plenty of time in advance for users to make the necessary changes. On 11/19/20 4:54 PM, Bernd Eckenfels wrote: > I don?t really understand why this has to be disabled. I can somewhat understand why the protocols are removed from the default context (however removing it from tlsv1 seems odd). But disabling it means you cannot programmatically turn it on... > > I think the common understanding is, that tls1.1 is not optimal and hard to configure well, but it is not considered broken, or? > > We encounter quite a few customers who would have to modify the JDK installation in that case. Can it be de-disabled (new word!) as a system property, maybe? > In my view, what's being suggested is to add TLSv1.0 and TLSv1.1 to the 'jdk.tls.disabledAlgorithms' list in java.security [1], as it was previously done for SSLv3 in JDK-8061210 [2]. Protocol support won't -and shouldn't- be removed from the JDK 8 or 11 [3]. This means that it could be available if you change the property value in the configuration [4] [5]. Thanks, Martin.- -- [0] - https://java.com/en/jre-jdk-cryptoroadmap.html [1] - https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/c7c0c3c9f33c/src/share/lib/security/java.security-linux#l654 [2] - https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/1c0cc3bbe07d [3] - https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/c7c0c3c9f33c/src/share/classes/sun/security/ssl/SSLContextImpl.java#l540 [4] - https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/c7c0c3c9f33c/src/share/classes/sun/security/ssl/ProtocolVersion.java#l153 [5] - https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/c7c0c3c9f33c/src/share/classes/sun/security/ssl/SSLContextImpl.java#l478 From gil at azul.com Thu Nov 26 20:36:55 2020 From: gil at azul.com (Gil Tene) Date: Thu, 26 Nov 2020 20:36:55 +0000 Subject: [8u, 11u] Disabling TLS 1.0/1.1 in 8u292/11.0.11 ? In-Reply-To: References: Message-ID: +1 > On Nov 26, 2020, at 12:23 PM, Martin Balao wrote: > > Hello, > > I believe we should keep OpenJDK 8 and 11 aligned to Oracle's JDK [0] > and other TLS implementations as well, and remove TLS 1.0 and TLS 1.1 > from a default configuration in April 2021. It's not only about the > protocol being completely broken (as is the case for TLS 1.0) but > improving the security posture by using better crypto primitives and > more reliable configurations. There has been plenty of time in advance > for users to make the necessary changes. > > On 11/19/20 4:54 PM, Bernd Eckenfels wrote: >> I don?t really understand why this has to be disabled. I can somewhat understand why the protocols are removed from the default context (however removing it from tlsv1 seems odd). But disabling it means you cannot programmatically turn it on... >> >> I think the common understanding is, that tls1.1 is not optimal and hard to configure well, but it is not considered broken, or? >> >> We encounter quite a few customers who would have to modify the JDK installation in that case. Can it be de-disabled (new word!) as a system property, maybe? >> > > In my view, what's being suggested is to add TLSv1.0 and TLSv1.1 to the > 'jdk.tls.disabledAlgorithms' list in java.security [1], as it was > previously done for SSLv3 in JDK-8061210 [2]. Protocol support won't > -and shouldn't- be removed from the JDK 8 or 11 [3]. This means that it > could be available if you change the property value in the configuration > [4] [5]. > > Thanks, > Martin.- > > -- > [0] - https://java.com/en/jre-jdk-cryptoroadmap.html > [1] - > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/c7c0c3c9f33c/src/share/lib/security/java.security-linux#l654 > [2] - https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/1c0cc3bbe07d > [3] - > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/c7c0c3c9f33c/src/share/classes/sun/security/ssl/SSLContextImpl.java#l540 > [4] - > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/c7c0c3c9f33c/src/share/classes/sun/security/ssl/ProtocolVersion.java#l153 > [5] - > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/c7c0c3c9f33c/src/share/classes/sun/security/ssl/SSLContextImpl.java#l478 > From mbalao at redhat.com Thu Nov 26 21:25:45 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 26 Nov 2020 18:25:45 -0300 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: <315008ad-73ae-f77d-5731-854d22083148@redhat.com> References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> <315008ad-73ae-f77d-5731-854d22083148@redhat.com> Message-ID: <92ed6f9d-9476-795c-eb16-65bce15db1c5@redhat.com> On 11/26/20 7:18 AM, Andrew Haley wrote: > > Have you got a test case for this? > Testing is not trivial but I'm working on something. Having said that, I still think it's worth having a look at / discussing this potential issue based on the static analysis so far. From shade at redhat.com Fri Nov 27 07:30:07 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 27 Nov 2020 08:30:07 +0100 Subject: [11u] RFR (XS) 8257181: s390x builds are very noisy with gc-sections messages Message-ID: Original fix: https://bugs.openjdk.java.net/browse/JDK-8257181 https://git.openjdk.java.net/jdk/commit/a3eec39b It does not apply to 11u cleanly, because the context is a bit different. 11u variant: diff -r bb715aaab6e0 make/autoconf/flags-ldflags.m4 --- a/make/autoconf/flags-ldflags.m4 Sat Oct 03 19:46:41 2020 +0000 +++ b/make/autoconf/flags-ldflags.m4 Fri Nov 27 08:28:42 2020 +0100 @@ -75,11 +75,11 @@ # add -z,relro (mark relocations read only) for all libs # add -z,now ("full relro" - more of the Global Offset Table GOT is marked read only) BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -Wl,-z,relro -Wl,-z,now" # s390x : remove unused code+data in link step if test "x$OPENJDK_TARGET_CPU" = xs390x; then - BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,--gc-sections -Wl,--print-gc-sections" + BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,--gc-sections" fi BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1" elif test "x$TOOLCHAIN_TYPE" = xclang; then Testing: linux-s390x-normal-server-fastdebug cross-compilation -- Thanks, -Aleksey From yan at openjdk.java.net Fri Nov 27 07:31:01 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 27 Nov 2020 07:31:01 GMT Subject: [jdk13u-dev] Integrated: 8249183: JVM crash in "AwtFrame::WmSize" method Message-ID: should be downported to 13u as well. Patch applies clean, relevant tests do pass ------------- Commit messages: - Backport 4e3d9e394438ab4cc1c303973c54b1604d0d5f0c Changes: https://git.openjdk.java.net/jdk13u-dev/pull/35/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=35&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249183 Stats: 89 lines in 5 files changed: 56 ins; 32 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/35.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/35/head:pull/35 PR: https://git.openjdk.java.net/jdk13u-dev/pull/35 From yan at openjdk.java.net Fri Nov 27 07:31:02 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 27 Nov 2020 07:31:02 GMT Subject: [jdk13u-dev] Integrated: 8249183: JVM crash in "AwtFrame::WmSize" method In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 07:24:52 GMT, Yuri Nesterenko wrote: > should be downported to 13u as well. Patch applies clean, relevant tests do pass This pull request has now been integrated. Changeset: 80be64a4 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/80be64a4 Stats: 89 lines in 5 files changed: 56 ins; 32 del; 1 mod 8249183: JVM crash in "AwtFrame::WmSize" method Backport-of: 4e3d9e394438ab4cc1c303973c54b1604d0d5f0c ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/35 From goetz.lindenmaier at sap.com Fri Nov 27 09:05:43 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 27 Nov 2020 09:05:43 +0000 Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" In-Reply-To: References: Message-ID: Hi Richard, Another try: http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/06/ Best regards, Goetz > -----Original Message----- > From: Reingruber, Richard > Sent: Thursday, November 26, 2020 3:58 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi G?tz, > > > Oops, fixed: > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/05/ > > Great. We're almost there now. The original patch has two occurences of > the following: > > + // Requires a lock, because threads can be adding to this queue. > > Your patch lacks one and the one you've got has trailing whitespace. > > Cheers, Richard. > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 26. November 2020 10:05 > To: Reingruber, Richard ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi Richard, > > Oops, fixed: > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/05/ > > Best regards, > Goetz > > > -----Original Message----- > > From: Reingruber, Richard > > Sent: Tuesday, November 24, 2020 4:35 PM > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > 0LL) failed: resolving NULL _value" > > > > Hi G?tz, > > > > > This affects the patch of this change, so I made a new webrev. > > > It also incorporates the comment I missed: > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/04/ > > > > Seems you forgot to remove the commented-out version of > > JvmtiExport::post_compiled_method_load(JvmtiEnv* env, nmethod *nm) > > > > See http://cr.openjdk.java.net/~goetz/wr20/8212160- > jvmti_crash_resolving- > > jdk11/04/src/hotspot/share/prims/jvmtiExport.cpp.udiff.html > > > > Cheers, Richard. > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Dienstag, 24. November 2020 08:57 > > To: Reingruber, Richard ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > 0LL) failed: resolving NULL _value" > > > > Hi Richard, > > > > Thanks for reviewing! > > > > Yes, you are right, downporting the predecessor makes sense. > > It is a limited change and a pure fix as I understand. > > I requested downport and sent a RFR for it: > > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > > November/004220.html > > > > This affects the patch of this change, so I made a new webrev. > > It also incorporates the comment I missed: > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/04/ > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: Reingruber, Richard > > > Sent: Thursday, November 19, 2020 6:17 PM > > > To: Lindenmaier, Goetz ; jdk-updates- > > > dev at openjdk.java.net > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > > "assert(_value != > > > 0LL) failed: resolving NULL _value" > > > > > > Hi G?tz, > > > > > > --- src/hotspot/share/prims/jvmtiExport.cpp > > > > > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > > > nmethod *nm) > > > > from head which is called in > > > > > > It would be cleaner to downport the original bugfix but I'm ok with your > > > solution. > > > > > > --- src/hotspot/share/runtime/serviceThread.cpp > > > > > > the patch you prepared seems to be missing the change marked with !!! > of > > > the original patch > > > > > > @@ -209,7 +219,8 @@ > > > if (_jvmti_event != NULL) { > > > _jvmti_event->nmethods_do(cf); > > > } > > > + // Requires a lock, because threads can be adding to this queue. !!! > > > MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); > > > - JvmtiDeferredEventQueue::nmethods_do(cf); > > > + _jvmti_service_queue.nmethods_do(cf); > > > > > > This is inadvertently, isn't it? > > > > > > The rest is good looking ;) > > > > > > Cheers, Richard. > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > Behalf > > > Of Reingruber, Richard > > > Sent: Mittwoch, 18. November 2020 22:29 > > > To: Lindenmaier, Goetz ; jdk-updates- > > > dev at openjdk.java.net > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > > "assert(_value != > > > 0LL) failed: resolving NULL _value" > > > > > > Hi G?tz, > > > > > > I'm getting ready to review this. > > > > > > If I'm not mistaken, your patch has 8173658 as prerequisite which is > > currently > > > out for review. It took me a few keystrokes and mouse clicks to figure > this > > > out. I'd suggest informing about prerequisite patches in the RFR mail. > > > > > > Cheers, Richard. > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > Behalf > > > Of Lindenmaier, Goetz > > > Sent: Dienstag, 17. November 2020 15:03 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: [CAUTION] RE: [11u] RFR: 8212160: JVMTI agent crashes with > > > "assert(_value != 0LL) failed: resolving NULL _value" > > > > > > Hi, > > > > > > I have another update to this change. > > > I had to resolve it again because of the Minimal VM fix 8235218 pushed > > > after 8173361. > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > > jdk11/03/ > > > > > > Also, I reqested downport for Minimal VM fixes required after this change: > > > JDK-8236124 Minimal VM slowdebug build failed after JDK-8212160 > > > JDK-8235456 Minimal VM is broken after JDK-8212160 > > > These both are clean downports once this is pushed. > > > > > > I would appreciate reviews ?? > > > > > > Best regards, > > > Goetz. > > > > > > > > > Hi, > > > > > > Please look at > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > > jdk11/02/ > > > > > > I had lost the changes to the test file because of C/C++ mismatch. > > > > > > Best regards, > > > Goetz. > > > > > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz > > > Sent: Freitag, 6. November 2020 09:39 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > > 0LL) > > > failed: resolving NULL _value" > > > > > > Hi > > > > > > I am downporting this for parity with 11.0.10-oracle. > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > > jdk11/01/ > > > I had to resolve and fis in quite some places: > > > > > > src/hotspot/share/code/nmethod.cpp > > > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > > > > > Added 'this' to call of > > JvmtiDeferredEvent::compiled_method_unload_event() > > > > > > src/hotspot/share/code/nmethod.hpp > > > Trivial, resolved. > > > > > > src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp > > > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > > > > > I removed NMethodIterator::only_alive_and_not_unloading and call > > > next_alive instead. > > > The NMethodIterator differs in head a lot. > > > > > > src/hotspot/share/prims/jvmtiExport.cpp > > > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > > > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > > > nmethod *nm) > > > from head which is called in > > > > > > src/hotspot/share/prims/jvmtiExport.hpp > > > Resolved. Deleted method has different arguments. > > > > > > src/hotspot/share/prims/jvmtiImpl.hpp > > > Resolved. > > > > > > src/hotspot/share/runtime/serviceThread.cpp > > > Context different. > > > > > > Please review. > > > https://bugs.openjdk.java.net/browse/JDK-8212160 > > > https://hg.openjdk.java.net/jdk/jdk/rev/366c0f357ee6 > > > > > > Best regards, > > > Goetz From yan at openjdk.java.net Fri Nov 27 09:19:00 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 27 Nov 2020 09:19:00 GMT Subject: [jdk13u-dev] Integrated: 8223940: Private key not supported by chosen signature algorithm Message-ID: <4ZxpBFkMQ76CtEMnMfDyuE_37cZYDI6LujoqSwk6E80=.2ca466db-0955-4068-a104-1f0dcae323b1@github.com> applicable to 13u as well and should be downported. Patch applies clean at this moment; all relevant regtests do pass. ------------- Commit messages: - Backport b7f557e5c7a934f5d962748e7162e131fcc336ad Changes: https://git.openjdk.java.net/jdk13u-dev/pull/36/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=36&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223940 Stats: 126 lines in 4 files changed: 49 ins; 24 del; 53 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/36.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/36/head:pull/36 PR: https://git.openjdk.java.net/jdk13u-dev/pull/36 From yan at openjdk.java.net Fri Nov 27 09:19:00 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 27 Nov 2020 09:19:00 GMT Subject: [jdk13u-dev] Integrated: 8223940: Private key not supported by chosen signature algorithm In-Reply-To: <4ZxpBFkMQ76CtEMnMfDyuE_37cZYDI6LujoqSwk6E80=.2ca466db-0955-4068-a104-1f0dcae323b1@github.com> References: <4ZxpBFkMQ76CtEMnMfDyuE_37cZYDI6LujoqSwk6E80=.2ca466db-0955-4068-a104-1f0dcae323b1@github.com> Message-ID: <3nutlaBr9DTzf3Ku1_Sb4Xl3SzNpxv524Z8RWrpzWgs=.0913e3cb-0919-415f-b568-388ee84b6722@github.com> On Fri, 27 Nov 2020 09:11:38 GMT, Yuri Nesterenko wrote: > applicable to 13u as well and should be downported. Patch applies clean at this moment; all relevant regtests do pass. This pull request has now been integrated. Changeset: c6f81a59 Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/c6f81a59 Stats: 126 lines in 4 files changed: 49 ins; 24 del; 53 mod 8223940: Private key not supported by chosen signature algorithm Backport-of: b7f557e5c7a934f5d962748e7162e131fcc336ad ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/36 From richard.reingruber at sap.com Fri Nov 27 10:43:12 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 27 Nov 2020 10:43:12 +0000 Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" In-Reply-To: References: Message-ID: Hi G?tz, The following isn't part of the original change. - // post a DYNAMIC_CODE_GENERATED event for a given environment // used by GenerateEvents void JvmtiExport::post_dynamic_code_generated(JvmtiEnv* env, const char *name, I've overlooked that, sorry. It's just whitespace. I'll leave it up to you if you correct it. Besides that the patch is good. Thanks, Richard. -----Original Message----- From: Lindenmaier, Goetz Sent: Freitag, 27. November 2020 10:06 To: Reingruber, Richard ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" Hi Richard, Another try: http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving-jdk11/06/ Best regards, Goetz > -----Original Message----- > From: Reingruber, Richard > Sent: Thursday, November 26, 2020 3:58 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi G?tz, > > > Oops, fixed: > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/05/ > > Great. We're almost there now. The original patch has two occurences of > the following: > > + // Requires a lock, because threads can be adding to this queue. > > Your patch lacks one and the one you've got has trailing whitespace. > > Cheers, Richard. > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 26. November 2020 10:05 > To: Reingruber, Richard ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi Richard, > > Oops, fixed: > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/05/ > > Best regards, > Goetz > > > -----Original Message----- > > From: Reingruber, Richard > > Sent: Tuesday, November 24, 2020 4:35 PM > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > 0LL) failed: resolving NULL _value" > > > > Hi G?tz, > > > > > This affects the patch of this change, so I made a new webrev. > > > It also incorporates the comment I missed: > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/04/ > > > > Seems you forgot to remove the commented-out version of > > JvmtiExport::post_compiled_method_load(JvmtiEnv* env, nmethod *nm) > > > > See http://cr.openjdk.java.net/~goetz/wr20/8212160- > jvmti_crash_resolving- > > jdk11/04/src/hotspot/share/prims/jvmtiExport.cpp.udiff.html > > > > Cheers, Richard. > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Dienstag, 24. November 2020 08:57 > > To: Reingruber, Richard ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > 0LL) failed: resolving NULL _value" > > > > Hi Richard, > > > > Thanks for reviewing! > > > > Yes, you are right, downporting the predecessor makes sense. > > It is a limited change and a pure fix as I understand. > > I requested downport and sent a RFR for it: > > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > > November/004220.html > > > > This affects the patch of this change, so I made a new webrev. > > It also incorporates the comment I missed: > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/04/ > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: Reingruber, Richard > > > Sent: Thursday, November 19, 2020 6:17 PM > > > To: Lindenmaier, Goetz ; jdk-updates- > > > dev at openjdk.java.net > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > > "assert(_value != > > > 0LL) failed: resolving NULL _value" > > > > > > Hi G?tz, > > > > > > --- src/hotspot/share/prims/jvmtiExport.cpp > > > > > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > > > nmethod *nm) > > > > from head which is called in > > > > > > It would be cleaner to downport the original bugfix but I'm ok with your > > > solution. > > > > > > --- src/hotspot/share/runtime/serviceThread.cpp > > > > > > the patch you prepared seems to be missing the change marked with !!! > of > > > the original patch > > > > > > @@ -209,7 +219,8 @@ > > > if (_jvmti_event != NULL) { > > > _jvmti_event->nmethods_do(cf); > > > } > > > + // Requires a lock, because threads can be adding to this queue. !!! > > > MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); > > > - JvmtiDeferredEventQueue::nmethods_do(cf); > > > + _jvmti_service_queue.nmethods_do(cf); > > > > > > This is inadvertently, isn't it? > > > > > > The rest is good looking ;) > > > > > > Cheers, Richard. > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > Behalf > > > Of Reingruber, Richard > > > Sent: Mittwoch, 18. November 2020 22:29 > > > To: Lindenmaier, Goetz ; jdk-updates- > > > dev at openjdk.java.net > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > > "assert(_value != > > > 0LL) failed: resolving NULL _value" > > > > > > Hi G?tz, > > > > > > I'm getting ready to review this. > > > > > > If I'm not mistaken, your patch has 8173658 as prerequisite which is > > currently > > > out for review. It took me a few keystrokes and mouse clicks to figure > this > > > out. I'd suggest informing about prerequisite patches in the RFR mail. > > > > > > Cheers, Richard. > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > Behalf > > > Of Lindenmaier, Goetz > > > Sent: Dienstag, 17. November 2020 15:03 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: [CAUTION] RE: [11u] RFR: 8212160: JVMTI agent crashes with > > > "assert(_value != 0LL) failed: resolving NULL _value" > > > > > > Hi, > > > > > > I have another update to this change. > > > I had to resolve it again because of the Minimal VM fix 8235218 pushed > > > after 8173361. > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > > jdk11/03/ > > > > > > Also, I reqested downport for Minimal VM fixes required after this change: > > > JDK-8236124 Minimal VM slowdebug build failed after JDK-8212160 > > > JDK-8235456 Minimal VM is broken after JDK-8212160 > > > These both are clean downports once this is pushed. > > > > > > I would appreciate reviews ?? > > > > > > Best regards, > > > Goetz. > > > > > > > > > Hi, > > > > > > Please look at > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > > jdk11/02/ > > > > > > I had lost the changes to the test file because of C/C++ mismatch. > > > > > > Best regards, > > > Goetz. > > > > > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz > > > Sent: Freitag, 6. November 2020 09:39 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > > 0LL) > > > failed: resolving NULL _value" > > > > > > Hi > > > > > > I am downporting this for parity with 11.0.10-oracle. > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > > jdk11/01/ > > > I had to resolve and fis in quite some places: > > > > > > src/hotspot/share/code/nmethod.cpp > > > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > > > > > Added 'this' to call of > > JvmtiDeferredEvent::compiled_method_unload_event() > > > > > > src/hotspot/share/code/nmethod.hpp > > > Trivial, resolved. > > > > > > src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp > > > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > > > > > I removed NMethodIterator::only_alive_and_not_unloading and call > > > next_alive instead. > > > The NMethodIterator differs in head a lot. > > > > > > src/hotspot/share/prims/jvmtiExport.cpp > > > Resolved. Few differences in code, e.g. MutexLocker --> MutexLockerEx. > > > > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > > > nmethod *nm) > > > from head which is called in > > > > > > src/hotspot/share/prims/jvmtiExport.hpp > > > Resolved. Deleted method has different arguments. > > > > > > src/hotspot/share/prims/jvmtiImpl.hpp > > > Resolved. > > > > > > src/hotspot/share/runtime/serviceThread.cpp > > > Context different. > > > > > > Please review. > > > https://bugs.openjdk.java.net/browse/JDK-8212160 > > > https://hg.openjdk.java.net/jdk/jdk/rev/366c0f357ee6 > > > > > > Best regards, > > > Goetz From yan at openjdk.java.net Fri Nov 27 11:16:58 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 27 Nov 2020 11:16:58 GMT Subject: [jdk13u-dev] RFR: 8236617: jtreg test containers/docker/TestMemoryAwareness.java fails after 8226575 In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 18:50:21 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8236617 to 13u as follow-up fix for 8226575 that is already included to 13u. > The patch doesn't apply cleanly due to the context difference in TestMemoryAwareness.java > (getTotalMemorySize() and getFreeMemorySize() methods are not added to OperatingSystemMXBean in 13u by 8226575), reapplied manually. > Tested with container tests, the affected test passed. Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/34 From evergizova at openjdk.java.net Fri Nov 27 12:07:56 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 27 Nov 2020 12:07:56 GMT Subject: [jdk13u-dev] Integrated: 8236617: jtreg test containers/docker/TestMemoryAwareness.java fails after 8226575 In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 18:50:21 GMT, Ekaterina Vergizova wrote: > I'd like to backport 8236617 to 13u as follow-up fix for 8226575 that is already included to 13u. > The patch doesn't apply cleanly due to the context difference in TestMemoryAwareness.java > (getTotalMemorySize() and getFreeMemorySize() methods are not added to OperatingSystemMXBean in 13u by 8226575), reapplied manually. > Tested with container tests, the affected test passed. This pull request has now been integrated. Changeset: e91e43b0 Author: Ekaterina Vergizova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/e91e43b0 Stats: 17 lines in 2 files changed: 6 ins; 0 del; 11 mod 8236617: jtreg test containers/docker/TestMemoryAwareness.java fails after 8226575 Reviewed-by: yan Backport-of: 44f7fe57a8e90f31875bb50cd55eaf4d57b1a6f6 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/34 From omikhaltcova at openjdk.java.net Fri Nov 27 16:13:00 2020 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 27 Nov 2020 16:13:00 GMT Subject: [jdk13u-dev] RFR: 8235183: Remove the "HACK CODE" in comment Message-ID: I'd like to backport JDK-8235183 to jdk13u for parity with jdk11. There is modification only in comments. The original patch applied cleanly. ------------- Commit messages: - Backport 50714b0fb9fd4391385eda3af89582dd3fb5a5f1 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/37/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=37&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8235183 Stats: 13 lines in 3 files changed: 6 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/37/head:pull/37 PR: https://git.openjdk.java.net/jdk13u-dev/pull/37 From omikhaltcova at openjdk.java.net Fri Nov 27 16:57:57 2020 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 27 Nov 2020 16:57:57 GMT Subject: [jdk13u-dev] Integrated: 8235183: Remove the "HACK CODE" in comment In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 16:07:33 GMT, Olga Mikhaltsova wrote: > I'd like to backport JDK-8235183 to jdk13u for parity with jdk11. > There is modification only in comments. > The original patch applied cleanly. This pull request has now been integrated. Changeset: dabaf4e9 Author: Olga Mikhaltsova Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/dabaf4e9 Stats: 13 lines in 3 files changed: 6 ins; 6 del; 1 mod 8235183: Remove the "HACK CODE" in comment Backport-of: 50714b0fb9fd4391385eda3af89582dd3fb5a5f1 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/37 From evergizova at openjdk.java.net Fri Nov 27 19:32:10 2020 From: evergizova at openjdk.java.net (Ekaterina Vergizova) Date: Fri, 27 Nov 2020 19:32:10 GMT Subject: [jdk13u-dev] RFR: 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics Message-ID: I would like to backport 8250627 to 13u for parity with 11u. The patch doesn't apply cleanly since 13u doesn't have cgroups v2 support (JDK-8231111), reapplied manually. Tested with container tests, including new one and tier1. ------------- Commit messages: - Backport e6517d1ae2628f16442e09fd8f48190762517d2e Changes: https://git.openjdk.java.net/jdk13u-dev/pull/38/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=38&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250627 Stats: 173 lines in 7 files changed: 172 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/38.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/38/head:pull/38 PR: https://git.openjdk.java.net/jdk13u-dev/pull/38 From mbalao at redhat.com Sun Nov 29 03:21:20 2020 From: mbalao at redhat.com (Martin Balao) Date: Sun, 29 Nov 2020 00:21:20 -0300 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: <92ed6f9d-9476-795c-eb16-65bce15db1c5@redhat.com> References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> <315008ad-73ae-f77d-5731-854d22083148@redhat.com> <92ed6f9d-9476-795c-eb16-65bce15db1c5@redhat.com> Message-ID: On Thu, Nov 26, 2020 at 6:25 PM Martin Balao wrote: > On 11/26/20 7:18 AM, Andrew Haley wrote: > > > > Have you got a test case for this? > > > > Testing is not trivial but I'm working on something. > Ok, here you have a reproducer that shows the problem I described earlier: http://people.redhat.com/mbalaoal/openjdk/workspace/sunjsse_experimental_fips_support_and_dh_jdk11u/test_experimental_fips_with_dh.jdk11u.v0.patch From aph at redhat.com Mon Nov 30 09:19:09 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 30 Nov 2020 09:19:09 +0000 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> <315008ad-73ae-f77d-5731-854d22083148@redhat.com> <92ed6f9d-9476-795c-eb16-65bce15db1c5@redhat.com> Message-ID: <062fb54a-71b0-5695-14e7-aec475316d04@redhat.com> On 11/29/20 3:21 AM, Martin Balao wrote: > On Thu, Nov 26, 2020 at 6:25 PM Martin Balao wrote: >> On 11/26/20 7:18 AM, Andrew Haley wrote: >>> >>> Have you got a test case for this? >>> >> >> Testing is not trivial but I'm working on something. > > Ok, here you have a reproducer that shows the problem I described > earlier: http://people.redhat.com/mbalaoal/openjdk/workspace/sunjsse_experimental_fips_support_and_dh_jdk11u/test_experimental_fips_with_dh.jdk11u.v0.patch Thanks. Do you think there's enough time to fix the problems with 8171279, or should we just back it out 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 goetz.lindenmaier at sap.com Mon Nov 30 10:06:26 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Nov 2020 10:06:26 +0000 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: <062fb54a-71b0-5695-14e7-aec475316d04@redhat.com> References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> <315008ad-73ae-f77d-5731-854d22083148@redhat.com> <92ed6f9d-9476-795c-eb16-65bce15db1c5@redhat.com> <062fb54a-71b0-5695-14e7-aec475316d04@redhat.com> Message-ID: Hi I have been looking at your test, but it is not yet working on my machine. It skips the test after initializing. Before backing out, we should consider whether not having the new EC curves introduced by 8171279 in 11.0.10 is acceptable. This is an extension that is documented as CSR and might be expected by people. It is in 11.0.10-oracle, too. To me, it seems more relevant than the FIPS feature broken, which never has been an official feature as I understand, and of which it has been communicated (inofficially) that it does not work any more since 9. Nevertheless we should fix it if broken, maybe in 11.0.11. Best regards, Goetz. > -----Original Message----- > From: Andrew Haley > Sent: Monday, November 30, 2020 10:19 AM > To: Martin Balao ; jdk-updates- > dev at openjdk.java.net; Lindenmaier, Goetz > Cc: Severin Gehwolf > Subject: Re: [11u] RFR: 8171279: Support X25519 and X448 in TLS > > On 11/29/20 3:21 AM, Martin Balao wrote: > > On Thu, Nov 26, 2020 at 6:25 PM Martin Balao > wrote: > >> On 11/26/20 7:18 AM, Andrew Haley wrote: > >>> > >>> Have you got a test case for this? > >>> > >> > >> Testing is not trivial but I'm working on something. > > > > Ok, here you have a reproducer that shows the problem I described > > earlier: > http://people.redhat.com/mbalaoal/openjdk/workspace/sunjsse_experimen > tal_fips_support_and_dh_jdk11u/test_experimental_fips_with_dh.jdk11u.v0. > patch > > Thanks. Do you think there's enough time to fix the problems with 8171279, > or should > we just back it out 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 Mon Nov 30 10:40:13 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 30 Nov 2020 10:40:13 +0000 Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" In-Reply-To: References: Message-ID: Hi G?tz and Richard, thanks for backporting it and for the thorough review. > Besides that the patch is good. +1 Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Reingruber, Richard > Sent: Freitag, 27. November 2020 11:43 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi G?tz, > > The following isn't part of the original change. > > - > // post a DYNAMIC_CODE_GENERATED event for a given environment > // used by GenerateEvents > void JvmtiExport::post_dynamic_code_generated(JvmtiEnv* env, const char > *name, > > I've overlooked that, sorry. It's just whitespace. I'll leave it up to you if you > correct it. > > Besides that the patch is good. > > Thanks, Richard. > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 27. November 2020 10:06 > To: Reingruber, Richard ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi Richard, > > Another try: > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > jdk11/06/ > > Best regards, > Goetz > > > > -----Original Message----- > > From: Reingruber, Richard > > Sent: Thursday, November 26, 2020 3:58 PM > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > > 0LL) failed: resolving NULL _value" > > > > Hi G?tz, > > > > > Oops, fixed: > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/05/ > > > > Great. We're almost there now. The original patch has two occurences of > > the following: > > > > + // Requires a lock, because threads can be adding to this queue. > > > > Your patch lacks one and the one you've got has trailing whitespace. > > > > Cheers, Richard. > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Donnerstag, 26. November 2020 10:05 > > To: Reingruber, Richard ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > > 0LL) failed: resolving NULL _value" > > > > Hi Richard, > > > > Oops, fixed: > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/05/ > > > > Best regards, > > Goetz > > > > > -----Original Message----- > > > From: Reingruber, Richard > > > Sent: Tuesday, November 24, 2020 4:35 PM > > > To: Lindenmaier, Goetz ; jdk-updates- > > > dev at openjdk.java.net > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > > "assert(_value != > > > 0LL) failed: resolving NULL _value" > > > > > > Hi G?tz, > > > > > > > This affects the patch of this change, so I made a new webrev. > > > > It also incorporates the comment I missed: > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160- > jvmti_crash_resolving- > > > jdk11/04/ > > > > > > Seems you forgot to remove the commented-out version of > > > JvmtiExport::post_compiled_method_load(JvmtiEnv* env, nmethod > *nm) > > > > > > See http://cr.openjdk.java.net/~goetz/wr20/8212160- > > jvmti_crash_resolving- > > > jdk11/04/src/hotspot/share/prims/jvmtiExport.cpp.udiff.html > > > > > > Cheers, Richard. > > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz > > > Sent: Dienstag, 24. November 2020 08:57 > > > To: Reingruber, Richard ; jdk-updates- > > > dev at openjdk.java.net > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > > "assert(_value != > > > 0LL) failed: resolving NULL _value" > > > > > > Hi Richard, > > > > > > Thanks for reviewing! > > > > > > Yes, you are right, downporting the predecessor makes sense. > > > It is a limited change and a pure fix as I understand. > > > I requested downport and sent a RFR for it: > > > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > > > November/004220.html > > > > > > This affects the patch of this change, so I made a new webrev. > > > It also incorporates the comment I missed: > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > > jdk11/04/ > > > > > > Best regards, > > > Goetz. > > > > > > > -----Original Message----- > > > > From: Reingruber, Richard > > > > Sent: Thursday, November 19, 2020 6:17 PM > > > > To: Lindenmaier, Goetz ; jdk-updates- > > > > dev at openjdk.java.net > > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > > > "assert(_value != > > > > 0LL) failed: resolving NULL _value" > > > > > > > > Hi G?tz, > > > > > > > > --- src/hotspot/share/prims/jvmtiExport.cpp > > > > > > > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* > env, > > > > nmethod *nm) > > > > > from head which is called in > > > > > > > > It would be cleaner to downport the original bugfix but I'm ok with your > > > > solution. > > > > > > > > --- src/hotspot/share/runtime/serviceThread.cpp > > > > > > > > the patch you prepared seems to be missing the change marked with > !!! > > of > > > > the original patch > > > > > > > > @@ -209,7 +219,8 @@ > > > > if (_jvmti_event != NULL) { > > > > _jvmti_event->nmethods_do(cf); > > > > } > > > > + // Requires a lock, because threads can be adding to this queue. > !!! > > > > MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); > > > > - JvmtiDeferredEventQueue::nmethods_do(cf); > > > > + _jvmti_service_queue.nmethods_do(cf); > > > > > > > > This is inadvertently, isn't it? > > > > > > > > The rest is good looking ;) > > > > > > > > Cheers, Richard. > > > > > > > > -----Original Message----- > > > > From: jdk-updates-dev On > > > Behalf > > > > Of Reingruber, Richard > > > > Sent: Mittwoch, 18. November 2020 22:29 > > > > To: Lindenmaier, Goetz ; jdk-updates- > > > > dev at openjdk.java.net > > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > > > "assert(_value != > > > > 0LL) failed: resolving NULL _value" > > > > > > > > Hi G?tz, > > > > > > > > I'm getting ready to review this. > > > > > > > > If I'm not mistaken, your patch has 8173658 as prerequisite which is > > > currently > > > > out for review. It took me a few keystrokes and mouse clicks to figure > > this > > > > out. I'd suggest informing about prerequisite patches in the RFR mail. > > > > > > > > Cheers, Richard. > > > > > > > > -----Original Message----- > > > > From: jdk-updates-dev On > > > Behalf > > > > Of Lindenmaier, Goetz > > > > Sent: Dienstag, 17. November 2020 15:03 > > > > To: jdk-updates-dev at openjdk.java.net > > > > Subject: [CAUTION] RE: [11u] RFR: 8212160: JVMTI agent crashes with > > > > "assert(_value != 0LL) failed: resolving NULL _value" > > > > > > > > Hi, > > > > > > > > I have another update to this change. > > > > I had to resolve it again because of the Minimal VM fix 8235218 pushed > > > > after 8173361. > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160- > jvmti_crash_resolving- > > > > jdk11/03/ > > > > > > > > Also, I reqested downport for Minimal VM fixes required after this > change: > > > > JDK-8236124 Minimal VM slowdebug build failed after JDK-8212160 > > > > JDK-8235456 Minimal VM is broken after JDK-8212160 > > > > These both are clean downports once this is pushed. > > > > > > > > I would appreciate reviews ?? > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > > > > Hi, > > > > > > > > Please look at > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160- > jvmti_crash_resolving- > > > > jdk11/02/ > > > > > > > > I had lost the changes to the test file because of C/C++ mismatch. > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > > > > -----Original Message----- > > > > From: Lindenmaier, Goetz > > > > Sent: Freitag, 6. November 2020 09:39 > > > > To: jdk-updates-dev at openjdk.java.net > > > > Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > > > 0LL) > > > > failed: resolving NULL _value" > > > > > > > > Hi > > > > > > > > I am downporting this for parity with 11.0.10-oracle. > > > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160- > jvmti_crash_resolving- > > > > jdk11/01/ > > > > I had to resolve and fis in quite some places: > > > > > > > > src/hotspot/share/code/nmethod.cpp > > > > Resolved. Few differences in code, e.g. MutexLocker --> > MutexLockerEx. > > > > > > > > Added 'this' to call of > > > JvmtiDeferredEvent::compiled_method_unload_event() > > > > > > > > src/hotspot/share/code/nmethod.hpp > > > > Trivial, resolved. > > > > > > > > src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp > > > > Resolved. Few differences in code, e.g. MutexLocker --> > MutexLockerEx. > > > > > > > > I removed NMethodIterator::only_alive_and_not_unloading and call > > > > next_alive instead. > > > > The NMethodIterator differs in head a lot. > > > > > > > > src/hotspot/share/prims/jvmtiExport.cpp > > > > Resolved. Few differences in code, e.g. MutexLocker --> > MutexLockerEx. > > > > > > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* env, > > > > nmethod *nm) > > > > from head which is called in > > > > > > > > src/hotspot/share/prims/jvmtiExport.hpp > > > > Resolved. Deleted method has different arguments. > > > > > > > > src/hotspot/share/prims/jvmtiImpl.hpp > > > > Resolved. > > > > > > > > src/hotspot/share/runtime/serviceThread.cpp > > > > Context different. > > > > > > > > Please review. > > > > https://bugs.openjdk.java.net/browse/JDK-8212160 > > > > https://hg.openjdk.java.net/jdk/jdk/rev/366c0f357ee6 > > > > > > > > Best regards, > > > > Goetz From goetz.lindenmaier at sap.com Mon Nov 30 10:42:12 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Nov 2020 10:42:12 +0000 Subject: [11u] RFR: 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: References: Message-ID: Hi Richard and Martin, Thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Monday, November 30, 2020 11:36 AM > To: Reingruber, Richard ; Lindenmaier, Goetz > ; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > CompiledMethodLoad events to wrong jvmtiEnv > > Hi G?tz, > > thanks for following Richard's proposal. Looks good to me, too. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Reingruber, Richard > > Sent: Donnerstag, 26. November 2020 15:10 > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > > CompiledMethodLoad events to wrong jvmtiEnv > > > > Thanks G?tz, looks good to me. > > > > Cheers, Richard. > > // Note: for some reason I'm not even listed as author in the JDK-updates > > project > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Donnerstag, 26. November 2020 09:51 > > To: Reingruber, Richard ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > > CompiledMethodLoad events to wrong jvmtiEnv > > > > Hi Richard, > > > > > I'd suggest to replace true/false with JNI_TRUE/JNI_FALSE and change > the > > > type of fail_status to jboolean. > > That makes complete sense. > > http://cr.openjdk.java.net/~goetz/wr20/8222072-wrong_jvmtiEnv- > jdk11/02/ > > > > Best, > > Goetz. > > > > > > > -----Original Message----- > > > From: Reingruber, Richard > > > Sent: Tuesday, November 24, 2020 4:24 PM > > > To: Lindenmaier, Goetz ; jdk-updates- > > > dev at openjdk.java.net > > > Subject: RE: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > > > CompiledMethodLoad events to wrong jvmtiEnv > > > > > > Hi G?tz, > > > > > > > The change applies clean, but I had to convert the test coding > > > > from C++ to C. > > > > > > I'd suggest to replace true/false with JNI_TRUE/JNI_FALSE and change > the > > > type of > > > fail_status to jboolean. > > > > > > Cheers, Richard. > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > Behalf > > > Of Lindenmaier, Goetz > > > Sent: Dienstag, 24. November 2020 08:42 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > > > CompiledMethodLoad events to wrong jvmtiEnv > > > > > > Hi, > > > > > > I would like to downport this fix for jvmti. > > > Some of the coding added here is needed by follow-up > > > 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: > resolving > > > NULL _value" > > > which I downported for 11.0.10-oracle parity. > > > > > > The change applies clean, but I had to convert the test coding > > > from C++ to C. > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8222072-wrong_jvmtiEnv- > > jdk11/01/ > > > > > > Please review. > > > > > > https://bugs.openjdk.java.net/browse/JDK-8222072 > > > http://hg.openjdk.java.net/jdk/jdk/rev/96230a5ef2ec > > > > > > Best regards > > > Goetz. From aph at redhat.com Mon Nov 30 10:45:04 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 30 Nov 2020 10:45:04 +0000 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> <315008ad-73ae-f77d-5731-854d22083148@redhat.com> <92ed6f9d-9476-795c-eb16-65bce15db1c5@redhat.com> <062fb54a-71b0-5695-14e7-aec475316d04@redhat.com> Message-ID: <54f015c4-fb27-6857-8b41-20f357326a9f@redhat.com> On 11/30/20 10:06 AM, Lindenmaier, Goetz wrote: > I have been looking at your test, but it is not yet working > on my machine. It skips the test after initializing. > > Before backing out, we should consider whether > not having the new EC curves introduced by 8171279 > in 11.0.10 is acceptable. This is an extension that is > documented as CSR and might be expected by people. > It is in 11.0.10-oracle, too. I understand, but when a patch breaks something, that patch is at fault. If 8171279 were a critical bug fix I might have a little more sympathy with your argument, but the new EC curves are a feature update. > To me, it seems more relevant than the FIPS feature broken, > which never has been an official feature as I understand, > and of which it has been communicated (inofficially) that it > does not work any more since 9. > > Nevertheless we should fix it if broken, maybe in 11.0.11. Please. There's some basic discipline here: patches shouldn't cause regressions. It's the responsibility of those who make changes to ensure 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 goetz.lindenmaier at sap.com Mon Nov 30 10:56:24 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Nov 2020 10:56:24 +0000 Subject: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value" In-Reply-To: References: Message-ID: Hi Richard and Martin, Thanks for reviewing! I added the deleted empty line again .. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Monday, November 30, 2020 11:40 AM > To: Reingruber, Richard ; Lindenmaier, Goetz > ; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with "assert(_value != > 0LL) failed: resolving NULL _value" > > Hi G?tz and Richard, > > thanks for backporting it and for the thorough review. > > > Besides that the patch is good. > +1 > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Reingruber, Richard > > Sent: Freitag, 27. November 2020 11:43 > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > 0LL) failed: resolving NULL _value" > > > > Hi G?tz, > > > > The following isn't part of the original change. > > > > - > > // post a DYNAMIC_CODE_GENERATED event for a given environment > > // used by GenerateEvents > > void JvmtiExport::post_dynamic_code_generated(JvmtiEnv* env, const > char > > *name, > > > > I've overlooked that, sorry. It's just whitespace. I'll leave it up to you if you > > correct it. > > > > Besides that the patch is good. > > > > Thanks, Richard. > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Freitag, 27. November 2020 10:06 > > To: Reingruber, Richard ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > 0LL) failed: resolving NULL _value" > > > > Hi Richard, > > > > Another try: > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > jdk11/06/ > > > > Best regards, > > Goetz > > > > > > > -----Original Message----- > > > From: Reingruber, Richard > > > Sent: Thursday, November 26, 2020 3:58 PM > > > To: Lindenmaier, Goetz ; jdk-updates- > > > dev at openjdk.java.net > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > > 0LL) failed: resolving NULL _value" > > > > > > Hi G?tz, > > > > > > > Oops, fixed: > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160- > jvmti_crash_resolving- > > > jdk11/05/ > > > > > > Great. We're almost there now. The original patch has two occurences of > > > the following: > > > > > > + // Requires a lock, because threads can be adding to this queue. > > > > > > Your patch lacks one and the one you've got has trailing whitespace. > > > > > > Cheers, Richard. > > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz > > > Sent: Donnerstag, 26. November 2020 10:05 > > > To: Reingruber, Richard ; jdk-updates- > > > dev at openjdk.java.net > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > > 0LL) failed: resolving NULL _value" > > > > > > Hi Richard, > > > > > > Oops, fixed: > > > http://cr.openjdk.java.net/~goetz/wr20/8212160-jvmti_crash_resolving- > > > jdk11/05/ > > > > > > Best regards, > > > Goetz > > > > > > > -----Original Message----- > > > > From: Reingruber, Richard > > > > Sent: Tuesday, November 24, 2020 4:35 PM > > > > To: Lindenmaier, Goetz ; jdk-updates- > > > > dev at openjdk.java.net > > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > > > "assert(_value != > > > > 0LL) failed: resolving NULL _value" > > > > > > > > Hi G?tz, > > > > > > > > > This affects the patch of this change, so I made a new webrev. > > > > > It also incorporates the comment I missed: > > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160- > > jvmti_crash_resolving- > > > > jdk11/04/ > > > > > > > > Seems you forgot to remove the commented-out version of > > > > JvmtiExport::post_compiled_method_load(JvmtiEnv* env, nmethod > > *nm) > > > > > > > > See http://cr.openjdk.java.net/~goetz/wr20/8212160- > > > jvmti_crash_resolving- > > > > jdk11/04/src/hotspot/share/prims/jvmtiExport.cpp.udiff.html > > > > > > > > Cheers, Richard. > > > > > > > > -----Original Message----- > > > > From: Lindenmaier, Goetz > > > > Sent: Dienstag, 24. November 2020 08:57 > > > > To: Reingruber, Richard ; jdk-updates- > > > > dev at openjdk.java.net > > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > > > "assert(_value != > > > > 0LL) failed: resolving NULL _value" > > > > > > > > Hi Richard, > > > > > > > > Thanks for reviewing! > > > > > > > > Yes, you are right, downporting the predecessor makes sense. > > > > It is a limited change and a pure fix as I understand. > > > > I requested downport and sent a RFR for it: > > > > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > > > > November/004220.html > > > > > > > > This affects the patch of this change, so I made a new webrev. > > > > It also incorporates the comment I missed: > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160- > jvmti_crash_resolving- > > > > jdk11/04/ > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > -----Original Message----- > > > > > From: Reingruber, Richard > > > > > Sent: Thursday, November 19, 2020 6:17 PM > > > > > To: Lindenmaier, Goetz ; jdk-updates- > > > > > dev at openjdk.java.net > > > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > > > > "assert(_value != > > > > > 0LL) failed: resolving NULL _value" > > > > > > > > > > Hi G?tz, > > > > > > > > > > --- src/hotspot/share/prims/jvmtiExport.cpp > > > > > > > > > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* > > env, > > > > > nmethod *nm) > > > > > > from head which is called in > > > > > > > > > > It would be cleaner to downport the original bugfix but I'm ok with > your > > > > > solution. > > > > > > > > > > --- src/hotspot/share/runtime/serviceThread.cpp > > > > > > > > > > the patch you prepared seems to be missing the change marked with > > !!! > > > of > > > > > the original patch > > > > > > > > > > @@ -209,7 +219,8 @@ > > > > > if (_jvmti_event != NULL) { > > > > > _jvmti_event->nmethods_do(cf); > > > > > } > > > > > + // Requires a lock, because threads can be adding to this queue. > > !!! > > > > > MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); > > > > > - JvmtiDeferredEventQueue::nmethods_do(cf); > > > > > + _jvmti_service_queue.nmethods_do(cf); > > > > > > > > > > This is inadvertently, isn't it? > > > > > > > > > > The rest is good looking ;) > > > > > > > > > > Cheers, Richard. > > > > > > > > > > -----Original Message----- > > > > > From: jdk-updates-dev On > > > > Behalf > > > > > Of Reingruber, Richard > > > > > Sent: Mittwoch, 18. November 2020 22:29 > > > > > To: Lindenmaier, Goetz ; jdk-updates- > > > > > dev at openjdk.java.net > > > > > Subject: RE: [11u] RFR: 8212160: JVMTI agent crashes with > > > > "assert(_value != > > > > > 0LL) failed: resolving NULL _value" > > > > > > > > > > Hi G?tz, > > > > > > > > > > I'm getting ready to review this. > > > > > > > > > > If I'm not mistaken, your patch has 8173658 as prerequisite which is > > > > currently > > > > > out for review. It took me a few keystrokes and mouse clicks to figure > > > this > > > > > out. I'd suggest informing about prerequisite patches in the RFR mail. > > > > > > > > > > Cheers, Richard. > > > > > > > > > > -----Original Message----- > > > > > From: jdk-updates-dev On > > > > Behalf > > > > > Of Lindenmaier, Goetz > > > > > Sent: Dienstag, 17. November 2020 15:03 > > > > > To: jdk-updates-dev at openjdk.java.net > > > > > Subject: [CAUTION] RE: [11u] RFR: 8212160: JVMTI agent crashes > with > > > > > "assert(_value != 0LL) failed: resolving NULL _value" > > > > > > > > > > Hi, > > > > > > > > > > I have another update to this change. > > > > > I had to resolve it again because of the Minimal VM fix 8235218 > pushed > > > > > after 8173361. > > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160- > > jvmti_crash_resolving- > > > > > jdk11/03/ > > > > > > > > > > Also, I reqested downport for Minimal VM fixes required after this > > change: > > > > > JDK-8236124 Minimal VM slowdebug build failed after JDK-8212160 > > > > > JDK-8235456 Minimal VM is broken after JDK-8212160 > > > > > These both are clean downports once this is pushed. > > > > > > > > > > I would appreciate reviews ?? > > > > > > > > > > Best regards, > > > > > Goetz. > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Please look at > > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160- > > jvmti_crash_resolving- > > > > > jdk11/02/ > > > > > > > > > > I had lost the changes to the test file because of C/C++ mismatch. > > > > > > > > > > Best regards, > > > > > Goetz. > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Lindenmaier, Goetz > > > > > Sent: Freitag, 6. November 2020 09:39 > > > > > To: jdk-updates-dev at openjdk.java.net > > > > > Subject: [11u] RFR: 8212160: JVMTI agent crashes with > "assert(_value != > > > > 0LL) > > > > > failed: resolving NULL _value" > > > > > > > > > > Hi > > > > > > > > > > I am downporting this for parity with 11.0.10-oracle. > > > > > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8212160- > > jvmti_crash_resolving- > > > > > jdk11/01/ > > > > > I had to resolve and fis in quite some places: > > > > > > > > > > src/hotspot/share/code/nmethod.cpp > > > > > Resolved. Few differences in code, e.g. MutexLocker --> > > MutexLockerEx. > > > > > > > > > > Added 'this' to call of > > > > JvmtiDeferredEvent::compiled_method_unload_event() > > > > > > > > > > src/hotspot/share/code/nmethod.hpp > > > > > Trivial, resolved. > > > > > > > > > > src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp > > > > > Resolved. Few differences in code, e.g. MutexLocker --> > > MutexLockerEx. > > > > > > > > > > I removed NMethodIterator::only_alive_and_not_unloading and call > > > > > next_alive instead. > > > > > The NMethodIterator differs in head a lot. > > > > > > > > > > src/hotspot/share/prims/jvmtiExport.cpp > > > > > Resolved. Few differences in code, e.g. MutexLocker --> > > MutexLockerEx. > > > > > > > > > > I added void JvmtiExport::post_compiled_method_load(JvmtiEnv* > env, > > > > > nmethod *nm) > > > > > from head which is called in > > > > > > > > > > src/hotspot/share/prims/jvmtiExport.hpp > > > > > Resolved. Deleted method has different arguments. > > > > > > > > > > src/hotspot/share/prims/jvmtiImpl.hpp > > > > > Resolved. > > > > > > > > > > src/hotspot/share/runtime/serviceThread.cpp > > > > > Context different. > > > > > > > > > > Please review. > > > > > https://bugs.openjdk.java.net/browse/JDK-8212160 > > > > > https://hg.openjdk.java.net/jdk/jdk/rev/366c0f357ee6 > > > > > > > > > > Best regards, > > > > > Goetz From goetz.lindenmaier at sap.com Mon Nov 30 10:58:32 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Nov 2020 10:58:32 +0000 Subject: [11u] RFR: 8235829: graal crashes with Zombie.java test In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Monday, November 23, 2020 2:03 PM > To: Lindenmaier, Goetz ; jdk-updates-dev > > Subject: RE: [11u] RFR: 8235829: graal crashes with Zombie.java test > > Hi G?tz, > > right, the nmethod barriers for concurrent class unloading with zGC and > Shenandoah are not needed in 11u. > Looks good to me. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Freitag, 20. November 2020 14:59 > > To: jdk-updates-dev > > Subject: [11u] RFR: 8235829: graal crashes with Zombie.java test > > > > Hi, > > > > I am downporting this for parity with 11.0.10-oracle. > > > > http://cr.openjdk.java.net/~goetz/wr20/8235823-graal_zombie_crash- > > jdk11/01/ > > > > The original change adds a lot of BarrierSetNMethod barriers. > > This barrier type does not exist in 11. It is not needed as no > > concurrent class unloading is implemented in 11. That was added upstream > > for ZGC and Shenandoah. > > I omitted this coding. > > > > https://bugs.openjdk.java.net/browse/JDK-8235829 > > https://hg.openjdk.java.net/jdk/jdk14/rev/26bb0fe2270a > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Mon Nov 30 11:30:32 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Nov 2020 11:30:32 +0000 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: <54f015c4-fb27-6857-8b41-20f357326a9f@redhat.com> References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> <315008ad-73ae-f77d-5731-854d22083148@redhat.com> <92ed6f9d-9476-795c-eb16-65bce15db1c5@redhat.com> <062fb54a-71b0-5695-14e7-aec475316d04@redhat.com> <54f015c4-fb27-6857-8b41-20f357326a9f@redhat.com> Message-ID: > I understand, but when a patch breaks something, that patch is at fault. > If 8171279 were a critical bug fix I might have a little more sympathy > with your argument, but the new EC curves are a feature update. TLS is a security feature, and thus I think the change is not only a nice-to-have. TLS is quite prominent currently in our customer messages. The FIPS feature is unsupported, and as I understand you can and shall select FIPS certified security by other means. So I'm not sure whether we should take this lightly. Unfortunately, I do not know about the importance of these two new curves. I will roll back the change if necessary. Best regards, Goetz. > -----Original Message----- > From: Andrew Haley > Sent: Monday, November 30, 2020 11:45 AM > To: Lindenmaier, Goetz ; Martin Balao > ; jdk-updates-dev at openjdk.java.net > Cc: Severin Gehwolf > Subject: Re: [11u] RFR: 8171279: Support X25519 and X448 in TLS > > On 11/30/20 10:06 AM, Lindenmaier, Goetz wrote: > > I have been looking at your test, but it is not yet working > > on my machine. It skips the test after initializing. > > > > Before backing out, we should consider whether > > not having the new EC curves introduced by 8171279 > > in 11.0.10 is acceptable. This is an extension that is > > documented as CSR and might be expected by people. > > It is in 11.0.10-oracle, too. > > I understand, but when a patch breaks something, that patch is at fault. > If 8171279 were a critical bug fix I might have a little more sympathy > with your argument, but the new EC curves are a feature update. > > > To me, it seems more relevant than the FIPS feature broken, > > which never has been an official feature as I understand, > > and of which it has been communicated (inofficially) that it > > does not work any more since 9. > > > > Nevertheless we should fix it if broken, maybe in 11.0.11. > > Please. > > There's some basic discipline here: patches shouldn't cause > regressions. It's the responsibility of those who make changes > to ensure 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 goetz.lindenmaier at sap.com Mon Nov 30 11:36:35 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Nov 2020 11:36:35 +0000 Subject: [11u] RFR: 8257408: Bump update version for OpenJDK: jdk-11.0.11 Message-ID: Hi, to start development of jdk-11.0.11, we need to bump the version: http://cr.openjdk.java.net/~goetz/wr20/8257408-version_11.0.11-jdk11/01/ Please review. Naturally, I will only push this after dev close of 11.0.10, and after JBS was updated to tag for 11.0.11. For the date, see also https://www.oracle.com/security-alerts/ Thanks, Goetz. From aph at redhat.com Mon Nov 30 12:29:39 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 30 Nov 2020 12:29:39 +0000 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> <315008ad-73ae-f77d-5731-854d22083148@redhat.com> <92ed6f9d-9476-795c-eb16-65bce15db1c5@redhat.com> <062fb54a-71b0-5695-14e7-aec475316d04@redhat.com> <54f015c4-fb27-6857-8b41-20f357326a9f@redhat.com> Message-ID: <2d6d8871-6d02-d7a6-4406-41b0d4d7938d@redhat.com> On 11/30/20 11:30 AM, Lindenmaier, Goetz wrote: > > The FIPS feature is unsupported, and as I understand > you can and shall select FIPS certified security by other means. > So I'm not sure whether we should take this lightly. I see. Here's my thinking: This is an LTS release. People who use it don't expect (and certainly don't desire) their deployed applications to be broken by a minor update. Every now and then we will break some applications, but only when there is some critical bug that we must fix. We do not know what our customers use, so the rule is "First, do no harm." If we are going to break this now, we must reach a consensus position either that there's no alternative or that FIPS mode cannot be suported. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Mon Nov 30 12:39:10 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 30 Nov 2020 13:39:10 +0100 Subject: [11u] RFR: JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 too Message-ID: Hi, may I have reviews please for the following backport: Original issue: https://bugs.openjdk.java.net/browse/JDK-8255734 Original patch: https://github.com/openjdk/jdk/commit/54c88132.diff Modified patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8255734-VM-should-ignore-SIGXFSZ-on-ppc64-s390-too.diff Patch is trivial and nothing changed, but did not apply correctly since "8252324: Signal related code should be shared among POSIX platforms" shuffled a lot of coding around. Thanks, Thomas From martin.doerr at sap.com Mon Nov 30 10:35:51 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 30 Nov 2020 10:35:51 +0000 Subject: [11u] RFR: 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: References: Message-ID: Hi G?tz, thanks for following Richard's proposal. Looks good to me, too. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Reingruber, Richard > Sent: Donnerstag, 26. November 2020 15:10 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > CompiledMethodLoad events to wrong jvmtiEnv > > Thanks G?tz, looks good to me. > > Cheers, Richard. > // Note: for some reason I'm not even listed as author in the JDK-updates > project > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 26. November 2020 09:51 > To: Reingruber, Richard ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > CompiledMethodLoad events to wrong jvmtiEnv > > Hi Richard, > > > I'd suggest to replace true/false with JNI_TRUE/JNI_FALSE and change the > > type of fail_status to jboolean. > That makes complete sense. > http://cr.openjdk.java.net/~goetz/wr20/8222072-wrong_jvmtiEnv-jdk11/02/ > > Best, > Goetz. > > > > -----Original Message----- > > From: Reingruber, Richard > > Sent: Tuesday, November 24, 2020 4:24 PM > > To: Lindenmaier, Goetz ; jdk-updates- > > dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > > CompiledMethodLoad events to wrong jvmtiEnv > > > > Hi G?tz, > > > > > The change applies clean, but I had to convert the test coding > > > from C++ to C. > > > > I'd suggest to replace true/false with JNI_TRUE/JNI_FALSE and change the > > type of > > fail_status to jboolean. > > > > Cheers, Richard. > > > > -----Original Message----- > > From: jdk-updates-dev On > Behalf > > Of Lindenmaier, Goetz > > Sent: Dienstag, 24. November 2020 08:42 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8222072: JVMTI GenerateEvents() sends > > CompiledMethodLoad events to wrong jvmtiEnv > > > > Hi, > > > > I would like to downport this fix for jvmti. > > Some of the coding added here is needed by follow-up > > 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving > > NULL _value" > > which I downported for 11.0.10-oracle parity. > > > > The change applies clean, but I had to convert the test coding > > from C++ to C. > > > > http://cr.openjdk.java.net/~goetz/wr20/8222072-wrong_jvmtiEnv- > jdk11/01/ > > > > Please review. > > > > https://bugs.openjdk.java.net/browse/JDK-8222072 > > http://hg.openjdk.java.net/jdk/jdk/rev/96230a5ef2ec > > > > Best regards > > Goetz. From thomas.stuefe at gmail.com Mon Nov 30 13:26:38 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 30 Nov 2020 14:26:38 +0100 Subject: [11u] RFR: JDK-8251255: [linux] Add process-memory information to hs-err and VM.info Message-ID: Hi, may I have reviews for this small backport please. Its goal is to add some beneficial information to the hs-err file (process virtual size and resident set size). The original patch applies unmodified, but only with --fuzz=3, since the surroundings changed too much. Original issue: https://bugs.openjdk.java.net/browse/JDK-8251255 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a6bd3cd0c3a2 Modified patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8251255-linux-add-process-memory-info-to-hserr-modified-for-11.patch Thanks, Thomas From rob.mckenna at oracle.com Mon Nov 30 13:33:42 2020 From: rob.mckenna at oracle.com (Robert McKenna) Date: Mon, 30 Nov 2020 13:33:42 +0000 Subject: [15u] MonitorInfo bugs: JDK-8249192 and JDK-8251118 In-Reply-To: <5413f266-4010-10ba-d58f-cd592c2f1346@redhat.com> References: <5413f266-4010-10ba-d58f-cd592c2f1346@redhat.com> Message-ID: <570b3cf4-91a9-87d1-1a5a-72cf8c3d475b@oracle.com> Thomas, I don't see any obvious reason why this was not pushed to the OpenJDK repo. Can you rectify this as soon as you get the chance. Aleksey, apologies for missing this, and thanks for the heads up. In future please include the responsible engineer for the bug in the mail (cc'ing the alias and me) ??? -Rob On 25/11/2020 08:34, Aleksey Shipilev wrote: > Rob, > > On 11/18/20 2:17 PM, Aleksey Shipilev wrote: >> On 11/11/20 11:00 AM, Aleksey Shipilev wrote: >>> Hi again, >>> >>> I asked this question in the relevant RFR threads, but they >>> apparently went unnoticed. Therefore, >>> let me ask this in a new thread. >>> >>> This is about the following issues: >>> ???? 8249192: MonitorInfo stores raw oops across safepoints >>> ???? 8251118: BiasedLocking::preserve_marks should not have a HandleMar >>> >>> At the time 15.0.1 was open for pushes, it had been stated that both >>> issues were pushed to some CPU >>> repo. I was under impression it was to appear in 15.0.1 release, but >>> it did not. So, there are no >>> changes in current 15u: >>> https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8249192 >>> https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251118 >>> >>> There is still the "Resolved" backport in 15.0.2 for one of the issues: >>> ????? https://bugs.openjdk.java.net/browse/JDK-8251485 >>> >>> ...and there is no resolved backport for another. >>> >>> So, is there a private 15.0.2 CPU repo within Oracle? Are we >>> expecting both issues to come with >>> 15.0.2 CPU push? Even in this case, can we push the change to open >>> 15.0.2, so we would be able to >>> test it in open repositories before next CPU hits? >> >> Friendly reminder. > > Another friendly reminder. > From rob.mckenna at oracle.com Mon Nov 30 13:35:37 2020 From: rob.mckenna at oracle.com (Robert McKenna) Date: Mon, 30 Nov 2020 13:35:37 +0000 Subject: [15u] MonitorInfo bugs: JDK-8249192 and JDK-8251118 In-Reply-To: <570b3cf4-91a9-87d1-1a5a-72cf8c3d475b@oracle.com> References: <5413f266-4010-10ba-d58f-cd592c2f1346@redhat.com> <570b3cf4-91a9-87d1-1a5a-72cf8c3d475b@oracle.com> Message-ID: <04ac4046-a8c4-0a79-407b-cdbdbb845446@oracle.com> W.r.t. 8251118 - I don't see a record of a 15u push after you requested fix approval. ??? -Rob On 30/11/2020 13:33, Robert McKenna wrote: > Thomas, I don't see any obvious reason why this was not pushed to the > OpenJDK repo. Can you rectify this as soon as you get the chance. > > Aleksey, apologies for missing this, and thanks for the heads up. In > future please include the responsible engineer for the bug in the mail > (cc'ing the alias and me) > > ??? -Rob > > On 25/11/2020 08:34, Aleksey Shipilev wrote: >> Rob, >> >> On 11/18/20 2:17 PM, Aleksey Shipilev wrote: >>> On 11/11/20 11:00 AM, Aleksey Shipilev wrote: >>>> Hi again, >>>> >>>> I asked this question in the relevant RFR threads, but they >>>> apparently went unnoticed. Therefore, >>>> let me ask this in a new thread. >>>> >>>> This is about the following issues: >>>> ???? 8249192: MonitorInfo stores raw oops across safepoints >>>> ???? 8251118: BiasedLocking::preserve_marks should not have a >>>> HandleMar >>>> >>>> At the time 15.0.1 was open for pushes, it had been stated that >>>> both issues were pushed to some CPU >>>> repo. I was under impression it was to appear in 15.0.1 release, >>>> but it did not. So, there are no >>>> changes in current 15u: >>>> https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8249192 >>>> https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251118 >>>> >>>> There is still the "Resolved" backport in 15.0.2 for one of the >>>> issues: >>>> ????? https://bugs.openjdk.java.net/browse/JDK-8251485 >>>> >>>> ...and there is no resolved backport for another. >>>> >>>> So, is there a private 15.0.2 CPU repo within Oracle? Are we >>>> expecting both issues to come with >>>> 15.0.2 CPU push? Even in this case, can we push the change to open >>>> 15.0.2, so we would be able to >>>> test it in open repositories before next CPU hits? >>> >>> Friendly reminder. >> >> Another friendly reminder. >> > From martin.doerr at sap.com Mon Nov 30 14:20:53 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 30 Nov 2020 14:20:53 +0000 Subject: [11u] RFR: JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 too In-Reply-To: References: Message-ID: Hi Thomas, backport looks good. Thanks for doing it. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Thomas St?fe > Sent: Montag, 30. November 2020 13:39 > To: HotSpot Open Source Developers ; > jdk-updates-dev > Subject: [11u] RFR: JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 > too > > Hi, > > may I have reviews please for the following backport: > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8255734 > Original patch: https://github.com/openjdk/jdk/commit/54c88132.diff > Modified patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8255734-VM- > should-ignore-SIGXFSZ-on-ppc64-s390-too.diff > > Patch is trivial and nothing changed, but did not apply correctly since > "8252324: Signal related code should be shared among POSIX platforms" > shuffled a lot of coding around. > > Thanks, Thomas From martin.doerr at sap.com Mon Nov 30 14:23:48 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 30 Nov 2020 14:23:48 +0000 Subject: [11u] RFR: JDK-8251255: [linux] Add process-memory information to hs-err and VM.info In-Reply-To: References: Message-ID: Hi Thomas, looks good. Thanks, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Thomas St?fe > Sent: Montag, 30. November 2020 14:27 > To: jdk-updates-dev ; Hotspot dev > runtime > Subject: [11u] RFR: JDK-8251255: [linux] Add process-memory information to > hs-err and VM.info > > Hi, > > may I have reviews for this small backport please. Its goal is to add some > beneficial information to the hs-err file (process virtual size and > resident set size). > > The original patch applies unmodified, but only with --fuzz=3, since the > surroundings changed too much. > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8251255 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a6bd3cd0c3a2 > Modified patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8251255-linux-add- > process-memory-info-to-hserr-modified-for-11.patch > > Thanks, Thomas From mbalao at redhat.com Mon Nov 30 14:43:10 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 30 Nov 2020 11:43:10 -0300 Subject: [11u] RFR: 8171279: Support X25519 and X448 in TLS In-Reply-To: References: <8f0f5ce9-abc9-1466-1ac0-8403c4d72277@redhat.com> <7a010205-9331-166e-d83a-c0d8b3704065@redhat.com> <315008ad-73ae-f77d-5731-854d22083148@redhat.com> <92ed6f9d-9476-795c-eb16-65bce15db1c5@redhat.com> <062fb54a-71b0-5695-14e7-aec475316d04@redhat.com> Message-ID: Hi Goetz, Thanks for having a look at this. On 11/30/20 7:06 AM, Lindenmaier, Goetz wrote: > > I have been looking at your test, but it is not yet working > on my machine. It skips the test after initializing. > Yes, NSS tests require some help from the environment so they might be skipped. A Linux-based environment with the NSS library located in the (major distros) standard path should make it. Let me know if I can help with that. > Before backing out, we should consider whether > not having the new EC curves introduced by 8171279 > in 11.0.10 is acceptable. This is an extension that is > documented as CSR and might be expected by people. > It is in 11.0.10-oracle, too. > I should be able to come up with a fix later today. The fix looks straight forward -it's essentially replacing KeyAgreement::getInstance calls with the previous calls-, but I want to make sure that everything else is fine. > To me, it seems more relevant than the FIPS feature broken, > which never has been an official feature as I understand, > and of which it has been communicated (inofficially) that it > does not work any more since 9. FIPS support in SunJSSE works up to 13, and our users rely on that. The comment about stopping to work in 9 is wrong -I'll try to have it fixed, as it has caused enough confusion-. There is a public API to initialize FIPS in SunJSSE, which is through the java.security configuration file (when you pass an argument to the SunJSSE security provider line). Thanks, Martin.- From harold.seigel at oracle.com Mon Nov 30 15:02:35 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 30 Nov 2020 10:02:35 -0500 Subject: [15u] MonitorInfo bugs: JDK-8249192 and JDK-8251118 In-Reply-To: <04ac4046-a8c4-0a79-407b-cdbdbb845446@oracle.com> References: <5413f266-4010-10ba-d58f-cd592c2f1346@redhat.com> <570b3cf4-91a9-87d1-1a5a-72cf8c3d475b@oracle.com> <04ac4046-a8c4-0a79-407b-cdbdbb845446@oracle.com> Message-ID: <51947dc9-1636-cbea-acb5-0ebd48185f9d@oracle.com> Hi Aleksey, The 15u backports for 8249192 and 8251118 were pushed (by me) to the wrong repo but will be included in the JDK 15.0.2 release. Harold On 11/30/2020 8:35 AM, Robert McKenna wrote: > W.r.t. 8251118 - I don't see a record of a 15u push after you > requested fix approval. > > ??? -Rob > > On 30/11/2020 13:33, Robert McKenna wrote: >> Thomas, I don't see any obvious reason why this was not pushed to the >> OpenJDK repo. Can you rectify this as soon as you get the chance. >> >> Aleksey, apologies for missing this, and thanks for the heads up. In >> future please include the responsible engineer for the bug in the >> mail (cc'ing the alias and me) >> >> ??? -Rob >> >> On 25/11/2020 08:34, Aleksey Shipilev wrote: >>> Rob, >>> >>> On 11/18/20 2:17 PM, Aleksey Shipilev wrote: >>>> On 11/11/20 11:00 AM, Aleksey Shipilev wrote: >>>>> Hi again, >>>>> >>>>> I asked this question in the relevant RFR threads, but they >>>>> apparently went unnoticed. Therefore, >>>>> let me ask this in a new thread. >>>>> >>>>> This is about the following issues: >>>>> ???? 8249192: MonitorInfo stores raw oops across safepoints >>>>> ???? 8251118: BiasedLocking::preserve_marks should not have a >>>>> HandleMar >>>>> >>>>> At the time 15.0.1 was open for pushes, it had been stated that >>>>> both issues were pushed to some CPU >>>>> repo. I was under impression it was to appear in 15.0.1 release, >>>>> but it did not. So, there are no >>>>> changes in current 15u: >>>>> https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8249192 >>>>> https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251118 >>>>> >>>>> There is still the "Resolved" backport in 15.0.2 for one of the >>>>> issues: >>>>> ????? https://bugs.openjdk.java.net/browse/JDK-8251485 >>>>> >>>>> ...and there is no resolved backport for another. >>>>> >>>>> So, is there a private 15.0.2 CPU repo within Oracle? Are we >>>>> expecting both issues to come with >>>>> 15.0.2 CPU push? Even in this case, can we push the change to open >>>>> 15.0.2, so we would be able to >>>>> test it in open repositories before next CPU hits? >>>> >>>> Friendly reminder. >>> >>> Another friendly reminder. >>> >> > From yan at openjdk.java.net Mon Nov 30 15:05:12 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 30 Nov 2020 15:05:12 GMT Subject: [jdk13u-dev] Integrated: 8233958: Memory retention due to HttpsURLConnection finalizer that serves no purpose Message-ID: Should be downported here, too. The patch applies clean. Tier[123] tests pass. ------------- Commit messages: - Backport 9f91b8dde2be4fbcebdde938c4ef017921c5c203 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/39/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=39&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233958 Stats: 19 lines in 2 files changed: 0 ins; 19 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/39.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/39/head:pull/39 PR: https://git.openjdk.java.net/jdk13u-dev/pull/39 From yan at openjdk.java.net Mon Nov 30 15:05:13 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Mon, 30 Nov 2020 15:05:13 GMT Subject: [jdk13u-dev] Integrated: 8233958: Memory retention due to HttpsURLConnection finalizer that serves no purpose In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 14:57:13 GMT, Yuri Nesterenko wrote: > Should be downported here, too. The patch applies clean. Tier[123] tests pass. This pull request has now been integrated. Changeset: 74991c9b Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/74991c9b Stats: 19 lines in 2 files changed: 0 ins; 19 del; 0 mod 8233958: Memory retention due to HttpsURLConnection finalizer that serves no purpose Backport-of: 9f91b8dde2be4fbcebdde938c4ef017921c5c203 ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/39 From harold.seigel at oracle.com Mon Nov 30 15:37:14 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 30 Nov 2020 10:37:14 -0500 Subject: [15u] MonitorInfo bugs: JDK-8249192 and JDK-8251118 In-Reply-To: <51947dc9-1636-cbea-acb5-0ebd48185f9d@oracle.com> References: <5413f266-4010-10ba-d58f-cd592c2f1346@redhat.com> <570b3cf4-91a9-87d1-1a5a-72cf8c3d475b@oracle.com> <04ac4046-a8c4-0a79-407b-cdbdbb845446@oracle.com> <51947dc9-1636-cbea-acb5-0ebd48185f9d@oracle.com> Message-ID: <28a72a80-ce9c-635a-2a09-9fcc2b363658@oracle.com> Hi Aleksey, The fix for JDK-825118, in JDK-16, was to remove the HandleMark from biasedLocking.cpp that was added as part of the JDK-16 fix for JDK-8249192.? But, my original 15u backport for JDK-8249192 did not contain the new HandleMark in biasedLocking.cpp.? So, there was no reason to backport 825118 because there was no HandleMark to remove. I plan to push these changes into the OpenJDK-15u repo in the next few days.? Sorry for all the confusion. Harold On 11/30/2020 10:02 AM, Harold Seigel wrote: > Hi Aleksey, > > The 15u backports for 8249192 and 8251118 were pushed (by me) to the > wrong repo but will be included in the JDK 15.0.2 release. > > Harold > > On 11/30/2020 8:35 AM, Robert McKenna wrote: >> W.r.t. 8251118 - I don't see a record of a 15u push after you >> requested fix approval. >> >> ??? -Rob >> >> On 30/11/2020 13:33, Robert McKenna wrote: >>> Thomas, I don't see any obvious reason why this was not pushed to >>> the OpenJDK repo. Can you rectify this as soon as you get the chance. >>> >>> Aleksey, apologies for missing this, and thanks for the heads up. In >>> future please include the responsible engineer for the bug in the >>> mail (cc'ing the alias and me) >>> >>> ??? -Rob >>> >>> On 25/11/2020 08:34, Aleksey Shipilev wrote: >>>> Rob, >>>> >>>> On 11/18/20 2:17 PM, Aleksey Shipilev wrote: >>>>> On 11/11/20 11:00 AM, Aleksey Shipilev wrote: >>>>>> Hi again, >>>>>> >>>>>> I asked this question in the relevant RFR threads, but they >>>>>> apparently went unnoticed. Therefore, >>>>>> let me ask this in a new thread. >>>>>> >>>>>> This is about the following issues: >>>>>> ???? 8249192: MonitorInfo stores raw oops across safepoints >>>>>> ???? 8251118: BiasedLocking::preserve_marks should not have a >>>>>> HandleMar >>>>>> >>>>>> At the time 15.0.1 was open for pushes, it had been stated that >>>>>> both issues were pushed to some CPU >>>>>> repo. I was under impression it was to appear in 15.0.1 release, >>>>>> but it did not. So, there are no >>>>>> changes in current 15u: >>>>>> https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8249192 >>>>>> https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251118 >>>>>> >>>>>> There is still the "Resolved" backport in 15.0.2 for one of the >>>>>> issues: >>>>>> ????? https://bugs.openjdk.java.net/browse/JDK-8251485 >>>>>> >>>>>> ...and there is no resolved backport for another. >>>>>> >>>>>> So, is there a private 15.0.2 CPU repo within Oracle? Are we >>>>>> expecting both issues to come with >>>>>> 15.0.2 CPU push? Even in this case, can we push the change to >>>>>> open 15.0.2, so we would be able to >>>>>> test it in open repositories before next CPU hits? >>>>> >>>>> Friendly reminder. >>>> >>>> Another friendly reminder. >>>> >>> >> From thomas.stuefe at gmail.com Mon Nov 30 16:29:27 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 30 Nov 2020 17:29:27 +0100 Subject: [11u] RFR: JDK-8251255: [linux] Add process-memory information to hs-err and VM.info In-Reply-To: References: Message-ID: Thanks, Martin. On Mon, Nov 30, 2020 at 3:23 PM Doerr, Martin wrote: > Hi Thomas, > > looks good. > > Thanks, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Thomas St?fe > > Sent: Montag, 30. November 2020 14:27 > > To: jdk-updates-dev ; Hotspot dev > > runtime > > Subject: [11u] RFR: JDK-8251255: [linux] Add process-memory information > to > > hs-err and VM.info > > > > Hi, > > > > may I have reviews for this small backport please. Its goal is to add > some > > beneficial information to the hs-err file (process virtual size and > > resident set size). > > > > The original patch applies unmodified, but only with --fuzz=3, since the > > surroundings changed too much. > > > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8251255 > > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a6bd3cd0c3a2 > > Modified patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8251255-linux-add- > > process-memory-info-to-hserr-modified-for-11.patch > > > > Thanks, Thomas > From thomas.stuefe at gmail.com Mon Nov 30 16:29:39 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 30 Nov 2020 17:29:39 +0100 Subject: [11u] RFR: JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 too In-Reply-To: References: Message-ID: Thanks, Martin. On Mon, Nov 30, 2020 at 3:20 PM Doerr, Martin wrote: > Hi Thomas, > > backport looks good. Thanks for doing it. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Thomas St?fe > > Sent: Montag, 30. November 2020 13:39 > > To: HotSpot Open Source Developers ; > > jdk-updates-dev > > Subject: [11u] RFR: JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 > > too > > > > Hi, > > > > may I have reviews please for the following backport: > > > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8255734 > > Original patch: https://github.com/openjdk/jdk/commit/54c88132.diff > > Modified patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8255734-VM- > > should-ignore-SIGXFSZ-on-ppc64-s390-too.diff > > > > Patch is trivial and nothing changed, but did not apply correctly since > > "8252324: Signal related code should be shared among POSIX platforms" > > shuffled a lot of coding around. > > > > Thanks, Thomas >